Re: Full install/removal/upgrade test results available
Le mercredi 29 décembre 2010 à 12:50 +, Ian Jackson a écrit : If so, that's a bug in python-xpcom. Any package which registers a hook with another package must be prepared for its hook to be run even when the registering package is not configured. If this is a problem, arrangements should be made to arrange that the hook is a no-op when in these circumstances and/or that it is run later when the registering package is properly working. For example, the hook could be registered only in python-xpcom's postinst (and deregistered in its preinst). This is what I have already proposed to Mike on IRC: moving libpyloader.so to a different directory and setting it as a symlink in python-xpcom.postinst. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1293627133.27024.25.ca...@meh
Re: Full install/removal/upgrade test results available
Mike Hommey writes (Re: Full install/removal/upgrade test results available): On Mon, Dec 27, 2010 at 11:59:16PM +, Ian Jackson wrote: So the problem is that python-xpcom does not work when it has been previously installed, and then during an upgrade the new version has been unpacked but not configured ? The remaining problem is that python-xpcom does not work when it was not previously installed but xulrunner-1.9.1 was. Right. If you add a dependency from xulrunner to python-xpcom this problem ought to go away (although if that would lead to a circular dependency the situation is more complicated as dpkg will need to break the cycle). Plus, xulrunner doesn't need python-xpcom. The problem is that xulrunner trigger can't work when python-xpcom is only unpacked. It can only work after python-support trigger has run (or update-python-modules has been run from python-xpcom postinst, for that matter). So what has happened is that python-xpcom registered something with xulrunner, using a trigger mechanism. But the thing which python-xpcom has registered is broken until python-xpcom is configured ? So xulrunner's postinst, doing its trigger processing, runs the python-xpcom hook, but the latter falls over due to lack of configuration of python-xpcom ? If so, that's a bug in python-xpcom. Any package which registers a hook with another package must be prepared for its hook to be run even when the registering package is not configured. If this is a problem, arrangements should be made to arrange that the hook is a no-op when in these circumstances and/or that it is run later when the registering package is properly working. For example, the hook could be registered only in python-xpcom's postinst (and deregistered in its preinst). Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19739.11902.527258.699...@chiark.greenend.org.uk
Re: Full install/removal/upgrade test results available
Le mercredi 29 décembre 2010 à 14:14 +0100, Mike Hommey a écrit : Which would also mean firing dpkg-trigger in python-xpcom.postinst, too. This all looks like overcomplication to circumvent an imho design flaw in python packages. Call it a design flaw, but no package is expected to actually work before its postinst has been executed. That is the policy. Unfortunately, except if I drop python-support use entirely (which could even mean going against the python policy, but I don't remember the details of it wrt modules location), there's nothing else I can do. You can use dh_python2 which does what you want, but AFAIK it’s not the recommended tool for squeeze. Cheers, -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1293628946.27024.27.ca...@meh
Re: Full install/removal/upgrade test results available
On Wed, Dec 29, 2010 at 12:50:06PM +, Ian Jackson wrote: Mike Hommey writes (Re: Full install/removal/upgrade test results available): On Mon, Dec 27, 2010 at 11:59:16PM +, Ian Jackson wrote: So the problem is that python-xpcom does not work when it has been previously installed, and then during an upgrade the new version has been unpacked but not configured ? The remaining problem is that python-xpcom does not work when it was not previously installed but xulrunner-1.9.1 was. Right. If you add a dependency from xulrunner to python-xpcom this problem ought to go away (although if that would lead to a circular dependency the situation is more complicated as dpkg will need to break the cycle). Plus, xulrunner doesn't need python-xpcom. The problem is that xulrunner trigger can't work when python-xpcom is only unpacked. It can only work after python-support trigger has run (or update-python-modules has been run from python-xpcom postinst, for that matter). So what has happened is that python-xpcom registered something with xulrunner, using a trigger mechanism. But the thing which python-xpcom has registered is broken until python-xpcom is configured ? So xulrunner's postinst, doing its trigger processing, runs the python-xpcom hook, but the latter falls over due to lack of configuration of python-xpcom ? xulrunner has a file trigger for components in /usr/lib/xulrunner-1.9.1/components, so that it registers them in compreg.dat and xpti.dat. This means it has to load the components to get their registration information. But the components python-xpcom adds need the python modules to be registered to work, which means xulrunner component registration need to happen after python-xpcom's modules are available, which usually only happens after python-support's trigger, but in python-xpcom case, it's forced to run during its postinst, which is unfortunately still too late. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101229131952.gb7...@glandium.org
Re: Full install/removal/upgrade test results available
On Wed, Dec 29, 2010 at 01:52:13PM +0100, Josselin Mouette wrote: Le mercredi 29 décembre 2010 à 12:50 +, Ian Jackson a écrit : If so, that's a bug in python-xpcom. Any package which registers a hook with another package must be prepared for its hook to be run even when the registering package is not configured. If this is a problem, arrangements should be made to arrange that the hook is a no-op when in these circumstances and/or that it is run later when the registering package is properly working. For example, the hook could be registered only in python-xpcom's postinst (and deregistered in its preinst). This is what I have already proposed to Mike on IRC: moving libpyloader.so to a different directory and setting it as a symlink in python-xpcom.postinst. Which would also mean firing dpkg-trigger in python-xpcom.postinst, too. This all looks like overcomplication to circumvent an imho design flaw in python packages. Unfortunately, except if I drop python-support use entirely (which could even mean going against the python policy, but I don't remember the details of it wrt modules location), there's nothing else I can do. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101229131412.ga7...@glandium.org
Re: Full install/removal/upgrade test results available
Le mercredi 29 décembre 2010 à 14:19 +0100, Mike Hommey a écrit : xulrunner has a file trigger for components in /usr/lib/xulrunner-1.9.1/components, so that it registers them in compreg.dat and xpti.dat. This means it has to load the components to get their registration information. But the components python-xpcom adds need the python modules to be registered to work, which means xulrunner component registration need to happen after python-xpcom's modules are available, which usually only happens after python-support's trigger, but in python-xpcom case, it's forced to run during its postinst, which is unfortunately still too late. Note that in the python-xpcom case, it is useless to force update-python-modules -p in the postinst. The symlinks are installed by the postinst and are sufficient for anything that needs the modules. The trigger is here for byte-compilation. Cheers, -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1293639833.27024.39.ca...@meh
Re: Full install/removal/upgrade test results available
On Wed, Dec 22, 2010 at 08:36:38PM +0100, Josselin Mouette wrote: Le mardi 21 décembre 2010 à 20:59 +0100, Mike Hommey a écrit : Adding update-python-modules -p in python-xpcom postinst could make things slightly better, but that would still leave xulrunner-1.9.1's postinst complaining if it's run before python-xpcom's. What if xulrunner-1.9.1's postinst would do nothing for configure ? would the trigger still kick in when one installs xulrunner-1.9.1 only? You could use dpkg-trigger to force the trigger to be run after xulrunner-1.9.1 being installed. Unfortunately, while some cases were fixed, the original case for which the pre-depends was added fails again :( (starting from xulrunner-1.9.1 already installed, and installing python-xpcom, case which I forgot to test before my last uploads) Unpacking python-xpcom (from .../python-xpcom_1%3a0.0~hg20100212-3_amd64.deb) ... Processing triggers for xulrunner-1.9.1 ... Obtaining the module object from Python failed. type 'exceptions.ImportError': No module named xpcom.server Obtaining the module object from Python failed. type 'exceptions.ImportError': No module named xpcom.server Setting up libncursesw5 (5.7+20100313-4) ... Setting up libssl0.9.8 (0.9.8o-4) ... Setting up mime-support (3.51-1) ... update-alternatives: using /usr/bin/see to provide /usr/bin/view (view) in auto mode. Setting up python2.6-minimal (2.6.6-8+b1) ... Setting up python2.6 (2.6.6-8+b1) ... Setting up python-minimal (2.6.6-3+squeeze4) ... Setting up python (2.6.6-3+squeeze4) ... Setting up python-support (1.0.11) ... Setting up libpython2.6 (2.6.6-8+b1) ... Setting up python-xpcom (1:0.0~hg20100212-3) ... Processing triggers for python-support ... Yes, the xulrunner-1.9.1 trigger happens right after unpack... before python-xpcom's postinst g. I'm starting to hate dpkg triggers. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101227175735.ga27...@glandium.org
Re: Full install/removal/upgrade test results available
Le lundi 27 décembre 2010 à 18:57 +0100, Mike Hommey a écrit : On Wed, Dec 22, 2010 at 08:36:38PM +0100, Josselin Mouette wrote: You could use dpkg-trigger to force the trigger to be run after xulrunner-1.9.1 being installed. Unfortunately, while some cases were fixed, the original case for which the pre-depends was added fails again :( Yes, the xulrunner-1.9.1 trigger happens right after unpack... before python-xpcom's postinst g. I'm starting to hate dpkg triggers. Maybe you want dpkg-trigger --no-await ? -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Full install/removal/upgrade test results available
On Mon, Dec 27, 2010 at 09:08:14PM +0100, Josselin Mouette wrote: Le lundi 27 décembre 2010 à 18:57 +0100, Mike Hommey a écrit : On Wed, Dec 22, 2010 at 08:36:38PM +0100, Josselin Mouette wrote: You could use dpkg-trigger to force the trigger to be run after xulrunner-1.9.1 being installed. Unfortunately, while some cases were fixed, the original case for which the pre-depends was added fails again :( Yes, the xulrunner-1.9.1 trigger happens right after unpack... before python-xpcom's postinst g. I'm starting to hate dpkg triggers. Maybe you want dpkg-trigger --no-await ? Point is, xulrunner is already installed, thus its postinst is not what triggers. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101227202440.ga30...@glandium.org
Re: Full install/removal/upgrade test results available
Mike Hommey writes (Re: Full install/removal/upgrade test results available): Unfortunately, while some cases were fixed, the original case for which the pre-depends was added fails again :( (starting from xulrunner-1.9.1 already installed, and installing python-xpcom, case which I forgot to test before my last uploads) Unpacking python-xpcom (from .../python-xpcom_1%3a0.0~hg20100212-3_amd64.deb) ... Processing triggers for xulrunner-1.9.1 ... Obtaining the module object from Python failed. type 'exceptions.ImportError': No module named xpcom.server Obtaining the module object from Python failed. So the problem is that python-xpcom does not work when it has been previously installed, and then during an upgrade the new version has been unpacked but not configured ? If you add a dependency from xulrunner to python-xpcom this problem ought to go away (although if that would lead to a circular dependency the situation is more complicated as dpkg will need to break the cycle). Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19737.10324.139286.394...@chiark.greenend.org.uk
Re: Full install/removal/upgrade test results available
On Mon, Dec 27, 2010 at 11:59:16PM +, Ian Jackson wrote: Mike Hommey writes (Re: Full install/removal/upgrade test results available): Unfortunately, while some cases were fixed, the original case for which the pre-depends was added fails again :( (starting from xulrunner-1.9.1 already installed, and installing python-xpcom, case which I forgot to test before my last uploads) Unpacking python-xpcom (from .../python-xpcom_1%3a0.0~hg20100212-3_amd64.deb) ... Processing triggers for xulrunner-1.9.1 ... Obtaining the module object from Python failed. type 'exceptions.ImportError': No module named xpcom.server Obtaining the module object from Python failed. So the problem is that python-xpcom does not work when it has been previously installed, and then during an upgrade the new version has been unpacked but not configured ? The remaining problem is that python-xpcom does not work when it was not previously installed but xulrunner-1.9.1 was. If you add a dependency from xulrunner to python-xpcom this problem ought to go away (although if that would lead to a circular dependency the situation is more complicated as dpkg will need to break the cycle). Plus, xulrunner doesn't need python-xpcom. The problem is that xulrunner trigger can't work when python-xpcom is only unpacked. It can only work after python-support trigger has run (or update-python-modules has been run from python-xpcom postinst, for that matter). The root of the problem, really, is that python packages can't be used when only simply unpacked. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101228072824.ga3...@glandium.org
Re: Full install/removal/upgrade test results available
Le mardi 21 décembre 2010 à 20:59 +0100, Mike Hommey a écrit : Adding update-python-modules -p in python-xpcom postinst could make things slightly better, but that would still leave xulrunner-1.9.1's postinst complaining if it's run before python-xpcom's. What if xulrunner-1.9.1's postinst would do nothing for configure ? would the trigger still kick in when one installs xulrunner-1.9.1 only? You could use dpkg-trigger to force the trigger to be run after xulrunner-1.9.1 being installed. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Full install/removal/upgrade test results available
* Mike Hommey m...@glandium.org, 2010-11-19, 09:18:
Mike Hommey gland...@debian.org
python-xpcom (U)
I /think/ this could be solved by not using a pre-depends on
xulrunner-1.9.1.
Indeed.
OTOH, the pre-depends solves a part of another problem though not
entirely, due to triggers ordering: the xulrunner-1.9.1 trigger can't
work until the python-support trigger has been run...
I don't see how pre-depends could have helped here. On the first glance
it makes it only worse. E.g., when I install python-xpcom in a clean
chroot I get:
| Unpacking python-xpcom (from .../python-xpcom_1%3a0.0~hg20100212-2_i386.deb)
...
| Processing triggers for xulrunner-1.9.1 ...
| Obtaining the module object from Python failed.
|
| type 'exceptions.ImportError': No module named xpcom.server
| Obtaining the module object from Python failed.
|
| type 'exceptions.ImportError': No module named xpcom.server
When I moved ${xulrunner:Depends} from Pre-Depends to Depends,
everything was registered just fine.
The only fix for that issue that I can think of would be to stop using
python-support... If other people have ideas, I'm all ears.
I think you could manually trigger xulrunner-1.9.1 in python-xpcom's
postinst if it's not already registered. See the attached patch (well,
except maybe xulrunner version shouldn't be hardcoded).
--
Jakub Wilk
diff -u pyxpcom-0.0~hg20100212/debian/control pyxpcom-0.0~hg20100212/debian/control
--- pyxpcom-0.0~hg20100212/debian/control
+++ pyxpcom-0.0~hg20100212/debian/control
@@ -18,8 +18,8 @@
Provides: ${python:Provides}
Depends: ${shlibs:Depends},
${misc:Depends},
- ${python:Depends}
-Pre-Depends: ${xulrunner:Depends}
+ ${python:Depends},
+ ${xulrunner:Depends}
Breaks: epiphany-gecko ( 2.28)
XB-Python-Version: ${python:Versions}
Description: XPCOM bindings for Python
diff -u pyxpcom-0.0~hg20100212/debian/postinst pyxpcom-0.0~hg20100212/debian/postinst
--- pyxpcom-0.0~hg20100212/debian/postinst
+++ pyxpcom-0.0~hg20100212/debian/postinst
@@ -9,2 +9,7 @@
+if ! grep -F '@mozilla.org/module-loader/python;' /usr/lib/xulrunner-1.9.1/components/compreg.dat /dev/null
+then
+ dpkg-trigger /usr/lib/xulrunner-1.9.1/components
+fi
+
#DEBHELPER#
Re: Full install/removal/upgrade test results available
On Tue, Dec 21, 2010 at 08:37:53PM +0100, Jakub Wilk wrote:
* Mike Hommey m...@glandium.org, 2010-11-19, 09:18:
Mike Hommey gland...@debian.org
python-xpcom (U)
I /think/ this could be solved by not using a pre-depends on
xulrunner-1.9.1.
Indeed.
OTOH, the pre-depends solves a part of another problem though not
entirely, due to triggers ordering: the xulrunner-1.9.1 trigger
can't work until the python-support trigger has been run...
I don't see how pre-depends could have helped here.
I don't remember the details, but it made things half better.
On the first
glance it makes it only worse. E.g., when I install python-xpcom in
a clean chroot I get:
| Unpacking python-xpcom (from
.../python-xpcom_1%3a0.0~hg20100212-2_i386.deb) ...
| Processing triggers for xulrunner-1.9.1 ...
| Obtaining the module object from Python failed.
|
| type 'exceptions.ImportError': No module named xpcom.server
| Obtaining the module object from Python failed.
|
| type 'exceptions.ImportError': No module named xpcom.server
When I moved ${xulrunner:Depends} from Pre-Depends to Depends,
everything was registered just fine.
The only fix for that issue that I can think of would be to stop
using python-support... If other people have ideas, I'm all ears.
I think you could manually trigger xulrunner-1.9.1 in python-xpcom's
postinst if it's not already registered. See the attached patch
(well, except maybe xulrunner version shouldn't be hardcoded).
I'd expect that to fail as well, because of python-support trigger not
having been run yet.
Part of the problem is that the xulrunner-1.9.1's postinst or trigger can
run with python-xpcom unpacked but not registered with python-support.
Adding update-python-modules -p in python-xpcom postinst could make
things slightly better, but that would still leave xulrunner-1.9.1's
postinst complaining if it's run before python-xpcom's.
What if xulrunner-1.9.1's postinst would do nothing for configure ?
would the trigger still kick in when one installs xulrunner-1.9.1 only?
Mike
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101221195957.gb3...@glandium.org
Re: Full install/removal/upgrade test results available
* Mike Hommey m...@glandium.org, 2010-12-21, 20:59: I think you could manually trigger xulrunner-1.9.1 in python-xpcom's postinst if it's not already registered. See the attached patch (well, except maybe xulrunner version shouldn't be hardcoded). I'd expect that to fail as well, because of python-support trigger not having been run yet. Part of the problem is that the xulrunner-1.9.1's postinst or trigger can run with python-xpcom unpacked but not registered with python-support. Adding update-python-modules -p in python-xpcom postinst could make things slightly better, update-python-modules -p is already in python-xpcom's postinst and it does exactly what python-support trigger would do. but that would still leave xulrunner-1.9.1's postinst complaining if it's run before python-xpcom's. Unfortunately, this is true. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101221204154.ga3...@jwilk.net
Re: Full install/removal/upgrade test results available
On Sun, Nov 21, 2010 at 10:32:49PM +0100, Serafeim Zanikolas wrote: On Sat, Nov 20, 2010 at 05:52:43PM +0100, Milan Zamazal wrote: LN == Lucas Nussbaum lu...@lucas-nussbaum.net writes: Milan Zamazal p...@debian.org cl-clx-sbcl cl-flexichain cl-mcclim cl-mcclim-examples cl-spatial-trees cl-speech-dispatcher cl-swank (U) slime (U) These, as well as probably other cl-* packages, fail because they depend on common-lisp-controller which fails. That's #601957, which I thought I've fixed but missed the install old-version case; pending new NMU. Fixed in 7.4+nmu2 -S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101124225609.ga30...@mobee
Re: Full install/removal/upgrade test results available
On 17/11/10 at 12:28 -0600, Lucas Nussbaum wrote: On 17/11/10 at 16:07 +0100, Andreas Tille wrote: [Debian Edu people please read below at /education-/] Hi Lucas, thanks for all your QA efforts! On Wed, Nov 17, 2010 at 08:37:17AM -0600, Lucas Nussbaum wrote: [1] http://people.debian.org/~lucas/logs/2010/11/17/ Full dd-list (binary packages): --- Andreas Tille ti...@debian.org cimg-dev (U) I checked for cimg-dev in http://people.debian.org/~lucas/logs/2010/11/17/cimg-dev.log and found only one hint of a failure when it says: -- New version is unstable version: FAILED (UNINSTALLED != 1.3.9-1) but from reasing the log I can not find any hint for this problem. Is this possibly one of the cases where some dependencies show a problem? Any help reading the log properly is welcome. So, that one is an interesting case, and there are several occurences of this. It might be a problem in APT. What happens is that, if you install cimg-dev on lenny, and then upgrade to squeeze, cimg-dev gets removed. But after the upgrade, you can safely reinstall it. It might be caused by the handling of Breaks in APT. I'm not sure. dict-wn (U) http://people.debian.org/~lucas/logs/2010/11/17/dict-wn.log ... Installing new version of config file /etc/dictd/dictd.conf ... Installing new version of config file /etc/init.d/dictd ... insserv: warning: current stop runlevel(s) (0 1 6) of script `dictd' overwrites defaults (1). invoke-rc.d: policy-rc.d denied execution of start. -- Finding version of dict-wn: 1:3.0-18 -- New version is unstable version: OK E: 10mount: umount: /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b/dev: device is busy. E: 10mount: (In some cases useful info about processes that use E: 10mount: the device is found by lsof(8) or fuser(1)) E: llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b: Chroot setup failed: stage=setup-stop Cleanup of chroot llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b failed. Running processes: /dc/debcluster/scripts/tasks/instest.rb:5: command not found: lsof -t +D /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b E: 10mount: umount: /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b/dev: device is busy. E: 10mount: (In some cases useful info about processes that use E: 10mount: the device is found by lsof(8) or fuser(1)) E: llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b: Chroot setup failed: stage=setup-stop This does look like a bug rather in dict than in dict-wn. However, if my assumption would be correct I would expect all other dict dictionaries to fail and thus I wonder if I missinterpreted this log. It seems that after installation of dict-wn, there's a process that is still running, so destroying the chroot fails. What happens is that in lenny, the postinst script doesn't honor policy-rc.d, so dictd is started, but never stopped. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101121102039.ga18...@xanadu.blop.info
Re: Full install/removal/upgrade test results available
On su, 2010-11-21 at 17:44 +0100, Andreas Tille wrote: On Sun, Nov 21, 2010 at 11:20:39AM +0100, Lucas Nussbaum wrote: What happens is that in lenny, the postinst script doesn't honor policy-rc.d, so dictd is started, but never stopped. So do you want to say that the dictd package is RC buggy? Or are you rather proposing a workaround for the dict-wn and if yes, what exactly would you propose? Not honoring policy-rc.d is a policy violation, so the dictd in lenny would seem to be RC buggy, in my opinion. The best fix would be to fix the package in lenny, which should be an easy fix, assuming the stable release team accepts it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1290358288.3234.53.ca...@havelock.lan
Re: Full install/removal/upgrade test results available
On Sun, Nov 21, 2010 at 11:20:39AM +0100, Lucas Nussbaum wrote: So, that one is an interesting case, and there are several occurences of this. It might be a problem in APT. What happens is that, if you install cimg-dev on lenny, and then upgrade to squeeze, cimg-dev gets removed. But after the upgrade, you can safely reinstall it. It might be caused by the handling of Breaks in APT. I'm not sure. dict-wn (U) http://people.debian.org/~lucas/logs/2010/11/17/dict-wn.log ... Installing new version of config file /etc/dictd/dictd.conf ... Installing new version of config file /etc/init.d/dictd ... insserv: warning: current stop runlevel(s) (0 1 6) of script `dictd' overwrites defaults (1). invoke-rc.d: policy-rc.d denied execution of start. -- Finding version of dict-wn: 1:3.0-18 -- New version is unstable version: OK E: 10mount: umount: /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b/dev: device is busy. E: 10mount: (In some cases useful info about processes that use E: 10mount: the device is found by lsof(8) or fuser(1)) E: llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b: Chroot setup failed: stage=setup-stop Cleanup of chroot llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b failed. Running processes: /dc/debcluster/scripts/tasks/instest.rb:5: command not found: lsof -t +D /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b E: 10mount: umount: /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b/dev: device is busy. E: 10mount: (In some cases useful info about processes that use E: 10mount: the device is found by lsof(8) or fuser(1)) E: llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b: Chroot setup failed: stage=setup-stop This does look like a bug rather in dict than in dict-wn. However, if my assumption would be correct I would expect all other dict dictionaries to fail and thus I wonder if I missinterpreted this log. It seems that after installation of dict-wn, there's a process that is still running, so destroying the chroot fails. What happens is that in lenny, the postinst script doesn't honor policy-rc.d, so dictd is started, but never stopped. So do you want to say that the dictd package is RC buggy? Or are you rather proposing a workaround for the dict-wn and if yes, what exactly would you propose? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101121164426.ga15...@an3as.eu
Re: Full install/removal/upgrade test results available
On 17/11/10 at 16:07 +0100, Andreas Tille wrote: So, that one is an interesting case, and there are several occurences of this. It might be a problem in APT. What happens is that, if you install cimg-dev on lenny, and then upgrade to squeeze, cimg-dev gets removed. But after the upgrade, you can safely reinstall it. It might be caused by the handling of Breaks in APT. I'm not sure. When you reinstall cimg-dev in squeeze what else gets installed? Is it just that removing cimg-dev is cheaper then pulling in all the new depends for it? (which I believe should never be considered cheaper). MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqtybmw5@frosties.localnet
Re: Full install/removal/upgrade test results available
On Sun, Nov 21, 2010 at 05:44:26PM +0100, Andreas Tille wrote: On Sun, Nov 21, 2010 at 11:20:39AM +0100, Lucas Nussbaum wrote: It seems that after installation of dict-wn, there's a process that is still running, so destroying the chroot fails. What happens is that in lenny, the postinst script doesn't honor policy-rc.d, so dictd is started, but never stopped. So do you want to say that the dictd package is RC buggy? Or are you rather proposing a workaround for the dict-wn and if yes, what exactly would you propose? dict-wn is what started dictd. The problem is that dict-wn's postinst in Lenny didn't use invoke-rc.d to restart dictd, so it didn't honor policy-rc.d. This isn't a problem in Squeeze since the postinst is using invoke-rc.d. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
Re: Full install/removal/upgrade test results available
On Sat, Nov 20, 2010 at 05:52:43PM +0100, Milan Zamazal wrote: LN == Lucas Nussbaum lu...@lucas-nussbaum.net writes: Milan Zamazal p...@debian.org cl-clx-sbcl cl-flexichain cl-mcclim cl-mcclim-examples cl-spatial-trees cl-speech-dispatcher cl-swank (U) slime (U) These, as well as probably other cl-* packages, fail because they depend on common-lisp-controller which fails. That's #601957, which I thought I've fixed but missed the install old-version case; pending new NMU. -S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101121213249.gb12...@mobee
Re: Full install/removal/upgrade test results available
On ven., 2010-11-19 at 23:49 +0100, David Kalnischkies wrote: And i am usually not offended by someone blaming APT to be too dumb. APT is all about dependency resolution, so saying you are not to deep into it, but blaming APT to be wrong isn't the best tone either. Draw i would say… Hey, please don't put words in my mouth, I never said apt was too dumb. I said it looked to me like it was doing the wrong thing. And you don't have to take that personally either. By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't work either, apt will still prefer to hold xfce4-session and keep xfce4-mcs-*. You have way more information than APT - for example: Is it communicated that xfce4-mcs-manager and xfce4-mcs-plugin are now obsolete? No. All which is said is that the new xfce4-session doesn't work with them (it breaks them). No, xfce4-session depends on xfce4-settings. And xfce4-settings *replaces* xfce4-mcs-*. So, for APT its clear that we loose two packages just to get another one upgraded… that doesn't feel right. Even with the Replaces: bit? Great, just that Replaces: only says that some files will be replaced, not the complete package… (so its mostly only used by dpkg). Hmh, I missed that. I thought Replaces was package wide for apt. They ship common files = Replaces Or is xfce4-mcs-plugins broken now that you replaces some of its files? (or better as footnote 46 suggests: Does it hurt if the files are gone?) Then it really also Breaks:, but you also give the indication that something in xfce4-mcs-plugins is left which can be broken and therefore functionality is lost by removing it… (or allowing the other package to replace files of it in the first place). So you might want to provide a new xfce4-mcs-plugins without these files (by depending on them) which still provides this functionality (or nothing as a dummy package). and xfce4-settings replaces the functionality provided by xfce4-mcs-manager. dummy xfce4-mcs-manager depending on xfce4-settings if it is a package rename. If its not, but they do not conflict just leave xfce4-mcs-manager alone. If they conflict as they use the same files, its the same as with the other package… xfce4-settings replaces (functionnalities) xfce4-mcs-manager and xfce4-mcs-plugins, and ships files contained in those two packages. So Conflicts/Replaces is necessary, but indeed not enough. So I guess I'll have to version them, and add dummy packages back (yeah, NEW!). Or in short: either make empty dummy packages out of them or just leave them alone. Which would then need to Depends on xfce4-settings in order to provide the same set of functionality, adding complexity to the dependencies. In general positive dependencies are easier to satisfy than negative as it is easier to install another package than to remove an installed. If we install a new package we have a relatively low probability that a negative dependency will effect it later. If we remove a package we can be nearly sure that another package depends on it and is now broken. (why would it be installed otherwise?) In this case, I thought apt would use the Replaces: field for that. Also, a user normally doesn't complain too much if new functionality is added, but heavily if some functionality is gone without good reason… And the good reason is why APT doesn't remove the package on the breaks - the 'Considering' line in the output shows the scores the packages have. 0 vs 0 isn't a strong thing. If more packages would depend on one of the packages the decision will follow the highest scoring package. Good point. In that case it's a simple package upgrade, while usually the whole Xfce stack is installed. I've tried with the xfce4 metapackage and the upgrade correctly picks xfce4-settings and wants to remove MCS. So while the partial upgrade for only xfce4-session is a bit broken (well, if you ask for xfce4-session install it works too), in general it won't be a problem. Thanks for your help and your time. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Full install/removal/upgrade test results available
LN == Lucas Nussbaum lu...@lucas-nussbaum.net writes: Milan Zamazal p...@debian.org cl-clx-sbcl cl-flexichain cl-mcclim cl-mcclim-examples cl-spatial-trees cl-speech-dispatcher cl-swank (U) slime (U) These, as well as probably other cl-* packages, fail because they depend on common-lisp-controller which fails. crm114 This is a very special case: The package may not be upgraded without user intervention (a debconf question) in order to prevent possible mail loss. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkt43pk4@blackbird.nest.zamazal.org
Re: Full install/removal/upgrade test results available
Russ Allbery r...@debian.org writes: brian m. carlson sand...@crustytoothpaste.net writes: On Fri, Nov 19, 2010 at 01:41:49PM -0800, Russ Allbery wrote: Goswin von Brederlow goswin-...@web.de writes: Also note that no frontend has ever made use of §7.6.2 and handled upgrading obsolete packages to their replacements. There's a reason for that: it's not possible to create a Policy-compliant package that could use 7.6.2 in that fashion. I keep trying to point this out each time you bring this up. Each time? I only remember one time where I brought up 7.6.1 as possibility for transitional packages after dpkg's behaviour with empty packages was fixed and you explained why it won't work. It would have been nice but it's not to be. You make it sound like I bring this up every month. Wait, what? Are you saying that other parts of Policy conflict with §7.6.2? Or are you saying that the Debian tools and infrastructure don't support it? Or something else entirely? Ack, sorry. I was completely wrong on this because I assumed I knew what Goswin was talking about but confused this with a previous discussion. No, 7.6.2 doesn't contradict other parts of Policy, and I'm not familiar with the issues in using that for transitional packages (other than the general problem that Conflicts Is Hard To Get Right). I thought Gowsin was talking about 7.6.*1*, the provision where packages are removed if all of their files are replaced, which isn't a usable way to eliminate transitional packages due to other Policy requirements. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y68n3gm1@frosties.localnet
Re: Full install/removal/upgrade test results available
On Wed, Nov 17, 2010 at 08:37:17AM -0600, Lucas Nussbaum wrote: Mike Hommey gland...@debian.org python-xpcom (U) I /think/ this could be solved by not using a pre-depends on xulrunner-1.9.1. OTOH, the pre-depends solves a part of another problem though not entirely, due to triggers ordering: the xulrunner-1.9.1 trigger can't work until the python-support trigger has been run... The only fix for that issue that I can think of would be to stop using python-support... If other people have ideas, I'm all ears. Cheers, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101119081840.ga3...@glandium.org
Re: Full install/removal/upgrade test results available
Le mercredi 17 novembre 2010 à 08:37 -0600, Lucas Nussbaum a écrit : Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org gnome gnome-accessibility gnome-app-install (U) gnome-core gnome-dbg gnome-desktop-environment gnome-devel gnome-office python-software-properties (U) software-properties-gtk (U) software-properties-kde (U) update-manager-core All these failures seem to be caused by the “apt-get install apt” run which happens before the rest. It will remove xulrunner: Package libcairo2 has broken dep on xulrunner-1.9 Considering xulrunner-1.9 2 as a solution to libcairo2 302 Added xulrunner-1.9 to the remove list Fixing libcairo2 via remove of xulrunner-1.9 I think libapt causes synaptic (and/or other APT frontends) to be upgraded, which is why it tries to upgrade cairo, but in the end it just removes both synaptic and the xulrunner rdeps. OTOH a plain dist-upgrade with lenny’s APT would probably just work. rhythmbox (U) rhythmbox-dbg (U) This one is similar, although a bit different. Because of the python upgrade, python-gtk2 ends up removed instead of upgraded. All of this suggests that the idea to upgrade APT first, as suggested in the release notes, is a very bad one. It would work if libapt hadn’t changed its ABI in the meantime. sabayon (U) This one looks like a genuine RC bug in sabayon.postrm. I’ve reported it and fixed it in the SVN. All in all, thanks for this very thorough test. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1290158968.23343.21.ca...@meh
Re: Full install/removal/upgrade test results available
On 19/11/2010 08:52, Yves-Alexis Perez wrote: Anyone knows why and how to fix that? Would a “breaks” instead of a “conflicts” fix it? Seems that “Breaks:” doesn't work either: Investigating (0) xfce4-settings [ amd64 ] none - 4.6.5-3 ( xfce ) Broken xfce4-settings:amd64 Breaks on xfce4-mcs-plugins [ amd64 ] 4.4.2-4 ( x11 ) Considering xfce4-mcs-plugins:amd64 0 as a solution to xfce4-settings:amd64 0 Holding Back xfce4-settings:amd64 rather than change xfce4-mcs-plugins:amd64 Investigating (0) xfce4-session [ amd64 ] 4.4.2-6 - 4.6.2-2 ( xfce ) Broken xfce4-session:amd64 Depends on xfce4-settings [ amd64 ] none - 4.6.5-3 ( xfce ) Considering xfce4-settings:amd64 0 as a solution to xfce4-session:amd64 0 Holding Back xfce4-session:amd64 rather than change xfce4-settings:amd64 Try to Re-Instate (1) xfce4-session:amd64 Done I'm not sure why apt doesn't want to remove xfce4-mcs-plugin at all. Any idea? -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce65239.7040...@debian.org
Re: Full install/removal/upgrade test results available
On Fri, Nov 19, 2010 at 11:32, Yves-Alexis Perez cor...@debian.org wrote: On 19/11/2010 08:52, Yves-Alexis Perez wrote: Anyone knows why and how to fix that? Would a “breaks” instead of a “conflicts” fix it? Seems that “Breaks:” doesn't work either: Investigating (0) xfce4-settings [ amd64 ] none - 4.6.5-3 ( xfce ) Broken xfce4-settings:amd64 Breaks on xfce4-mcs-plugins [ amd64 ] 4.4.2-4 ( x11 ) Considering xfce4-mcs-plugins:amd64 0 as a solution to xfce4-settings:amd64 0 Holding Back xfce4-settings:amd64 rather than change xfce4-mcs-plugins:amd64 Investigating (0) xfce4-session [ amd64 ] 4.4.2-6 - 4.6.2-2 ( xfce ) Broken xfce4-session:amd64 Depends on xfce4-settings [ amd64 ] none - 4.6.5-3 ( xfce ) Considering xfce4-settings:amd64 0 as a solution to xfce4-session:amd64 0 Holding Back xfce4-session:amd64 rather than change xfce4-settings:amd64 Try to Re-Instate (1) xfce4-session:amd64 Done I'm not sure why apt doesn't want to remove xfce4-mcs-plugin at all. Any idea? xfce4-mcs-manager recommends it. As APT has no indication that this package can go away it does the only right thing (TM): Chooses to keep xfce4-mcs-plugins as otherwise the user will lose functionality… (recommends are defined as installed on all, expect unusual systems, so their value is very close to a depends for APT) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktino9o5nfbect-kif1=sj6jgspukvunjp3x4s...@mail.gmail.com
Re: Full install/removal/upgrade test results available
On 19/11/2010 12:29, David Kalnischkies wrote: xfce4-mcs-manager recommends it. As APT has no indication that this package can go away it does the only right thing (TM): Chooses to keep xfce4-mcs-plugins as otherwise the user will lose functionality… (recommends are defined as installed on all, expect unusual systems, so their value is very close to a depends for APT) Except it's not. System would be perfectly usable with xfce4-mcs-plugin and without xfce4-mcs-manager (it wouldn't make much sense, but still). Preferring to ignore a Breaks: in order to keep a Recommends: satisfied looks to me like the wrong thing to do, though I'm not fluent enough in dependencies to be sure. By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't work either, apt will still prefer to hold xfce4-session and keep xfce4-mcs-*. Cheers, -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce66692.1050...@debian.org
Re: Full install/removal/upgrade test results available
On Fri, Nov 19, 2010 at 10:29:28 +0100, Josselin Mouette wrote: All of this suggests that the idea to upgrade APT first, as suggested in the release notes, is a very bad one. It would work if libapt hadn’t changed its ABI in the meantime. Last I checked the squeeze release notes didn't recommend that. Cheers, Julien signature.asc Description: Digital signature
Re: Full install/removal/upgrade test results available
On Fri, Nov 19, 2010 at 12:59, Yves-Alexis Perez cor...@debian.org wrote:
On 19/11/2010 12:29, David Kalnischkies wrote:
xfce4-mcs-manager recommends it.
As APT has no indication that this package can go away it does the
only right thing (TM): Chooses to keep xfce4-mcs-plugins as otherwise
the user will lose functionality…
(recommends are defined as installed on all, expect unusual systems,
so their value is very close to a depends for APT)
Except it's not. System would be perfectly usable with xfce4-mcs-plugin
and without xfce4-mcs-manager (it wouldn't make much sense, but still).
Preferring to ignore a Breaks: in order to keep a Recommends: satisfied
looks to me like the wrong thing to do, though I'm not fluent enough in
dependencies to be sure.
So, go and start reading. Debian has a lot of dependencies and you have a
lot of possibilities because of that.
You can't use them if you don't know them.
And, more important, you can't blame APT for being stupid if you don't
know what you talk about yourself.
Oh, and in the end, i am not a D{D,M}, so you shouldn't trust me and
what i say about a policy as i don't upload packages to the archive
which needs to comply to that policy…
By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't
work either, apt will still prefer to hold xfce4-session and keep
xfce4-mcs-*.
You have way more information than APT - for example:
Is it communicated that xfce4-mcs-manager and xfce4-mcs-plugin are
now obsolete? No. All which is said is that the new xfce4-session doesn't
work with them (it breaks them). So, for APT its clear that we loose two
packages just to get another one upgraded… that doesn't feel right.
Just imagine dpkg gets a new console interface and therefore isn't
compatible with apt/aptitude anymore - should APT really decide to
remove apt, aptitude and friends just to upgrade dpkg? No. Better wait
for apt, aptitude and friends to be upgraded to work again with dpkg
and retreat from upgrading dpkg now (in that case the breaks would be
versioned, but still).
We have cases in which packages in extra break each other - this
doesn't mean they obsolete each other - it doesn't even say that they
do the same nor even something similar, it just says that they doesn't
work together on the same system (unversioned as the breaks here).
If apt would provide a /usr/bin/apt it could break java for example (and v.v.)
as this provides /usr/bin/apt too - it should be clear that apt and java
have nothing in common expect that they use the same name for
an executable… (yes, thats completely made up, in reality this binary
is already an alternative - but even then it would feel strange to provide
an alternative with apt for javas annotation processing tool…)
Before you ask, no, debian has no way to say: this package is obsolete -
its fine that it will be removed as other packages take care of its tasks.
The closest thing to that is §7.6.2, but i doubt that this is really such
a drop-in replacement in your case.
(and that doesn't say anything about an upgrade path, too)
So, to solve your problem, you have more or less only one option:
Do not try to clean up behind you, let the package managers do it
(with autoremove or deborphan or whatever). Trying it yourself only
complicates stuff -- and adding Breaks for this kind of stuff is even
against the policy if you want to read it that way: §7.4
Neither Breaks nor Conflicts should be used unless two packages
cannot be installed at the same time or installing them both causes
one of them to be broken or unusable. Having similar functionality or
performing the same tasks as another package is not sufficient
reason to declare Breaks or Conflicts with that package.
Or in short: either make empty dummy packages out of them or
just leave them alone.
Best regards
David Kalnischkies
P.S.: The first option will be revisited and properly enhanced at the time
of wheezy (aka disappearing packages) but let us talk about that later…
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktinb2eg+=+pmhkjrmkcf6t6pwcru-hqd+jfdq...@mail.gmail.com
Re: Full install/removal/upgrade test results available
David Kalnischkies kalnischk...@gmail.com writes: Before you ask, no, debian has no way to say: this package is obsolete - its fine that it will be removed as other packages take care of its tasks. The closest thing to that is §7.6.2, but i doubt that this is really such a drop-in replacement in your case. (and that doesn't say anything about an upgrade path, too) Also note that no frontend has ever made use of §7.6.2 and handled upgrading obsolete packages to their replacements. This is usualy done by providing a dummy package under the old name that depends on the new name. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lj4p6sa4@frosties.localnet
Re: Full install/removal/upgrade test results available
On ven., 2010-11-19 at 19:23 +0100, David Kalnischkies wrote: So, go and start reading. Debian has a lot of dependencies and you have a lot of possibilities because of that. You can't use them if you don't know them. And, more important, you can't blame APT for being stupid if you don't know what you talk about yourself. Well, I thought that Recommends: and Depends: were different things, which looks to me like a fair assumption. It seems I'm wrong. Oh, and I don't really like your tone, and I'm not usually offended by rudeness. By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't work either, apt will still prefer to hold xfce4-session and keep xfce4-mcs-*. You have way more information than APT - for example: Is it communicated that xfce4-mcs-manager and xfce4-mcs-plugin are now obsolete? No. All which is said is that the new xfce4-session doesn't work with them (it breaks them). No, xfce4-session depends on xfce4-settings. And xfce4-settings *replaces* xfce4-mcs-*. So, for APT its clear that we loose two packages just to get another one upgraded… that doesn't feel right. Even with the Replaces: bit? Before you ask, no, debian has no way to say: this package is obsolete - its fine that it will be removed as other packages take care of its tasks. The closest thing to that is §7.6.2, but i doubt that this is really such a drop-in replacement in your case. (and that doesn't say anything about an upgrade path, too) Well, it is a replacement, and I don't see such a thing as “drop-in” replacement (and this is not a virtual package). So, to solve your problem, you have more or less only one option: Do not try to clean up behind you, let the package managers do it (with autoremove or deborphan or whatever). Trying it yourself only complicates stuff -- and adding Breaks for this kind of stuff is even against the policy if you want to read it that way: §7.4 Except that in my case, I'm more in the $7.6. I'm not adding Conflicts/Replaces just because I'd like to force people to get rid of xfce4-mcs-*, it's just that it xfce4-settings needs it. They both ship common files (along with xfce4-mcs-plugins) and xfce4-settings replaces the functionality provided by xfce4-mcs-manager. Neither Breaks nor Conflicts should be used unless two packages cannot be installed at the same time or installing them both causes one of them to be broken or unusable. Which is the case here, and why the fields were added in the first place. Or in short: either make empty dummy packages out of them or just leave them alone. Which would then need to Depends on xfce4-settings in order to provide the same set of functionality, adding complexity to the dependencies. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Full install/removal/upgrade test results available
Goswin von Brederlow goswin-...@web.de writes: Also note that no frontend has ever made use of §7.6.2 and handled upgrading obsolete packages to their replacements. There's a reason for that: it's not possible to create a Policy-compliant package that could use 7.6.2 in that fashion. I keep trying to point this out each time you bring this up. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipzt7zz6@windlord.stanford.edu
Re: Full install/removal/upgrade test results available
On Fri, Nov 19, 2010 at 22:10, Yves-Alexis Perez cor...@debian.org wrote: On ven., 2010-11-19 at 19:23 +0100, David Kalnischkies wrote: So, go and start reading. Debian has a lot of dependencies and you have a lot of possibilities because of that. You can't use them if you don't know them. And, more important, you can't blame APT for being stupid if you don't know what you talk about yourself. Well, I thought that Recommends: and Depends: were different things, which looks to me like a fair assumption. It seems I'm wrong. Oh, and I don't really like your tone, and I'm not usually offended by rudeness. And i am usually not offended by someone blaming APT to be too dumb. APT is all about dependency resolution, so saying you are not to deep into it, but blaming APT to be wrong isn't the best tone either. Draw i would say… By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't work either, apt will still prefer to hold xfce4-session and keep xfce4-mcs-*. You have way more information than APT - for example: Is it communicated that xfce4-mcs-manager and xfce4-mcs-plugin are now obsolete? No. All which is said is that the new xfce4-session doesn't work with them (it breaks them). No, xfce4-session depends on xfce4-settings. And xfce4-settings *replaces* xfce4-mcs-*. So, for APT its clear that we loose two packages just to get another one upgraded… that doesn't feel right. Even with the Replaces: bit? Great, just that Replaces: only says that some files will be replaced, not the complete package… (so its mostly only used by dpkg). APT currently Replaces: manpages-pl as it ships its own manpage translation now. Should APT assume now while upgrading itself that it is a complete replacement for manpages-pl ? My example with apt and java is similar: They will declare Replaces and Breaks as they conflict on filename usage and installing the one breaks the other… java is still no valid upgrade path for apt nor vise versa. So, to solve your problem, you have more or less only one option: Do not try to clean up behind you, let the package managers do it (with autoremove or deborphan or whatever). Trying it yourself only complicates stuff -- and adding Breaks for this kind of stuff is even against the policy if you want to read it that way: §7.4 Except that in my case, I'm more in the $7.6. I'm not adding Conflicts/Replaces just because I'd like to force people to get rid of xfce4-mcs-*, it's just that it xfce4-settings needs it. They both ship common files (along with xfce4-mcs-plugins) They ship common files = Replaces Or is xfce4-mcs-plugins broken now that you replaces some of its files? (or better as footnote 46 suggests: Does it hurt if the files are gone?) Then it really also Breaks:, but you also give the indication that something in xfce4-mcs-plugins is left which can be broken and therefore functionality is lost by removing it… (or allowing the other package to replace files of it in the first place). So you might want to provide a new xfce4-mcs-plugins without these files (by depending on them) which still provides this functionality (or nothing as a dummy package). and xfce4-settings replaces the functionality provided by xfce4-mcs-manager. dummy xfce4-mcs-manager depending on xfce4-settings if it is a package rename. If its not, but they do not conflict just leave xfce4-mcs-manager alone. If they conflict as they use the same files, its the same as with the other package… Or in short: either make empty dummy packages out of them or just leave them alone. Which would then need to Depends on xfce4-settings in order to provide the same set of functionality, adding complexity to the dependencies. In general positive dependencies are easier to satisfy than negative as it is easier to install another package than to remove an installed. If we install a new package we have a relatively low probability that a negative dependency will effect it later. If we remove a package we can be nearly sure that another package depends on it and is now broken. (why would it be installed otherwise?) Also, a user normally doesn't complain too much if new functionality is added, but heavily if some functionality is gone without good reason… And the good reason is why APT doesn't remove the package on the breaks - the 'Considering' line in the output shows the scores the packages have. 0 vs 0 isn't a strong thing. If more packages would depend on one of the packages the decision will follow the highest scoring package. To go back to the apt and java example: On most systems, far more packages depend on apt, so if APT would need to choose, between the two it would choose apt - but if the system is full of java packages it might choose to prefer java instead -- depending on how broken the system is after deciding for one of the sides. And as the system is more broken if xfce4-session is upgraded, why should APT walk this way… Best regards David
Re: Full install/removal/upgrade test results available
On Fri, Nov 19, 2010 at 01:41:49PM -0800, Russ Allbery wrote: Goswin von Brederlow goswin-...@web.de writes: Also note that no frontend has ever made use of §7.6.2 and handled upgrading obsolete packages to their replacements. There's a reason for that: it's not possible to create a Policy-compliant package that could use 7.6.2 in that fashion. Wait, what? Are you saying that other parts of Policy conflict with §7.6.2? Or are you saying that the Debian tools and infrastructure don't support it? Or something else entirely? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Full install/removal/upgrade test results available
brian m. carlson sand...@crustytoothpaste.net writes: On Fri, Nov 19, 2010 at 01:41:49PM -0800, Russ Allbery wrote: Goswin von Brederlow goswin-...@web.de writes: Also note that no frontend has ever made use of §7.6.2 and handled upgrading obsolete packages to their replacements. There's a reason for that: it's not possible to create a Policy-compliant package that could use 7.6.2 in that fashion. Wait, what? Are you saying that other parts of Policy conflict with §7.6.2? Or are you saying that the Debian tools and infrastructure don't support it? Or something else entirely? Ack, sorry. I was completely wrong on this because I assumed I knew what Goswin was talking about but confused this with a previous discussion. No, 7.6.2 doesn't contradict other parts of Policy, and I'm not familiar with the issues in using that for transitional packages (other than the general problem that Conflicts Is Hard To Get Right). I thought Gowsin was talking about 7.6.*1*, the provision where packages are removed if all of their files are replaced, which isn't a usable way to eliminate transitional packages due to other Policy requirements. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjywzoqk@windlord.stanford.edu
Re: Full install/removal/upgrade test results available
On Wed, 2010-11-17 at 08:37 -0600, Lucas Nussbaum wrote: [...] Debian Kernel Team debian-ker...@lists.debian.org linux-image-2.6-amd64 linux-image-2.6.32-5-amd64 linux-image-2.6.32-5-amd64-dbg linux-image-amd64 [...] Removal of linux-image-2.6.32-5-amd64 failed because: You are running a kernel (version 2.6.32-5-amd64) and attempting to remove the same version. This can make the system unbootable as it will remove /boot/vmlinuz-2.6.32-5-amd64 and all modules under the directory /lib/modules/2.6.32-5-amd64. This can only be fixed with a copy of the kernel image and the corresponding modules. It is highly recommended to abort the kernel removal unless you are prepared to fix the system after removal. and your script naturally sets DEBIAN_FRONTEND=noninteractive, so debconf takes the default answer (abort removal). The other packages all depend on this one. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Full install/removal/upgrade test results available
Tshepang Lekhonkhobe tshep...@gmail.com wajig (U) Can someone help me. I don't understand what the problem here is: http://people.debian.org/~lucas/logs/2010/11/17/wajig.log -- blog: http://tshepang.tumblr.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=6lu+m+vhfjns7fuxrfr2ek5ccmac8sd=9m...@mail.gmail.com
Re: Full install/removal/upgrade test results available
On 18/11/10 at 12:10 +0200, Tshepang Lekhonkhobe wrote: Tshepang Lekhonkhobe tshep...@gmail.com wajig (U) Can someone help me. I don't understand what the problem here is: http://people.debian.org/~lucas/logs/2010/11/17/wajig.log Apparently, upgrading apt to the squeeze version at the beginning of the upgrade process causes python-apt and wajig to be removed. That looks like a suboptimal choice by APT. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118124659.ga30...@xanadu.blop.info
Re: Full install/removal/upgrade test results available
On Wed, Nov 17, 2010 at 06:11:28PM -0600, Lucas Nussbaum wrote: On 17/11/10 at 22:34 +0100, Harald Jenny wrote: Hello Lucas, concerning the openswan* packages: http://people.debian.org/~lucas/logs/2010/11/17/openswan.log: Configuration file `/etc/ipsec.conf' == Modified (by you or by a script) since installation. == Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : background this process to examine the situation The default action is to keep your current version. *** ipsec.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing openswan (--configure): EOF on stdin at conffile prompt . . . Errors were encountered while processing: openswan E: Sub-process /usr/bin/dpkg returned an error code (1) I guess this problem arises because we need user input here, correct? Yes, but you shouldn't, since the file installed in lenny was not modified, so it's a bug somewhere. Well I'm fairly new to the maintainance of this package but I would guess the postinst of lenny modifies ipsec.conf... http://people.debian.org/~lucas/logs/2010/11/17/openswan-modules-dkms.log: dpkg: error processing linux-image-2.6.32-5-amd64 (--remove): subprocess installed pre-removal script returned error exit status 1 . . . Errors were encountered while processing: linux-image-2.6.32-5-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) And here it's the already mentioned kernel issue, am I right? Right Ok thanks - Lucas Kind regards Harald -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118001128.ga21...@xanadu.blop.info -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118164643.gb10...@harald-has.a-little-linux-box.at
Re: Full install/removal/upgrade test results available
On Thu, Nov 18, 2010 at 11:46 AM, Harald Jenny har...@a-little-linux-box.at wrote: On Wed, Nov 17, 2010 at 06:11:28PM -0600, Lucas Nussbaum wrote: On 17/11/10 at 22:34 +0100, Harald Jenny wrote: Hello Lucas, concerning the openswan* packages: http://people.debian.org/~lucas/logs/2010/11/17/openswan.log: Configuration file `/etc/ipsec.conf' == Modified (by you or by a script) since installation. == Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : background this process to examine the situation The default action is to keep your current version. *** ipsec.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing openswan (--configure): EOF on stdin at conffile prompt . . . Errors were encountered while processing: openswan E: Sub-process /usr/bin/dpkg returned an error code (1) I guess this problem arises because we need user input here, correct? Yes, but you shouldn't, since the file installed in lenny was not modified, so it's a bug somewhere. Well I'm fairly new to the maintainance of this package but I would guess the postinst of lenny modifies ipsec.conf... It does[0]. This was filed as #515098 and #515095, which was fixed post-Lenny. [0]: http://ur1.ca/2dja1 -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik-u1pw5emofztpiwwmeb2e9kuycdrwhnjdk...@mail.gmail.com
Re: Full install/removal/upgrade test results available
On Thu, Nov 18, 2010 at 12:12:39PM -0500, James Vega wrote: On Thu, Nov 18, 2010 at 11:46 AM, Harald Jenny har...@a-little-linux-box.at wrote: On Wed, Nov 17, 2010 at 06:11:28PM -0600, Lucas Nussbaum wrote: On 17/11/10 at 22:34 +0100, Harald Jenny wrote: Hello Lucas, concerning the openswan* packages: http://people.debian.org/~lucas/logs/2010/11/17/openswan.log: Configuration file `/etc/ipsec.conf' == Modified (by you or by a script) since installation. == Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : background this process to examine the situation The default action is to keep your current version. *** ipsec.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing openswan (--configure): EOF on stdin at conffile prompt . . . Errors were encountered while processing: openswan E: Sub-process /usr/bin/dpkg returned an error code (1) I guess this problem arises because we need user input here, correct? Yes, but you shouldn't, since the file installed in lenny was not modified, so it's a bug somewhere. Well I'm fairly new to the maintainance of this package but I would guess the postinst of lenny modifies ipsec.conf... It does[0]. This was filed as #515098 and #515095, which was fixed post-Lenny. Ok so the problem is not the upcoming Squeeze package but rather the old Lenny one... [0]: http://ur1.ca/2dja1 -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik-u1pw5emofztpiwwmeb2e9kuycdrwhnjdk...@mail.gmail.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118172412.gd11...@harald-has.a-little-linux-box.at
Re: Full install/removal/upgrade test results available
On mer., 2010-11-17 at 08:37 -0600, Lucas Nussbaum wrote: I have been working on a piuparts rewrite that makes it easier to find install/removal/upgrade bugs. When running it on all packages in squeeze, I'm currently getting 682 failures. That doesn't mean 682 RC bugs, because some of the failures are caused by bugs in other packages, or only exhibit when the debconf frontend is set to noninteractive, or are caused by dbconfig-common problems, etc. But still, there's a fair number of issues that should be fixed in squeeze. I've tried to investigate xfce4-session upgrade failure. I've reproduced it in a lenny chroot, but I can't explain apt-get behavior: Investigating (0) xfce4-settings [ amd64 ] none - 4.6.5-2 ( xfce ) Broken xfce4-settings:amd64 Conflicts on xfce4-mcs-plugins [ amd64 ] 4.4.2-4 ( x11 ) Considering xfce4-mcs-plugins:amd64 0 as a solution to xfce4-settings:amd64 0 Holding Back xfce4-settings:amd64 rather than change xfce4-mcs-plugins:amd64 Investigating (0) xfce4-session [ amd64 ] 4.4.2-6 - 4.6.2-2 ( xfce ) Broken xfce4-session:amd64 Depends on xfce4-settings [ amd64 ] none - 4.6.5-2 ( xfce ) Considering xfce4-settings:amd64 0 as a solution to xfce4-session:amd64 0 Holding Back xfce4-session:amd64 rather than change xfce4-settings:amd64 Try to Re-Instate (1) xfce4-session:amd64 Done xfce4-session (4.6.2-2) depends on xfce4-settings which in turns Conflicts: xfce4-mcs-plugins. For some reason, apt-get doesn't want to remove xfce4-mcs-plugins and prefers to keep xfce4-settings uninstalled, and thus xfce4-session at the previous version. Anyone knows why and how to fix that? Would a “breaks” instead of a “conflicts” fix it? Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Full install/removal/upgrade test results available
Hi Lucas,
thanks for the tests, I think this is much appreciated.
I checked my package install-info and that was a false positive,
the removal test failed - of course - becasue install-info is
an essential package, so removing it needs typing in
Yes, do as I say!
;-)
Again, thanks for doing the tests.
Best wishes
Norbert
Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
LOUTH (n.)
The sort of man who wears loud check jackets, has a personalised
tankard behind the bar and always gets served before you do.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101117145035.ga29...@gamma.logic.tuwien.ac.at
Re: Full install/removal/upgrade test results available
On 17/11/10 at 23:50 +0900, Norbert Preining wrote: Hi Lucas, thanks for the tests, I think this is much appreciated. I checked my package install-info and that was a false positive, the removal test failed - of course - becasue install-info is an essential package, so removing it needs typing in Yes, do as I say! Yup, the case of essential packages is a bit hard to deal with. I check if a package is Essential: yes and do not remove them, but that's not the case of install-info. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101117150027.ga29...@xanadu.blop.info
Re: Full install/removal/upgrade test results available
Hi Lucas, On Mittwoch, 17. November 2010, Lucas Nussbaum wrote: I'm looking for people willing to work on such tools and mass bug filings (that also include archive rebuilds). I'm getting a bit tired of working on that myself, and might stop after squeeze. Understandable. Please dont stop! :-) I'd still like to work together with you, but its a bit hard, with two different tools now... Also, for proper credits, I should say that the results were obtained using the Grid'5000 platform. Testing the ~28300 packages in squeeze took ~12 hours using 20 compute nodes. The performance suffered greatly from the dpkg sync/fsync issues, even if I'm running the tests on tmpfs, because I'm swapping a bit, so sync() requires swapping in some data. I'll have to investigate how to work around that. I've heard that apt-get install eatmydata ; eatmydata piuparts $options will help greatly, I haven't yet actually tried myself though. Full dd-list (binary packages): --- Holger Levsen hol...@debian.org Ups, thanks! Will take a look now. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Full install/removal/upgrade test results available
[Debian Edu people please read below at /education-/] Hi Lucas, thanks for all your QA efforts! On Wed, Nov 17, 2010 at 08:37:17AM -0600, Lucas Nussbaum wrote: [1] http://people.debian.org/~lucas/logs/2010/11/17/ Full dd-list (binary packages): --- Andreas Tille ti...@debian.org cimg-dev (U) I checked for cimg-dev in http://people.debian.org/~lucas/logs/2010/11/17/cimg-dev.log and found only one hint of a failure when it says: -- New version is unstable version: FAILED (UNINSTALLED != 1.3.9-1) but from reasing the log I can not find any hint for this problem. Is this possibly one of the cases where some dependencies show a problem? Any help reading the log properly is welcome. dict-wn (U) http://people.debian.org/~lucas/logs/2010/11/17/dict-wn.log ... Installing new version of config file /etc/dictd/dictd.conf ... Installing new version of config file /etc/init.d/dictd ... insserv: warning: current stop runlevel(s) (0 1 6) of script `dictd' overwrites defaults (1). invoke-rc.d: policy-rc.d denied execution of start. -- Finding version of dict-wn: 1:3.0-18 -- New version is unstable version: OK E: 10mount: umount: /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b/dev: device is busy. E: 10mount: (In some cases useful info about processes that use E: 10mount: the device is found by lsof(8) or fuser(1)) E: llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b: Chroot setup failed: stage=setup-stop Cleanup of chroot llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b failed. Running processes: /dc/debcluster/scripts/tasks/instest.rb:5: command not found: lsof -t +D /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b E: 10mount: umount: /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b/dev: device is busy. E: 10mount: (In some cases useful info about processes that use E: 10mount: the device is found by lsof(8) or fuser(1)) E: llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b: Chroot setup failed: stage=setup-stop This does look like a bug rather in dict than in dict-wn. However, if my assumption would be correct I would expect all other dict dictionaries to fail and thus I wonder if I missinterpreted this log. education-desktop-kde (U) education-thin-client (U) education-thin-client-server (U) education-workstation (U) I have looked into these logs and think they are caused by dependant packages. The only probable exception might be education-thin-client http://people.debian.org/~lucas/logs/2010/11/17/education-thin-client.log which says: -- Finding version: education-thin-client 0.850 -- Finding depends: ... long list deleted here -- Installing depends: FAILED This might be some missing dependency in the metapackage. None of the above should be related to the following problem of the metapackages in the other Blends. The following packages are a consequence of bugs #577062 and #601959 which I'm working on. junior-arcade (U) junior-art (U) junior-games-card (U) junior-games-gl (U) junior-games-net (U) junior-games-sim (U) junior-games-text (U) junior-gnome (U) junior-internet (U) junior-kde (U) junior-math (U) junior-programming (U) junior-puzzle (U) junior-sound (U) junior-system (U) junior-toys (U) junior-typing (U) junior-writing (U) med-bio (U) med-bio-dev (U) med-epi (U) med-imaging (U) med-imaging-dev (U) med-pharmacy (U) med-physics (U) med-practice (U) med-tools (U) med-typesetting (U) science-astronomy (U) science-biology (U) science-chemistry (U) science-electronics (U) science-engineering (U) science-geography (U) science-linguistics (U) science-mathematics (U) science-mathematics-dev (U) science-physics (U) science-robotics (U) science-statistics (U) science-typesetting (U) science-viewing (U) -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101117150728.gc26...@an3as.eu
Re: Full install/removal/upgrade test results available
On 2010-11-17 15:50 +0100, Norbert Preining wrote: I checked my package install-info and that was a false positive, the removal test failed - of course - becasue install-info is an essential package, so removing it needs typing in Yes, do as I say! Or rather apt treats install-info as essential even though it is not; see #601961. Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3q4oulz@turtle.gmx.de
Re: Full install/removal/upgrade test results available
Hi, On Mittwoch, 17. November 2010, Andreas Tille wrote: education-desktop-kde (U) education-thin-client (U) education-thin-client-server (U) education-workstation (U) I have looked into these logs and think they are caused by dependant packages. The only probable exception might be education-thin-client http://people.debian.org/~lucas/logs/2010/11/17/education-thin-client.log nope, thats a false-negative and fine, it depends on ltsp-client-core which is one of out 4 packages (out of 30k!) which IMO qualify for special treatment by piuparts. ltsp-client-core must not be installed on normal systems, therefore (like with fai-nfsroot) the installation fails. education-thin-client-server and education-workstation OTOH do show RC bugs: dpkg: considering deconfiguration of python-apt, which would be broken by installation of python-apt-common ... dpkg: yes, will deconfigure python-apt (broken by python-apt-common). Unpacking python-apt-common (from .../python-apt-common_0.7.98.1_all.deb) ... De-configuring python-apt ... dpkg: error processing /var/cache/apt/archives/python-apt-common_0.7.98.1_all.deb (--unpack): trying to overwrite `/usr/share/python-apt/templates/Debian.info', which is also in package python-apt And education-desktop-kde too but another: Unpacking kdebase-workspace-bin (from .../kdebase-workspace-bin_4%3a4.4.5-4_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/kdebase-workspace-bin_4%3a4.4.5-4_amd64.deb (--unpack): trying to overwrite `/usr/bin/kcheckrunning', which is also in package kdesktop configured to not write apport reports cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Full install/removal/upgrade test results available
On 17/11/10 at 16:07 +0100, Andreas Tille wrote: [Debian Edu people please read below at /education-/] Hi Lucas, thanks for all your QA efforts! On Wed, Nov 17, 2010 at 08:37:17AM -0600, Lucas Nussbaum wrote: [1] http://people.debian.org/~lucas/logs/2010/11/17/ Full dd-list (binary packages): --- Andreas Tille ti...@debian.org cimg-dev (U) I checked for cimg-dev in http://people.debian.org/~lucas/logs/2010/11/17/cimg-dev.log and found only one hint of a failure when it says: -- New version is unstable version: FAILED (UNINSTALLED != 1.3.9-1) but from reasing the log I can not find any hint for this problem. Is this possibly one of the cases where some dependencies show a problem? Any help reading the log properly is welcome. So, that one is an interesting case, and there are several occurences of this. It might be a problem in APT. What happens is that, if you install cimg-dev on lenny, and then upgrade to squeeze, cimg-dev gets removed. But after the upgrade, you can safely reinstall it. It might be caused by the handling of Breaks in APT. I'm not sure. dict-wn (U) http://people.debian.org/~lucas/logs/2010/11/17/dict-wn.log ... Installing new version of config file /etc/dictd/dictd.conf ... Installing new version of config file /etc/init.d/dictd ... insserv: warning: current stop runlevel(s) (0 1 6) of script `dictd' overwrites defaults (1). invoke-rc.d: policy-rc.d denied execution of start. -- Finding version of dict-wn: 1:3.0-18 -- New version is unstable version: OK E: 10mount: umount: /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b/dev: device is busy. E: 10mount: (In some cases useful info about processes that use E: 10mount: the device is found by lsof(8) or fuser(1)) E: llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b: Chroot setup failed: stage=setup-stop Cleanup of chroot llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b failed. Running processes: /dc/debcluster/scripts/tasks/instest.rb:5: command not found: lsof -t +D /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b E: 10mount: umount: /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b/dev: device is busy. E: 10mount: (In some cases useful info about processes that use E: 10mount: the device is found by lsof(8) or fuser(1)) E: llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b: Chroot setup failed: stage=setup-stop This does look like a bug rather in dict than in dict-wn. However, if my assumption would be correct I would expect all other dict dictionaries to fail and thus I wonder if I missinterpreted this log. It seems that after installation of dict-wn, there's a process that is still running, so destroying the chroot fails. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101117182854.ga31...@xanadu.blop.info
Re: Full install/removal/upgrade test results available
Lucas Nussbaum lu...@lucas-nussbaum.net writes: Russ Allbery r...@debian.org libpam-afs-session libpam-openafs-kaserver openafs-client openafs-dbg openafs-dbserver openafs-fileserver openafs-kpasswd openafs-modules-dkms Bug in dpkg. Nothing that the openafs packages can do anything about so far as I can tell. libsaml2-dev (U) libshibsp-dev (U) libxml-security-c-dev (U) libxmltooling-dev (U) I have no idea what these would be about. I can go take a look and try to figure it out, but help is definitely welcome. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqu3lrby@windlord.stanford.edu
Re: Full install/removal/upgrade test results available
On 17/11/10 at 10:48 -0800, Russ Allbery wrote: Lucas Nussbaum lu...@lucas-nussbaum.net writes: Russ Allbery r...@debian.org libpam-afs-session libpam-openafs-kaserver openafs-client openafs-dbg openafs-dbserver openafs-fileserver openafs-kpasswd openafs-modules-dkms Bug in dpkg. Nothing that the openafs packages can do anything about so far as I can tell. Actually, the problem here is that the kernel being removed has the same version as the running kernel (the compute nodes run squeeze), that debconf warns about it, but that the warning is not see due to the non-interactive debconf frontend. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101117185449.ga...@xanadu.blop.info
Re: Full install/removal/upgrade test results available
Lucas Nussbaum lu...@lucas-nussbaum.net writes: On 17/11/10 at 10:48 -0800, Russ Allbery wrote: Lucas Nussbaum lu...@lucas-nussbaum.net writes: Russ Allbery r...@debian.org libpam-afs-session libpam-openafs-kaserver openafs-client openafs-dbg openafs-dbserver openafs-fileserver openafs-kpasswd openafs-modules-dkms Bug in dpkg. Nothing that the openafs packages can do anything about so far as I can tell. Actually, the problem here is that the kernel being removed has the same version as the running kernel (the compute nodes run squeeze), that debconf warns about it, but that the warning is not see due to the non-interactive debconf frontend. Ah, yes, you're right. I was assuming this was the standard piuparts problem with openafs, which is a dpkg bug, but you're actually doing something different that ran into a different issue. Sorry about the noise there. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipzvlqy6@windlord.stanford.edu
Re: Full install/removal/upgrade test results available
Lucas Nussbaum lu...@lucas-nussbaum.net writes: Russ Allbery r...@debian.org libsaml2-dev (U) libshibsp-dev (U) libxml-security-c-dev (U) libxmltooling-dev (U) These are all the same problem, I think, but I don't understand the problem. It's an inability to upgrade from lenny to squeeze that's blocking because of a problem with Xerces-C: Investigating (0) libxml-security-c-dev [ amd64 ] 1.4.0-3+lenny2 - 1.5.1-3 ( libdevel ) Broken libxml-security-c-dev:amd64 Depends on libxerces-c-dev [ amd64 ] none - 3.1.1-1+b1 ( libdevel ) Considering libxerces-c-dev:amd64 1 as a solution to libxml-security-c-dev:amd64 -1 Holding Back libxml-security-c-dev:amd64 rather than change libxerces-c-dev:amd64 but I don't understand why it's not upgrading libxerces-c-dev, which is the correct solution. libxerces-c-dev itself didn't fail, which makes this even more mystifying. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eiajlqu0@windlord.stanford.edu
Re: Full install/removal/upgrade test results available
I checked for cimg-dev in http://people.debian.org/~lucas/logs/2010/11/17/cimg-dev.log and found only one hint of a failure when it says: -- New version is unstable version: FAILED (UNINSTALLED != 1.3.9-1) but from reasing the log I can not find any hint for this problem. Is this possibly one of the cases where some dependencies show a problem? Any help reading the log properly is welcome. So, that one is an interesting case, and there are several occurences of this. It might be a problem in APT. What happens is that, if you install cimg-dev on lenny, and then upgrade to squeeze, cimg-dev gets removed. But after the upgrade, you can safely reinstall it. It might be caused by the handling of Breaks in APT. I'm not sure. I see exactly same situation with libetpan-dev package. signature.asc Description: This is a digitally signed message part.
Re: Full install/removal/upgrade test results available
On Wed, Nov 17, 2010 at 12:28:54PM -0600, Lucas Nussbaum wrote: I checked for cimg-dev in http://people.debian.org/~lucas/logs/2010/11/17/cimg-dev.log and found only one hint of a failure when it says: -- New version is unstable version: FAILED (UNINSTALLED != 1.3.9-1) but from reasing the log I can not find any hint for this problem. Is this possibly one of the cases where some dependencies show a problem? Any help reading the log properly is welcome. So, that one is an interesting case, and there are several occurences of this. It might be a problem in APT. What happens is that, if you install cimg-dev on lenny, and then upgrade to squeeze, cimg-dev gets removed. But after the upgrade, you can safely reinstall it. It might be caused by the handling of Breaks in APT. I'm not sure. So I have no idea what to do except waiting for other hints or somebody confirming that APT has a problem. dict-wn (U) http://people.debian.org/~lucas/logs/2010/11/17/dict-wn.log ... Installing new version of config file /etc/dictd/dictd.conf ... Installing new version of config file /etc/init.d/dictd ... insserv: warning: current stop runlevel(s) (0 1 6) of script `dictd' overwrites defaults (1). invoke-rc.d: policy-rc.d denied execution of start. -- Finding version of dict-wn: 1:3.0-18 -- New version is unstable version: OK E: 10mount: umount: /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b/dev: device is busy. E: 10mount: (In some cases useful info about processes that use E: 10mount: the device is found by lsof(8) or fuser(1)) E: llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b: Chroot setup failed: stage=setup-stop Cleanup of chroot llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b failed. Running processes: /dc/debcluster/scripts/tasks/instest.rb:5: command not found: lsof -t +D /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b E: 10mount: umount: /tmp/lucas/schroot/mount/llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b/dev: device is busy. E: 10mount: (In some cases useful info about processes that use E: 10mount: the device is found by lsof(8) or fuser(1)) E: llenny64-instest-0fa5a864-f08b-447b-955e-c3b7b7befe5b: Chroot setup failed: stage=setup-stop This does look like a bug rather in dict than in dict-wn. However, if my assumption would be correct I would expect all other dict dictionaries to fail and thus I wonder if I missinterpreted this log. It seems that after installation of dict-wn, there's a process that is still running, so destroying the chroot fails. I'm quoting the relevant part of dict-wn postinst resp. postrm: configure) if [ -x /usr/sbin/dictdconfig ]; then dictdconfig -w ;fi # if [ -x /etc/init.d/dictd ]; then /etc/init.d/dictd restart; fi if which invoke-rc.d /dev/null 21; then invoke-rc.d dictd restart else /etc/init.d/dictd restart fi exit 0 remove|purge) if [ -x /usr/sbin/dictdconfig ]; then dictdconfig -w ;fi # if [ -x /etc/init.d/dictd ]; then /etc/init.d/dictd restart; fi if which invoke-rc.d /dev/null 21; then invoke-rc.d dictd restart else /etc/init.d/dictd restart fi exit 0 Can you imagine that this might cause the problem? The other content of the package is simply a dictionary. So either the call of dictd init script is wrong or dictd itself has a problem. What do you think? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101117203352.ga7...@an3as.eu
Re: Full install/removal/upgrade test results available
Le mercredi 17 novembre 2010 à 21:33 +0100, Andreas Tille a écrit : On Wed, Nov 17, 2010 at 12:28:54PM -0600, Lucas Nussbaum wrote: So, that one is an interesting case, and there are several occurences of this. It might be a problem in APT. What happens is that, if you install cimg-dev on lenny, and then upgrade to squeeze, cimg-dev gets removed. But after the upgrade, you can safely reinstall it. It might be caused by the handling of Breaks in APT. I'm not sure. So I have no idea what to do except waiting for other hints or somebody confirming that APT has a problem. Same goes for rhythmbox and gnome-core, apparently, and the APT debug logs don’t make it easy to understand what happens. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Full install/removal/upgrade test results available
On 17/11/10 at 21:53 +0100, Josselin Mouette wrote: Le mercredi 17 novembre 2010 à 21:33 +0100, Andreas Tille a écrit : On Wed, Nov 17, 2010 at 12:28:54PM -0600, Lucas Nussbaum wrote: So, that one is an interesting case, and there are several occurences of this. It might be a problem in APT. What happens is that, if you install cimg-dev on lenny, and then upgrade to squeeze, cimg-dev gets removed. But after the upgrade, you can safely reinstall it. It might be caused by the handling of Breaks in APT. I'm not sure. So I have no idea what to do except waiting for other hints or somebody confirming that APT has a problem. Same goes for rhythmbox and gnome-core, apparently, and the APT debug logs don’t make it easy to understand what happens. There's already an open APT bug about upgrade issues (#591882, Cced). Ideally, we would have one bug per type of issue, but I'm having problem distinguishing the various issues here. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101117212203.ga14...@xanadu.blop.info
Re: Full install/removal/upgrade test results available
On Wed, 2010-11-17 at 21:33:52 +0100, Andreas Tille wrote: On Wed, Nov 17, 2010 at 12:28:54PM -0600, Lucas Nussbaum wrote: It seems that after installation of dict-wn, there's a process that is still running, so destroying the chroot fails. I'm quoting the relevant part of dict-wn postinst resp. postrm: remove|purge) if [ -x /usr/sbin/dictdconfig ]; then dictdconfig -w ;fi # if [ -x /etc/init.d/dictd ]; then /etc/init.d/dictd restart; fi if which invoke-rc.d /dev/null 21; then invoke-rc.d dictd restart else /etc/init.d/dictd restart fi exit 0 Can you imagine that this might cause the problem? The other content of the package is simply a dictionary. So either the call of dictd init script is wrong or dictd itself has a problem. What do you think? It's restarting (instead of stoppping) on remove/purge. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101117211635.ga6...@gaara.hadrons.org
Re: Full install/removal/upgrade test results available
On 2010-11-17 22:16 +0100, Guillem Jover wrote: On Wed, 2010-11-17 at 21:33:52 +0100, Andreas Tille wrote: On Wed, Nov 17, 2010 at 12:28:54PM -0600, Lucas Nussbaum wrote: It seems that after installation of dict-wn, there's a process that is still running, so destroying the chroot fails. I'm quoting the relevant part of dict-wn postinst resp. postrm: remove|purge) if [ -x /usr/sbin/dictdconfig ]; then dictdconfig -w ;fi # if [ -x /etc/init.d/dictd ]; then /etc/init.d/dictd restart; fi if which invoke-rc.d /dev/null 21; then invoke-rc.d dictd restart else /etc/init.d/dictd restart fi exit 0 Can you imagine that this might cause the problem? The other content of the package is simply a dictionary. So either the call of dictd init script is wrong or dictd itself has a problem. What do you think? It's restarting (instead of stoppping) on remove/purge. Could you elaborate? Surely a dictionary package should not stop the dictionary server when it is being removed, should it? Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxp7ocnp@turtle.gmx.de
Re: Full install/removal/upgrade test results available
On Wed, Nov 17, 2010 at 4:16 PM, Guillem Jover guil...@debian.org wrote: On Wed, 2010-11-17 at 21:33:52 +0100, Andreas Tille wrote: On Wed, Nov 17, 2010 at 12:28:54PM -0600, Lucas Nussbaum wrote: It seems that after installation of dict-wn, there's a process that is still running, so destroying the chroot fails. I'm quoting the relevant part of dict-wn postinst resp. postrm: remove|purge) if [ -x /usr/sbin/dictdconfig ]; then dictdconfig -w ;fi # if [ -x /etc/init.d/dictd ]; then /etc/init.d/dictd restart; fi if which invoke-rc.d /dev/null 21; then invoke-rc.d dictd restart else /etc/init.d/dictd restart fi exit 0 Can you imagine that this might cause the problem? The other content of the package is simply a dictionary. So either the call of dictd init script is wrong or dictd itself has a problem. What do you think? It's restarting (instead of stoppping) on remove/purge. Right, because dict-wn is just a database. It detects if a dict-server is installed and restarts it so it is aware of the change in available databases, but the restart was blocked (according to the log) due to the invoke-rc.d policy. This sounds like something (without having looked at the details) that would be prime for triggers instead of having the various database-providing package worry about what the server needs to do. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin_jitezhmv0ufotxfde77hc6ocarisbfw5z...@mail.gmail.com
Re: Full install/removal/upgrade test results available
On Wed, Nov 17, 2010 at 04:37:38PM -0500, James Vega wrote: I'm quoting the relevant part of dict-wn postinst resp. postrm: remove|purge) if [ -x /usr/sbin/dictdconfig ]; then dictdconfig -w ;fi # if [ -x /etc/init.d/dictd ]; then /etc/init.d/dictd restart; fi if which invoke-rc.d /dev/null 21; then invoke-rc.d dictd restart else /etc/init.d/dictd restart fi exit 0 It's restarting (instead of stoppping) on remove/purge. Right, because dict-wn is just a database. It detects if a dict-server is installed and restarts it so it is aware of the change in available databases, but the restart was blocked (according to the log) due to the invoke-rc.d policy. This exactly was intended. This sounds like something (without having looked at the details) that would be prime for triggers instead of having the various database-providing package worry about what the server needs to do. If I understand this correctly this has to be fixed in the dict package first and then all dict-database providing packages need to be adapted, right. I wonder whether this is a thing we should do for Squeeze. IMHO the upgrade works fine and thus is not RC critical. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101117222401.gd9...@an3as.eu
Re: Full install/removal/upgrade test results available
Hello Lucas, concerning the openswan* packages: http://people.debian.org/~lucas/logs/2010/11/17/openswan.log: Configuration file `/etc/ipsec.conf' == Modified (by you or by a script) since installation. == Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : background this process to examine the situation The default action is to keep your current version. *** ipsec.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing openswan (--configure): EOF on stdin at conffile prompt . . . Errors were encountered while processing: openswan E: Sub-process /usr/bin/dpkg returned an error code (1) I guess this problem arises because we need user input here, correct? http://people.debian.org/~lucas/logs/2010/11/17/openswan-modules-dkms.log: dpkg: error processing linux-image-2.6.32-5-amd64 (--remove): subprocess installed pre-removal script returned error exit status 1 . . . Errors were encountered while processing: linux-image-2.6.32-5-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) And here it's the already mentioned kernel issue, am I right? Thanks very much for the valuable work you provide! Kind regards Harald Jenny -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101117213402.ga9...@harald-has.a-little-linux-box.at
Re: Full install/removal/upgrade test results available
On 17/11/10 at 22:34 +0100, Harald Jenny wrote: Hello Lucas, concerning the openswan* packages: http://people.debian.org/~lucas/logs/2010/11/17/openswan.log: Configuration file `/etc/ipsec.conf' == Modified (by you or by a script) since installation. == Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : background this process to examine the situation The default action is to keep your current version. *** ipsec.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing openswan (--configure): EOF on stdin at conffile prompt . . . Errors were encountered while processing: openswan E: Sub-process /usr/bin/dpkg returned an error code (1) I guess this problem arises because we need user input here, correct? Yes, but you shouldn't, since the file installed in lenny was not modified, so it's a bug somewhere. http://people.debian.org/~lucas/logs/2010/11/17/openswan-modules-dkms.log: dpkg: error processing linux-image-2.6.32-5-amd64 (--remove): subprocess installed pre-removal script returned error exit status 1 . . . Errors were encountered while processing: linux-image-2.6.32-5-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) And here it's the already mentioned kernel issue, am I right? Right - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118001128.ga21...@xanadu.blop.info
Re: Full install/removal/upgrade test results available
On Wed, 2010-11-17 at 22:36:42 +0100, Sven Joachim wrote: On 2010-11-17 22:16 +0100, Guillem Jover wrote: It's restarting (instead of stoppping) on remove/purge. Could you elaborate? Surely a dictionary package should not stop the dictionary server when it is being removed, should it? Err, right, nevermind and sorry for the noise. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118025616.ga10...@gaara.hadrons.org
