Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-12-09 Thread David Kalnischkies 
On Sun, Dec 04, 2016 at 04:13:47AM +0100, Guillem Jover wrote:
> On Tue, 2016-11-22 at 18:50:51 +0100, David Kalnischkies wrote:
> >  On Tue, Nov 22, 2016 at 02:43:35PM +0100, Vincent Lefevre wrote:
> > > --\ Packages to be upgraded (17)
> > […]
> > > iuA nvidia-driver-libs367.57-1 
> > > 367.57-2
> > […]
> > > --\ Packages being removed because they are no longer used (27)
> > […]
> > > idA nvidia-driver-libs:i386 -180 kB   367.57-1 
> > > 367.57-2
> > […]
> > > dpkg: error processing package nvidia-driver-libs:amd64 (--configure):
> > >  package nvidia-driver-libs:amd64 367.57-2 cannot be configured because 
> > > nvidia-driver-libs:i386 is at a different version (367.57-1)
> > 
> > This looks like a bug in dpkg as it is not considering the removal of
> > nvidia-driver-libs:i386 as solution to the problem it runs into here
> > even through libapt has told it via selections that it wants it removed.
> 
> Hmm, dpkg does not remove other packages at configure time, it only
> ever does that at unpack time. Removing this kind of packages at
> unpack time would seem gratuituous though, as it might or might not end

> up seeing an updated packages, and version-skew (I like screw too BTW :)

(skew vs screw – such a typical "david"…)


> is not a problem at unpack time anyway. Also remember that an unpack of
> the selected to be deinstalled package would reset that selection.

At least in terms of apt there is no situation in which a package would
be upgraded before its removed (the other way around exists). The only
time apt has to remember the reselection is with purged packages as it
removes them first nowadays.

So at least I would have no problem if --unpack would decide to remove
the "siblings" of a M-A:same package if they are marked for removal
given that this is what was requested anyhow even if the remove is
strictly speaking only needed at configure time.


> So, this seems like a new kind of feature to me. Also the frontends
> would need to handle the current dpkg anyway when doing upgrades, so
> it seems this needs to be handled in frontends right now no matter
> what?

libapt deals with this now (>= 1.4) and was effected only since recently
(as mentioned, it "confused" it with a crossgrade), so there is no hurry
needed from my PoV. It would be nice if we could stop doing (all)
explicit removals using selections only for removals eventually through,
but that is a buster topic…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-12-04 Thread Vincent Lefevre 
Control: retitle -1 dpkg: Please remove packages selected for deinstall on 
Multi-Arch version skew

(fixing a typo in the retitle)

On 2016-12-04 04:13:47 +0100, Guillem Jover wrote:
> Control: severity -1 wishlist
> Control: retitle -1 dpkg: Please remove packages seclected for deinstall on 
> Multi-Arch version skew
> 
> [ I'm actually a bit undecided whether this is normal or wishlist in dpkg
>   itself, see below. ]
[...]
> So, this seems like a new kind of feature to me. Also the frontends
> would need to handle the current dpkg anyway when doing upgrades, so
> it seems this needs to be handled in frontends right now no matter
> what?

Then a new bug should be opened against the frontends. Since this
can put the system in a broken state (and I suppose that this can
also affect stable with bad luck or due to an attack, as there is
no guarantee that two arch's are in sync), I suppose that this
should be grave.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-12-03 Thread Guillem Jover 
Control: severity -1 wishlist
Control: retitle -1 dpkg: Please remove packages seclected for deinstall on 
Multi-Arch version skew

[ I'm actually a bit undecided whether this is normal or wishlist in dpkg
  itself, see below. ]

[ BTW David, do not forget to CC pkgname@packages.d.o either! :) ]

Hi!

On Tue, 2016-11-22 at 18:50:51 +0100, David Kalnischkies wrote:
>  On Tue, Nov 22, 2016 at 02:43:35PM +0100, Vincent Lefevre wrote:
> > --\ Packages to be upgraded (17)
> […]
> > iuA nvidia-driver-libs367.57-1 
> > 367.57-2
> […]
> > --\ Packages being removed because they are no longer used (27)
> […]
> > idA nvidia-driver-libs:i386 -180 kB   367.57-1 
> > 367.57-2
> […]
> > dpkg: error processing package nvidia-driver-libs:amd64 (--configure):
> >  package nvidia-driver-libs:amd64 367.57-2 cannot be configured because 
> > nvidia-driver-libs:i386 is at a different version (367.57-1)
> 
> This looks like a bug in dpkg as it is not considering the removal of
> nvidia-driver-libs:i386 as solution to the problem it runs into here
> even through libapt has told it via selections that it wants it removed.

Hmm, dpkg does not remove other packages at configure time, it only
ever does that at unpack time. Removing this kind of packages at
unpack time would seem gratuituous though, as it might or might not end
up seeing an updated packages, and version-skew (I like screw too BTW :)
is not a problem at unpack time anyway. Also remember that an unpack of
the selected to be deinstalled package would reset that selection.

So, this seems like a new kind of feature to me. Also the frontends
would need to handle the current dpkg anyway when doing upgrades, so
it seems this needs to be handled in frontends right now no matter
what?

Thanks,
Guillem

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-22 Thread David Kalnischkies 
reassign -1 dpkg 1.18.15

(cutting down heavily on the text)

 On Tue, Nov 22, 2016 at 02:43:35PM +0100, Vincent Lefevre wrote:
> --\ Packages to be upgraded (17)
[…]
> iuA nvidia-driver-libs367.57-1 
> 367.57-2
[…]
> --\ Packages being removed because they are no longer used (27)
[…]
> idA nvidia-driver-libs:i386 -180 kB   367.57-1 
> 367.57-2
[…]
> dpkg: error processing package nvidia-driver-libs:amd64 (--configure):
>  package nvidia-driver-libs:amd64 367.57-2 cannot be configured because 
> nvidia-driver-libs:i386 is at a different version (367.57-1)

This looks like a bug in dpkg as it is not considering the removal of
nvidia-driver-libs:i386 as solution to the problem it runs into here
even through libapt has told it via selections that it wants it removed.

Reproducing is 'easy' with any M-A:same package which is installed for
two (or more) architectures in version 1 and one of the architectures is
upgraded to version 2 while the other is removed.


That said, you can see this bug with apt(itude) only as libapt
incorrectly detects a crossgrade here dropping the explicit remove.
As we (= libapt) want to eventually drop the explicit removes and other
frontends arguable have already like dselect I am reassigning to dpkg
– "fixing" (its closer to a workaround) this in libapt is partly done
already, so I don't need/want a clone.

In terms of the solution itself: I haven't looked closely, but apt tries
to not explore solutions caused by M-A:same version screw – aptitude
seems way more willing to suggest such solutions; that is okay I guess
as it is way more interactive, too.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#844300: [Aptitude-devel] Bug#844300: Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-22 Thread Vincent Lefevre 
On 2016-11-22 13:44:16 +0100, Axel Beckert wrote:
> Thanks for these additional details. I currently think that this might
> suffice to further track down the issue. So if the additional state
> bundle is too much effort, we'll see how far we come with this.

The bundle is very large (380 MB). I've temporarily put it here:

  https://www.dropbox.com/s/tc81xuaysj1eoen/aptitude.bundle.bz2?dl=0

It's SHA1 sum is:

6dc3b971059bb7391cf4f55b77605ac3987f4f0d  aptitude.bundle.bz2

Let's reproduce the bug...

1. Run aptitude as root.

2. Type "[".

3. Go to:

--\ non-free   Programs which are not free software (37)

