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

Bug#782517: Could not configure, followed by Internal error, packages left unconfigured.



On Mon, Apr 13, 2015 at 06:05:35PM +0200, Joachim Breitner wrote:
> $ LANG=C sudo apt upgrade
[…]
> 2 upgraded, 0 newly installed, 0 to remove and 296 not upgraded.
> Need to get 0 B/47.5 kB of archives.
> After this operation, 138 kB disk space will be freed.
> Do you want to continue? [Y/n] 
> E: Could not configure 'libghc-data-lens-template-dev:amd64'. 
> E: Internal error, packages left unconfigured. libghc-data-lens-template-dev:amd64

Interesting. The difference between the commands can be explained:
'install' (and dist-upgrade) can do everything they want to, 'apt
upgrade' can install new and upgrade old packages but not remove them
and 'apt-get upgrade' can only upgrade packages, so different solutions
wouldn't be a problem.
That 'apt upgrade' is erroring out like that is one through as that
isn't supposed to happen…
And idealy the three wouldn't grossly disagree, but that just as a bonus…


Can you attach your /var/lib/dpkg/status file (preferable compressed) ?
[I think you know, but the usual disclaimer ramble anyhow: The file
contains information about ALL packages you have installed and in what
version. In case you don't want or can't expose these details to the
public, you can sent it to me privately, if that is acceptable for you]

Keeping the directory content of /var/lib/apt/lists someplace save might
come in handy, too, but please just back it up somewhere as the
resulting file would be too large and is usually not needed, if I can
get hold of the Packages files any other way.


>  libghc-data-lens-dev : Depends: libghc-comonad-dev-4.2.5-ae1b1 but it is not installable
>                         Depends: libghc-semigroupoids-dev-4.2-68274 but it is not installable

Looking at the package names here makes me believe some unofficial/
staging repository is involved through. Is that one public?


There are a bunch of debug flags we could try, but with ~300 packages
involved that is usually not too much fun to look at via mail…

Why solver comes to this solution:
-o Debug::pkgDepCache::AutoInstall=1
-o Debug::pkgDepCache::Marker=1
-o Debug::pkgProblemResolver=1

How the execution shedule looks and why:
-o Debug::pkgOrderList=1  (usually just noise through)
-o Debug::pkgPackageManager=1


Best regards

David Kalnischkies

Attachment: signature.asc
Description: Digital signature


Reply to: