Control: tags -1 + moreinfo
Hi,
2012-03-10 10:00 Sven Joachim:
2. Insert some logic to not mark packages violating the multiarch
lockstep requirement, thereby avoiding invoking the resolver and the
resulting status messages.
Option 2 is easy, but personally I'd like to avoid it because it is
On 10 March 2012 22:17, Sven Joachim wrote:
> On 2012-03-10 14:53 +0100, Daniel Hartwig wrote:
>
>> Your original report only had the two
>> out-of-sync gcc packages available, which, of course, can not be
>> upgraded.
>
> Right, because I made the mistake of running
> "aptitude --full-resolver sa
On 2012-03-10 14:53 +0100, Daniel Hartwig wrote:
> On 10 March 2012 18:00, Sven Joachim wrote:
>> On 2012-03-10 04:17 +0100, Daniel Hartwig wrote:
>>
>>>
>>> However, the output of the programs does differ. Aptitude
>>> safe-upgrade reports that it can not resolve the dependency problems
>>> (co
On 10 March 2012 18:00, Sven Joachim wrote:
> On 2012-03-10 04:17 +0100, Daniel Hartwig wrote:
>
>>
>> However, the output of the programs does differ. Aptitude
>> safe-upgrade reports that it can not resolve the dependency problems
>> (correct), and that the user should try using the full resolv
On 2012-03-10 04:17 +0100, Daniel Hartwig wrote:
> On 10 March 2012 00:42, Sven Joachim wrote:
>> Would be
>> interesting to see what apt-get does if the dist-upgrade does not
>> require removing essential packages.
>
> I have included output from apt-get in this situation.[1]
>
> It seems that b
On 10 March 2012 00:42, Sven Joachim wrote:
> Would be
> interesting to see what apt-get does if the dist-upgrade does not
> require removing essential packages.
I have included output from apt-get in this situation.[1]
It seems that both programs do the same thing here:
1. mark all upgradable
On 10 March 2012 00:39, Sven Joachim wrote:
>>
>> You can record the state using aptitude-create-state-bundle.
>
> Of course, silly me.
>
>> That will contain enough info to reproduce it at a later date.
>
> Hopefully it does, the experience in #655483 was not so great. Would
> you be interested
On 2012-03-09 05:19 +0100, Daniel Hartwig wrote:
> On 9 March 2012 11:16, Daniel Hartwig wrote:
>> On 9 March 2012 03:09, Sven Joachim wrote:
>>> Package: aptitude
>>> Version: 0.6.5-1
>>> User: multiarch-de...@lists.alioth.debian.org
>>> Usertags: multiarch
>>>
>>> A few days ago there was a si
On 2012-03-09 04:16 +0100, Daniel Hartwig wrote:
> On 9 March 2012 03:09, Sven Joachim wrote:
>> Package: aptitude
>> Version: 0.6.5-1
>> User: multiarch-de...@lists.alioth.debian.org
>> Usertags: multiarch
>>
>> A few days ago there was a situation where libgcc1:amd64 was at a newer
>> version t
On 9 March 2012 11:16, Daniel Hartwig wrote:
> On 9 March 2012 03:09, Sven Joachim wrote:
>> Package: aptitude
>> Version: 0.6.5-1
>> User: multiarch-de...@lists.alioth.debian.org
>> Usertags: multiarch
>>
>> A few days ago there was a situation where libgcc1:amd64 was at a newer
>> version than
On 9 March 2012 03:09, Sven Joachim wrote:
> Package: aptitude
> Version: 0.6.5-1
> User: multiarch-de...@lists.alioth.debian.org
> Usertags: multiarch
>
> A few days ago there was a situation where libgcc1:amd64 was at a newer
> version than libgcc1:i386, and aptitude was unable to perform a
> sa
Package: aptitude
Version: 0.6.5-1
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch
A few days ago there was a situation where libgcc1:amd64 was at a newer
version than libgcc1:i386, and aptitude was unable to perform a
safe-upgrade for this case (the correct solution is not to do
12 matches
Mail list logo
