[gentoo-user] migrating to gcc-3.4.4

[gentoo-user] migrating to gcc-3.4.4

[Fernando Meira]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

I've decided to migrate to gcc-3.4.4, so I've emerged it, and switch the 
system to use it instead the previous (gcc-3.3.5-20050130).

After that I am supposed to update my system packages, so when I run
# emerge -va system
I get:
[ebuild N ] sys-devel/patch-2.5.9 -build -static 197 kB 
[ebuild N ] app-arch/bzip2-1.0.3-r5 -build -static 0 kB 
[ebuild N ] app-arch/cpio-2.6-r4 +nls 0 kB 
[ebuild N ] sys-apps/texinfo-4.8 -build +nls -static 0 kB 
[ebuild N ] dev-lang/tcl-8.4.9 -threads 0 kB 
[ebuild N ] sys-devel/gnuconfig-20050324 0 kB 
[ebuild N ] sys-libs/readline-5.0-r2 0 kB 
(...)
All with "N"!! I understand that this is not a update.. will the old 
packages be overwritten?
It doesn't make sense to think that I'll have duplicate apps... but just for 
being sure.. :)

In the middle of that list are:
[ebuild N ] sys-devel/gcc-3.4.4
[ebuild N ] sys-devel/gcc-3.3.6

This will compile anew gcc-3.4.4, but this time using the new compiler. 
That's the point, right?
The old gcc version is still there.. I haven't unmerge it yet, cause I first 
want to check if all goes fine..

So, should I go ahead..?

Thanks,
Fernando

[-- Attachment #2: Type: text/html, Size: 1529 bytes --]

[gentoo-user] Re: migrating to gcc-3.4.4

[Fernando Meira]

[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]

Oh.. and by the way, how reliable is this prediction?
(...)
[ebuild N ] sys-apps/hdparm-5.9 
[ebuild N ] sys-libs/pwdb-0.62 

Estimated update time: 6 hours, 7 minutes.

All system in 6h? It is something like 120 packages..

On 8/24/05, Fernando Meira <fmeira@gmail.com> wrote:
> 
> I've decided to migrate to gcc-3.4.4, so I've emerged it, and switch the 
> system to use it instead the previous (gcc-3.3.5-20050130).
> 
> After that I am supposed to update my system packages, so when I run
> # emerge -va system
> I get:
> [ebuild N ] sys-devel/patch-2.5.9 -build -static 197 kB 
> [ebuild N ] app-arch/bzip2-1.0.3-r5 -build -static 0 kB 
> [ebuild N ] app-arch/cpio-2.6-r4 +nls 0 kB 
> [ebuild N ] sys-apps/texinfo-4.8 -build +nls -static 0 kB 
> [ebuild N ] dev-lang/tcl-8.4.9 -threads 0 kB 
> [ebuild N ] sys-devel/gnuconfig-20050324 0 kB 
> [ebuild N ] sys-libs/readline-5.0-r2 0 kB 
> (...)
> All with "N"!! I understand that this is not a update.. will the old 
> packages be overwritten?
> It doesn't make sense to think that I'll have duplicate apps... but just 
> for being sure.. :)
> 
> In the middle of that list are:
> [ebuild N ] sys-devel/gcc-3.4.4
> [ebuild N ] sys-devel/gcc-3.3.6
> 
> This will compile anew gcc-3.4.4, but this time using the new compiler. 
> That's the point, right?
> The old gcc version is still there.. I haven't unmerge it yet, cause I 
> first want to check if all goes fine..
> 
> So, should I go ahead..?
> 
> Thanks,
> Fernando
>

[-- Attachment #2: Type: text/html, Size: 2203 bytes --]

Re: [gentoo-user] Re: migrating to gcc-3.4.4

[Willie Wong]

On Wed, Aug 24, 2005 at 08:30:11PM +0000, Fernando Meira wrote:
> Oh.. and by the way, how reliable is this prediction?
> (...)
> [ebuild N ] sys-apps/hdparm-5.9 
> [ebuild N ] sys-libs/pwdb-0.62 
> 
> Estimated update time: 6 hours, 7 minutes.
> 
> All system in 6h? It is something like 120 packages..
> 

What's the speed of your box? I recently did an emerge --emptytree
world on my 1.6G Pentium M laptop. It had 446 packages done in less
than 29 hours (I say less than because if would run long stretches at
a time and stop after failed downloads here and there because of
wireless problems... for all I know it could have been sitting there
waiting for me to fix my wireless router for a couple of hours or
more). 

So if you have a comparably fast system, with not too many useflags
enabled, I'd say that 120 packages in 6 hours is quite possible. 

W
>

-- 
   As a math atheist, I think I should be excused from this.
              --- Calvin, to Hobbes
Sortir en Pantoufles: up 13 days,  2:38
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: migrating to gcc-3.4.4

[Fernando Meira]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

On 8/24/05, Willie Wong <wwong@princeton.edu> wrote:
> 
> On Wed, Aug 24, 2005 at 08:30:11PM +0000, Fernando Meira wrote:
> > Oh.. and by the way, how reliable is this prediction?
> > (...)
> > [ebuild N ] sys-apps/hdparm-5.9
> > [ebuild N ] sys-libs/pwdb-0.62
> >
> > Estimated update time: 6 hours, 7 minutes.
> >
> > All system in 6h? It is something like 120 packages..
> >
> 
> What's the speed of your box? I recently did an emerge --emptytree
> world on my 1.6G Pentium M laptop. It had 446 packages done in less
> than 29 hours (I say less than because if would run long stretches at
> a time and stop after failed downloads here and there because of
> wireless problems... for all I know it could have been sitting there
> waiting for me to fix my wireless router for a couple of hours or
> more).
> 
> So if you have a comparably fast system, with not too many useflags
> enabled, I'd say that 120 packages in 6 hours is quite possible.


I have a P4-2.4GHz laptop. 
I forgot to say that the estimation time was made by genlop. And was quite 
wrong! It took something like 11h to compile 112 packages, (though I've 
interrupted while compiling gcc-3.3.6.. so it had to restart it anew). From 
this, I don't know if I should trust genlop anymore.. or is there something 
to configure so that it is more accurate?

Just for the record, the migration to gcc-3.4.4 went just fine.. until now 
at least. :)

[-- Attachment #2: Type: text/html, Size: 1780 bytes --]

Re: [gentoo-user] genlop times was: migrating to gcc-3.4.4

[Willie Wong]

On Thu, Aug 25, 2005 at 11:51:32AM +0000, Fernando Meira wrote:
> I have a P4-2.4GHz laptop. 
> I forgot to say that the estimation time was made by genlop. And was quite 
> wrong! It took something like 11h to compile 112 packages, (though I've 
> interrupted while compiling gcc-3.3.6.. so it had to restart it anew). From 
> this, I don't know if I should trust genlop anymore.. or is there something 
> to configure so that it is more accurate?
> 
> Just for the record, the migration to gcc-3.4.4 went just fine.. until now 
> at least. :)

hum. Genlop looks at the past emerge times of the packages, calculates
an average based on that. 

The one thing genlop can't do is figure out how long it takes to merge
new packages. So it just skips them. That is the only way I see genlop
being wrong by so much. (The other possibility is that you were
running the box with a high load WHILE compiling, though I guess you
won't be complaining if that were the case.)

To be honest, I've found the genlop time quite reliable... I've
rebuilt my systems with --emptytree a few times in the past 6 months.
(Once after killing PAM and LDAP, once after changing to hardened,
once after changing from ~x86 to x86, and once after a major rehaul of
my USE flags; these are on my desktop machine only). The 500 or so
packages came up to be 1 day and 15 hours from genlop. The actual
compiles never took more than 2 days, and that was while the computer
was still in use. Once it actually finished before the estimated time. 

Do note that, however, genlop can only calculate its merge time based
on past averages. So if you made major changes to your system, or if
the codebase changed significantly upstream, genlop can be completely
wrong. For example, looking at past emerges of glibc, I see the
compile time goes from everything between 28 minutes to 3 hours.
genlop tells me that if I were to remerge glibc it would take me 1
hour and 9 minutes. But I know from experience if I were to install
2.3.5-r1, it will most likely only take me 40 minutes, and if I were
to compile glibc-2.3.4.20050125-r1, it will take me about 2 hour and
10 minutes. Why the funky discrepancy I don't know. So I think that
while genlop is generally rather reliable for a rough idea on how long
I need to wait for the compile (i.e. is it worth it just sitting here
reading a book or should I just go to bed), the numbers it give should
be taken with a grain of salt if you don't have a large number of
history of emerges for it to base its guesses on. 

W

-- 
"Anyone who is capable of getting themselves made President 
should on no account be allowed to do the job." 

- Some wisdom from The Book. 
Sortir en Pantoufles: up 13 days, 18:42
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] genlop times was: migrating to gcc-3.4.4

[Fernando Meira]

[-- Attachment #1: Type: text/plain, Size: 3627 bytes --]

On 8/25/05, Willie Wong <wwong@princeton.edu> wrote:
> 
> On Thu, Aug 25, 2005 at 11:51:32AM +0000, Fernando Meira wrote:
> > I have a P4-2.4GHz laptop.
> > I forgot to say that the estimation time was made by genlop. And was 
> quite
> > wrong! It took something like 11h to compile 112 packages, (though I've
> > interrupted while compiling gcc-3.3.6.. so it had to restart it anew). 
> From
> > this, I don't know if I should trust genlop anymore.. or is there 
> something
> > to configure so that it is more accurate?
> >
> > Just for the record, the migration to gcc-3.4.4 went just fine.. until 
> now
> > at least. :)
> 
> hum. Genlop looks at the past emerge times of the packages, calculates
> an average based on that.
> 
> The one thing genlop can't do is figure out how long it takes to merge
> new packages. So it just skips them. That is the only way I see genlop
> being wrong by so much. (The other possibility is that you were
> running the box with a high load WHILE compiling, though I guess you
> won't be complaining if that were the case.)


That was not the case. I started emerge system just before going to bed, so 
it had all cpu for itself (considering that the remaining apps, such as X, 
and others, were not very active).
I would say that most of the emerged packages were emerged before.. but 
maybe not that much so that genlop could be accurate. Also, a new compiler 
was being used.. no idea how much can that change the performance.

To be honest, I've found the genlop time quite reliable... I've
> rebuilt my systems with --emptytree a few times in the past 6 months.
> (Once after killing PAM and LDAP, once after changing to hardened,
> once after changing from ~x86 to x86, and once after a major rehaul of
> my USE flags; these are on my desktop machine only). The 500 or so
> packages came up to be 1 day and 15 hours from genlop. The actual
> compiles never took more than 2 days, and that was while the computer
> was still in use. Once it actually finished before the estimated time.
> 
> Do note that, however, genlop can only calculate its merge time based
> on past averages. So if you made major changes to your system, or if
> the codebase changed significantly upstream, genlop can be completely
> wrong. For example, looking at past emerges of glibc, I see the
> compile time goes from everything between 28 minutes to 3 hours.
> genlop tells me that if I were to remerge glibc it would take me 1
> hour and 9 minutes. But I know from experience if I were to install
> 2.3.5-r1, it will most likely only take me 40 minutes, and if I were
> to compile glibc-2.3.4.20050125-r1, it will take me about 2 hour and
> 10 minutes. Why the funky discrepancy I don't know. So I think that
> while genlop is generally rather reliable for a rough idea on how long
> I need to wait for the compile (i.e. is it worth it just sitting here
> reading a book or should I just go to bed), the numbers it give should
> be taken with a grain of salt if you don't have a large number of
> history of emerges for it to base its guesses on.
> 
> W
> 

Ok.. so I'll get better estimations the more times I update my system. 
Great!! That was in fact the first time I've used genlop. It's quite 
interesting to be able to predict how much something will take to emerge. 
For what you said, "is it worth it just sitting here reading a book or 
should I just go to bed", would it be possible to check an active emerge for 
the estimated time left? That would tell you what you should do... does 
genlop do that?

Cheers,
Fernando

[-- Attachment #2: Type: text/html, Size: 4130 bytes --]

Re: [gentoo-user] genlop times was: migrating to gcc-3.4.4

[Willie Wong]

On Thu, Aug 25, 2005 at 05:33:14PM +0000, Fernando Meira wrote:
> I would say that most of the emerged packages were emerged before.. but 
> maybe not that much so that genlop could be accurate. Also, a new compiler 
> was being used.. no idea how much can that change the performance.

That might. -shrug-

> Ok.. so I'll get better estimations the more times I update my system. 

Genlop actually just monitors /var/log/emerge.log
and the estimated times comes from, as I said, averaging the times
from past emerges. So you don't really need to have genlop installed
before hand or used it before for it to gather data. 

> Great!! That was in fact the first time I've used genlop. It's quite 
> interesting to be able to predict how much something will take to emerge. 

It's like weather prediction: you will be 80% correct if you guess the
weather tomorrow is the same as today. Same spirit with genlop.

> For what you said, "is it worth it just sitting here reading a book or 
> should I just go to bed", would it be possible to check an active emerge for 
> the estimated time left? That would tell you what you should do... does 
> genlop do that?

Technically, genlop -c should show the currently compiling package and
estimate time left. (And if it has been compiling longer than the
average time, it would say: Any Time Now.)

BUT!!! It seems that there is a bug with genlop and newer versions of
portage because some issues with a sandbox lockfile. Search for
"genlop sandbox" on bugs.gentoo.org for more info. In any case, for
the time being, until the bug is fixed, genlop -c will never detect an
active emerge. So that's too bad. 

Though... if you are talking about, for example, emerge world, then
genlop won't be able to tell you how long until EVERYTHING is done. It
can give you an estimate on how long it will be until the current
compiling package is done. 

W
-- 
"I assume you've all done stationary phase integrals...right?"
~DeathMech, S. Sondhi. P-town PHY 205
Sortir en Pantoufles: up 13 days, 21:48
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] genlop times was: migrating to gcc-3.4.4

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Thu, 25 Aug 2005 14:51:33 -0400, Willie Wong wrote:

> BUT!!! It seems that there is a bug with genlop and newer versions of
> portage because some issues with a sandbox lockfile. Search for
> "genlop sandbox" on bugs.gentoo.org for more info. In any case, for
> the time being, until the bug is fixed, genlop -c will never detect an
> active emerge. So that's too bad. 

That's been fixed. The latest release - 0.30.5 - works with the new
sandbox and genlop --current is back.


-- 
Neil Bothwick

I stayed up all night playing poker with tarot cards. I got a full
house and four people died.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] genlop times was: migrating to gcc-3.4.4

[Willie Wong]

On Thu, Aug 25, 2005 at 11:03:47PM +0100, Neil Bothwick wrote:
> On Thu, 25 Aug 2005 14:51:33 -0400, Willie Wong wrote:
> 
> > BUT!!! It seems that there is a bug with genlop and newer versions of
> > portage because some issues with a sandbox lockfile. Search for
> > "genlop sandbox" on bugs.gentoo.org for more info. In any case, for
> > the time being, until the bug is fixed, genlop -c will never detect an
> > active emerge. So that's too bad. 
> 
> That's been fixed. The latest release - 0.30.5 - works with the new
> sandbox and genlop --current is back.
> 
> 

Thanks! Now time to emerge sync...

W

-- 
This one's a bit....ummm...graphic?
"Lagrangian Mechanics with Differential Equations is like masturbating. You do 
what works and what makes you feel good."
~DeathMech, Some Student. P-town PHY 205
Sortir en Pantoufles: up 14 days,  2:15
-- 
gentoo-user@gentoo.org mailing list