Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #203705 > unrolled thread

strangest things after upgrade from 8 to 9

Back to article view | Back to linux.debian.user

Contents

  strangest things after upgrade from 8 to 9 "mikesa@corigroup.it" <mikesa@corigroup.it> - 2018-12-29 15:50 +0100
    Re: strangest things after upgrade from 8 to 9 Roberto C. Sánchez <roberto@debian.org> - 2018-12-29 16:00 +0100
      Re: strangest things after upgrade from 8 to 9 "mikesa@corigroup.it" <mikesa@corigroup.it> - 2018-12-29 16:10 +0100
        Re: strangest things after upgrade from 8 to 9 Roberto C. Sánchez <roberto@debian.org> - 2018-12-29 16:20 +0100
          Re: strangest things after upgrade from 8 to 9 "mikesa@corigroup.it" <mikesa@corigroup.it> - 2018-12-29 16:30 +0100
        Re: strangest things after upgrade from 8 to 9 "mikesa@corigroup.it" <mikesa@corigroup.it> - 2018-12-29 16:20 +0100
          Re: strangest things after upgrade from 8 to 9 Roberto C. Sánchez <roberto@debian.org> - 2018-12-29 16:30 +0100
    Re: strangest things after upgrade from 8 to 9 David Christensen <dpchrist@holgerdanske.com> - 2018-12-29 20:00 +0100
      Re: strangest things after upgrade from 8 to 9 Roberto C. Sánchez <roberto@debian.org> - 2018-12-29 20:50 +0100
        Re: strangest things after upgrade from 8 to 9 John Hasler <jhasler@newsguy.com> - 2018-12-29 21:00 +0100
        Re: strangest things after upgrade from 8 to 9 Reco <recoverym4n@enotuniq.net> - 2018-12-29 21:10 +0100
          Re: strangest things after upgrade from 8 to 9 Roberto C. Sánchez <roberto@debian.org> - 2018-12-29 22:20 +0100
            Re: strangest things after upgrade from 8 to 9 John Hasler <jhasler@newsguy.com> - 2018-12-29 22:30 +0100
              Re: strangest things after upgrade from 8 to 9 Reco <recoverym4n@enotuniq.net> - 2018-12-30 07:30 +0100
                Re: strangest things after upgrade from 8 to 9 John Hasler <jhasler@newsguy.com> - 2018-12-30 15:40 +0100
                  Re: strangest things after upgrade from 8 to 9 Roberto C. Sánchez <roberto@debian.org> - 2018-12-30 15:50 +0100
                    Re: strangest things after upgrade from 8 to 9 John Hasler <jhasler@newsguy.com> - 2018-12-31 15:40 +0100
            Re: strangest things after upgrade from 8 to 9 Reco <recoverym4n@enotuniq.net> - 2018-12-30 07:30 +0100
    Re: pavucontrol missing device selection per stream after upgrade  from Debian 8 to 9 David Wright <deblis@lionunicorn.co.uk> - 2019-02-03 02:10 +0100

#203705 — strangest things after upgrade from 8 to 9

I couple of days ago I've upgraded from 8 (jessie) to 9 (stretch)
taking care of removing third-party repositories before upgrading, in my /etc/apt/sources.list file,
which is now as follows:

deb http://deb.debian.org/debian/ stretch main contrib non-free
deb http://security.debian.org/ stretch/updates main contrib non-free
deb http://deb.debian.org/debian/ stretch-updates main contrib non-free
deb http://ftp.debian.org/debian stretch-backports main contrib
deb https://dl.winehq.org/wine-builds/debian/ stretch main

The upgrade went decently well (system is booting) but I've noticed some incongruences with apt and aptitute while installing winehq-staging
which led me thinking some old packages were still in the system.

So I performed (I think) a cleanup of the packages which are not included in the current repositories, with the command:
aptitude search ?obsolete  > mylist
and then removing the resulting packages.

My system now 'looks' clean, but for example mpv (media player) is not working:

user@linux:~$ ldd /usr/bin/mpv|grep -i "not found"
	libwebp.so.5 => not found
	libx265.so.102 => not found
	libopenjpeg.so.5 => not found
	libgnutls-deb0.so.28 => not found
	libcrypto.so.1.0.0 => not found
	libvidstab.so.1.0 => not found
	libnppi.so.7.5 => not found

and I have no idea why /usr/local/lib/libavcodec.so.57 is liked with libwebp.so.5:
root@linux:~# ldd /usr/local/lib/libavcodec.so.57|grep -i found
	libwebp.so.5 => not found
	libx265.so.102 => not found
	libopenjpeg.so.5 => not found

as it looks like it's the current version as the upstream:
root@linux:~# dpkg -l|grep avco
ii  libavcodec57:amd64                                          7:3.2.12-1~deb9u1                           amd64        FFmpeg library with de/encoders for audio/video codecs - runtime files
ii  libavcodec57:i386                                           7:3.2.12-1~deb9u1                           i386         FFmpeg library with de/encoders for audio/video codecs - runtime files


please help ?



Thank you,
Mike

[toc] | [next] | [standalone]

#203706

On Sat, Dec 29, 2018 at 03:36:40PM +0100, mikesa@corigroup.it wrote:
> I couple of days ago I've upgraded from 8 (jessie) to 9 (stretch)
> taking care of removing third-party repositories before upgrading, in my /etc/apt/sources.list file,
> which is now as follows:
> 
> deb http://deb.debian.org/debian/ stretch main contrib non-free
> deb http://security.debian.org/ stretch/updates main contrib non-free
> deb http://deb.debian.org/debian/ stretch-updates main contrib non-free
> deb http://ftp.debian.org/debian stretch-backports main contrib
> deb https://dl.winehq.org/wine-builds/debian/ stretch main
> 
> The upgrade went decently well (system is booting) but I've noticed some incongruences with apt and aptitute while installing winehq-staging
> which led me thinking some old packages were still in the system.
> 
> So I performed (I think) a cleanup of the packages which are not included in the current repositories, with the command:
> aptitude search ?obsolete  > mylist
> and then removing the resulting packages.
> 
> My system now 'looks' clean, but for example mpv (media player) is not working:
> 
> user@linux:~$ ldd /usr/bin/mpv|grep -i "not found"
> 	libwebp.so.5 => not found
> 	libx265.so.102 => not found
> 	libopenjpeg.so.5 => not found
> 	libgnutls-deb0.so.28 => not found
> 	libcrypto.so.1.0.0 => not found
> 	libvidstab.so.1.0 => not found
> 	libnppi.so.7.5 => not found
> 
> and I have no idea why /usr/local/lib/libavcodec.so.57 is liked with libwebp.so.5:
> root@linux:~# ldd /usr/local/lib/libavcodec.so.57|grep -i found
> 	libwebp.so.5 => not found
> 	libx265.so.102 => not found
> 	libopenjpeg.so.5 => not found
> 
> as it looks like it's the current version as the upstream:
> root@linux:~# dpkg -l|grep avco
> ii  libavcodec57:amd64                                          7:3.2.12-1~deb9u1                           amd64        FFmpeg library with de/encoders for audio/video codecs - runtime files
> ii  libavcodec57:i386                                           7:3.2.12-1~deb9u1                           i386         FFmpeg library with de/encoders for audio/video codecs - runtime files
> 
> 
> please help ?
> 
You have an unofficial source listed there, so I am not sure it is
correct to call the system 'clean'.  What is the output of this command:

apt-cache policy `dpkg -S /usr/bin/mpv`

Also, /usr/local/lib/libavcodec.so.57 certainly did not come from an
official Debian package.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#203707

On Sat, 29 Dec 2018 09:50:13 -0500
Roberto C. Sánchez <roberto@debian.org> wrote:

> On Sat, Dec 29, 2018 at 03:36:40PM +0100, mikesa@corigroup.it wrote:
> > I couple of days ago I've upgraded from 8 (jessie) to 9 (stretch)
> > taking care of removing third-party repositories before upgrading, in my /etc/apt/sources.list file,
> > which is now as follows:
> > 
> > deb http://deb.debian.org/debian/ stretch main contrib non-free
> > deb http://security.debian.org/ stretch/updates main contrib non-free
> > deb http://deb.debian.org/debian/ stretch-updates main contrib non-free
> > deb http://ftp.debian.org/debian stretch-backports main contrib
> > deb https://dl.winehq.org/wine-builds/debian/ stretch main
> > 
> > The upgrade went decently well (system is booting) but I've noticed some incongruences with apt and aptitute while installing winehq-staging
> > which led me thinking some old packages were still in the system.
> > 
> > So I performed (I think) a cleanup of the packages which are not included in the current repositories, with the command:
> > aptitude search ?obsolete  > mylist
> > and then removing the resulting packages.
> > 
> > My system now 'looks' clean, but for example mpv (media player) is not working:
> > 
> > user@linux:~$ ldd /usr/bin/mpv|grep -i "not found"
> > 	libwebp.so.5 => not found
> > 	libx265.so.102 => not found
> > 	libopenjpeg.so.5 => not found
> > 	libgnutls-deb0.so.28 => not found
> > 	libcrypto.so.1.0.0 => not found
> > 	libvidstab.so.1.0 => not found
> > 	libnppi.so.7.5 => not found
> > 
> > and I have no idea why /usr/local/lib/libavcodec.so.57 is liked with libwebp.so.5:
> > root@linux:~# ldd /usr/local/lib/libavcodec.so.57|grep -i found
> > 	libwebp.so.5 => not found
> > 	libx265.so.102 => not found
> > 	libopenjpeg.so.5 => not found
> > 
> > as it looks like it's the current version as the upstream:
> > root@linux:~# dpkg -l|grep avco
> > ii  libavcodec57:amd64                                          7:3.2.12-1~deb9u1                           amd64        FFmpeg library with de/encoders for audio/video codecs - runtime files
> > ii  libavcodec57:i386                                           7:3.2.12-1~deb9u1                           i386         FFmpeg library with de/encoders for audio/video codecs - runtime files
> > 
> > 
> > please help ?
> >   
> You have an unofficial source listed there, so I am not sure it is
> correct to call the system 'clean'.  What is the output of this command:
> 
> apt-cache policy `dpkg -S /usr/bin/mpv`
> 
> Also, /usr/local/lib/libavcodec.so.57 certainly did not come from an
> official Debian package.
> 
> Regards,
> 
> -Roberto
> 
> -- 
> Roberto C. Sánchez
> 


Hello Roberto, please have a look:


root@linux:~# apt-cache policy `dpkg -S /usr/bin/mpv`
mpv:
  Installed: 0.23.0-2+deb9u2
  Candidate: 0.23.0-2+deb9u2
  Version table:
 *** 0.23.0-2+deb9u2 500
        500 http://deb.debian.org/debian stretch/main amd64 Packages
        500 http://security.debian.org stretch/updates/main amd64 Packages
        100 /var/lib/dpkg/status