4. Over this line, type "+" then "g".

I get:

i┌┐ 
i│Some packages were broken and have been fixed:  │ 
i││ 
i│Upgrade the following packages: │ 
i│libegl-nvidia0 [367.57-1 (now, testing) -> 367.57-2 (unstable)] │ 
-│libegl1-glvnd-nvidia [367.57-1 (now, testing) -> 367.57-2 (unstable)]   │
i│libgldispatch0-nvidia [367.57-1 (now, testing) -> 367.57-2 (unstable)]  │ 
i│libnvidia-eglcore [367.57-1 (now, testing) -> 367.57-2 (unstable)]  │ 
i│nvidia-driver [367.57-1 (now, testing) -> 367.57-2 (unstable)]  │ 
i│nvidia-driver-bin [367.57-1 (now, testing) -> 367.57-2 (unstable)]  │ 
i│nvidia-driver-libs [367.57-1 (now, testing) -> 367.57-2 (unstable)] │ 
i│nvidia-kernel-support [367.57-1 (now, testing) -> 367.57-2 (unstable)]  │ 
i│nvidia-vdpau-driver [367.57-1 (now, testing) -> 367.57-2 (unstable)]│ 
i│xserver-xorg-video-nvidia [367.57-1 (now, testing) -> 367.57-2 (unstable)]  │ 
 ││
T│Leave the following dependencies unresolved:│▒
 │nvidia-driver-libs recommends nvidia-driver-libs-i386   │▒
T│nvidia-driver-libs recommends libopengl0-glvnd-nvidia   │▒
 │nvidia-driver-libs recommends libglx-nvidia0 (= 367.57-2)   │▒
I│nvidia-driver-libs recommends libgles-nvidia1 (= 367.57-2)  │▒
t│nvidia-driver-libs recommends libgles-nvidia2 (= 367.57-2)  │▒
 │nvidia-driver-libs recommends libnvidia-cfg1 (= 367.57-2)   │▒
 │nvidia-driver-libs recommends nvidia-vulkan-icd (= 367.57-2)│▒
 ││▒
 │   [ Ok ]   │▒
 └┘▒

Note: The unresolved recommends are somewhat expected since the
nvidia packages have conflicting recommends (on purpose, according
to Luca). Anyway, this is not the problem.

5. Type [Enter] (i.e. OK).

I get:

--\ Packages to be upgraded (17)
   
iuA libegl-nvidia0367.57-1 367.57-2 
   
iuA libegl1-glvnd-nvidia  367.57-1 367.57-2 
   
iu  libgl1-nvidia-glx 367.57-1 367.57-2 
   
iu  libgl1-nvidia-glx:i386367.57-1 367.57-2 
   
iuA libgldispatch0-nvidia 367.57-1 367.57-2 
   
iuA libnvidia-eglcore 367.57-1 367.57-2 
   
iuA libnvidia-glcore  367.57-1 367.57-2 
   
iuA libnvidia-glcore:i386 367.57-1 367.57-2 
   
iuA libnvidia-ml1 367.57-1 367.57-2 
   
iuA nvidia-alternative367.57-1 367.57-2 
   
iuA nvidia-driver 367.57-1 367.57-2 
   
iuA nvidia-driver-bin 367.57-1 367.57-2 
   
iuA nvidia-driver-libs367.57-1 367.57-2 
   
iuA nvidia-kernel-support 367.57-1 367.57-2 
   
iuA nvidia-legacy-check   367.57-1 367.57-2 
   
iuA nvidia-vdpau-driver   367.57-1 367.57-2 
   
iuA xserver-xorg-video-nvidia 367.57-1 367.57-2 
   
--\ Packages being removed because they are no longer used (27)
idA libegl-nvidia0:i386 -863 kB   367.57-1 367.57-2 
   
idA libegl1-glvnd-nvidia:i386   -205 kB   367.57-1 367.57-2 
   
idA

Bug#844300: [Aptitude-devel] Bug#844300: Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-22 Thread Axel Beckert 
Control: tag -1 - moreinfo

Hi Vincent,

Vincent Lefevre wrote:
> On 2016-11-22 12:36:32 +0100, Axel Beckert wrote:
> > Vincent Lefevre wrote:
> > > In any case, if the dependencies are correct, the package system
> > > should never be put in a broken state.
> > 
> > I'm sorry but that's wrong. Maintainer scripts can still put packages
> > in a broken state even if dependencies are correct.
> 
> Hmmm... After a closer look, this seems more complex than I've
> thought. I've just noticed that the dpkg output does not match the
> aptitude log (I wasn't aware of that, hence my confusion), but the
> problem may also come from in which order operations on a group of
> packages is done. Perhaps a bug in dpkg.

At least in the apt case, the order comes from apt. I'm currently not
sure how much order control aptitude leaves to dpkg. mafm likely knows
that better than me.

> [REMOVE, NOT USED] nvidia-driver-libs:i386 367.57-1
> 
> So, nvidia-driver-libs:i386 is to be removed. But the only packages
> that have been removed in the dpkg output are:
> 
> Removing nvidia-driver-libs-i386:i386 (367.57-1) ...
> Removing libopengl0-glvnd-nvidia:i386 (367.57-1) ...
> Removing nvidia-vulkan-icd:i386 (367.57-1) ...
> Removing libglx-nvidia0:i386 (367.57-1) ...
> Removing libglx0-glvnd-nvidia:i386 (367.57-1) ...
> Removing libgles-nvidia2:i386 (367.57-1) ...
> Removing libgles2-glvnd-nvidia:i386 (367.57-1) ...
> Removing libgles-nvidia1:i386 (367.57-1) ...
> Removing libgles1-glvnd-nvidia:i386 (367.57-1) ...
> Removing libgles-nvidia1:amd64 (367.57-1) ...
> Removing libgles-nvidia2:amd64 (367.57-1) ...
> Removing libgles1-glvnd-nvidia:amd64 (367.57-1) ...
> Removing libgles2-glvnd-nvidia:amd64 (367.57-1) ...
> Removing nvidia-vulkan-icd:amd64 (367.57-1) ...
> Removing libglx-nvidia0:amd64 (367.57-1) ...
> Removing libglx0-glvnd-nvidia:amd64 (367.57-1) ...
> Removing libnvidia-cfg1:amd64 (367.57-1) ...
> Removing libnvidia-cfg1:i386 (367.57-1) ...
> Removing libopengl0-glvnd-nvidia:amd64 (367.57-1) ...
> Removing libvulkan1:i386 (1.0.26.0+dfsg1-1) ...
> Removing libvulkan1:amd64 (1.0.26.0+dfsg1-1) ...
> Removing nvidia-vulkan-common (367.57-1) ...
> 
> This does not include nvidia-driver-libs:i386.

Probably because it would have been removed only after the issues
happened.

> Then, the upgrades are performed, then the packages are configured,
> so that one gets the failure due to the missing removal:
> 
> dpkg: error processing package nvidia-driver-libs:amd64 (--configure):
>  package nvidia-driver-libs:amd64 367.57-2 cannot be configured because 
> nvidia-driver-libs:i386 is at a different version (367.57-1)
> 
> I suppose that nvidia-driver-libs:i386 should have been removed earlier.
> Whose fault is it?

Good question. What irritates me here is that this initially looked to
me like e.g. postinst script output, but there are no maintainer
scripts in the nvidia-driver-libs package, at least not on amd64.

So this seems indeed something dpkg requires but either aptitude or
libapt-inst didn't take care of when passing stuff to dpkg.

> > Anyways, in the whole correspondence I saw nowhere that you also tried
> > the same with apt or apt-get. Can you please check if upgrading these
> > packages with apt or apt-get leads to the same issue? (If so, it's
> > clearly no issue in aptitude.)
> 
> There are other issues with apt (basically about recommendations
> not being fulfilled, partly due to internal conflicts in the nvidia
> packages), but the system is always put in a consistent state (I've
> tried for installation only, not upgrade).

Thanks for clarifying this.

> I have not tried yet to reproduce the bug, because this was too late
> when it occurred.

I see.

Thanks for these additional details. I currently think that this might
suffice to further track down the issue. So if the additional state
bundle is too much effort, we'll see how far we come with this.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#844300: [Aptitude-devel] Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-22 Thread Vincent Lefevre 
On 2016-11-22 12:36:32 +0100, Axel Beckert wrote:
> Vincent Lefevre wrote:
> > In any case, if the dependencies are correct, the package system
> > should never be put in a broken state.
> 
> I'm sorry but that's wrong. Maintainer scripts can still put packages
> in a broken state even if dependencies are correct.

Hmmm... After a closer look, this seems more complex than I've
thought. I've just noticed that the dpkg output does not match the
aptitude log (I wasn't aware of that, hence my confusion), but the
problem may also come from in which order operations on a group of
packages is done. Perhaps a bug in dpkg.

The aptitude log is the following:

Aptitude 0.8.3: log report
Mon, Nov 14 2016 11:28:14 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 17 packages, and remove 27 packages.
44.5 MB of disk space will be freed

[REMOVE, NOT USED] libegl-nvidia0:i386 367.57-1
[REMOVE, NOT USED] libegl1-glvnd-nvidia:i386 367.57-1
[REMOVE, NOT USED] libgldispatch0-nvidia:i386 367.57-1
[REMOVE, NOT USED] libgles-nvidia1:amd64 367.57-1
[REMOVE, NOT USED] libgles-nvidia1:i386 367.57-1
[REMOVE, NOT USED] libgles-nvidia2:amd64 367.57-1
[REMOVE, NOT USED] libgles-nvidia2:i386 367.57-1
[REMOVE, NOT USED] libgles1-glvnd-nvidia:amd64 367.57-1
[REMOVE, NOT USED] libgles1-glvnd-nvidia:i386 367.57-1
[REMOVE, NOT USED] libgles2-glvnd-nvidia:amd64 367.57-1
[REMOVE, NOT USED] libgles2-glvnd-nvidia:i386 367.57-1
[REMOVE, NOT USED] libglx-nvidia0:amd64 367.57-1
[REMOVE, NOT USED] libglx-nvidia0:i386 367.57-1
[REMOVE, NOT USED] libglx0-glvnd-nvidia:amd64 367.57-1
[REMOVE, NOT USED] libglx0-glvnd-nvidia:i386 367.57-1
[REMOVE, NOT USED] libnvidia-cfg1:amd64 367.57-1
[REMOVE, NOT USED] libnvidia-cfg1:i386 367.57-1
[REMOVE, NOT USED] libnvidia-eglcore:i386 367.57-1
[REMOVE, NOT USED] libopengl0-glvnd-nvidia:amd64 367.57-1
[REMOVE, NOT USED] libopengl0-glvnd-nvidia:i386 367.57-1
[REMOVE, NOT USED] libvulkan1:amd64 1.0.26.0+dfsg1-1
[REMOVE, NOT USED] libvulkan1:i386 1.0.26.0+dfsg1-1
[REMOVE, NOT USED] nvidia-driver-libs:i386 367.57-1
[REMOVE, NOT USED] nvidia-driver-libs-i386:i386 367.57-1
[REMOVE, NOT USED] nvidia-vulkan-common:amd64 367.57-1
[REMOVE, NOT USED] nvidia-vulkan-icd:amd64 367.57-1
[REMOVE, NOT USED] nvidia-vulkan-icd:i386 367.57-1
[HOLD, DEPENDENCIES] evolution-common:amd64 3.22.1-2
[HOLD, DEPENDENCIES] evolution-data-server:amd64 3.22.1-2
[HOLD, DEPENDENCIES] evolution-data-server-common:amd64 3.22.1-2
[HOLD, DEPENDENCIES] evolution-plugins:amd64 3.22.1-2
[HOLD, DEPENDENCIES] exim4:amd64 4.87-3
[HOLD, DEPENDENCIES] exim4-base:amd64 4.87-3+b1
[HOLD, DEPENDENCIES] exim4-config:amd64 4.87-3
[HOLD, DEPENDENCIES] exim4-daemon-light:amd64 4.87-3+b1
[HOLD, DEPENDENCIES] gedit-common:amd64 3.21.90-2
[HOLD, DEPENDENCIES] gir1.2-gst-plugins-base-1.0:amd64 1.8.3-1
[HOLD, DEPENDENCIES] gir1.2-gstreamer-1.0:amd64 1.8.3-1
[HOLD, DEPENDENCIES] gir1.2-totem-1.0:amd64 3.21.91-1
[HOLD, DEPENDENCIES] gstreamer1.0-libav:amd64 1.8.3-1
[HOLD, DEPENDENCIES] gstreamer1.0-plugins-bad:amd64 1.8.3-1+b3
[HOLD, DEPENDENCIES] gstreamer1.0-plugins-base:amd64 1.8.3-1
[HOLD, DEPENDENCIES] gstreamer1.0-plugins-good:amd64 1.8.3-1+b1
[HOLD, DEPENDENCIES] gstreamer1.0-plugins-ugly:amd64 1.8.3-1
[HOLD, DEPENDENCIES] gstreamer1.0-pulseaudio:amd64 1.8.3-1+b1
[HOLD, DEPENDENCIES] gstreamer1.0-x:amd64 1.8.3-1
[HOLD, DEPENDENCIES] libavcodec57:amd64 7:3.1.5-1
[HOLD, DEPENDENCIES] libavfilter6:amd64 7:3.1.5-1
[HOLD, DEPENDENCIES] libavformat57:amd64 7:3.1.5-1
[HOLD, DEPENDENCIES] libavresample3:amd64 7:3.1.5-1
[HOLD, DEPENDENCIES] libavutil55:amd64 7:3.1.5-1
[HOLD, DEPENDENCIES] libcamel-1.2-59:amd64 3.22.1-2
[HOLD, DEPENDENCIES] libclutter-gtk-1.0-0:amd64 1.8.0-2
[HOLD, DEPENDENCIES] libcmis-0.5-5v5:amd64 0.5.1+git20160603-3
[HOLD, DEPENDENCIES] libcupsfilters1:amd64 1.11.6-1
[HOLD, DEPENDENCIES] libebackend-1.2-10:amd64 3.22.1-2
[HOLD, DEPENDENCIES] libebook-1.2-16:amd64 3.22.1-2
[HOLD, DEPENDENCIES] libebook-contacts-1.2-2:amd64 3.22.1-2
[HOLD, DEPENDENCIES] libecal-1.2-19:amd64 3.22.1-2
[HOLD, DEPENDENCIES] libedata-book-1.2-25:amd64 3.22.1-2
[HOLD, DEPENDENCIES] libedata-cal-1.2-28:amd64 3.22.1-2
[HOLD, DEPENDENCIES] libedataserver-1.2-22:amd64 3.22.1-2
[HOLD, DEPENDENCIES] libedataserverui-1.2-1:amd64 3.22.1-2
[HOLD, DEPENDENCIES] libevolution:amd64 3.22.1-2
[HOLD, DEPENDENCIES] libgstreamer-plugins-base1.0-0:amd64 1.8.3-1
[HOLD, DEPENDENCIES] libgstreamer1.0-0:amd64 1.8.3-1
[HOLD, DEPENDENCIES] libkpathsea6:amd64 2016.20160513.41080-7
[HOLD, DEPENDENCIES] liblircclient0:amd64 0.9.0~pre1-1.2
[HOLD, DEPENDENCIES] libmutter0i:amd64 3.22.0-1
[HOLD, DEPENDENCIES] libphonenumber7:amd64 7.1.0-5
[HOLD, DEPENDENCIES] libpoppler-dev:amd64 0.44.0-3
[HOLD, DEPENDENCIES] libpoppler-glib8:amd64 0.44.0-3
[HOLD, DEPENDENCIES] libpoppler-qt4-4:amd64 0.44.0-3
[HOLD, DEPENDENCIES] libpostproc54:amd64 7:3.1.5-1
[HOLD, DEPENDENCIES] libptexenc1:amd64

Bug#844300: [Aptitude-devel] Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-22 Thread Axel Beckert 
Control: tag -1 + moreinfo

Hi Vincent,

Vincent Lefevre wrote:
> On 2016-11-22 09:10:01 +, Luca Boccassi wrote:
> > On Tue, 2016-11-22 at 04:27 +0100, Vincent Lefevre wrote:
> > > On 2016-11-22 00:37:14 +, Luca Boccassi wrote:
> > > > In the end, you shouldn't have let aptitude remove the packages. It can
> > > > happen from time to time on unstable to have temporary inconsistent
> > > > state in the apt tree (that's why it's called unstable), for example in
> > > > this case it was probably because the new amd64 version was up in the
> > > > repo but the i386 was still being built/published.
> > > 
> > > The problem here is that aptitude said that the packages were
> > > no longer used, i.e. there were no dependencies on them. This
> > > is very misleading.
> > 
> > I have no control over what text aptitude outputs, I suggest contacting
> > the aptitude maintainers if you have a suggestion regarding that.
> > 
> > > Still, there are missing Breaks.
> > 
> > No, there are not.
> 
> So, this is a bug in aptitude.

Not necessarily.

> In any case, if the dependencies are correct, the package system
> should never be put in a broken state.

I'm sorry but that's wrong. Maintainer scripts can still put packages
in a broken state even if dependencies are correct.

>From an earlier mail of you:
> But an upgrade should not fail even when the apt sources are not up
> to date: that's the goal of Depends and Breaks to make sure that the
> package system remains in a consistent state.

Also wrong. Example: Not uptodate package lists can lead to download
failures (aptitude asks then if it should continue anyways) and hence
(if the user decides to continue) to packages where dependencies are
missing as they were not downloadable.

Anyways, in the whole correspondence I saw nowhere that you also tried
the same with apt or apt-get. Can you please check if upgrading these
packages with apt or apt-get leads to the same issue? (If so, it's
clearly no issue in aptitude.)

Additionally it could be helpful to provide a state bundle (man
aptitude-create-state-bundle) of the situation, either before the
issue appears (if you can reproduce it) or directly after it has
happened. TIA!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-22 Thread Vincent Lefevre 
Control: reassign -1 aptitude
Control: retitle -1 aptitude can put the package system in a broken state with 
different versions of a MultiArch package
Control: severity -1 serious

On 2016-11-22 09:10:01 +, Luca Boccassi wrote:
> On Tue, 2016-11-22 at 04:27 +0100, Vincent Lefevre wrote:
> > On 2016-11-22 00:37:14 +, Luca Boccassi wrote:
> > > In the end, you shouldn't have let aptitude remove the packages. It can
> > > happen from time to time on unstable to have temporary inconsistent
> > > state in the apt tree (that's why it's called unstable), for example in
> > > this case it was probably because the new amd64 version was up in the
> > > repo but the i386 was still being built/published.
> > 
> > The problem here is that aptitude said that the packages were
> > no longer used, i.e. there were no dependencies on them. This
> > is very misleading.
> 
> I have no control over what text aptitude outputs, I suggest contacting
> the aptitude maintainers if you have a suggestion regarding that.
> 
> > Still, there are missing Breaks.
> 
> No, there are not.

So, this is a bug in aptitude.

In any case, if the dependencies are correct, the package system
should never be put in a broken state.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-22 Thread Vincent Lefevre 
On 2016-11-22 04:27:19 +0100, Vincent Lefevre wrote:
> Still, there are missing Breaks.

This may be a separate issue. For instance, if I try:

cventin:~> apt install -s libsolv0:i386/stable libsolv0:amd64
NOTE: This is only a simulation!
  apt needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Selected version '0.6.5-1' (Debian:8.6/stable [i386]) for 'libsolv0:i386'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libsolv0 : Breaks: libsolv0:i386 (!= 0.6.21-1+b1) but 0.6.5-1 is to be 
installed
 libsolv0:i386 : Breaks: libsolv0 (!= 0.6.5-1) but 0.6.21-1+b1 is to be 
installed
E: Unable to correct problems, you have held broken packages.

I get an error because the versions are different for architectures
i386 and amd64. But why didn't I get the same error with the nvidia
packages (avoiding a system in a broken state)?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-22 Thread Luca Boccassi 
On Tue, 2016-11-22 at 04:27 +0100, Vincent Lefevre wrote:
> On 2016-11-22 00:37:14 +, Luca Boccassi wrote:
> > In the end, you shouldn't have let aptitude remove the packages. It can
> > happen from time to time on unstable to have temporary inconsistent
> > state in the apt tree (that's why it's called unstable), for example in
> > this case it was probably because the new amd64 version was up in the
> > repo but the i386 was still being built/published.
> 
> The problem here is that aptitude said that the packages were
> no longer used, i.e. there were no dependencies on them. This
> is very misleading.

I have no control over what text aptitude outputs, I suggest contacting
the aptitude maintainers if you have a suggestion regarding that.

> Still, there are missing Breaks.

No, there are not.

Kind regards,
Luca Boccassi



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

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-22 Thread Luca Boccassi 
Control: -1 normal

On Tue, 2016-11-22 at 09:34 +0100, Vincent Lefevre wrote:
> Control: severity -1 serious
> 
> due to inconsistent Recommends, which may be one of the causes of the
> issue.

I already explained that the -2 version only adds a patch to fix kernel
builds and there is no point holding that back, in fact it will cause
actual problem to users. Please stop fiddling with the severity.

> On 2016-11-22 00:37:14 +, Luca Boccassi wrote:
> > I can't manage to reproduce this.
> > 
> > In the end, you shouldn't have let aptitude remove the packages. It can
> > happen from time to time on unstable to have temporary inconsistent
> > state in the apt tree (that's why it's called unstable), for example in
> > this case it was probably because the new amd64 version was up in the
> > repo but the i386 was still being built/published.
> > 
> > The solution is simply to reinstall what was removed, so there's nothing
> > that justifies holding he migration of 367.57-2 to stretch, which just
> > adds a patch to make it compatible with newer kernels which are about to
> > be uploaded and nothing else, so severity downgraded.
> 
> I've tried a full reinstallation of the nvidia packages, but get
> conflicts as shown below. First, it confuses apt / apt-get, which
> have themselves an inconsistent behavior. I've reported:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845299
> 
> Now, after installing nvidia-kernel-dkms (with its dependencies),
> I need to install nvidia-settings, and I get:
> 
> cventin:~> apt install -s nvidia-settings
> NOTE: This is only a simulation!
>   apt needs root privileges for real execution.
>   Keep also in mind that locking is deactivated,
>   so don't depend on the relevance to the real current situation!
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> The following packages were automatically installed and are no longer 
> required:
>   linux-doc-4.6 linux-image-4.5.0-2-amd64 linux-image-4.6.0-1-amd64
> Use 'apt autoremove' to remove them.
> The following additional packages will be installed:
>   libxnvctrl0
> Recommended packages:
>   libgl1-nvidia-glx
> The following NEW packages will be installed:
>   libxnvctrl0 nvidia-settings
> 0 upgraded, 2 newly installed, 0 to remove and 278 not upgraded.
> Inst libxnvctrl0 (361.45.11-1 Debian:testing, Debian:unstable [amd64])
> Inst nvidia-settings (361.45.11-1 Debian:testing, Debian:unstable [amd64])
> Conf libxnvctrl0 (361.45.11-1 Debian:testing, Debian:unstable [amd64])
> Conf nvidia-settings (361.45.11-1 Debian:testing, Debian:unstable [amd64])
> 
> You can see that the recommended package libgl1-nvidia-glx is not
> installed by default. If I force its installation:
> 
> cventin:~> apt install -s nvidia-settings libgl1-nvidia-glx
> NOTE: This is only a simulation!
>   apt needs root privileges for real execution.
>   Keep also in mind that locking is deactivated,
>   so don't depend on the relevance to the real current situation!
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> The following packages were automatically installed and are no longer 
> required:
>   libegl-nvidia0:i386 libegl1-glvnd-nvidia:i386 libgl1-nvidia-glx:i386
>   linux-doc-4.6 linux-image-4.5.0-2-amd64 linux-image-4.6.0-1-amd64
> Use 'apt autoremove' to remove them.
> The following additional packages will be installed:
>   libgl1-nvidia-glx:i386 libxnvctrl0
> The following packages will be REMOVED:
>   libgl1-glvnd-nvidia-glx libgl1-glvnd-nvidia-glx:i386 nvidia-driver-libs:i386
>   nvidia-driver-libs-i386:i386
> The following NEW packages will be installed:
>   libgl1-nvidia-glx libgl1-nvidia-glx:i386 libxnvctrl0 nvidia-settings
> 0 upgraded, 4 newly installed, 4 to remove and 278 not upgraded.
> Remv nvidia-driver-libs-i386:i386 [367.57-2]
> Remv nvidia-driver-libs:i386 [367.57-2]
> Remv libgl1-glvnd-nvidia-glx:i386 [367.57-2]
> Remv libgl1-glvnd-nvidia-glx [367.57-2] [nvidia-driver-libs:amd64 ]
> Inst libgl1-nvidia-glx (367.57-2 Debian:unstable [amd64])
> Inst libgl1-nvidia-glx:i386 (367.57-2 Debian:unstable [i386])
> Inst libxnvctrl0 (361.45.11-1 Debian:testing, Debian:unstable [amd64])
> Inst nvidia-settings (361.45.11-1 Debian:testing, Debian:unstable [amd64])
> Conf libgl1-nvidia-glx (367.57-2 Debian:unstable [amd64])
> Conf libgl1-nvidia-glx:i386 (367.57-2 Debian:unstable [i386])
> Conf libxnvctrl0 (361.45.11-1 Debian:testing, Debian:unstable [amd64])
> Conf nvidia-settings (361.45.11-1 Debian:testing, Debian:unstable [amd64])
> 
> nvidia-driver-libs-i386 is removed!!!
> 
> Here's what aptitude says:
> 
> cventin:~> aptitude install -s nvidia-settings
> The following NEW packages will be installed:
>   libgl1-nvidia-glx{a} libxnvctrl0{a} nvidia-settings 
> 0 packages upgraded, 3 newly installed, 0 to remove and 278 not upgraded.
> Need to get 0 B/1461 kB of archives. After unpacking 5587 kB will be used.
>

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-22 Thread Vincent Lefevre 
Control: severity -1 serious

due to inconsistent Recommends, which may be one of the causes of the
issue.

On 2016-11-22 00:37:14 +, Luca Boccassi wrote:
> I can't manage to reproduce this.
> 
> In the end, you shouldn't have let aptitude remove the packages. It can
> happen from time to time on unstable to have temporary inconsistent
> state in the apt tree (that's why it's called unstable), for example in
> this case it was probably because the new amd64 version was up in the
> repo but the i386 was still being built/published.
> 
> The solution is simply to reinstall what was removed, so there's nothing
> that justifies holding he migration of 367.57-2 to stretch, which just
> adds a patch to make it compatible with newer kernels which are about to
> be uploaded and nothing else, so severity downgraded.

I've tried a full reinstallation of the nvidia packages, but get
conflicts as shown below. First, it confuses apt / apt-get, which
have themselves an inconsistent behavior. I've reported:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845299

Now, after installing nvidia-kernel-dkms (with its dependencies),
I need to install nvidia-settings, and I get:

cventin:~> apt install -s nvidia-settings
NOTE: This is only a simulation!
  apt needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  linux-doc-4.6 linux-image-4.5.0-2-amd64 linux-image-4.6.0-1-amd64
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  libxnvctrl0
Recommended packages:
  libgl1-nvidia-glx
The following NEW packages will be installed:
  libxnvctrl0 nvidia-settings
0 upgraded, 2 newly installed, 0 to remove and 278 not upgraded.
Inst libxnvctrl0 (361.45.11-1 Debian:testing, Debian:unstable [amd64])
Inst nvidia-settings (361.45.11-1 Debian:testing, Debian:unstable [amd64])
Conf libxnvctrl0 (361.45.11-1 Debian:testing, Debian:unstable [amd64])
Conf nvidia-settings (361.45.11-1 Debian:testing, Debian:unstable [amd64])

You can see that the recommended package libgl1-nvidia-glx is not
installed by default. If I force its installation:

cventin:~> apt install -s nvidia-settings libgl1-nvidia-glx
NOTE: This is only a simulation!
  apt needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libegl-nvidia0:i386 libegl1-glvnd-nvidia:i386 libgl1-nvidia-glx:i386
  linux-doc-4.6 linux-image-4.5.0-2-amd64 linux-image-4.6.0-1-amd64
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  libgl1-nvidia-glx:i386 libxnvctrl0
The following packages will be REMOVED:
  libgl1-glvnd-nvidia-glx libgl1-glvnd-nvidia-glx:i386 nvidia-driver-libs:i386
  nvidia-driver-libs-i386:i386
The following NEW packages will be installed:
  libgl1-nvidia-glx libgl1-nvidia-glx:i386 libxnvctrl0 nvidia-settings
0 upgraded, 4 newly installed, 4 to remove and 278 not upgraded.
Remv nvidia-driver-libs-i386:i386 [367.57-2]
Remv nvidia-driver-libs:i386 [367.57-2]
Remv libgl1-glvnd-nvidia-glx:i386 [367.57-2]
Remv libgl1-glvnd-nvidia-glx [367.57-2] [nvidia-driver-libs:amd64 ]
Inst libgl1-nvidia-glx (367.57-2 Debian:unstable [amd64])
Inst libgl1-nvidia-glx:i386 (367.57-2 Debian:unstable [i386])
Inst libxnvctrl0 (361.45.11-1 Debian:testing, Debian:unstable [amd64])
Inst nvidia-settings (361.45.11-1 Debian:testing, Debian:unstable [amd64])
Conf libgl1-nvidia-glx (367.57-2 Debian:unstable [amd64])
Conf libgl1-nvidia-glx:i386 (367.57-2 Debian:unstable [i386])
Conf libxnvctrl0 (361.45.11-1 Debian:testing, Debian:unstable [amd64])
Conf nvidia-settings (361.45.11-1 Debian:testing, Debian:unstable [amd64])

nvidia-driver-libs-i386 is removed!!!

Here's what aptitude says:

cventin:~> aptitude install -s nvidia-settings
The following NEW packages will be installed:
  libgl1-nvidia-glx{a} libxnvctrl0{a} nvidia-settings 
0 packages upgraded, 3 newly installed, 0 to remove and 278 not upgraded.
Need to get 0 B/1461 kB of archives. After unpacking 5587 kB will be used.
The following packages have unmet dependencies:
 libgl1-glvnd-nvidia-glx : Conflicts: libgl1-nvidia-glx but 367.57-2 is to be 
installed
 libgl1-glvnd-nvidia-glx:i386 : Conflicts: libgl1-nvidia-glx but 367.57-2 is to 
be installed
The following actions will resolve these dependencies:

 Keep the following packages at their current version:
1) libgl1-nvidia-glx [Not Installed]  

 Leave the following dependencies unresolved: 
2)

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-21 Thread Vincent Lefevre 
On 2016-11-22 00:37:14 +, Luca Boccassi wrote:
> In the end, you shouldn't have let aptitude remove the packages. It can
> happen from time to time on unstable to have temporary inconsistent
> state in the apt tree (that's why it's called unstable), for example in
> this case it was probably because the new amd64 version was up in the
> repo but the i386 was still being built/published.

