[gentoo-ppc-user] Re: Errors emerge'ing xfree-4.3.0-r3 (on PPC)

[gentoo-ppc-user] Re: Errors emerge'ing xfree-4.3.0-r3 (on PPC)

[Eric Pretorious]

On 11 Jul 2003, Martin Schlemmer wrote:
> # emerge xfree &> xfree.log
> 
> Or just paste a bigger part of the failure - from what you pasted,
> we cannot see what exactly caused the problem ...

Martin:

The text that I included I entered by hand on a different machine. :^(

I'll re-run emerge tonight [using the syntax that you recommend] and send 
the results tomorrow.

Thank you!

-- 
Eric P.
Sunnyvale, CA


--
gentoo-ppc-user@gentoo.org mailing list

[gentoo-ppc-user] Re: Errors emerge'ing xfree-4.3.0-r3 (on PPC)

[Eric Pretorious]

On 11 Jul 2003, Martin Schlemmer wrote:

> On Thu, 2003-07-10 at 07:37, Eric Pretorious wrote:
> > On 10 Jul 2003, Martin Schlemmer wrote:
> > > You need to include a more complete log.
> > 
> > I didn't realize that ebuilds kept logs. Where can I find the log from 
> > this ebuild?
> 
> # emerge xfree &> xfree.log

Martin:

Rather than clog anyone's inbox, I've made the entire 2.1MB log-file 
available at...

  http://www.pretorious.net/~eric/xfree.log.txt

-- 
Eric P.
Sunnyvale, CA


--
gentoo-ppc-user@gentoo.org mailing list

[gentoo-ppc-user] Re: Errors emerge'ing xfree-4.3.0-r3 (on PPC)

[Calum Selkirk]

* Eric Pretorious [eric@pretorious.net] [2003-07-10 12:12 +0800]:

[snip]
> This occured just after make complained a few times about... 
> 
> collect2: ld returned 1 exit status
> make[3]: *** [XFree86] Error 1
> make[3]: Leaving directory /var/tmp/portage/xfree-4.3.0-sr3/work/xc/programs/Xserver
> make[2]: *** [install] Error 2
> make[2]: Leaving directory /var/tmp/portage/xfree-4.3.0-sr3/work/xc/programs
> make[1]: *** [install] Error 2
> make[1]: Leaving directory /var/tmp/portage/xfree-4.3.0-sr3/work/xc
> make: *** [install] Error 2
> 
> FWIW: /var/tmp/portage/xfree-4.3.0-r3/build-info/DEBUGBUILD is empty.
> 
> What happened? What do I need to do to get this to emerge on my system?
[snip]

The recent "stable" binutils did not have adequte testing before being
released (and such a core system component .. the mind boggles). You
should down grade to 2.13.19.0.18-r1 and inject the 2.14.90.0.2 version.
I have had numerious problems with 2.14.90.0.2, including failed builds
of the same version of xfree as above (three attempts in fact), i
eventually tracked it down to the recent binutils upgrade, downgrade and
xfree should build fine.

best

cal

--
gentoo-ppc-user@gentoo.org mailing list

Re: [gentoo-ppc-user] Re: Errors emerge'ing xfree-4.3.0-r3 (on PPC)

[Pieter Van den Abeele]

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

the mind boggles:

TiBook ~# emerge --pretend xfree binutils

These are the packages I would merge, in order:

Calculating dependencies ...done!
[ebuild   R  ] x11-base/xfree-4.3.0-r3
[ebuild   R  ] sys-devel/binutils-2.14.90.0.2 

TiBook ~# 

I'll remerge both and try to reproduce the error - azarah feel free to drop
me an email if you need something tested :-)

Pieter

----- Forwarded message from Calum Selkirk <cselkirk@xs4all.nl> -----

From: Calum Selkirk <cselkirk@xs4all.nl>
Date: Fri, 11 Jul 2003 19:23:42 +0200
To: Gentoo Linux <gentoo-ppc-user@gentoo.org>
Subject: [gentoo-ppc-user] Re: Errors emerge'ing xfree-4.3.0-r3 (on PPC)
Reply-To: Calum Selkirk <cselkirk@xs4all.nl>
User-Agent: Mutt/1.3.99i

* Eric Pretorious [eric@pretorious.net] [2003-07-10 12:12 +0800]:

[snip]
> This occured just after make complained a few times about... 
> 
> collect2: ld returned 1 exit status
> make[3]: *** [XFree86] Error 1
> make[3]: Leaving directory /var/tmp/portage/xfree-4.3.0-sr3/work/xc/programs/Xserver
> make[2]: *** [install] Error 2
> make[2]: Leaving directory /var/tmp/portage/xfree-4.3.0-sr3/work/xc/programs
> make[1]: *** [install] Error 2
> make[1]: Leaving directory /var/tmp/portage/xfree-4.3.0-sr3/work/xc
> make: *** [install] Error 2
> 
> FWIW: /var/tmp/portage/xfree-4.3.0-r3/build-info/DEBUGBUILD is empty.
> 
> What happened? What do I need to do to get this to emerge on my system?
[snip]

The recent "stable" binutils did not have adequte testing before being
released (and such a core system component .. the mind boggles). You
should down grade to 2.13.19.0.18-r1 and inject the 2.14.90.0.2 version.
I have had numerious problems with 2.14.90.0.2, including failed builds
of the same version of xfree as above (three attempts in fact), i
eventually tracked it down to the recent binutils upgrade, downgrade and
xfree should build fine.

best

cal

-- 
Pieter Van den Abeele
Gentoo Linux                            http://www.gentoo.org/~pvdabeel/

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF238673E
Key fingerprint = F29C C550 54CD 1196 6723  EDC3 9B0D 4EA7 F238 673E

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

[gentoo-ppc-user] Re: Errors emerge'ing xfree-4.3.0-r3 (on PPC)

[Calum Selkirk]

* Pieter Van den Abeele [pvdabeel@gentoo.org] [2003-07-11 19:55 +0200]:

> I'll remerge both and try to reproduce the error - azarah feel free to
> drop me an email if you need something tested :-)

It wasn't azarah but luca who marked this stable.

best

cal

--
gentoo-ppc-user@gentoo.org mailing list

[gentoo-ppc-user] Re: Errors emerge'ing xfree-4.3.0-r3 (on PPC)

[Pieter Van den Abeele]

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

On 11/07/03 20:40 +0200, Calum Selkirk wrote:
> * Pieter Van den Abeele [pvdabeel@gentoo.org] [2003-07-11 19:55 +0200]:
> 
> > I'll remerge both and try to reproduce the error - azarah feel free to
> > drop me an email if you need something tested :-)
> 
> It wasn't azarah but luca who marked this stable.

Indeed, also mentioned in the Changelog (I've read) and I can remember lu
asking me about this on irc.

As illustrated by my previous email, I've been using it for a while now,
without any problems. The ebuild was marked stable one month ago, I have
seen nil bugreports on it, except for this one, and we're on it - doing QA. 
xfree-r3 was last changed 3 days ago and is not marked stable on ppc. 
I don't see how lu could possibly have predicted one month ago that xfree-r3 was 
going to break using the binutils he was masking stable after a long time in
unstable without problems (even today - see my previous email).

Instead of pointing fingers, I'd prefer a bug report that gives us a chance
to look into this situation and in the end help the user out. 

Even if the bug is an upstream bug, we'll report it upstream, so don't
hesitate bombing us with this kind of feedback, but please no finger
pointing. <insert stuff about gentoo developers being unpaid volunteers here> 

Best regards,

Pieter

-- 
Pieter Van den Abeele
Gentoo Linux                            http://www.gentoo.org/~pvdabeel/

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF238673E
Key fingerprint = F29C C550 54CD 1196 6723  EDC3 9B0D 4EA7 F238 673E

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

[gentoo-ppc-user] Re: Errors emerge'ing xfree-4.3.0-r3 (on PPC)

[Calum Selkirk]

* Pieter Van den Abeele [pvdabeel@gentoo.org] [2003-07-11 21:44 +0200]:

> > > I'll remerge both and try to reproduce the error - azarah feel
> > > free to drop me an email if you need something tested :-)
> > 
> > It wasn't azarah but luca who marked this stable.
> 
> Indeed, also mentioned in the Changelog (I've read) and I can remember
> lu asking me about this on irc.
> 
> As illustrated by my previous email, I've been using it for a while
> now, without any problems. The ebuild was marked stable one month ago,
> I have seen nil bugreports on it, except for this one, and we're on it
> - doing QA.  xfree-r3 was last changed 3 days ago and is not marked
> stable on ppc.  I don't see how lu could possibly have predicted one
> month ago that xfree-r3 was going to break using the binutils he was
> masking stable after a long time in unstable without problems (even
> today - see my previous email).

That is why you build everything from bootstrap on release of a core
component like binutils. It's not a matter of 'predicting' but doing
adequate testing before releasing as stable. How many people would you
say tested binutils before it was considered stable? How many people
built their system from the ground up with this version?

To question your time line, both xfree-4.3.0-r2 and binutils-2.14.90.0.2
were marked stable (or at least last touched according to the
Changelogs) on 04 Jun and 08 Jun respectively. Where does "xfree-r3" even
come into this?

I, also, have been using it (i assume you mean binutils here) 'for a
while', and probably upgraded shortly after it was marked stable, but
didn't run into problems until doing an upgrade on a separate machine
(which happened to also be upgrading xfree).

Of course, it's easy for something to slip through the cracks, too easy.
But 'how could lu have possibly predicted' seems like a strange and
defensive response and/or question to ask, prediction is for soothsayers
and other occult fanciers, QA is based on thorough testing *before* it
is released on the world.

That said, I can't say for sure that binutils is at issue, which is
partly why I made no bug report, nor attempted to contact Franz Sirl
(ppc binutils and gcc maintainer). All i can say is that Tuesday of this
week I was attempting to upgrade an install on a research fellows' TiBook
(I work at a University). The machine in question hadn't been touched
administration wise for a little over two months and there were quite a
number of packages to upgrade.

The first package on the list, gnome-themes, died as it required xft,
I had removed the package as it conflicted with the upgrade of xfree and I
needed to merge world so I could leave the machine unattended. When i saw
gnome-themes had failed I decided to build, gcc, binutils and xfree
first (and so replace the xft supplied by xfree).

Returning a few hours later xfree had died spitting out the following error:

6ScanPci.c
In file included from xf86ScanPci.c:52:
xf86PciIds.h:27185: parse error before '}' token
xf86PciIds.h:47724: `pci_ss_list_10de_0068' undeclared here (not in a function)
xf86PciIds.h:47724: initializer element is not constant
xf86PciIds.h:47724: (near initialization for `pci_dev_info_10de_0068.Subsystem')
make[5]: *** [xf86ScanPci.o] Error 1

and on the second attempt ..

../../../lib/GL/dri/XF86dri.c:367: `XExtDisplayInfo' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c:367: `info' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c: In function `XF86DRICreateDrawable':
../../../lib/GL/dri/XF86dri.c:389: parse error before "drmDrawablePtr"
../../../lib/GL/dri/XF86dri.c:391: `XExtDisplayInfo' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c:391: `info' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c:410: invalid type argument of `unary *'
../../../lib/GL/dri/XF86dri.c: In function `XF86DRIDestroyDrawable':
../../../lib/GL/dri/XF86dri.c:422: `XExtDisplayInfo' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c:422: `info' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c: In function `XF86DRIGetDrawableInfo':
../../../lib/GL/dri/XF86dri.c:462: `XExtDisplayInfo' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c:462: `info' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c: In function `XF86DRIGetDeviceInfo':
../../../lib/GL/dri/XF86dri.c:544: parse error before "drmHandlePtr"
../../../lib/GL/dri/XF86dri.c:551: `XExtDisplayInfo' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c:551: `info' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c:570: invalid type argument of `unary *'
../../../lib/GL/dri/XF86dri.c:575: invalid type argument of `unary *'
../../../lib/GL/dri/XF86dri.c:576: invalid type argument of `unary *'
../../../lib/GL/dri/XF86dri.c:577: invalid type argument of `unary *'
../../../lib/GL/dri/XF86dri.c:578: invalid type argument of `unary *'
../../../lib/GL/dri/XF86dri.c:581: invalid type argument of `unary *'
../../../lib/GL/dri/XF86dri.c:588: invalid type argument of `unary *'
../../../lib/GL/dri/XF86dri.c:590: invalid type argument of `unary *'
../../../lib/GL/dri/XF86dri.c: In function `XF86DRIOpenFullScreen':
../../../lib/GL/dri/XF86dri.c:604: `XExtDisplayInfo' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c:604: `info' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c: In function `XF86DRICloseFullScreen':
../../../lib/GL/dri/XF86dri.c:632: `XExtDisplayInfo' undeclared (first use in this function)
../../../lib/GL/dri/XF86dri.c:632: `info' undeclared (first use in this function)

At this point I checked over the hardware, replaced the hardrive and
RAM, and dd'ed the old hardisk to the new (without error).

The third attempt at building xfree I wasn't able log as the
2.4.30-ppc-r3 crashed to MON and "x" (exit) didn't bring it back and
give me enough time to cut and paste the output, the kernel opps'd.
The errors were similar to the report made by Eric P.  .. ld errors. I
decided at this point that perhaps the upgrade of binutils was causing
the problem and so downgraded to 2.13.90.0.18. I then emerge'd xfree,
this time the build was successful (which is why I suggested Eric P. do
the same)

The the next package to die was control-center-1.4.0.5-r1, with the
error:

X11R6/include-O2 -pipe -mcpu=7450 -maltivec -mabi=altivec -mpowerpc-gfxopt -fsigned-char -Wall -Wunused  -c file-types-capplet-dialogs.c
file-types-capplet.c: In function `main':
file-types-capplet.c:184: warning: statement with no effect
file-types-capplet.c:185: warning: statement with no effect
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I. -I../.. -I. -I../../intl -I../../intl -I../../libgnomevfs -I./../../control-center -I/usr/include/gnome-1.0 -DNEED_GNOMESUPPORT_H -I/usr/lib/gnome-libs/include -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/orbit-1.0 -I/usr/include/gtk-1.2 -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/gdk-pixbuf-1.0 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -DGNOMELOCALEDIR=\""/usr/share/locale"\" -I/usr/include -I/usr/include/gnome-vfs-1.0 -I/usr/lib/gnome-vfs-1.0/include -I/usr/include/gnome-xml -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/orbit-1.0 -I/usr/include/gconf/1 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/orbit-1.0 -I/usr/include/gtk-1.2 -I/usr/X11R6/include -I/usr/include/glib-1.2 -I/usr/lib/glib/include -D_REENTRANT    -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include  -I/usr/include/gdk-pixbuf-1.0 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include-O2 -pipe -mcpu=7450 -maltivec -mabi=altivec -mpowerpc-gfxopt -fsigned-char -Wall -Wunused  -c file-types-icon-entry.c
file-types-capplet.c: In function `init_mime_capplet':
file-types-capplet.c:716: stray '\177' in program
file-types-capplet.c:716: `small' undeclared (first use in this function)
file-types-capplet.c:716: (Each undeclared identifier is reported only once
file-types-capplet.c:716: for each function it appears in.)
file-types-capplet.c:716: parse error before "table"
make[4]: *** [file-types-capplet.o] Error 1
make[4]: *** Waiting for unfinished jobs....

Based on the error I decided to merge using MAKEOPTS="-j1" and it built
and installed successfully.

Then the upgrade of qt-3.1.0-r3 died, this I had encountered before,
in fact i had made a bug report on June 15th see:

http://bugs.gentoo.org/show_bug.cgi?id=22860

emergeing ~ppc got me past this hurdle.

Next nautilus-2.2.4 failed with:

-lcrypto /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so -lpthread /usr/lib/libglib-2.0.so -lcdda_paranoia -lcdda_interface /usr/lib/libjpeg.so -lX11
nautilus-window-toolbars.o(.text+0x890): In function `create_back_or_forward_toolbar_item':
: undefined reference to `bonobo_ui_component_widget_set'
collect2: ld returned 1 exit status

At this point I was saved from having to go any further as I was
informed that the research fellow had arrived with his own laptop in
tow, and the machine went back under my desk.

> Instead of pointing fingers, I'd prefer a bug report that gives us a
> chance to look into this situation and in the end help the user out. 

Where was I pointing fingers? I had assumed, as you had asked a question
of azarah, that you had bcc'd it to him and I was simply pointing out
that luca had arch'ed the package, I had assumed this *knowing* azarah's
involvement with binutils.

> Even if the bug is an upstream bug, we'll report it upstream, so don't
> hesitate bombing us with this kind of feedback, but please no finger
> pointing. <insert stuff about gentoo developers being unpaid
> volunteers here> 

As far as a bug reporting goes, I certainly had little time that day to
make one. Here it is as requested. Again, no finger pointing involved.

If you plan contacting upstream developers I'd suggest contacting Franz
Sirl with any questions re binutils, you can normally find him on
#mklinux.

One more thing about QA. Working along the lines of "how could
<insert_developer> predict .." .. yes, how could anyone predict
that all of the above happened on a simple upgrade? You can't
.. but QA isn't based on prediction, it's way more simple than that ;)

What really constitutes "adequate" or "thorough" testing, and can this
be a guideline to "predicting" a package will be stable? Again,
unanswerable, but perhaps what we are looking for, and I mean the
proverbial we, is not what gets us there but *are* we getting there,
are our methods getting us stability (a second order cybernetic
methodology).

Now, perhaps there have been "nil bug reports" and that some, including
yourself, have "been using it for a while", but what does this tell you,
methodologically speaking? It might only tell you that users were failing
to fill out bug reports, that I am a special instance that passed the QA
procedure, that I am your only user, that others simply moved on to
using Yellow Dog or Debian when encountering this or other problems.
What does it really tell you?

I'm not attempting to knock you or other developers, nor pointing
fingers, but simply trying to show that QA is far from there. You might
remember my parting letter (from Gentoo) where I spoke of "an every
increasing semantic quagmire" when talking about the Gentoo namespace,
I happen to think we have a similar problem in terms of QA. QA is, imo,
something that is represented in the current state of the tree, it is
something that is suggested by the very word "stable" and not bug
fixing post stable.

I accept the fact that there will *always* be bugs that sneak by *any*
testing procedure, it is the nature of the complexity of software
itself, but QA is quite a different animal, again, it is represented in
the current state of the tree and in the methodologies used to label
that tree as stable. From the example shown above, there is nothing in
the present state of the ppc tree that would indicate that QA is in
place. I say that not to deride you, nor to diminish the work you, and
other developers, put in. It is, I hope, an unbiased appraisal, based on
one persons experience of upgrading.

best regards

cal

--
gentoo-ppc-user@gentoo.org mailing list

[gentoo-ppc-user] Re: Errors emerge'ing xfree-4.3.0-r3 (on PPC)

[Pieter Van den Abeele]

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

wow long email, really appreciate your reply.

On 12/07/03 13:21 +0200, Calum Selkirk wrote:
> > now, without any problems. The ebuild was marked stable one month ago,
> > I have seen nil bugreports on it, except for this one, and we're on it
> > - doing QA.  xfree-r3 was last changed 3 days ago and is not marked
> > stable on ppc.  I don't see how lu could possibly have predicted one
> > month ago that xfree-r3 was going to break using the binutils he was
> > masking stable after a long time in unstable without problems (even
> > today - see my previous email).
> 
> That is why you build everything from bootstrap on release of a core
> component like binutils. It's not a matter of 'predicting' but doing
> adequate testing before releasing as stable. How many people would you
> say tested binutils before it was considered stable? How many people
> built their system from the ground up with this version?

I cannot answer that question exactly. I run a ~ppc system build from
scratch myself, I rebuild about once every two weeks. I keep notes of every
rebuild and try to keep the docs up to date and the pile of bugreports small.

> To question your time line, both xfree-4.3.0-r2 and binutils-2.14.90.0.2
> were marked stable (or at least last touched according to the
> Changelogs) on 04 Jun and 08 Jun respectively. Where does "xfree-r3" even
> come into this?

This thread is about -r3, see subject; -r3 is currently unstable,
binutils-2.14 is now stable because 2.13 was upstream broken as indicated by lu_zero. 
2.14 might be broken upstream too, but as stated, that's upstream. and in
lu's opinion 2.14 was less broken than 2.13, I'm perfectly confortable with
that. 

> I, also, have been using it (i assume you mean binutils here) 

both -r3 and binutils-2.14

> 'for a while'

for quite a while on unstable