N: Unable to locate package /usr/bin/mpv

and yes you are correct, /usr/local/lib/libavcodec.so.57 was some spurious file I don't know why it was there
and I've deleted it (and rerun ldconfig)
and now mpv is linking to the correct file:

user@linux:~$ ldd /usr/bin/mpv|grep -i "not found"
	libgnutls-deb0.so.28 => not found
	libcrypto.so.1.0.0 => not found
	libvidstab.so.1.0 => not found
	libnppi.so.7.5 => not found

user@linux:~$ ldd /usr/bin/mpv|grep -i libav
	libavutil.so.55 => /usr/local/lib/libavutil.so.55 (0x00007f441e37a000)
	libavcodec.so.57 => /usr/lib/x86_64-linux-gnu/libavcodec.so.57 (0x00007f441cda6000)
	libavformat.so.57 => /usr/local/lib/libavformat.so.57 (0x00007f441c96f000)
	libavfilter.so.6 => /usr/local/lib/libavfilter.so.6 (0x00007f4419d59000)
	libavdevice.so.57 => /usr/local/lib/libavdevice.so.57 (0x00007f4416782000)
	libavresample.so.3 => /usr/local/lib/libavresample.so.3 (0x00007f440f497000)

I've also noticed that I still have 'deb8' packages installed :(

root@linux:~# dpkg -l|grep -i deb8|wc
     85     782   13487

root@linux:~# dpkg -l|grep deb8|awk '{ print $2 }'|xargs apt-get --purge remove 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  apg cheese-common gir1.2-totem-1.0 gnome-control-center-data gstreamer1.0-clutter-3.0 libavahi-ui-gtk3-0 libde265-0 libfluidsynth1 libfolks-telepathy25 libfreerdp-cache1.1
  libfreerdp-codec1.1 libfreerdp-common1.1.0 libfreerdp-core1.1 libfreerdp-crypto1.1 libfreerdp-gdi1.1 libfreerdp-locale1.1 libfreerdp-primitives1.1 libfreerdp-utils1.1 libgtk-vnc-2.0-0
  libgvnc-1.0-0 libkate1 libmjpegutils-2.1-0 libmpeg2encpp-2.1-0 libmplex2-2.1-0 libnss-myhostname libofa0 libphodav-2.0-0 libphodav-2.0-common libspandsp2 libsrtp0 libtotem0
  libusbredirhost1 libvo-aacenc0 libwinpr-crt0.1 libwinpr-crypto0.1 libwinpr-dsparse0.1 libwinpr-environment0.1 libwinpr-file0.1 libwinpr-handle0.1 libwinpr-heap0.1 libwinpr-input0.1
  libwinpr-interlocked0.1 libwinpr-library0.1 libwinpr-path0.1 libwinpr-pool0.1 libwinpr-registry0.1 libwinpr-rpc0.1 libwinpr-sspi0.1 libwinpr-synch0.1 libwinpr-sysinfo0.1
  libwinpr-thread0.1 libwinpr-utils0.1 libzbar0 mousetweaks spice-client-glib-usb-acl-helper totem-common
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  cheese* gnome* gnome-contacts* gnome-control-center* gnome-core* gnome-video-effects* gstreamer1.0-plugins-bad* libaacs0* libakonadi-calendar4* libakonadi-contact4* libakonadi-kcal4*
  libav-tools* libavdevice55* libbind9-90* libcalendarsupport4* libcheese-gtk25* libcheese8* libcrypto++9* libdca0* libdns100* libebook-1.2-14* libebook-contacts-1.2-0*
  libedata-book-1.2-20* libeventviews4* libfaac0* libgif4* libgit2-21* libgles1-mesa* libgpgme++2* libgsoap5* libgstreamer-plugins-bad0.10-0* libguess1* libincidenceeditorsng4* libisc95*
  libisccc90* libisccfg90* libjasper1* libkabc4* libkalarmcal2* libkblog4* libkcal4* libkdepim4* libkdepimdbusinterfaces4* libkholidays4* libkleo4* libkresources4* libksieveui4* libktnef4*
  liblouis2* liblwres90* libmagickcore-6.q16-2* libmagickwand-6.q16-2* libmailcommon4* libmailimporter4* libmessagecomposer4* libmessagecore4* libmessagelist4* libmessageviewer4*
  libmlt++3* libmlt6* libmutter0e* libnoteshared4* libokularcore5* libonig2* libopencv-calib3d2.4* libopencv-contrib2.4* libopencv-core2.4* libopencv-features2d2.4* libopencv-flann2.4*
  libopencv-gpu2.4* libopencv-highgui2.4* libopencv-imgproc2.4* libopencv-legacy2.4* libopencv-ml2.4* libopencv-objdetect2.4* libopencv-ocl2.4* libopencv-photo2.4* libopencv-stitching2.4*
  libopencv-superres2.4* libopencv-ts2.4* libopencv-video2.4* libopencv-videostab2.4* libopenmpi1.6* libpcrecpp0* libpimcommon4* libpng12-0:i386* libpolarssl7* libpoppler46*
  libsoundtouch0* libspice-client-glib-2.0-8* libspice-client-gtk-3.0-5* libtag1-vanilla* libtemplateparser4* libvncclient0* libvncserver0* libxen-4.4* totem* totem-plugins* vinagre*
0 upgraded, 0 newly installed, 99 to remove and 0 not upgraded.
After this operation, 24.8 MB disk space will be freed.
Do you want to continue? [Y/n] Abort.