The problem here is that aptitude said that the packages were
no longer used, i.e. there were no dependencies on them. This
is very misleading.

Still, there are missing Breaks.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-21 Thread Luca Boccassi 
Control: severity -1 normal

On Mon, 2016-11-14 at 16:20 +0100, Vincent Lefevre wrote:
> On 2016-11-14 15:52:28 +0100, Diederik de Haas wrote:
> > On maandag 14 november 2016 15:12:14 CET Vincent Lefevre wrote:
> > > aptitude often ignores Recommends. So, you should not rely on it.
> > 
> > That's an incorrect statement.
> > Aptitude, and I think apt too, doesn't automatically install _new_ 
> > recommended 
> > packages for an already installed package. 
> > It does report "The following recommended packages will not be installed" 
> > (or 
> > sth along those lines). But that's far from ignoring it.
> 
> No, I do not always get these reports. Here I didn't even have any
> report that a recommended package would be removed: aptitude just
> said that  would be removed because they are
> no longer used.

I can't manage to reproduce this.

In the end, you shouldn't have let aptitude remove the packages. It can
happen from time to time on unstable to have temporary inconsistent
state in the apt tree (that's why it's called unstable), for example in
this case it was probably because the new amd64 version was up in the
repo but the i386 was still being built/published.

The solution is simply to reinstall what was removed, so there's nothing
that justifies holding he migration of 367.57-2 to stretch, which just
adds a patch to make it compatible with newer kernels which are about to
be uploaded and nothing else, so severity downgraded.

Kind regards,
Luca Boccassi


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

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-14 Thread Vincent Lefevre 
On 2016-11-14 15:52:28 +0100, Diederik de Haas wrote:
> On maandag 14 november 2016 15:12:14 CET Vincent Lefevre wrote:
> > aptitude often ignores Recommends. So, you should not rely on it.
> 
> That's an incorrect statement.
> Aptitude, and I think apt too, doesn't automatically install _new_ 
> recommended 
> packages for an already installed package. 
> It does report "The following recommended packages will not be installed" (or 
> sth along those lines). But that's far from ignoring it.

No, I do not always get these reports. Here I didn't even have any
report that a recommended package would be removed: aptitude just
said that  would be removed because they are
no longer used.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-14 Thread Diederik de Haas 
On maandag 14 november 2016 15:12:14 CET Vincent Lefevre wrote:
> aptitude often ignores Recommends. So, you should not rely on it.

That's an incorrect statement.
Aptitude, and I think apt too, doesn't automatically install _new_ recommended 
packages for an already installed package. 
It does report "The following recommended packages will not be installed" (or 
sth along those lines). But that's far from ignoring it.

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

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-14 Thread Vincent Lefevre 
On 2016-11-14 14:01:55 +, Luca Boccassi wrote:
> If the i386 libraries are installed, then they must be upgraded at the
> same time. You cannot install them later. The dependencies are there to
> ensure this happens.
> 
> This looks like a bug in aptitude, which shouldn't have let the upgrade
> happen if it couldn't satisfy all dependencies. Given the i386 top-level
> dependencies, the nvidia-driver-libs-i386 metapapkg, is only a recommend
> of nvidia-driver-libs, I'd guess aptitude failed to parse it.

nvidia-driver-libs-i386 was installed, but aptitude chose to remove
it (together with other packages) for the reason it was not used:

[REMOVE, NOT USED] libegl-nvidia0:i386 367.57-1
[REMOVE, NOT USED] libegl1-glvnd-nvidia:i386 367.57-1
[REMOVE, NOT USED] libgldispatch0-nvidia:i386 367.57-1
[REMOVE, NOT USED] libgles-nvidia1:amd64 367.57-1
[REMOVE, NOT USED] libgles-nvidia1:i386 367.57-1
[REMOVE, NOT USED] libgles-nvidia2:amd64 367.57-1
[REMOVE, NOT USED] libgles-nvidia2:i386 367.57-1
[REMOVE, NOT USED] libgles1-glvnd-nvidia:amd64 367.57-1
[REMOVE, NOT USED] libgles1-glvnd-nvidia:i386 367.57-1
[REMOVE, NOT USED] libgles2-glvnd-nvidia:amd64 367.57-1
[REMOVE, NOT USED] libgles2-glvnd-nvidia:i386 367.57-1
[REMOVE, NOT USED] libglx-nvidia0:amd64 367.57-1
[REMOVE, NOT USED] libglx-nvidia0:i386 367.57-1
[REMOVE, NOT USED] libglx0-glvnd-nvidia:amd64 367.57-1
[REMOVE, NOT USED] libglx0-glvnd-nvidia:i386 367.57-1
[REMOVE, NOT USED] libnvidia-cfg1:amd64 367.57-1
[REMOVE, NOT USED] libnvidia-cfg1:i386 367.57-1
[REMOVE, NOT USED] libnvidia-eglcore:i386 367.57-1
[REMOVE, NOT USED] libopengl0-glvnd-nvidia:amd64 367.57-1
[REMOVE, NOT USED] libopengl0-glvnd-nvidia:i386 367.57-1
[REMOVE, NOT USED] libvulkan1:amd64 1.0.26.0+dfsg1-1
[REMOVE, NOT USED] libvulkan1:i386 1.0.26.0+dfsg1-1
[REMOVE, NOT USED] nvidia-driver-libs:i386 367.57-1
[REMOVE, NOT USED] nvidia-driver-libs-i386:i386 367.57-1
[REMOVE, NOT USED] nvidia-vulkan-common:amd64 367.57-1
[REMOVE, NOT USED] nvidia-vulkan-icd:amd64 367.57-1
[REMOVE, NOT USED] nvidia-vulkan-icd:i386 367.57-1

I don't know why aptitude did this. But anyway, Recommends are not
strong dependencies, and aptitude often ignores Recommends. So, you
should not rely on it.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-14 Thread Luca Boccassi 
On Mon, 2016-11-14 at 14:40 +0100, Vincent Lefevre wrote:
> On 2016-11-14 12:09:50 +, Luca Boccassi wrote:
> > The same versions are available in the i386 and amd64 archives. Are you
> > sure your local apt sources are all up to date?
> 
> I could install the i386 versions later. But an upgrade should not
> fail even when the apt sources are not up to date: that's the goal
> of Depends and Breaks to make sure that the package system remains
> in a consistent state.

If the i386 libraries are installed, then they must be upgraded at the
same time. You cannot install them later. The dependencies are there to
ensure this happens.

This looks like a bug in aptitude, which shouldn't have let the upgrade
happen if it couldn't satisfy all dependencies. Given the i386 top-level
dependencies, the nvidia-driver-libs-i386 metapapkg, is only a recommend
of nvidia-driver-libs, I'd guess aptitude failed to parse it.

Kind regards,
Luca Boccassi


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

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-14 Thread Vincent Lefevre 
On 2016-11-14 12:09:50 +, Luca Boccassi wrote:
> The same versions are available in the i386 and amd64 archives. Are you
> sure your local apt sources are all up to date?

I could install the i386 versions later. But an upgrade should not
fail even when the apt sources are not up to date: that's the goal
of Depends and Breaks to make sure that the package system remains
in a consistent state.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-14 Thread Luca Boccassi 
Control: tags -1 moreinfo

On Mon, 2016-11-14 at 11:31 +0100, Vincent Lefevre wrote:
> Package: nvidia-driver-libs
> Version: 367.57-2
> Severity: grave
> Justification: renders package unusable
> 
> I got the folloing failure when upgrading with aptitude:
> 
> Preconfiguring packages ...
> (Reading database ... 528479 files and directories currently installed.)
> Removing nvidia-driver-libs-i386:i386 (367.57-1) ...
> Removing libopengl0-glvnd-nvidia:i386 (367.57-1) ...
> Removing nvidia-vulkan-icd:i386 (367.57-1) ...
> Removing libglx-nvidia0:i386 (367.57-1) ...
> Removing libglx0-glvnd-nvidia:i386 (367.57-1) ...
> Removing libgles-nvidia2:i386 (367.57-1) ...
> Removing libgles2-glvnd-nvidia:i386 (367.57-1) ...
> Removing libgles-nvidia1:i386 (367.57-1) ...
> Removing libgles1-glvnd-nvidia:i386 (367.57-1) ...
> Removing libgles-nvidia1:amd64 (367.57-1) ...
> Removing libgles-nvidia2:amd64 (367.57-1) ...
> Removing libgles1-glvnd-nvidia:amd64 (367.57-1) ...
> Removing libgles2-glvnd-nvidia:amd64 (367.57-1) ...
> Removing nvidia-vulkan-icd:amd64 (367.57-1) ...
> Removing libglx-nvidia0:amd64 (367.57-1) ...
> Removing libglx0-glvnd-nvidia:amd64 (367.57-1) ...
> Removing libnvidia-cfg1:amd64 (367.57-1) ...
> Removing libnvidia-cfg1:i386 (367.57-1) ...
> Removing libopengl0-glvnd-nvidia:amd64 (367.57-1) ...
> Removing libvulkan1:i386 (1.0.26.0+dfsg1-1) ...
> Removing libvulkan1:amd64 (1.0.26.0+dfsg1-1) ...
> Removing nvidia-vulkan-common (367.57-1) ...
> (Reading database ... 528357 files and directories currently installed.)
> Preparing to unpack .../00-xserver-xorg-video-nvidia_367.57-2_amd64.deb ...
> Unpacking xserver-xorg-video-nvidia (367.57-2) over (367.57-1) ...
> Preparing to unpack .../01-nvidia-kernel-support_367.57-2_amd64.deb ...
> Unpacking nvidia-kernel-support (367.57-2) over (367.57-1) ...
> Preparing to unpack .../02-nvidia-driver-bin_367.57-2_amd64.deb ...
> Unpacking nvidia-driver-bin (367.57-2) over (367.57-1) ...
> Preparing to unpack .../03-libnvidia-ml1_367.57-2_amd64.deb ...
> Unpacking libnvidia-ml1:amd64 (367.57-2) over (367.57-1) ...
> Preparing to unpack .../04-nvidia-driver-libs_367.57-2_amd64.deb ...
> De-configuring nvidia-driver-libs:i386 (367.57-1) ...
> Unpacking nvidia-driver-libs:amd64 (367.57-2) over (367.57-1) ...
> Preparing to unpack .../05-libnvidia-glcore_367.57-2_amd64.deb ...
> De-configuring libnvidia-glcore:i386 (367.57-1) ...
> Unpacking libnvidia-glcore:amd64 (367.57-2) over (367.57-1) ...
> Preparing to unpack .../06-libnvidia-glcore_367.57-2_i386.deb ...
> Unpacking libnvidia-glcore:i386 (367.57-2) over (367.57-1) ...
> Preparing to unpack .../07-libgl1-nvidia-glx_367.57-2_i386.deb ...
> De-configuring libgl1-nvidia-glx:amd64 (367.57-1) ...
> Unpacking libgl1-nvidia-glx:i386 (367.57-2) over (367.57-1) ...
> Preparing to unpack .../08-libgl1-nvidia-glx_367.57-2_amd64.deb ...
> Unpacking libgl1-nvidia-glx:amd64 (367.57-2) over (367.57-1) ...
> Preparing to unpack .../09-libegl1-glvnd-nvidia_367.57-2_amd64.deb ...
> De-configuring libegl1-glvnd-nvidia:i386 (367.57-1) ...
> Unpacking libegl1-glvnd-nvidia:amd64 (367.57-2) over (367.57-1) ...
> Preparing to unpack .../10-libegl-nvidia0_367.57-2_amd64.deb ...
> De-configuring libegl-nvidia0:i386 (367.57-1) ...
> Unpacking libegl-nvidia0:amd64 (367.57-2) over (367.57-1) ...
> Preparing to unpack .../11-nvidia-alternative_367.57-2_amd64.deb ...
> Unpacking nvidia-alternative (367.57-2) over (367.57-1) ...
> Preparing to unpack .../12-nvidia-driver_367.57-2_amd64.deb ...
> Unpacking nvidia-driver (367.57-2) over (367.57-1) ...
> Preparing to unpack .../13-nvidia-vdpau-driver_367.57-2_amd64.deb ...
> Unpacking nvidia-vdpau-driver:amd64 (367.57-2) over (367.57-1) ...
> Preparing to unpack .../14-libgldispatch0-nvidia_367.57-2_amd64.deb ...
> De-configuring libgldispatch0-nvidia:i386 (367.57-1) ...
> Unpacking libgldispatch0-nvidia:amd64 (367.57-2) over (367.57-1) ...
> Preparing to unpack .../15-libnvidia-eglcore_367.57-2_amd64.deb ...
> De-configuring libnvidia-eglcore:i386 (367.57-1) ...
> Unpacking libnvidia-eglcore:amd64 (367.57-2) over (367.57-1) ...
> Preparing to unpack .../16-nvidia-legacy-check_367.57-2_amd64.deb ...
> Unpacking nvidia-legacy-check (367.57-2) over (367.57-1) ...
> Processing triggers for glx-alternative-nvidia (0.7.4) ...
> dpkg: error processing package nvidia-driver-libs:amd64 (--configure):
>  package nvidia-driver-libs:amd64 367.57-2 cannot be configured because 
> nvidia-driver-libs:i386 is at a different version (367.57-1)
> Processing triggers for mime-support (3.60) ...
> dpkg: error processing package libnvidia-eglcore:amd64 (--configure):
>  package libnvidia-eglcore:amd64 367.57-2 cannot be configured because 
> libnvidia-eglcore:i386 is at a different version (367.57-1)
> dpkg: error processing package libgldispatch0-nvidia:amd64 (--configure):
>  package libgldispatch0-nvidia:amd64 367.57-2 cannot be configured because 
> libgldispatch0-nvidia:i386 is at a different version

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-14 Thread Vincent Lefevre 
On 2016-11-14 11:31:38 +0100, Vincent Lefevre wrote:
> dpkg: error processing package nvidia-driver-libs:amd64 (--configure):
>  package nvidia-driver-libs:amd64 367.57-2 cannot be configured because 
> nvidia-driver-libs:i386 is at a different version (367.57-1)

