[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#768054: when is it ok for a package to need "apt-get dist-upgrade" to upgrade?


On Freitag, 7. November 2014, Paul Gevers wrote:
> To be honest, I didn't mean that dist-upgrade was the way to fix this
> issue, but I meant that I wanted to know if it solved the issue.

ah, ok. That makes way more sense to me ;)

> I
> scanned the Internet and the error message seemed to be related to the
> behavior of apt (and that sort of made sense with how fpc is build up;
> see the "hold back" packages). And I still don't understand the error
> message, fp-units-multimedia-2.6.0 IS installed, so why complain about
> it not "going to be installed"

the log says:

The following packages have unmet dependencies:
 fp-units-multimedia : Depends: fp-units-multimedia-2.6.0 (= 2.6.0-9) but it 
is not going to be installed
 fpc-2.6.0 : Depends: fp-units-multimedia-2.6.0 (>= 2.6.0-9) but it is not 
going to be installed

which means: fp-units-multimedia depends on f-u-2.6.0 (=2.6.0-9) but this 
version is not _going to be_ installed once the upgrade is done, so apt 
refuses it. same for fpc-2.6.0....

> > second, the script does just that, for upgrading from $distro to $distro
> > this is done after updating sources.list:
> > 
> > apt-get update
> > apt-get -y upgrade
> > apt-get clean
> > apt-get -yf dist-upgrade
> > apt-get clean
> > apt-get -yf dist-upgrade
> > apt-get clean
> > apt-get -y autoremove
> Tried it, but it didn't reproduce in my clean wheezy pbuilder chroot.
> See attached log. I noticed that dpkg got an update, maybe related, so
> it would be good to reschedule a retry of the jenkins job.

all chroot-installation-wheezy* jobs run on the 4th and 18th of the month,
to be more verbose:

trigger_times = { 'squeeze': '30 16 25 * *',
                  'wheezy':  '30 16 4,18 * *',
                  'jessie':  '30 10 */2 * *',
                  'sid':     '30 4 * * *' }

I've also already rescheduled this job, so the result should be there soon...


(I've also added some output to the beginning of the script, so its more clear 
how to debug it:

+       echo 
+       echo
+       echo "$(date) - running job $JOB_NAME now."
+       echo
+       echo "To understand what this job does, clone 
+       echo "and then have a look at bin/$(basename $0)"
+       echo 
+       echo "This invocation of the script has been called using \"$@\" as 
+       echo 
+       echo "$(date) - start running \"$0\" as \"$TTT\"."
+       echo

> Sure, but we are lacking information about what is the real reason of
> the failure. Nobody has spotted it yet, which makes me believe as Peter
> did, that it is a problem in the dependency resolution.

sure, but this would still be a problem we should address for the release :) 
though I'm very fine having it tagged unreproducible for the moment...


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: