On Wed, 7 Dec 2016 21:36:37 +0200, Thanasis wrote:
> > While you can untar it, that's a bit messy, and has caused problems
> > for me in the past (overwriting the /lib symlink with a directory.
>
> There is an option for tar, to *not overwrite* a symlinked directory, I
> think it's *h*
On 07/12/2016 20:57, Alan Grimes wrote:
> Alan McKinnon wrote:
>> So why are you running it?
>
> Do I really need to answer that?
> I want my system upgraded and the gentle approach isn't working -> try
> the rough approach.
>
>
> I think a significant issue is that I have a number of dead and
Op woensdag 7 december 2016 13:57:04 schreef Alan Grimes:
> Alan McKinnon wrote:
> > So why are you running it?
>
> Do I really need to answer that?
> I want my system upgraded and the gentle approach isn't working -> try
> the rough approach.
>
Hello Alan,
It's against my better judgement, but
On 12/07/2016 04:28 PM, Neil Bothwick wrote:
On Wed, 7 Dec 2016 16:14:35 +0200, Alan McKinnon wrote:
I do not know what quickpkg is.
Makes a tarball of a package so you can later untar it and get the
package back without a remerge. It's all in portage's man pages
While you can untar it,
Alan McKinnon wrote:
> So why are you running it?
Do I really need to answer that?
I want my system upgraded and the gentle approach isn't working -> try
the rough approach.
I think a significant issue is that I have a number of dead and missing
packages:
Here's the revdep rebuild list, I
On Wed, 7 Dec 2016 16:14:35 +0200, Alan McKinnon wrote:
> > I do not know what quickpkg is.
>
> Makes a tarball of a package so you can later untar it and get the
> package back without a remerge. It's all in portage's man pages
While you can untar it, that's a bit messy, and has caused
On 07/12/2016 15:47, Alan Grimes wrote:
> Alan McKinnon wrote:
>> On 07/12/2016 15:03, Alan Grimes wrote:
>>> Certainly there are groups of packages in the 439 that could be updated
>>> without triggering these conflicts but then doing that automatically
>>> wouldn't waste enough of the user's
Alan McKinnon wrote:
> On 07/12/2016 15:03, Alan Grimes wrote:
>> Certainly there are groups of packages in the 439 that could be updated
>> without triggering these conflicts but then doing that automatically
>> wouldn't waste enough of the user's time...
>>
>>
>> [ebuild U ]
On 07/12/2016 15:03, Alan Grimes wrote:
> I have a user consuming most of my CPU time so that's part of the reason
> why it's slow...
>
> My current misery factory is 439...
>
> I didn't even get it to update BASH until day 4... The thing seems to
> have a problem with the --deep flag these
I have a user consuming most of my CPU time so that's part of the reason
why it's slow...
My current misery factory is 439...
I didn't even get it to update BASH until day 4... The thing seems to
have a problem with the --deep flag these days, omitting deep seems to
evade a number of the
10 matches
Mail list logo