(and here I didn't confirm: would like to keep gnome installed, but let me know if you want me to proceed)


about the other two repositories in my /etc/apt/sources.list file (stretch-backports and winehq), let me know if you want me to remove them.



Thank you,
Mike

[toc] | [prev] | [next] | [standalone]

#203708

On Sat, Dec 29, 2018 at 04:01:15PM +0100, mikesa@corigroup.it wrote:
> 
> root@linux:~# apt-cache policy `dpkg -S /usr/bin/mpv`
> mpv:
>   Installed: 0.23.0-2+deb9u2
>   Candidate: 0.23.0-2+deb9u2
>   Version table:
>  *** 0.23.0-2+deb9u2 500
>         500 http://deb.debian.org/debian stretch/main amd64 Packages
>         500 http://security.debian.org stretch/updates/main amd64 Packages
>         100 /var/lib/dpkg/status

OK.  That seems normal.

> N: Unable to locate package /usr/bin/mpv

Oops.  I forgot to have you trim the output of the 'dpkg -S' command :-)

> 
> and yes you are correct, /usr/local/lib/libavcodec.so.57 was some spurious file I don't know why it was there
> and I've deleted it (and rerun ldconfig)
> and now mpv is linking to the correct file:
> 
> user@linux:~$ ldd /usr/bin/mpv|grep -i "not found"
> 	libgnutls-deb0.so.28 => not found
> 	libcrypto.so.1.0.0 => not found
> 	libvidstab.so.1.0 => not found
> 	libnppi.so.7.5 => not found
> 

None of these libraries exist in Debian, so you have something else
going on here.

What is the out of these commands?

readlink -f /usr/bin/mpv
ldd /usr/bin/mpv

> I've also noticed that I still have 'deb8' packages installed :(
> 
> root@linux:~# dpkg -l|grep -i deb8|wc
>      85     782   13487
> 
Yeah, that might be a problem.  Did you read the release notes and
follow the upgrade instructions step by step?  Did you happen to record
your upgrade terminal session with 'script' as recommended in the
release notes?

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#203710

On Sat, 29 Dec 2018 10:13:35 -0500
Roberto C. Sánchez <roberto@debian.org> wrote:

> On Sat, Dec 29, 2018 at 04:01:15PM +0100, mikesa@corigroup.it wrote:
> > 
> > root@linux:~# apt-cache policy `dpkg -S /usr/bin/mpv`
> > mpv:
> >   Installed: 0.23.0-2+deb9u2
> >   Candidate: 0.23.0-2+deb9u2
> >   Version table:
> >  *** 0.23.0-2+deb9u2 500
> >         500 http://deb.debian.org/debian stretch/main amd64 Packages
> >         500 http://security.debian.org stretch/updates/main amd64 Packages
> >         100 /var/lib/dpkg/status  
> 
> OK.  That seems normal.
> 
> > N: Unable to locate package /usr/bin/mpv  
> 
> Oops.  I forgot to have you trim the output of the 'dpkg -S' command :-)
> 
> > 
> > and yes you are correct, /usr/local/lib/libavcodec.so.57 was some spurious file I don't know why it was there
> > and I've deleted it (and rerun ldconfig)
> > and now mpv is linking to the correct file:
> > 
> > user@linux:~$ ldd /usr/bin/mpv|grep -i "not found"
> > 	libgnutls-deb0.so.28 => not found
> > 	libcrypto.so.1.0.0 => not found
> > 	libvidstab.so.1.0 => not found
> > 	libnppi.so.7.5 => not found
> >   
> 
> None of these libraries exist in Debian, so you have something else
> going on here.
> 
> What is the out of these commands?
> 
> readlink -f /usr/bin/mpv
> ldd /usr/bin/mpv
> 
> > I've also noticed that I still have 'deb8' packages installed :(
> > 
> > root@linux:~# dpkg -l|grep -i deb8|wc
> >      85     782   13487
> >   
> Yeah, that might be a problem.  Did you read the release notes and
> follow the upgrade instructions step by step?  Did you happen to record
> your upgrade terminal session with 'script' as recommended in the
> release notes?
> 
> Regards,
> 
> -Roberto
> 
> -- 
> Roberto C. Sánchez
> 

I've slowly deleted the deb8 packages until the last one was only:
ii  libdca0:amd64                                               0.0.5-dmo2+deb8u1                           amd64        decoding library for DTS Coherent Acoustics streams
which was a dependency of gnome.

I've downloaded the new one from debian.org (http://ftp.us.debian.org/debian/pool/main/libd/libdca/libdca0_0.0.5-10_amd64.deb) and installed:
root@linux:~# dpkg -l|grep -i libdca
ii  libdca0:amd64                                               0.0.5-10                                    amd64        decoding library for DTS Coherent Acoustics streams

Now the system looks better:
root@linux:~# dpkg -l|grep -i deb8|wc
      0       0       0

Thank you Roberto, I guess my system is still a little frankestein after 3 years of messing with Jessie :)
Hope I've learned to debug and fix the following issues :)


Thank you,
Mike

[toc] | [prev] | [next] | [standalone]

#203709

On Sat, 29 Dec 2018 16:01:15 +0100
"mikesa@corigroup.it" <mikesa@corigroup.it> wrote:

> On Sat, 29 Dec 2018 09:50:13 -0500
> Roberto C. Sánchez <roberto@debian.org> wrote:
> 
> > On Sat, Dec 29, 2018 at 03:36:40PM +0100, mikesa@corigroup.it wrote:  
> > > I couple of days ago I've upgraded from 8 (jessie) to 9 (stretch)
> > > taking care of removing third-party repositories before upgrading, in my /etc/apt/sources.list file,
> > > which is now as follows:
> > > 
> > > deb http://deb.debian.org/debian/ stretch main contrib non-free
> > > deb http://security.debian.org/ stretch/updates main contrib non-free
> > > deb http://deb.debian.org/debian/ stretch-updates main contrib non-free
> > > deb http://ftp.debian.org/debian stretch-backports main contrib
> > > deb https://dl.winehq.org/wine-builds/debian/ stretch main
> > > 
> > > The upgrade went decently well (system is booting) but I've noticed some incongruences with apt and aptitute while installing winehq-staging
> > > which led me thinking some old packages were still in the system.
> > > 
> > > So I performed (I think) a cleanup of the packages which are not included in the current repositories, with the command:
> > > aptitude search ?obsolete  > mylist
> > > and then removing the resulting packages.
> > > 
> > > My system now 'looks' clean, but for example mpv (media player) is not working:
> > > 
> > > user@linux:~$ ldd /usr/bin/mpv|grep -i "not found"
> > > 	libwebp.so.5 => not found
> > > 	libx265.so.102 => not found
> > > 	libopenjpeg.so.5 => not found
> > > 	libgnutls-deb0.so.28 => not found
> > > 	libcrypto.so.1.0.0 => not found
> > > 	libvidstab.so.1.0 => not found
> > > 	libnppi.so.7.5 => not found
> > > 
> > > and I have no idea why /usr/local/lib/libavcodec.so.57 is liked with libwebp.so.5:
> > > root@linux:~# ldd /usr/local/lib/libavcodec.so.57|grep -i found
> > > 	libwebp.so.5 => not found
> > > 	libx265.so.102 => not found
> > > 	libopenjpeg.so.5 => not found
> > > 
> > > as it looks like it's the current version as the upstream:
> > > root@linux:~# dpkg -l|grep avco
> > > ii  libavcodec57:amd64                                          7:3.2.12-1~deb9u1                           amd64        FFmpeg library with de/encoders for audio/video codecs - runtime files
> > > ii  libavcodec57:i386                                           7:3.2.12-1~deb9u1                           i386         FFmpeg library with de/encoders for audio/video codecs - runtime files
> > > 
> > > 
> > > please help ?
> > >     
> > You have an unofficial source listed there, so I am not sure it is
> > correct to call the system 'clean'.  What is the output of this command:
> > 
> > apt-cache policy `dpkg -S /usr/bin/mpv`
> > 
> > Also, /usr/local/lib/libavcodec.so.57 certainly did not come from an
> > official Debian package.
> > 
> > Regards,
> > 
> > -Roberto
> > 
> > -- 
> > Roberto C. Sánchez
> >   
> 
> 
> Hello Roberto, please have a look:
> 
> 
> root@linux:~# apt-cache policy `dpkg -S /usr/bin/mpv`
> mpv:
>   Installed: 0.23.0-2+deb9u2
>   Candidate: 0.23.0-2+deb9u2
>   Version table:
>  *** 0.23.0-2+deb9u2 500
>         500 http://deb.debian.org/debian stretch/main amd64 Packages
>         500 http://security.debian.org stretch/updates/main amd64 Packages
>         100 /var/lib/dpkg/status
> N: Unable to locate package /usr/bin/mpv
> 
> and yes you are correct, /usr/local/lib/libavcodec.so.57 was some spurious file I don't know why it was there
> and I've deleted it (and rerun ldconfig)
> and now mpv is linking to the correct file:
> 
> user@linux:~$ ldd /usr/bin/mpv|grep -i "not found"
> 	libgnutls-deb0.so.28 => not found
> 	libcrypto.so.1.0.0 => not found
> 	libvidstab.so.1.0 => not found
> 	libnppi.so.7.5 => not found
> 
> user@linux:~$ ldd /usr/bin/mpv|grep -i libav
> 	libavutil.so.55 => /usr/local/lib/libavutil.so.55 (0x00007f441e37a000)
> 	libavcodec.so.57 => /usr/lib/x86_64-linux-gnu/libavcodec.so.57 (0x00007f441cda6000)
> 	libavformat.so.57 => /usr/local/lib/libavformat.so.57 (0x00007f441c96f000)
> 	libavfilter.so.6 => /usr/local/lib/libavfilter.so.6 (0x00007f4419d59000)
> 	libavdevice.so.57 => /usr/local/lib/libavdevice.so.57 (0x00007f4416782000)
> 	libavresample.so.3 => /usr/local/lib/libavresample.so.3 (0x00007f440f497000)
> 
> I've also noticed that I still have 'deb8' packages installed :(
> 
> root@linux:~# dpkg -l|grep -i deb8|wc
>      85     782   13487
> 
> root@linux:~# dpkg -l|grep deb8|awk '{ print $2 }'|xargs apt-get --purge remove 
> Reading package lists... Done
> Building dependency tree       
> Reading state information... Done
> The following packages were automatically installed and are no longer required:
>   apg cheese-common gir1.2-totem-1.0 gnome-control-center-data gstreamer1.0-clutter-3.0 libavahi-ui-gtk3-0 libde265-0 libfluidsynth1 libfolks-telepathy25 libfreerdp-cache1.1
>   libfreerdp-codec1.1 libfreerdp-common1.1.0 libfreerdp-core1.1 libfreerdp-crypto1.1 libfreerdp-gdi1.1 libfreerdp-locale1.1 libfreerdp-primitives1.1 libfreerdp-utils1.1 libgtk-vnc-2.0-0
>   libgvnc-1.0-0 libkate1 libmjpegutils-2.1-0 libmpeg2encpp-2.1-0 libmplex2-2.1-0 libnss-myhostname libofa0 libphodav-2.0-0 libphodav-2.0-common libspandsp2 libsrtp0 libtotem0
>   libusbredirhost1 libvo-aacenc0 libwinpr-crt0.1 libwinpr-crypto0.1 libwinpr-dsparse0.1 libwinpr-environment0.1 libwinpr-file0.1 libwinpr-handle0.1 libwinpr-heap0.1 libwinpr-input0.1
>   libwinpr-interlocked0.1 libwinpr-library0.1 libwinpr-path0.1 libwinpr-pool0.1 libwinpr-registry0.1 libwinpr-rpc0.1 libwinpr-sspi0.1 libwinpr-synch0.1 libwinpr-sysinfo0.1
>   libwinpr-thread0.1 libwinpr-utils0.1 libzbar0 mousetweaks spice-client-glib-usb-acl-helper totem-common
> Use 'apt autoremove' to remove them.
> The following packages will be REMOVED:
>   cheese* gnome* gnome-contacts* gnome-control-center* gnome-core* gnome-video-effects* gstreamer1.0-plugins-bad* libaacs0* libakonadi-calendar4* libakonadi-contact4* libakonadi-kcal4*
>   libav-tools* libavdevice55* libbind9-90* libcalendarsupport4* libcheese-gtk25* libcheese8* libcrypto++9* libdca0* libdns100* libebook-1.2-14* libebook-contacts-1.2-0*
>   libedata-book-1.2-20* libeventviews4* libfaac0* libgif4* libgit2-21* libgles1-mesa* libgpgme++2* libgsoap5* libgstreamer-plugins-bad0.10-0* libguess1* libincidenceeditorsng4* libisc95*
>   libisccc90* libisccfg90* libjasper1* libkabc4* libkalarmcal2* libkblog4* libkcal4* libkdepim4* libkdepimdbusinterfaces4* libkholidays4* libkleo4* libkresources4* libksieveui4* libktnef4*
>   liblouis2* liblwres90* libmagickcore-6.q16-2* libmagickwand-6.q16-2* libmailcommon4* libmailimporter4* libmessagecomposer4* libmessagecore4* libmessagelist4* libmessageviewer4*
>   libmlt++3* libmlt6* libmutter0e* libnoteshared4* libokularcore5* libonig2* libopencv-calib3d2.4* libopencv-contrib2.4* libopencv-core2.4* libopencv-features2d2.4* libopencv-flann2.4*
>   libopencv-gpu2.4* libopencv-highgui2.4* libopencv-imgproc2.4* libopencv-legacy2.4* libopencv-ml2.4* libopencv-objdetect2.4* libopencv-ocl2.4* libopencv-photo2.4* libopencv-stitching2.4*
>   libopencv-superres2.4* libopencv-ts2.4* libopencv-video2.4* libopencv-videostab2.4* libopenmpi1.6* libpcrecpp0* libpimcommon4* libpng12-0:i386* libpolarssl7* libpoppler46*
>   libsoundtouch0* libspice-client-glib-2.0-8* libspice-client-gtk-3.0-5* libtag1-vanilla* libtemplateparser4* libvncclient0* libvncserver0* libxen-4.4* totem* totem-plugins* vinagre*
> 0 upgraded, 0 newly installed, 99 to remove and 0 not upgraded.
> After this operation, 24.8 MB disk space will be freed.
> Do you want to continue? [Y/n] Abort.
> 
> (and here I didn't confirm: would like to keep gnome installed, but let me know if you want me to proceed)
> 
> 
> about the other two repositories in my /etc/apt/sources.list file (stretch-backports and winehq), let me know if you want me to remove them.
> 
> 
> 
> Thank you,
> Mike


So I've performed an elegant:
rm -rf /usr/local/lib/*
lddconfig

and now mpv is working :)

It looks like /usr/local/lib/ was getting priority over the other libraries
and /usr/local/lib/ was full of old stuff from my jessie days :)

Thank you Roberto I hope that I can proceed further in cleaning the system :)


Regards,
Mike

[toc] | [prev] | [next] | [standalone]

#203711

On Sat, Dec 29, 2018 at 04:15:07PM +0100, mikesa@corigroup.it wrote:
> 
> So I've performed an elegant:
> rm -rf /usr/local/lib/*
> lddconfig
> 
> and now mpv is working :)
> 
> It looks like /usr/local/lib/ was getting priority over the other libraries
> and /usr/local/lib/ was full of old stuff from my jessie days :)
> 
That would do it.

You can check the contents of /etc/ld.so.conf to see the order in which
the directories are searched.

> Thank you Roberto I hope that I can proceed further in cleaning the system :)
> 
No problem.

Regards,

-Roberto
-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#203717

On 12/29/18 6:36 AM, mikesa@corigroup.it wrote:
> I couple of days ago I've upgraded from 8 (jessie) to 9 (stretch) ...

In years past, I tried doing major version upgrades in-place.  It seemed 
like no matter how many issues I tracked down and fixed, another would 
emerge.  I had no confidence in the result.


So, now I back up/ archive system configuration files and user data, 
pull the system drive, install a wiped system drive, do a fresh install, 
and reconfigure/ restore.  I use this process both for major version 
upgrades and also for re-installs when the system has become crufty or 
doesn't feel right.  This process is expedited by using small, dedicated 
system drives (16 GB), keeping my system configuration files in a 
version control system (CVS), and keeping my user data in CVS or on a 
file server.  User e-mail folders are the only item that I need to 
manually backup and restore.


David

[toc] | [prev] | [next] | [standalone]

#203718

On Sat, Dec 29, 2018 at 10:56:51AM -0800, David Christensen wrote:
> On 12/29/18 6:36 AM, mikesa@corigroup.it wrote:
> > I couple of days ago I've upgraded from 8 (jessie) to 9 (stretch) ...
> 
> In years past, I tried doing major version upgrades in-place.  It seemed
> like no matter how many issues I tracked down and fixed, another would
> emerge.  I had no confidence in the result.
> 
> 
> So, now I back up/ archive system configuration files and user data, pull
> the system drive, install a wiped system drive, do a fresh install, and
> reconfigure/ restore.  I use this process both for major version upgrades
> and also for re-installs when the system has become crufty or doesn't feel
> right.  This process is expedited by using small, dedicated system drives
> (16 GB), keeping my system configuration files in a version control system
> (CVS), and keeping my user data in CVS or on a file server.  User e-mail
> folders are the only item that I need to manually backup and restore.
> 
On the other hand, I have done in-place upgrades of Debian on every
occasion save one: when I moved my main personal file server from 32-bit
to 64-bit after a hardware swap.

Debian's upgrade process is rather robust.  So much so, that people
complaining to Red Hat that Debian managed to provide robust in-place
upgrades since forever while people paying $$$ for RHEL support
contracts were always told, "wipe and reinstall" was at least part of
what moved Red Hat to start providing support for in-place upgrades (at
least as of RHEL7, if I understand correctly).

The problem that people tend to encounter is when they either don't read
and follow the instructions in the release notes for the new release or
have packages installed from low quality third party sources.  There
have been some problematic transitions (e.g., the one involving udev was
a good example) and there are times when maintainers of external
repositories do not keep their packages updated.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#203719

Roberto's experience matches mine.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#203720

On Sat, Dec 29, 2018 at 02:40:41PM -0500, Roberto C. Sánchez wrote:
> On the other hand, I have done in-place upgrades of Debian on every
> occasion

Ditto. Worked better than they tell on this list to the newcomers.
This particular installation I'm writing from began its life as etch
back before it was testing.


> save one: when I moved my main personal file server from 32-bit
> to 64-bit after a hardware swap.

Did that one too.


> Debian's upgrade process is rather robust.  So much so, that people
> complaining to Red Hat that Debian managed to provide robust in-place
> upgrades since forever

For the sake of the completeness, Red Hat provides a way. It involves
booting from an install CD/DVD with an "upgrade" option. It's
unsupported though.
I did it multiple times, end result can be described as 'salvageable'.


> while people paying $$$ for RHEL support
> contracts were always told, "wipe and reinstall" was at least part of
> what moved Red Hat to start providing support for in-place upgrades (at
> least as of RHEL7, if I understand correctly).

Please do not blame support for that.
Those poor (literally) overseas guys and gals have two options then it
comes to such things.
Option A - do it official Red Hat way (i.e. - reinstall).
Option B - suggest a customer to do an unsupported upgrade, and get
blamed/fired for all kinds of inevitable trouble afterwards.


> The problem that people tend to encounter is when they either don't read
> and follow the instructions in the release notes for the new release or
> have packages installed from low quality third party sources.

Or, in this particular case, follow "good old"
configure-make-make_install pattern.


> There have been some problematic transitions (e.g., the one involving
> udev was a good example)

That's a *very* x86-centric POV.
For instance, whoever came up with the idea of disabling
CONFIG_COMPACTION on armel/kirkwood between jessie and stretch rendered
armel ununsable on stretch.
And let's do not mention kfreebsd.

Reco

[toc] | [prev] | [next] | [standalone]

#203721

On Sat, Dec 29, 2018 at 11:06:37PM +0300, Reco wrote:
> On Sat, Dec 29, 2018 at 02:40:41PM -0500, Roberto C. Sánchez wrote:
> 
> > while people paying $$$ for RHEL support
> > contracts were always told, "wipe and reinstall" was at least part of
> > what moved Red Hat to start providing support for in-place upgrades (at
> > least as of RHEL7, if I understand correctly).
> 
> Please do not blame support for that.
> Those poor (literally) overseas guys and gals have two options then it
> comes to such things.
> Option A - do it official Red Hat way (i.e. - reinstall).
> Option B - suggest a customer to do an unsupported upgrade, and get
> blamed/fired for all kinds of inevitable trouble afterwards.
> 
I was not trying to blame anyone.  My perspective is based on a
conversation I had with someone who worked for Red Hat as a solutions
engineer.  That and my experience obtaining an RHCE some years ago.
When I referred to support I was thinking more of folks like solutions
engineers as opposed to call center support personnel.

> 
> > The problem that people tend to encounter is when they either don't read
> > and follow the instructions in the release notes for the new release or
> > have packages installed from low quality third party sources.
> 
> Or, in this particular case, follow "good old"
> configure-make-make_install pattern.
> 
Yes, that can have interesting effects on a system depending on how
everything is configured.  I try to avoid installing libraries in this
manner for that reason.

> 
> > There have been some problematic transitions (e.g., the one involving
> > udev was a good example)
> 
> That's a *very* x86-centric POV.
> For instance, whoever came up with the idea of disabling
> CONFIG_COMPACTION on armel/kirkwood between jessie and stretch rendered
> armel ununsable on stretch.
> And let's do not mention kfreebsd.
> 
I wasn't saying udev transition was the only one that was problematic.
It happened to be the first that came to mind because I had remotely
upgrade some systems without a good out of band access to them if the
system was rendered unbootable.

Certainly there have been other problematic transitions, as you point
out.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#203722

Reco writes:
> Or, in this particular case, follow "good old"
> configure-make-make_install pattern.

Nothing wrong with that as long as you install in /usr/local and realize
that you may have to recompile after an upgrade.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#203725

	Hi.

On Sat, Dec 29, 2018 at 03:26:48PM -0600, John Hasler wrote:
> Reco writes:
> > Or, in this particular case, follow "good old"
> > configure-make-make_install pattern.
> 
> Nothing wrong with that as long as you install in /usr/local and realize
> that you may have to recompile after an upgrade.

You install any library in /usr/local/lib, run ldconfig and every binary
will start searching libraries there first. That can always lead to
funny results.
Binaries are more or less safe if installed that way.

Reco

[toc] | [prev] | [next] | [standalone]

#203734

I wrote:
> Nothing wrong with that as long as you install in /usr/local and realize
> that you may have to recompile after an upgrade.

Reco writes:
> You install any library in /usr/local/lib, run ldconfig and every
> binary will start searching libraries there first. That can always
> lead to funny results.

You wouldn't be installing something in /usr/local/lib that shadows the
SONAME of a library that is in the Debian archive (as it will be if a
binary from a Debian package is searching for it) unless the "funny
results" are what you want.

In any case the loader isn't that easy to fool.  The cache is not the
first place searched.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#203737

On Sun, Dec 30, 2018 at 08:37:38AM -0600, John Hasler wrote:
> 
> You wouldn't be installing something in /usr/local/lib that shadows the
> SONAME of a library that is in the Debian archive (as it will be if a
> binary from a Debian package is searching for it) unless the "funny
> results" are what you want.
> 
Unless you install a library with a SONAME that is not in the Debian
archive (of your current version), you upgrade, and then you discover
(through the funny results) that the SONAME of that library in
/usr/local/lib is the same as one from the archive and is masking the
latter.

> In any case the loader isn't that easy to fool.  The cache is not the
> first place searched.

Sure, with things like rpath and runpath it is relatively easy to ensure
that a consistent set of libraries are used for a given binary.
However, in my experience, many upstream projects simply do not support
them or employ them improperly.  Of those that do attempt to support
rpath/runpath many get it wrong.  So, a user/admin is frequently left to
the chance that comes with the loader's directory search order.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#203757

The Debian upgrade will run ldconfig and the Debian maintainers are not
likely to get it wrong.

I'll concede that it might be possible to bugger up your system in such
a way as to make an upgrade fail by installing a sufficiently broken
package in /usr/local but it's going to be a rare corner case.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#203726

On Sat, Dec 29, 2018 at 04:12:53PM -0500, Roberto C. Sánchez wrote:
> On Sat, Dec 29, 2018 at 11:06:37PM +0300, Reco wrote:
> > On Sat, Dec 29, 2018 at 02:40:41PM -0500, Roberto C. Sánchez wrote:
> > 
> > > while people paying $$$ for RHEL support
> > > contracts were always told, "wipe and reinstall" was at least part of
> > > what moved Red Hat to start providing support for in-place upgrades (at
> > > least as of RHEL7, if I understand correctly).
> > 
> > Please do not blame support for that.
> > Those poor (literally) overseas guys and gals have two options then it
> > comes to such things.
> > Option A - do it official Red Hat way (i.e. - reinstall).
> > Option B - suggest a customer to do an unsupported upgrade, and get
> > blamed/fired for all kinds of inevitable trouble afterwards.
> > 
> I was not trying to blame anyone.

'Blame' was a wrong word.


> My perspective is based on a conversation I had with someone who
> worked for Red Hat as a solutions engineer.

'Avoid responsibility' would be better wording. That unsupported upgrade
procedure goes back to RedHat 6 (not to be confused with RHEL6) at
least. But given a small size (compared to Debian main) of Red Hat
repository and bazillion of warez dumps (such as rpmfind) which are
tempting customer to install useful stuff from - it's a little surprise
that such upgrade is not suggested left and right.


> That and my experience obtaining an RHCE some years ago.

One of the main points of RHCE is to teach people Red Hat way.
An interesting experience, although somewhat limited one.

Reco

[toc] | [prev] | [next] | [standalone]

#204941 — Re: pavucontrol missing device selection per stream after upgrade from Debian 8 to 9

Excuse me. Can you please fix your email client so that you don't post
in February using the header from a post you made last December.

    Date: Sun, 3 Feb 2019 01:06:25 +0100
    From: "mikesa@corigroup.it" <mikesa@corigroup.it>
    To: debian-user@lists.debian.org
    Subject: pavucontrol missing device selection per stream after upgrade from
        Debian 8 to 9
    Message-ID: <20181229153640.4d6e058b@linux>

    To: debian-user@lists.debian.org
    Subject: strangest things after upgrade from 8 to 9
    From: "mikesa@corigroup.it" <mikesa@corigroup.it>
    Date: Sat, 29 Dec 2018 15:36:40 +0100
    Message-id: <[🔎] 20181229153640.4d6e058b@linux>

Groundhog Day¹ is no excuse :)

¹ in this TZ.

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web