Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
On Fri, Dec 28, 2012 at 12:54:55PM +0200, Andrei POPESCU wrote: > On Jo, 27 dec 12, 16:42:58, Joel Roth wrote: > > > > What *is* biting me is that the new multiarch organization > > won't allow me to (re)install skype, which is expecting ia32-libs and > > ia32-libs-gtk. > > Work for me (on wheezy): My drama was on sid amd64 :-) It took me: dpkg --add-architecture i386 apt-get update And a couple trips through the APT resolver for all the needed i386 libraries to get installed. Greetings, Joel > Kind regards, > Andrei -- Joel Roth -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121228110941.GB32326@sprite
Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
On Jo, 27 dec 12, 16:42:58, Joel Roth wrote: > > What *is* biting me is that the new multiarch organization > won't allow me to (re)install skype, which is expecting ia32-libs and > ia32-libs-gtk. Work for me (on wheezy): $ apt-cache show skype Package: skype Status: install ok installed Priority: extra Section: non-free/net Installed-Size: 35952 Maintainer: Skype Technologies Architecture: i386 Version: 4.1.0.20-1 Replaces: skype-mid, skype-common, skype-bin Depends: libasound2 (>= 1.0.16), libc6 (>= 2.3.6-6~), libc6 (>= 2.7), libgcc1 (>= 1:4.1.1), libqt4-dbus (>= 4:4.5.3), libqt4-network (>= 4:4.8.0), libqt4-xml (>= 4:4.5.3), libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.8.0), libqtwebkit4 (>= 2.1.0~2011week13), libstdc++6 (>= 4.6), libx11-6, libxext6, libxss1, libxv1, libssl1.0.0 Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
Bob Proulx wrote: > Joel Roth wrote: > > Bob Proulx wrote: > > > Joel Roth wrote: > > > > I usually just upgrade apps individually as I need to... > > > > > > As in 'apt-get install openssh-client' ? But that won't upgrade any > > > of the dependencies. > > > > I didn't know that. My first try was apt-get install ssh. > > If the packages were not previously installed then of course the > entire dependency tree is pulled in and installed in order to satisfy > the dependencies. And if a new version dependency appears such as > bind9 for example which always depends upon specific versions of > libraries then those new versions will be upgraded too. But if there > isn't a specific need by stated dependency to pull in a newer version > then it won't be triggered for an install. > > For example 'ssh' has: > > $ apt-cache show ssh | grep ^Depends: > Depends: openssh-client, openssh-server > > $ apt-cache show openssh-client | grep ^Depends: > Depends: libc6 (>= 2.11), libedit2 (>= 2.11-20080614-1), libgssapi-krb5-2 > (>= 1.10+dfsg~), libselinux1 (>= 1.32), libssl1.0.0 (>= 1.0.1), zlib1g (>= > 1:1.1.4), debconf (>= 1.2.0) | debconf-2.0, adduser (>= 3.10), dpkg (>= > 1.7.0), passwd > > I will focus on this part of that collection: > ... libssl1.0.0 (>= 1.0.1) ... > > At the time openssh-client was created and pushed out those were the > minimum versions it required. But then other libs such as libssl1.0.0 > will upgrade independently. They will either need to move forward due > to general needs such as compatibility. Or it might have a security > vulnerability. It will be upgraded to a newer version number. > > Meanwhile the ssh packaging will not have changed. That program is > only using the library. It won't change in order to specify a new > requirement until the next time it is rolled out for whatever reason. > In the meantime it will be perfectly fine. The dependency chain will > be satified with the installed version. Therefore running "install > openssh-client" will also be satisified. > > > Hmmm, and we don't have apt-get --update-dependencies install ssh, > > Of course it would be possible to create such a thing for Debian's APT > but the thinking is rather different. Because if one thing needs to > be upgraded then probably another thing needs to be upgraded too. One > could chase down a particular tree of dependencies only. But why do > that instead of more simply ensuring that everything is up to date. > If one thing is up to date manually but another thing is not then that > other thing is suffering and may be vulnerable to security problems or > other breakage. Better to make sure everything is up to date. > > > I see that I'm 1,680 packages behind... > > Things do change rapidly in Unstable! :-) > > > > On Sid/Unstable I upgrade daily with: > > > > > > # apt-get update > > > # apt-get upgrade > > > # apt-get dist-upgrade > > I should have added at the end that I run "clean" to empty out the > cache directory. Otherwise the buildup of cached packages can consume > all available disk space. Not knowing that option, I had manually deleted them. > > The resolution of more complicated dependency issues, has > > improved a lot, in my subjective opinion. Let's see how my > > current upgrade goes > > There are some current problems. Bug#676485 for example. But I am > confident it will all be worked out before release. > > > Some 1300 were packaged installed by 'upgrade' another 340 > > packages installed by 'dist-upgrade'. > That is a good example of why 'upgrade' followed by 'dist-upgrade' > reduces the problem space for the resolver to deal with. Going from > 1300 to 340 is a huge reduction in problem space size. And for the > human looking over the "remove" list. :-) > > There were minor hiccups. In both cases errors were reported, and > > in both cases an extra apt-get install completed the process. > > Sounds about normal. If you had upgraded daily you would probably > have seen those and a handful more but one at a time as they > happened. The difference is spending time dealing with it lumped > versus amortized over the year. What *is* biting me is that the new multiarch organization won't allow me to (re)install skype, which is expecting ia32-libs and ia32-libs-gtk. > > Your descriptions of the upgrade procedure and how to > > review it and hold packages could be a useful reference > > for users of testing or unstable. > > Where would we put it? > > Also there is: > > > http://wiki.debian.org/DebianUnstable#What_are_some_best_practices_for_testing.2BAC8-sid_users.3F It would go with that subject matter, but your is text longer and more explanatory, the next level of detail. Many non-experts use unstable. They need to know. How do I keep my Sid-based system current? The best practice is to upgrade your system regularly, and deal with the occasional breakage that occurs. As (Bob Proulx | one e
Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
Joel Roth wrote: > Bob Proulx wrote: > > Joel Roth wrote: > > > I usually just upgrade apps individually as I need to... > > > > As in 'apt-get install openssh-client' ? But that won't upgrade any > > of the dependencies. > > I didn't know that. My first try was apt-get install ssh. If the packages were not previously installed then of course the entire dependency tree is pulled in and installed in order to satisfy the dependencies. And if a new version dependency appears such as bind9 for example which always depends upon specific versions of libraries then those new versions will be upgraded too. But if there isn't a specific need by stated dependency to pull in a newer version then it won't be triggered for an install. For example 'ssh' has: $ apt-cache show ssh | grep ^Depends: Depends: openssh-client, openssh-server $ apt-cache show openssh-client | grep ^Depends: Depends: libc6 (>= 2.11), libedit2 (>= 2.11-20080614-1), libgssapi-krb5-2 (>= 1.10+dfsg~), libselinux1 (>= 1.32), libssl1.0.0 (>= 1.0.1), zlib1g (>= 1:1.1.4), debconf (>= 1.2.0) | debconf-2.0, adduser (>= 3.10), dpkg (>= 1.7.0), passwd I will focus on this part of that collection: ... libssl1.0.0 (>= 1.0.1) ... At the time openssh-client was created and pushed out those were the minimum versions it required. But then other libs such as libssl1.0.0 will upgrade independently. They will either need to move forward due to general needs such as compatibility. Or it might have a security vulnerability. It will be upgraded to a newer version number. Meanwhile the ssh packaging will not have changed. That program is only using the library. It won't change in order to specify a new requirement until the next time it is rolled out for whatever reason. In the meantime it will be perfectly fine. The dependency chain will be satified with the installed version. Therefore running "install openssh-client" will also be satisified. > Hmmm, and we don't have apt-get --update-dependencies install ssh, Of course it would be possible to create such a thing for Debian's APT but the thinking is rather different. Because if one thing needs to be upgraded then probably another thing needs to be upgraded too. One could chase down a particular tree of dependencies only. But why do that instead of more simply ensuring that everything is up to date. If one thing is up to date manually but another thing is not then that other thing is suffering and may be vulnerable to security problems or other breakage. Better to make sure everything is up to date. > I see that I'm 1,680 packages behind... Things do change rapidly in Unstable! :-) > > On Sid/Unstable I upgrade daily with: > > > > # apt-get update > > # apt-get upgrade > > # apt-get dist-upgrade I should have added at the end that I run "clean" to empty out the cache directory. Otherwise the buildup of cached packages can consume all available disk space. > The resolution of more complicated dependency issues, has > improved a lot, in my subjective opinion. Let's see how my > current upgrade goes There are some current problems. Bug#676485 for example. But I am confident it will all be worked out before release. > Some 1300 were packaged installed by 'upgrade' another 340 > packages installed by 'dist-upgrade'. That is a good example of why 'upgrade' followed by 'dist-upgrade' reduces the problem space for the resolver to deal with. Going from 1300 to 340 is a huge reduction in problem space size. And for the human looking over the "remove" list. :-) > There were minor hiccups. In both cases errors were reported, and > in both cases an extra apt-get install completed the process. Sounds about normal. If you had upgraded daily you would probably have seen those and a handful more but one at a time as they happened. The difference is spending time dealing with it lumped versus amortized over the year. > Your descriptions of the upgrade procedure and how to > review it and hold packages could be a useful reference > for users of testing or unstable. Where would we put it? Also there is: http://wiki.debian.org/DebianUnstable#What_are_some_best_practices_for_testing.2BAC8-sid_users.3F Bob signature.asc Description: Digital signature
Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
Bob Proulx wrote: > Joel Roth wrote: > > Bob Proulx wrote: > > > Joel Roth wrote: > > > > I'm just so used to the dependencies being taken > > > > care of by APT, that I was surprised to have to > > > > lift my little pinkie. > > > > > > Uhm... An 'apt-get upgrade' should have offered those for upgrade. > > > They do for me. They didn't for you? Perhaps you have pinning or > > > other preventatives in place? Please say more! > > > > Ah, I didn't even think to try an apt-get upgrade. > > !!?? Shock! Surprise! It is the *first* thing I think of to try to > fix something. Well, it's a credit to Debian and software in general that I've coasted along. > > I usually just upgrade apps individually as I need to... > > As in 'apt-get install openssh-client' ? But that won't upgrade any > of the dependencies. I didn't know that. My first try was apt-get install ssh. Hmmm, and we don't have apt-get --update-dependencies install ssh, I see that I'm 1,680 packages behind... > > an attitude based on (possibly) outdated fears of > > getting stuck in between upgrades of C libraries > > or other large-scale brokenness. > > As others commented (but I wanted to directly address this) you > shouldn't have this worry like this. And actually not getting > upgrades in a timely manor is a worse problem. > > On Sid/Unstable I upgrade daily with: > > # apt-get update > # apt-get upgrade > # apt-get dist-upgrade > > The first sync's the Packages files, the index of what is current. > Then the 'upgrade' is a very restricted upgrade that only upgrades > packages in place. It cannot pull in any new packages such as when a > package is split or when a package gains new dependencies. But most > important it cannot remove packages. > > Then 'dist-upgrade' and I look at the screen for dist-upgrade very > carefully. I cannot stress this enough. Look at that very carefully. > Most important is to check to see if any packages are going to be > removed. If a bind9 update wants to install new liblwres80 that is > okay. But if a netcf upgrade wants to remove kvm (Bug#694362 for > example) then do not do it! > > Examine the problem and apply "hold" to dpkg as needed to whatever > packages are appropriate 'apt-mark hold pkg' is a convenient frontend > to 'echo pkg hold | dpkg --set-selections'. After holding try the > dist-upgrade again. Repeat as needed until the result is > satisfactory. If this is needed then file a bug report. > > I do this every day. Because the changes from one day to the next day > are small enough that I can work through them and recognize them as > they occur. If I were to wait six months then the amount of thrash in > Sid/Unstable would make recognizing and reducing these problems much > more difficult. > > Also a Sid/Unstable upgrade that was from a year ago to today may need > special handling that was already taken care of in other ways. In a > day to day transition everything will be current and rolling. But > after a long time people forget and the upgrade may be broken in ways > that don't matter to anyone else and therefore will never get fixed. > Remember that only major release points such as Squeeze and Wheezy are > extensively tested across long times and large changes. Major > releases will work, within the documented procedures from the upgrade > notes. But what amounts to a similar major upgrade between Sid-2011 > and Sid-2012 won't be tested at all. You are on your own. > > > an attitude based on (possibly) outdated fears of > > getting stuck in between upgrades of C libraries > > or other large-scale brokenness. The resolution of more complicated dependency issues, has improved a lot, in my subjective opinion. Let's see how my current upgrade goes Some 1300 were packaged installed by 'upgrade' another 340 packages installed by 'dist-upgrade'. There were minor hiccups. In both cases errors were reported, and in both cases an extra apt-get install completed the process. I don't know when the last upgrade took place, next one will be sooner, I'm sure. > In summary if running Sid/Unstable or Testing too then I think it is > best to keep current and not let the parts get too old and stale. It > is just easier that way. "In for a penny, in for a pound." Your descriptions of the upgrade procedure and how to review it and hold packages could be a useful reference for users of testing or unstable. Joel > > Thanks for your comment. This list/community is a great support. > > It seriously is one of the best things! > > Bob -- Joel Roth -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121227005313.GA24616@sprite
Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
Osamu Aoki wrote: > If anyone have suggestion to improve debian-reference to prevent > people to take such strategy, let me know. Also, concrete case > example of why such method is less safer than 'apt-get upgrade' or > 'aptitude safe-upgrade', let us know. I think this case is one example. By selectively upgrading only the ssh program binary and not the dependent libraries the openssl libssl library was allowed to become stale. It was almost certainly behind on security upgrades as I remember there have been DSAs filed against it relatively recently. It was almost certainly vulnerable to DSA-2392-1, DSA-2454-2, or DSA-2475-1 for example. Bob signature.asc Description: Digital signature
Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
Joel Roth wrote: > Bob Proulx wrote: > > Joel Roth wrote: > > > I'm just so used to the dependencies being taken > > > care of by APT, that I was surprised to have to > > > lift my little pinkie. > > > > Uhm... An 'apt-get upgrade' should have offered those for upgrade. > > They do for me. They didn't for you? Perhaps you have pinning or > > other preventatives in place? Please say more! > > Ah, I didn't even think to try an apt-get upgrade. !!?? Shock! Surprise! It is the *first* thing I think of to try to fix something. > I usually just upgrade apps individually as I need to... As in 'apt-get install openssh-client' ? But that won't upgrade any of the dependencies. > an attitude based on (possibly) outdated fears of > getting stuck in between upgrades of C libraries > or other large-scale brokenness. As others commented (but I wanted to directly address this) you shouldn't have this worry like this. And actually not getting upgrades in a timely manor is a worse problem. On Sid/Unstable I upgrade daily with: # apt-get update # apt-get upgrade # apt-get dist-upgrade The first sync's the Packages files, the index of what is current. Then the 'upgrade' is a very restricted upgrade that only upgrades packages in place. It cannot pull in any new packages such as when a package is split or when a package gains new dependencies. But most important it cannot remove packages. Then 'dist-upgrade' and I look at the screen for dist-upgrade very carefully. I cannot stress this enough. Look at that very carefully. Most important is to check to see if any packages are going to be removed. If a bind9 update wants to install new liblwres80 that is okay. But if a netcf upgrade wants to remove kvm (Bug#694362 for example) then do not do it! Examine the problem and apply "hold" to dpkg as needed to whatever packages are appropriate 'apt-mark hold pkg' is a convenient frontend to 'echo pkg hold | dpkg --set-selections'. After holding try the dist-upgrade again. Repeat as needed until the result is satisfactory. If this is needed then file a bug report. I do this every day. Because the changes from one day to the next day are small enough that I can work through them and recognize them as they occur. If I were to wait six months then the amount of thrash in Sid/Unstable would make recognizing and reducing these problems much more difficult. Also a Sid/Unstable upgrade that was from a year ago to today may need special handling that was already taken care of in other ways. In a day to day transition everything will be current and rolling. But after a long time people forget and the upgrade may be broken in ways that don't matter to anyone else and therefore will never get fixed. Remember that only major release points such as Squeeze and Wheezy are extensively tested across long times and large changes. Major releases will work, within the documented procedures from the upgrade notes. But what amounts to a similar major upgrade between Sid-2011 and Sid-2012 won't be tested at all. You are on your own. > an attitude based on (possibly) outdated fears of > getting stuck in between upgrades of C libraries > or other large-scale brokenness. In summary if running Sid/Unstable or Testing too then I think it is best to keep current and not let the parts get too old and stale. It is just easier that way. "In for a penny, in for a pound." > Thanks for your comment. This list/community is a great support. It seriously is one of the best things! Bob signature.asc Description: Digital signature
Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
On Mon, Dec 24, 2012 at 10:48:00AM +0200, Andrei POPESCU wrote: > On Du, 23 dec 12, 20:15:19, Joel Roth wrote: > > > > Ah, I didn't even think to try an apt-get upgrade. > > I usually just upgrade apps individually as I need to... > > an attitude based on (possibly) outdated fears of > > getting stuck in between upgrades of C libraries > > or other large-scale brokenness. > > IMVHO your method is less safer than 'apt-get upgrade' or > 'aptitude safe-upgrade'. I can not agree with you more. But there seem to exist some myth on this feeling of safe upgrade using partial upgrade. With symbols file in the package, we as Debian seem to care library compatibility issues when transitioning package from unstable to testing. But this manual method does not check such thing. If anyone have suggestion to improve debian-reference to prevent people to take such strategy, let me know. Also, concrete case example of why such method is less safer than 'apt-get upgrade' or 'aptitude safe-upgrade', let us know. Osamu -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121224144647.GA8023@goofy.localdomain
Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
On Du, 23 dec 12, 20:15:19, Joel Roth wrote: > > Ah, I didn't even think to try an apt-get upgrade. > I usually just upgrade apps individually as I need to... > an attitude based on (possibly) outdated fears of > getting stuck in between upgrades of C libraries > or other large-scale brokenness. IMVHO your method is less safer than 'apt-get upgrade' or 'aptitude safe-upgrade'. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
On Wed, Dec 19, 2012 at 04:13:21PM -0700, Bob Proulx wrote: > Joel Roth wrote: > > Bob Proulx wrote: > > > On Sid I have: > > > openssh-client 1:6.0p1-3 > > > Depends: ... libssl1.0.0 (>= 1.0.1) ... > > > Make sure that at the least both of those are up to date. > > > > Thanks for this suggestion. Your intuition was right! > > > > I just needed to update openssh-client and openssh-server. > > > > I'm just so used to the dependencies being taken > > care of by APT, that I was surprised to have to > > lift my little pinkie. > > Uhm... An 'apt-get upgrade' should have offered those for upgrade. > They do for me. They didn't for you? Perhaps you have pinning or > other preventatives in place? Please say more! Ah, I didn't even think to try an apt-get upgrade. I usually just upgrade apps individually as I need to... an attitude based on (possibly) outdated fears of getting stuck in between upgrades of C libraries or other large-scale brokenness. 'apt-get upgrade' is a good first prophylactic, and this is one example. Thanks for your comment. This list/community is a great support. Happy holidays and best wishes. Joel > Bob -- Joel Roth -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121224061519.GA22892@sprite
Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
Joel Roth wrote: > Bob Proulx wrote: > > On Sid I have: > > openssh-client 1:6.0p1-3 > > Depends: ... libssl1.0.0 (>= 1.0.1) ... > > Make sure that at the least both of those are up to date. > > Thanks for this suggestion. Your intuition was right! > > I just needed to update openssh-client and openssh-server. > > I'm just so used to the dependencies being taken > care of by APT, that I was surprised to have to > lift my little pinkie. Uhm... An 'apt-get upgrade' should have offered those for upgrade. They do for me. They didn't for you? Perhaps you have pinning or other preventatives in place? Please say more! Bob signature.asc Description: Digital signature
Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
On Tue, Dec 18, 2012 at 12:36:02PM -0700, Bob Proulx wrote: > Joel Roth wrote: > > Joel Roth wrote: > > > $ git pull > > > OpenSSL version mismatch. Built against 105f, you have 1000103f > > > fatal: The remote end hung up unexpectedly > > > > This error also occurs when I use ssh directly, to any > > host. > > This reads to me that you have not updated your system, specifically > the openssl libraries. > > # apt-get update > # apt-get ugprade > > > Ah, well, actually I am using unstable... > > Be careful out there! :-) > > On Sid I have: > > openssh-client 1:6.0p1-3 > Depends: ... libssl1.0.0 (>= 1.0.1) ... > > Make sure that at the least both of those are up to date. > > $ apt-cache policy openssh-client libssl1.0.0 > > You might also need others too but I think you must be behind on > updates to those. Thanks for this suggestion. Your intuition was right! I just needed to update openssh-client and openssh-server. I'm just so used to the dependencies being taken care of by APT, that I was surprised to have to lift my little pinkie. Regards Joel > Bob -- Joel Roth -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121219095451.GA24518@sprite