> and probably upgraded shortly after it was marked stable, but
> didn't run into problems until doing an upgrade on a separate machine
> (which happened to also be upgrading xfree).

I do several emerge --update world daily and rebuild every two weeks.

> Of course, it's easy for something to slip through the cracks, too easy.
> But 'how could lu have possibly predicted' seems like a strange and
> defensive response and/or question to ask, prediction is for soothsayers
> and other occult fanciers, QA is based on thorough testing *before* it
> is released on the world.

xfree-r2 was stable 
binutils-2.13 was stable
both worked fine together 

binutils-stable was upgraded to 2.14 because on unstable because it worked fine (no
problems whatsoever, especially not with xfree). Also, binutils-2.14 contains less
upstream bugs than 2.13.

a user running stable reports a problem with xfree-r3, you report that it is
because of binutils and make a statement about our QA being mind-boggling.

> That said, I can't say for sure that binutils is at issue, which is
> partly why I made no bug report, nor attempted to contact Franz Sirl
> (ppc binutils and gcc maintainer). 

...

> The first package on the list, gnome-themes, died as it required xft,
> I had removed the package as it conflicted with the upgrade of xfree and I
> needed to merge world so I could leave the machine unattended. When i saw
> gnome-themes had failed I decided to build, gcc, binutils and xfree
> first (and so replace the xft supplied by xfree).

I would have done:

emerge --unmerge xfree

followed by a 

emerge xfree 
emerge --update world

especially since you know that the problem was caused by removing xft.

Portage package manager development will be done by a team of developers now,
to ensure a higher quality.

> Returning a few hours later xfree had died spitting out the following error:

this is a compile (parse) error. maybe a bad patch or something? Is this on a
stable machine?

If so I would go for an emerge sync and a retry 

> and on the second attempt ..

link error. 

Were you emerging two things at the same time? Why should the parse error
have suddenly vanished? It could be that some x86 developer was experimenting
with an ebuild marked unstable on x86 but stable on ppc. Feel free to join
irc and ask out the xfree team.

> The third attempt at building xfree I wasn't able log as the
> 2.4.30-ppc-r3 crashed to MON and "x" (exit)

you probably mean 2.4.20-ppc-r2?

There was an upstream issue with the kernel: on reclaiming memory (easy
reproduceable when swap is disabled) the kernel oopsed. This bug also made it
onto the kde/gnome livecds. 2.4.21 and xfree-r3 solve that problem. 


> The the next package to die was control-center-1.4.0.5-r1, with the
> error:
> file-types-capplet.c:716: parse error before "table"

this is a parse error. Parse errors are reproduceable on all machines and
therefore code with parse errors shouldn't make it into stable. Does
your university have its own rsync mirror? I am starting to get a feeling
that your tarballs seem to be damaged. (why should \177 be in a C file?) 

> Based on the error I decided to merge using MAKEOPTS="-j1" and it built
> and installed successfully.

that could be it. control-center-1.4.0 is a very old ebuild. Not sure who was
doing QA (if any) at the time (20 Jan 2002). Keep in mind that at the time
most ppc devs were kde users

> Then the upgrade of qt-3.1.0-r3 died, this I had encountered before,
> in fact i had made a bug report on June 15th see:
> 
> http://bugs.gentoo.org/show_bug.cgi?id=22860

I'll ping darkspecter and see if he can close the bug, if not I'll do so on
the next bug closing day. 

> emergeing ~ppc got me past this hurdle.

I'll have a look at that bug - thxs for the feedback

> Next nautilus-2.2.4 failed with:
> 
> -lcrypto /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so -lpthread /usr/lib/libglib-2.0.so -lcdda_paranoia -lcdda_interface /usr/lib/libjpeg.so -lX11
> nautilus-window-toolbars.o(.text+0x890): In function `create_back_or_forward_toolbar_item':
> : undefined reference to `bonobo_ui_component_widget_set'
> collect2: ld returned 1 exit status

I think lu_zero went over most of the gnome bugs, and ensured gnome is
properly masked (at least on ~ppc). Please bear with us while we migrate to a
better stable profile.

> If you plan contacting upstream developers I'd suggest contacting Franz
> Sirl with any questions re binutils, you can normally find him on
> #mklinux.

thnxs

> One more thing about QA. Working along the lines of "how could
> <insert_developer> predict .." .. yes, how could anyone predict
> that all of the above happened on a simple upgrade? You can't
> .. but QA isn't based on prediction, it's way more simple than that ;)

> What really constitutes "adequate" or "thorough" testing, and can this
> be a guideline to "predicting" a package will be stable? Again,
> unanswerable, but perhaps what we are looking for, and I mean the
> proverbial we, is not what gets us there but *are* we getting there,
> are our methods getting us stability (a second order cybernetic
> methodology).
> 
> Now, perhaps there have been "nil bug reports" and that some, including
> yourself, have "been using it for a while", but what does this tell you,
> methodologically speaking? It might only tell you that users were failing
> to fill out bug reports, that I am a special instance that passed the QA
> procedure, that I am your only user, that others simply moved on to
> using Yellow Dog or Debian when encountering this or other problems.
> What does it really tell you?
> 
> I'm not attempting to knock you or other developers, nor pointing
> fingers, but simply trying to show that QA is far from there. You might
> remember my parting letter (from Gentoo) where I spoke of "an every
> increasing semantic quagmire" when talking about the Gentoo namespace,
> I happen to think we have a similar problem in terms of QA. QA is, imo,
> something that is represented in the current state of the tree, it is
> something that is suggested by the very word "stable" and not bug
> fixing post stable.
> 
> I accept the fact that there will *always* be bugs that sneak by *any*
> testing procedure, it is the nature of the complexity of software
> itself, but QA is quite a different animal, again, it is represented in
> the current state of the tree and in the methodologies used to label
> that tree as stable. From the example shown above, there is nothing in
> the present state of the ppc tree that would indicate that QA is in
> place. I say that not to deride you, nor to diminish the work you, and
> other developers, put in. It is, I hope, an unbiased appraisal, based on
> one persons experience of upgrading.

As current ppc team lead and ppc port founder, one of my tasks is to ensure quality of the portage
tree. This has proven to be a very difficult task right now. Gentoo-PPC is
about one year old, went from gcc2 to gcc3, has psychologically survived a
fork, developers/leads/co-leads came, left, rejoined, started a jihad, were missing in
action... Our unstable tree is right now more up to date than x86. We have ppc X-enabled 
livecds (altough still experimental). Gentoo itself is also growing exponentially: ppc, arm, 
hppa, sparc, amd64, G5, osx, bsd, hurd, darwin, cygwin, hardened, oldworld , server , desktop,
embedded, cluster, ...

One can have the best QA team in the world, as long as new ports/projects are going to
have to touch/patch ebuilds marked stable on other platforms, things might
break on stable on your platform. Yep, stuff shouldn't break, but it is a very
complex situation. We do have very strict guidelines and policies but time on developer side 
is limited, there are lots of bugs, lots of projects, few developers, upstream bugs,
experimental architectures, infrastructure moving/breaking... I'm not saying
these are good excuses for an stable tree that is not 100% in perfectly good
shape, but please bear with us. If something (or some dependency) breaks, well most of
the time somebody on irc that is able to help you out. And please, we're
still in beta for 1.4. That means we are (painfully) aware of these issues. Our ultimate
goal is to give the user an enourmeous amount of choice (different platforms,
architectures, the packages you want. And ultimately a flawless install, a
well-documented open source system that can be continuously upgraded (no need 
to reinstall) that offers the latest software on whatever platform you like,
allowing people to migrate to linux.

Best things about gentoo are still to come. There is research going on on the
package management area, we're migrating to industry grade infrastructure, we
are discussing stuff such as herds, QA, p2p, ebuild signing, gpg... Feel free
to participate in these discussions on the gentoo-ppc-dev or gentoo-dev lists. 
I'm 100% convinced that in time our stable tree will be rock solid. 

thnxs for feedback! 

Pieter

> best regards
> 
> cal
> 
> --
> gentoo-ppc-user@gentoo.org mailing list
> 

-- 
Pieter Van den Abeele
Gentoo Linux                            http://www.gentoo.org/~pvdabeel/

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF238673E
Key fingerprint = F29C C550 54CD 1196 6723  EDC3 9B0D 4EA7 F238 673E

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