strangest things after upgrade from 8 to 9

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

strangest things after upgrade from 8 to 9

mikesa@corigroup.it
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
Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

Roberto C. Sánchez-2
On Sat, Dec 29, 2018 at 03:36:40PM +0100, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

mikesa@corigroup.it
On Sat, 29 Dec 2018 09:50:13 -0500
Roberto C. Sánchez <[hidden email]> wrote:

> On Sat, Dec 29, 2018 at 03:36:40PM +0100, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

Roberto C. Sánchez-2
On Sat, Dec 29, 2018 at 04:01:15PM +0100, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

mikesa@corigroup.it
In reply to this post by mikesa@corigroup.it
On Sat, 29 Dec 2018 16:01:15 +0100
"[hidden email]" <[hidden email]> wrote:

> On Sat, 29 Dec 2018 09:50:13 -0500
> Roberto C. Sánchez <[hidden email]> wrote:
>
> > On Sat, Dec 29, 2018 at 03:36:40PM +0100, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

mikesa@corigroup.it
In reply to this post by Roberto C. Sánchez-2
On Sat, 29 Dec 2018 10:13:35 -0500
Roberto C. Sánchez <[hidden email]> wrote:

> On Sat, Dec 29, 2018 at 04:01:15PM +0100, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

Roberto C. Sánchez-2
In reply to this post by mikesa@corigroup.it
On Sat, Dec 29, 2018 at 04:15:07PM +0100, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

David Christensen
In reply to this post by mikesa@corigroup.it
On 12/29/18 6:36 AM, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

Roberto C. Sánchez-2
On Sat, Dec 29, 2018 at 10:56:51AM -0800, David Christensen wrote:

> On 12/29/18 6:36 AM, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

John Hasler-3
Roberto's experience matches mine.
--
John Hasler
[hidden email]
Elmwood, WI USA

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

Reco
In reply to this post by Roberto C. Sánchez-2
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

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

Roberto C. Sánchez-2
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

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

John Hasler-3
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
[hidden email]
Elmwood, WI USA

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

Reco
In reply to this post by Roberto C. Sánchez-2
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

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

Reco
In reply to this post by John Hasler-3
        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

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

John Hasler-3
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
[hidden email]
Elmwood, WI USA

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

Roberto C. Sánchez-2
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

Reply | Threaded
Open this post in threaded view
|

Re: strangest things after upgrade from 8 to 9

John Hasler-3
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
[hidden email]
Elmwood, WI USA

Reply | Threaded
Open this post in threaded view
|

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

David Wright-3
In reply to this post by mikesa@corigroup.it
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: "[hidden email]" <[hidden email]>
    To: [hidden email]
    Subject: pavucontrol missing device selection per stream after upgrade from
        Debian 8 to 9
    Message-ID: <20181229153640.4d6e058b@linux>

    To: [hidden email]
    Subject: strangest things after upgrade from 8 to 9
    From: "[hidden email]" <[hidden email]>
    Date: Sat, 29 Dec 2018 15:36:40 +0100
    Message-id: <[🔎] 20181229153640.4d6e058b@linux>

Groundhog Day¹ is no excuse :)

¹ in this TZ.

Cheers,
David.