2008/6/10 Ira Abramov <[EMAIL PROTECTED]>:
> Quoting Amos Shapira, from the post of Sat, 07 Jun:
>> >> But can you mark a package as "nothing depends on it, but I want it
>> >> around" (lower-case "m" in aptitude) vs. "keep it around as long as
>> >> something needs it, but remove it when it's no l
Quoting Amos Shapira, from the post of Sat, 07 Jun:
> >> But can you mark a package as "nothing depends on it, but I want it
> >> around" (lower-case "m" in aptitude) vs. "keep it around as long as
> >> something needs it, but remove it when it's no longer needed by
> >> anything else" (upper-case
2008/6/7 Ira Abramov <[EMAIL PROTECTED]>:
> Quoting Amos Shapira, from the post of Tue, 03 Jun:
>> On Tue, Jun 3, 2008 at 8:05 AM, Ira Abramov
>> >
>> > I have no idea where that comes from. "apt-get autoremove" takes care of
>> > packages that are no longer dependent upon (or is that only in sid?)
Quoting Amos Shapira, from the post of Tue, 03 Jun:
> On Tue, Jun 3, 2008 at 8:05 AM, Ira Abramov
> >
> > I have no idea where that comes from. "apt-get autoremove" takes care of
> > packages that are no longer dependent upon (or is that only in sid?).
>
> But can you mark a package as "nothing de
One other small thing: If ever something breaks, 'apt-get install -f'
usually has the minimal brains to recover. 'aptitude install -f' seems
to be too smart for its own good in such cases (asking to remove some
packages and such).
I also prefer the default of 'apt-cache search' to that of 'aptitud
On Tue, Jun 3, 2008 at 8:05 AM, Ira Abramov
<[EMAIL PROTECTED]> wrote:
> Quoting Amos Shapira, from the post of Mon, 02 Jun:
>> > First, stop working with apt-get. Only work with aptitude.
>>
>> That's what I always do - just because aptitude is smart enough to
>> mark "automatically installed pack
Quoting Amos Shapira, from the post of Mon, 02 Jun:
> > First, stop working with apt-get. Only work with aptitude.
>
> That's what I always do - just because aptitude is smart enough to
> mark "automatically installed packages" to be removed when no longer
> required, but also because it indeed gi
On Mon, Jun 2, 2008 at 2:24 PM, Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> Amos Shapira wrote:
>>
>>>
>>> The correct package version is libssl0.9.8-4etch3 . That's where the
>>> PRNG code resides.
>>>
>>
>> $ dpkg -l libssl0.9.8
>> Desired=Unknown/Install/Remove/Purge/Hold
>> | Status=Not/Instal
On Mon, Jun 02, 2008 at 07:24:30AM +0300, Shachar Shemesh wrote:
> Amos Shapira wrote:
> >
> >>
> >>The correct package version is libssl0.9.8-4etch3 . That's where the
> >>PRNG code resides.
> >>
> >
> >$ dpkg -l libssl0.9.8
> >Desired=Unknown/Install/Remove/Purge/Hold
> >| Status=Not/Installe
Amos Shapira wrote:
and as far as I can tell this one didn't come from backports.
Maybe they had it and removed it the moment they realized it breaks the
ssl upgrade. If that happens, it will seem like a locally created
package to aptitude, and it won't point the finger any longer. Sadly,
Amos Shapira wrote:
The correct package version is libssl0.9.8-4etch3 . That's where the
PRNG code resides.
$ dpkg -l libssl0.9.8
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=bot
On Sun, Jun 1, 2008 at 10:07 PM, Yedidyah Bar-David
<[EMAIL PROTECTED]> wrote:
> Mind you, the bug was not in openssh, but in openssl. You should (at
> least) update this one too. It affected many other packagess, including
> openssh, which was updated to check for bad keys etc., but the actual fix
On Sun, Jun 1, 2008 at 10:14 PM, Tzafrir Cohen <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 01, 2008 at 09:49:34PM +1000, Amos Shapira wrote:
>> On Sun, Jun 1, 2008 at 3:56 PM, Ira Abramov
>
>> > make sure you did dist-upgrade and not just upgrade. I think without it,
>>
>> Why "dist-upgrade"? It's a s
On Sun, Jun 01, 2008 at 09:49:34PM +1000, Amos Shapira wrote:
> On Sun, Jun 1, 2008 at 3:56 PM, Ira Abramov
> > make sure you did dist-upgrade and not just upgrade. I think without it,
>
> Why "dist-upgrade"? It's a security fix for the same distro (Debian Etch).
The "dist-upgrade" is due to the
On Sun, Jun 01, 2008 at 09:49:34PM +1000, Amos Shapira wrote:
> Why "dist-upgrade"? It's a security fix for the same distro (Debian Etch).
Contrary to common wisdom (and intuition), dist-upgrade is not related
to upgrading between distros. The difference between it and upgrade is
that upgrade will
On Sun, Jun 01, 2008 at 09:00:11PM +1000, Amos Shapira wrote:
> On Sun, Jun 1, 2008 at 8:01 PM, Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> > Actually, it's better to have the "security" repository after the isoc one.
> > This way, if both have the same package, you will get it from the
> > geogra
On Sun, Jun 1, 2008 at 3:56 PM, Ira Abramov
<[EMAIL PROTECTED]> wrote:
> Quoting Amos Shapira, from the post of Fri, 30 May:
>>
>> All packages on my Debian Etch desktop are up to date, "vulnkeys"
>> found old vulnerable keys and I cleaned them up (also from other
>> systems).
>>
>> BUT - I can't g
On Sun, Jun 1, 2008 at 8:01 PM, Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> Actually, it's better to have the "security" repository after the isoc one.
> This way, if both have the same package, you will get it from the
> geographically closer one.
>
> But, yes, failing to have the security source
Ariel Bar-David wrote:
I had the same problem (bad keys generated after dist-upgrade),
and I updated my source.list (in a most newbie way, without
investigating anything)
from:
deb http://mirror.isoc.org.il/pub/debian/ etch main non-free contrib
deb-src http://mirror.isoc.org.il/pub/debi
I had the same problem (bad keys generated after dist-upgrade),
and I updated my source.list (in a most newbie way, without
investigating anything)
from:
deb http://mirror.isoc.org.il/pub/debian/ etch main non-free contrib
deb-src http://mirror.isoc.org.il/pub/debian/ etch main non-free c
Quoting Amos Shapira, from the post of Fri, 30 May:
>
> All packages on my Debian Etch desktop are up to date, "vulnkeys"
> found old vulnerable keys and I cleaned them up (also from other
> systems).
>
> BUT - I can't generate good keys on Debian any more:
that's odd. are you sure you are not r
(Sent to Noam in private by mistake - sorry Noam)
On Fri, May 16, 2008 at 7:06 PM, Noam Rathaus <[EMAIL PROTECTED]> wrote:
> The new ssl and ssh packages don't work if they are given known vulnerable
>
> During upgrade/update they upgrade/replace bad keys
All packages on my Debian Etch desktop ar
22 matches
Mail list logo