I wonder why such a failure since there are no dependencies between
the amd64 and i386 versions.

And if this combination doesn't work, there should be a "Breaks:"
against the older versions.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

2016-11-14 Thread Vincent Lefevre 
Package: nvidia-driver-libs
Version: 367.57-2
Severity: grave
Justification: renders package unusable

I got the folloing failure when upgrading with aptitude:

Preconfiguring packages ...
(Reading database ... 528479 files and directories currently installed.)
Removing nvidia-driver-libs-i386:i386 (367.57-1) ...
Removing libopengl0-glvnd-nvidia:i386 (367.57-1) ...
Removing nvidia-vulkan-icd:i386 (367.57-1) ...
Removing libglx-nvidia0:i386 (367.57-1) ...
Removing libglx0-glvnd-nvidia:i386 (367.57-1) ...
Removing libgles-nvidia2:i386 (367.57-1) ...
Removing libgles2-glvnd-nvidia:i386 (367.57-1) ...
Removing libgles-nvidia1:i386 (367.57-1) ...
Removing libgles1-glvnd-nvidia:i386 (367.57-1) ...
Removing libgles-nvidia1:amd64 (367.57-1) ...
Removing libgles-nvidia2:amd64 (367.57-1) ...
Removing libgles1-glvnd-nvidia:amd64 (367.57-1) ...
Removing libgles2-glvnd-nvidia:amd64 (367.57-1) ...
Removing nvidia-vulkan-icd:amd64 (367.57-1) ...
Removing libglx-nvidia0:amd64 (367.57-1) ...
Removing libglx0-glvnd-nvidia:amd64 (367.57-1) ...
Removing libnvidia-cfg1:amd64 (367.57-1) ...
Removing libnvidia-cfg1:i386 (367.57-1) ...
Removing libopengl0-glvnd-nvidia:amd64 (367.57-1) ...
Removing libvulkan1:i386 (1.0.26.0+dfsg1-1) ...
Removing libvulkan1:amd64 (1.0.26.0+dfsg1-1) ...
Removing nvidia-vulkan-common (367.57-1) ...
(Reading database ... 528357 files and directories currently installed.)
Preparing to unpack .../00-xserver-xorg-video-nvidia_367.57-2_amd64.deb ...
Unpacking xserver-xorg-video-nvidia (367.57-2) over (367.57-1) ...
Preparing to unpack .../01-nvidia-kernel-support_367.57-2_amd64.deb ...
Unpacking nvidia-kernel-support (367.57-2) over (367.57-1) ...
Preparing to unpack .../02-nvidia-driver-bin_367.57-2_amd64.deb ...
Unpacking nvidia-driver-bin (367.57-2) over (367.57-1) ...
Preparing to unpack .../03-libnvidia-ml1_367.57-2_amd64.deb ...
Unpacking libnvidia-ml1:amd64 (367.57-2) over (367.57-1) ...
Preparing to unpack .../04-nvidia-driver-libs_367.57-2_amd64.deb ...
De-configuring nvidia-driver-libs:i386 (367.57-1) ...
Unpacking nvidia-driver-libs:amd64 (367.57-2) over (367.57-1) ...
Preparing to unpack .../05-libnvidia-glcore_367.57-2_amd64.deb ...
De-configuring libnvidia-glcore:i386 (367.57-1) ...
Unpacking libnvidia-glcore:amd64 (367.57-2) over (367.57-1) ...
Preparing to unpack .../06-libnvidia-glcore_367.57-2_i386.deb ...
Unpacking libnvidia-glcore:i386 (367.57-2) over (367.57-1) ...
Preparing to unpack .../07-libgl1-nvidia-glx_367.57-2_i386.deb ...
De-configuring libgl1-nvidia-glx:amd64 (367.57-1) ...
Unpacking libgl1-nvidia-glx:i386 (367.57-2) over (367.57-1) ...
Preparing to unpack .../08-libgl1-nvidia-glx_367.57-2_amd64.deb ...
Unpacking libgl1-nvidia-glx:amd64 (367.57-2) over (367.57-1) ...
Preparing to unpack .../09-libegl1-glvnd-nvidia_367.57-2_amd64.deb ...
De-configuring libegl1-glvnd-nvidia:i386 (367.57-1) ...
Unpacking libegl1-glvnd-nvidia:amd64 (367.57-2) over (367.57-1) ...
Preparing to unpack .../10-libegl-nvidia0_367.57-2_amd64.deb ...
De-configuring libegl-nvidia0:i386 (367.57-1) ...
Unpacking libegl-nvidia0:amd64 (367.57-2) over (367.57-1) ...
Preparing to unpack .../11-nvidia-alternative_367.57-2_amd64.deb ...
Unpacking nvidia-alternative (367.57-2) over (367.57-1) ...
Preparing to unpack .../12-nvidia-driver_367.57-2_amd64.deb ...
Unpacking nvidia-driver (367.57-2) over (367.57-1) ...
Preparing to unpack .../13-nvidia-vdpau-driver_367.57-2_amd64.deb ...
Unpacking nvidia-vdpau-driver:amd64 (367.57-2) over (367.57-1) ...
Preparing to unpack .../14-libgldispatch0-nvidia_367.57-2_amd64.deb ...
De-configuring libgldispatch0-nvidia:i386 (367.57-1) ...
Unpacking libgldispatch0-nvidia:amd64 (367.57-2) over (367.57-1) ...
Preparing to unpack .../15-libnvidia-eglcore_367.57-2_amd64.deb ...
De-configuring libnvidia-eglcore:i386 (367.57-1) ...
Unpacking libnvidia-eglcore:amd64 (367.57-2) over (367.57-1) ...
Preparing to unpack .../16-nvidia-legacy-check_367.57-2_amd64.deb ...
Unpacking nvidia-legacy-check (367.57-2) over (367.57-1) ...
Processing triggers for glx-alternative-nvidia (0.7.4) ...
dpkg: error processing package nvidia-driver-libs:amd64 (--configure):
 package nvidia-driver-libs:amd64 367.57-2 cannot be configured because 
nvidia-driver-libs:i386 is at a different version (367.57-1)
Processing triggers for mime-support (3.60) ...
dpkg: error processing package libnvidia-eglcore:amd64 (--configure):
 package libnvidia-eglcore:amd64 367.57-2 cannot be configured because 
libnvidia-eglcore:i386 is at a different version (367.57-1)
dpkg: error processing package libgldispatch0-nvidia:amd64 (--configure):
 package libgldispatch0-nvidia:amd64 367.57-2 cannot be configured because 
libgldispatch0-nvidia:i386 is at a different version (367.57-1)
Processing triggers for desktop-file-utils (0.23-1) ...
Setting up libnvidia-glcore:amd64 (367.57-2) ...
Setting up libnvidia-glcore:i386 (367.57-2) ...
dpkg: error processing package libegl1-glvnd-nvidia:amd64 (--configure):
 package