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

[Calum Selkirk]

* Pieter Van den Abeele [pvdabeel@g.o] [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@g.o mailing list