On 3/8/21 5:59 PM, antlists wrote:
As I remember, you always had to use eselect to switch versions ... and
witness all the chaos with python at the moment ...
I don't know.
If you leave things "at the default", doesn't that screw you over when
python/kernel/gcc etc upgrade and a depclean
On Tue, 9 Mar 2021 17:26:41 +0100, smurfd wrote:
> Massive congrats :)
> Great when things work out, after doing a ton of work to get there.
As the great Douglas Adams once said
"I am rarely happier than when spending an entire day programming my
computer to perform automatically a task that
Massive congrats :)
Great when things work out, after doing a ton of work to get there.
br smurfd
On 2021-03-08 23:06, Grant Taylor wrote:
On 2/25/21 5:31 PM, Grant Taylor wrote:
10 have git switch to the next day
20 emerge -aDUN @world
30 assess / deal with masked packages
40 goto 10
It
On Tue, 9 Mar 2021 00:59:29 +, antlists wrote:
> > It means you probably spent a lot of time compile gcc versions only to
> > carry on using the old version, but as you said, this wasn't about
> > efficiency. You were going to emerge -e @world at the end anyway,
> > which would get everything
On 08/03/2021 23:16, Neil Bothwick wrote:
I don't remember what it was at the start, probably 8. or
9.. I did see 9.3 somewhere along the way. gcc -v says
that 10.2.0 is currently installed.
It means you probably spent a lot of time compile gcc versions only to
carry on using the old
On 3/8/21 5:35 PM, Neil Bothwick wrote:
Not if you went up a slot, then the old version would still continue to
be used until you ran gcc-config. However, if you were depcleaning at each
step, that would remove the previous slot and you would stay current.
So my overall method, which included
On Mon, 8 Mar 2021 16:44:35 -0700, Grant Taylor wrote:
> > It means you probably spent a lot of time compile gcc versions only
> > to carry on using the old version, but as you said, this wasn't about
> > efficiency.
>
> Wouldn't the next execution of gcc, post Emerge & Installation use the
On 3/8/21 4:16 PM, Neil Bothwick wrote:
It would have to be done before the first update, when the repo was
set to a date just after the last update.
Yes and no.
It really could have been done at any point along the way.
Also, with the git version of the portage repo, I could switch back to
On Mon, 8 Mar 2021 15:44:38 -0700, Grant Taylor wrote:
> On 3/8/21 3:29 PM, Neil Bothwick wrote:
> > With hindsight, removing firefox, thunderbird and libreoffice and
> > replacing them with their -bin counterparts at the start of the
> > process would have saved much time. You could switch
On 3/8/21 3:29 PM, Neil Bothwick wrote:
With hindsight, removing firefox, thunderbird and libreoffice and
replacing them with their -bin counterparts at the start of the
process would have saved much time. You could switch back to the
source options once the system is up to date.
You're
On Mon, 8 Mar 2021 15:06:01 -0700, Grant Taylor wrote:
> The following packages take what seems like F O R E V E R to emerge:
>
> - gcc
> - rust
> - Firefox
> - Thunderbird
With hindsight, removing firefox, thunderbird and libreoffice and
replacing them with their -bin counterparts at
On 2/25/21 5:31 PM, Grant Taylor wrote:
10 have git switch to the next day
20 emerge -aDUN @world
30 assess / deal with masked packages
40 goto 10
It /looks/ like things are working.
*TL;DR*
DenverCoder9: DEAR PEOPLE FROM THE FUTURE ...
This method /does/ work. I have successfully brought
On Sat, 27 Feb 2021 08:59:08 +, Michael wrote:
> > That's right, the source files are in $DISTDIR, unless you have
> > cleaned it. /var/db/pkg contains all the information portage needs
> > about the installed software.
>
> $ emerge --info | grep DISTDIR
>
> will show if the source files
On Saturday, 27 February 2021 08:34:02 GMT Neil Bothwick wrote:
> On Sat, 27 Feb 2021 00:47:04 -0700, Grant Taylor wrote:
> > The ebuild and what looks like additional metadata files are in the
> > /var/db/pkg directory tree. But the source files aren't in the tree.
> > At least not for the
On Sat, 27 Feb 2021 00:47:04 -0700, Grant Taylor wrote:
> The ebuild and what looks like additional metadata files are in the
> /var/db/pkg directory tree. But the source files aren't in the tree.
> At least not for the example package I looked at.
That's right, the source files are in
On 2/26/21 11:55 PM, Arve Barsnes wrote:
I'm not sure what you're saying here, but the ebuild files of the
installed packages are in /var/db/pkg
Hum.
Today I Learned...
The ebuild and what looks like additional metadata files are in the
/var/db/pkg directory tree. But the source files
On Fri, 26 Feb 2021 at 23:30, Grant Taylor
wrote:
> > If the packages are installed, the ebuilds are in var/db/pkg.
>
> The package (distribution files) for the version that is installed are
> in distfiles. But that does little for an ebuild that's looking for a
> newer version that's no longer
On 2/26/21 12:50 PM, Neil Bothwick wrote:
Ah yes, I hadn't thought about the mirrors being too up to date.
There's also issue with older packages being installed. E.g. I have an
older kernel source (4.14.127) that I'm keeping around for various
reasons. I've found that the Gentoo repo /
On Fri, 26 Feb 2021 11:44:12 -0700, Grant Taylor wrote:
> I have run into a few problems where emerge can't download files. So
> I'm finding them online, downloading them, and saving them to
> /usr/portage/distfiles.
Ah yes, I hadn't thought about the mirrors being too up to date.
> I have
On 2/25/21 5:31 PM, Grant Taylor wrote:
10 have git switch to the next day
20 emerge -aDUN @world
30 assess / deal with masked packages
40 goto 10
It /looks/ like things are working.
This method is working.
I have managed to successfully update from 2020-03-24 to 2020-05-29 in
one day
On Thu, 25 Feb 2021 17:31:15 -0700, Grant Taylor wrote:
> One added advantage of doing this day by day is that when I do get to
> the big changes, things should be fairly clean. Thus hopefully
> simplifying the big changes.
You are also going to hit the annoying bugs that were fixed a few
On 2/24/21 9:29 PM, Grant Taylor wrote:
I'm currently doing an "emerge -DUNe @system" on the restore of
/usr/portage (typical PORTDIR) from prior to messing with things today.
The system is now stable with a full -DUNe @system.
emerge -DUNe @system
reboot
emerge -DUNe @world &&
On Thursday, 25 February 2021 15:42:38 GMT Grant Taylor wrote:
> On 2/25/21 2:51 AM, Michael wrote:
> > A reinstall in this context is not a wholesale replace.
>
> ~blink~
>
> > It implies obtaining the latest Stage 3 archive from a mirror,
> > but retaining part of your current installation.
On 2/25/21 2:51 AM, Michael wrote:
It would probably be better even with a lot of customizations. ;-)
Please elaborate on what "better" means in this case. I'm thinking that
you might be meaning "faster" and / or "easier" (as in less effort).
At least it /should/ be better in terms of
On Thu, 25 Feb 2021 09:51:25 +, Michael wrote:
> > Besides, wouldn't each of the incremental processes over the last year
> > have been possible? ;-)
>
> Yes, it would have been, but what is the benefit of updating multiple
> packages many times over, instead of doing it just once?
One
On 25/02/21 08:45, hitachi303 wrote:
> Am 25.02.2021 um 02:43 schrieb Grant Taylor:
>> I need to update a system that hasn't been updated in 337 days (March
>> 24th 2020. -- Life has been ... trying.
>>
>> What is the best way forward?
>>
>> It seems as if there have been a lot of changes in the
On Thursday, 25 February 2021 04:29:25 GMT Grant Taylor wrote:
> On 2/24/21 9:16 PM, John Covici wrote:
[snip ...]
> > Unless you have a lot of customizations, reinstall would be much
> > better.
It would probably be better even with a lot of customizations. ;-)
At least it /should/ be better
Am 25.02.2021 um 02:43 schrieb Grant Taylor:
I need to update a system that hasn't been updated in 337 days (March
24th 2020. -- Life has been ... trying.
What is the best way forward?
It seems as if there have been a lot of changes in the interim; glibc,
Python 2.7 being deprecated,
On 2/24/21 9:16 PM, John Covici wrote:
The portdir has to be the one gotten from git, not rsync,
ACK
I'm currently doing an "emerge -DUNe @system" on the restore of
/usr/portage (typical PORTDIR) from prior to messing with things today.
I've got multiple GB of git data. It looks like
On Wed, 24 Feb 2021 21:20:05 -0500,
Grant Taylor wrote:
>
> On 2/24/21 6:48 PM, John Covici wrote:
> > What you could try to do, if you are syncing using git, is to
> > roll it back to those dates by checking out a commit each time
> > and doing an update. I don't guarantee it would work, but
On 2/24/21 6:48 PM, John Covici wrote:
What you could try to do, if you are syncing using git, is to roll
it back to those dates by checking out a commit each time and doing
an update. I don't guarantee it would work, but its worth a shot,
otherwise reinstall time.
I hit send too soon.
On 2/24/21 6:48 PM, John Covici wrote:
What you could try to do, if you are syncing using git, is to roll
it back to those dates by checking out a commit each time and doing
an update. I don't guarantee it would work, but its worth a shot,
otherwise reinstall time.
And what if I was still
On Wed, 24 Feb 2021 20:43:39 -0500,
Grant Taylor wrote:
>
> I need to update a system that hasn't been updated in 337 days
> (March 24th 2020. -- Life has been ... trying.
>
> What is the best way forward?
>
> It seems as if there have been a lot of changes in the interim;
> glibc, Python
I need to update a system that hasn't been updated in 337 days (March
24th 2020. -- Life has been ... trying.
What is the best way forward?
It seems as if there have been a lot of changes in the interim; glibc,
Python 2.7 being deprecated, default Python going to 3.7(?), other
breaking
34 matches
Mail list logo
