[Cooker] Xfig bug report (2 problems)
I just built the xfig rpm from the .src.rpm on cooker. Compilation and installation went fine. To tickle the bug: After firing it up, go to `help' and bink on Xfig Reference (HTML) You should get an error dialog box that says /usr/share/doc/xfig/html/index.html is not installed, please install package xfig-doc # Problem 1 ## Problem is, there is no xfig-doc either in the SRPMS or RPMS for cooker. And none gets built. Ok, minor error (but confusing to a newbie). # Problem 2 ## rpm -ql xfig | fgrep index.html returns: /usr/X11R6/lib/X11/xfig/html/index.html /usr/X11R6/lib/X11/xfig/html/japanese/index.html So a patch or a configuration option needs to be put in xfig.spec to tell xfig where the (very excellent!!) HTML documentation is. This is one of the best documented tools in Linuxdom and it would be a shame for the newbie looking for a great 2D figure-drawing tool to miss it. Dean
Re: [Cooker] Bug in gcc-3.2.1 .src.rpm build
This is to report that with the cleanup of my "alternatives" stuff for libgcj the gcc-3.2.1 build went through just fine. Just for fun I did a rpm -e --nodeps $(cat files | sed 's/\.athlon.rpm//') where `files' contained the 21 .rpm names associated to gcc-3.2.1. I then did rpm -Uvh files and looked in /usr/include/libgcj-3.2.1/ and found the link libgcj-3.2.1 --> ../../usr/include/libgcj-3.2.1/ which, of course, is invalid (and bogus). This was _not_ there when I installed gcc-3.2.1 from the hand-intervened build from yesterday. I'm not sure where it came from but I went ahead, re-deleted all the rpms as above, hand deleted all the associated links in /etc/alternatives and /var/lib/rpm/alternatives (by looking at creation times) and deleted the directory /usr/include/libgcj-3.2.1/ with its bogus link file and re-installed the 21 rpms. All seems to be correct now. Don't quite understand where that funny link came from. Dean
Re: [Cooker] Bug in gcc-3.2.1 .src.rpm build
Austin Acton wrotes: :: The %post macro is executed *only* when you install the actual :: i586.rpm. It is not involved in the build process at all. :: Ok. Thanks. I didn't know this (which just shows how profoundly ignorant I really am!) :: > I know how to make sure there are no leftovers. And there are none. :: > Each build is clean. I have even deleted the the unpacked sources and :: > the spec file and done rpm -i on the .src.rpm a couple of times :: > "just in case". :: :: Then I was wrong, it's not leftover files causing the problem. :: :: However, considering that nobody else has this problem, and considering :: that it CAN'T have anything to do with the fact that it's a dual athlon, :: I can only conclude that you have a non-standard system, and the error :: is due to having a mix of 9.0 and cooker rpms on the same system. I agree. And with the cleanup of the "alternatives" links for libgcj-3.2 which I mentioned in my eariler private mail to you, I think this build is going to work. I just looked in the BUILD/gcc-3.2.1 dir and I neither see the bogus link nor the root/etc directory in: /usr/src/RPM/BUILD/gcc-3.2.1/obj-athlon-mandrake-linux-gnu/gcc/include But I'll wait to completion of the build before I say any more. It's currently do the compiler tests. But I _will_ say that all I did on this machine that was different than the laptop on which building always has worked was that I built and installed gcc-3.2-4mdk from cooker in late Nov/early Dec. I'm guessing that something in _that_ install screwed up the alternatives links for libgcj and led to my current problems. So the fact that nobody has seen it only means that very few have walked the exact path I did. Since I didn't even know about "alternatives" before two days ago, I doubt I am (directly) to blame :-) But who knows. Clearly the bug is not in the current package. Dean
Re: [Cooker] Bug in gcc-3.2.1 .src.rpm build
Austin, as I just wrote you in private mail, I'm trying another build because
I found some funnies in my "alternatives" system.
But I'll comment on your remarks below, nonetheless.
Austin Acton
:: On Tue, 2003-01-07 at 23:26, Dean S. Messing wrote:
:: > No it is getting created during the build. I discovered, also,
:: > that after the build bomb-out one finds in
:: > /var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.1/include/
:: > a `root/' directory in which there is both a usr/ subdir and an etc/
:: > subdir.
::
:: This is normal. This is the buildroot directory. It's where RPM gets
:: the files to put into the package.
I'm not sure you read the above carefully (or maybe I was not clear):
I know about the buildroot directory in /var/tmp (and the little shell
rpm.tmp. script in /var/tmp assocaiated to it.
My point was the existence of the root/etc directory in
/var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.1/include/
On the machine (my laptop) for which the build goes through, this directory
is _not_ present. Only root/usr.
:: > The lines I suspected of creating the alternative stuff
:: > were:
:: >
:: > %if %{build_java}
:: > %post -n libgcj%{libjava_major}-devel
:: > update-alternatives --install %{_includedir}/libgcj libgcj
:%{_includedir}/libgcj-%{version} %{gcj_alternative_priority}
:: > %endif
::
:: These lines are executed at install-time, not compile time.
I know. I probably was sloppy in my terminolgy if I said "compile" when
I should have said "build". I do realise the problem is occuring
during "installation" into the buildroot. That's how come I was
able to "fix" it.
:: > Didn't try, but I seriously doublt it because the .spec file
:: > contains the explicit `ln -s' commands that cause the failure.
::
:: ln -s is not causing the failure. The failure is caused by said
:: symbolic link already existing. Which is why Todd and I both had the
:: initial question: are you 100% sure your buildroot was empty?
ls -s "exposing" the failure. The existence of the link is "causing"
the failure. Sorry, again for my impreciseness.
:: > I did discover two differences between the system on which it
:: > builds and the one on which it does not.
:: > The working system had a stock Mdk 9.0 installation of gcc-3.2-1mdk.i586.rpm.
:: > The non-working system had a re-build of the cooker gcc-3.2 from
:: > around Nov 25th. built for an athlon-mp. (This was necessary to
:: > get MPlayer to compile).
::
:: Again leads me to believe that the symlink was leftover from that build.
Please trust me (you and I have both heard that before).
I know how to make sure there are no leftovers. And there are none.
Each build is clean. I have even deleted the the unpacked sources and
the spec file and done rpm -i on the .src.rpm a couple of times
"just in case".
:: > I did "solve" the problem by deleting the link and root/etc/ directories
:: > deep down in the /usr/src/RPM/BUILD/gcc-3.2.1 (again, sorry
:: > for not remembering exactly where)
::
:: You mean /var/tmp/gcc-3.2.1-buildroot/etc.
No I (think) I mean in the BUILD dir. After deleting
the root/etc/ and the bogus link in
/usr/src/RPM/BUILD/gcc-3.2.1/obj-athlon-mandrake-linux-gnu/gcc/include
I also deleted the buildroot in /var/tmp
as well as the rpm.tmp. file, and did
rpm --short-circuit -bi gcc.spec
and it rebuild the buildroot and generated the .rpm files
This was couple of days ago and so I hope I am not experiencing
a case of "I dreamed that I did it" :-)
:: > So when I find bugs is it OK to report them here as I did?
::
:: Yes. Although this wasn't technically a 'bug'.
Ok.
:: > Shall I assume they will get seen even if there's no ack?
::
:: They will get seen. But it's always possible that nobody will have time
:: to work on it.
::
:: > If someone instructs me on what, exactly, to do to trace this
:: > I'll do it. Problem is that now that I have installed the
:: > latest gcc the bug may vanish, if it had anything to do
:: > with the above machine differences.
::
:: Do this:
:: # rm -fr /var/tmp/*root
Have done this each time.
:: # rm -fr /usr/src/RPM/BUILD/*
As well as this.
:: # rm -fr /usr/src/RPM/tmp/*
/usr/src/RPM/tmp does not nor ever has existed on my system.
:: before you try to build anything, and you won't have any problems like
:: this.
I wish.
Dean
Re: [Cooker] Bug in gcc-3.2.1 .src.rpm build
Austin Acton writes: :: $ rpm -bb gcc.spec :: worked perfectly on my dual Athlon 1900 :: :: $ rpmbuild -bb --target=athlonxp gcc.spec :: failed to even get underway, but that's because I have no :: athlonxp-mandrake-linux-gnu target on my machine :: :: Are you 100% sure your rpm/BUILD and rpm/tmp directories were clean? Yes, absolutely sure. I hand cleaned /usr/src/RPM and /var/tmp before issuing rpm -i on the .src.rpm :: Austin To build athlon-mp centric .rpm's here is my /etc/rpmrc file: optflags: athlon -O3 -fomit-frame-pointer -pipe -march=athlon-mp -ffast-math -fno-strength-reduce buildarchtranslate: athlon: athlon buildarchtranslate: i686: athlon It turns out to be necessary to build the compiler (at least gcc-3.2-4) so that MPlyayer will properly compile. Otherwise you end up with compiler errors on the embedded assembler w/in MPlayer. I'm now starting the build I memtioned in the previous message. Will see what happens in the morning. Goodnight.
Re: [Cooker] Bug in gcc-3.2.1 .src.rpm build
Austin Acton wrote: :: Seems hard to believe that error. Yeah. I know. :: If you're just doing :: rpm -ba :: it won't make ANY difference what processor you're using. Unless there's some logic in the .spec file that detects processor and branches differently. The .spec file for MPlayer certainly does this. :: It will build :: for i586 (unless you have altered the .rpmrc file). In fact, from your :: post, it looks like you were building i586-mandrake-linux-gnu. (see below) :: So the :: error shouldn't be caused by building on an athlon. And if it works on :: you other system, it makes me think that your dual athlon has a dirty :: build environment or something. (see differences between the two systems in my "other message" dicussed below) :: However, I have a dual athlon and I will try to reproduce the problem :: right now. :: :: Austin Austin, be sure to read the (long, involved) message I just wrote to Todd L. on cooker about this. In fact (as I said in that message) the bug was originally tickled when I built for the athlon-mp (modifed /etc/rpmrc file) but I deleted that file on a second attempt to remove one variable and the build still bombed out. See that message for the two other differences between the "good" and the "bad" system. Now that I "fixed" the problem (see message on how) I will build again tonight to see if the build goes through. Problem is that I know nothing at all about "update-alternatives" which seems to be the fundamental cause of the problem. For some reason it is creating the error-causing link on one machine and not in the other. Dean, starting yet another build of gcc-3.2.1
Re: [Cooker] Bug in gcc-3.2.1 .src.rpm build
Sorry for the gory details below. I know no other way
to communicate exactly what I did, what I found, &c, so
someone can find the build bug (or my config bug).
Todd Lyons writes:
:: Dean S. Messing wrote on Mon, Jan 06, 2003 at 12:28:14PM -0800 :
:: >
:: > + ln -s /usr/include/libgcj-3.2.1
:/var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.1/include/libgcj
:: > ln:
:`/var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.1/include/libgcj':
: File exists
:: > error: Bad exit status from /var/tmp/rpm-tmp.71143 (%install)
:: > The problem is that there is already a file (link) in
:: > /var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/athlon-mandrake-linux-gnu/3.2.1/include/
:: > called `libgcj'. It points to `root/etc/alternatives/libgcj'
:: > so when the above link is attempted, it fails.
:: > Surely other athlon users have run across this? But I've not seen
:: > anything mentioned. I went over the cooker archives and see nothing.
::
:: Can you isolate
:: 1) Does the link already exist in some tarball (almost certaily no).
No it is getting created during the build. I discovered, also,
that after the build bomb-out one finds in
/var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.1/include/
a `root/' directory in which there is both a usr/ subdir and an etc/
subdir. In the etc/ subdir there's an empty alternatives/ subdir.
They are also present in the BUILD/gcc-3.2.1/blah-blah diretory in /usr/src/RPM
and are created during build. (Sorry I don't remember exactly the path.)
On my PIII laptop the link I mentioned in the
first message and the above subdirs don't exist
and hence the bomb-out never occurs.
:: 2) Does the link get made by some earlier invocation of
:: update-alternatives?
I don't understand update-alternatives at all except from what little
I read in the man page. In trying to trace the error I think I
found a possible source in the .spec file but I really don't
understand it enough to say for sure.
The lines I suspected of creating the alternative stuff
were:
%if %{build_java}
%post -n libgcj%{libjava_major}-devel
update-alternatives --install %{_includedir}/libgcj libgcj
%{_includedir}/libgcj-%{version} %{gcj_alternative_priority}
%endif
in the .spec file. But again I really don't understand what
"update-alternatives" does or why these lines would be triggered on one
machine and not other (but see differences between machines below).
:: 3) Can you ascertain exactly where it gets created?
No. I'm too ignorant of the process.
:: 4) Does it do the same thing if you do everything by hand?
Didn't try, but I seriously doublt it because the .spec file
contains the explicit `ln -s' commands that cause the failure.
And, as I said, I believe the offensive "alternatives" stuff is called
from the .spec file also.
I did discover two differences between the system on which it
builds and the one on which it does not.
The working system had a stock Mdk 9.0 installation of gcc-3.2-1mdk.i586.rpm.
The non-working system had a re-build of the cooker gcc-3.2 from
around Nov 25th. built for an athlon-mp. (This was necessary to
get MPlayer to compile).
It's rpm was gcc-3.2-4mdk.athlon.rpm
The second difference was that on the working system only
libgcj3-3.2-1mdk.i586.rpm
libgcj3-devel-3.2-1mdk.i586.rpm
were present.
On the non-working system
libgcj3-3.2-4mdk.athlon.rpm
libgcj3-devel-3.2-4mdk.athlon.rpm
libgcj3-static-devel-3.2-4mdk.athlon.rpm
were present.
I did "solve" the problem by deleting the link and root/etc/ directories
deep down in the /usr/src/RPM/BUILD/gcc-3.2.1 (again, sorry
for not remembering exactly where)
and then issuing
rpm --short-circuit -bi gcc.spec
It then correctly did the "install" in /var/tmp/gcc-3.2.1-root
and built .rpm's.
The astute reader will now be wondering why, when I reported
the error the messages refer to `i586-mandrake-linux-gnu'
whereas the above installed .rpm's have "athlon" in their name
(so that the messages should have had `athlon-mandrake-linux-gnu'
in them.
It is because when I first started to get the error, in order
to simplify things, I got rid of my /etc/rpmrc which builds
for athlon-mp. This did not get rid of the build bomb-out so
I reported errors relative to a vanilla i586 build (on my athlon) to
avoid someone saying "It must be your /etc/rpmrc file".
After I discovered how to make it work (with user intervention) I put
the /etc/rpmrc file back and re-built for athlon.
:: I'm really just replying to this to acknowledge your message. I know
:: that nothing I've written above is something you couldn't do on your own
:: (and probably already have), but I saw your "was this a faux pas"
:: message and just wanted to send the acknowledgement.
[Cooker] Is this the place to post cooker bugs?
I posted a (possible) cooker bug here yesterday. The bug appears in the build process for gcc-3.2.1 on my athlon machine. It's entitled: [Cooker] Bug in gcc-3.2.1 .src.rpm build and can be found here: http://www.mandrakelinux.com/en/archives/cooker/2003-01/msg00286.php I have seen no remarks, acknowledgement of receipt, questions, or statements to effect that I'm an idiotic doofus and the "bug" is all my fault. Is anyone listing? Did I commit some cooker social faux pax by posting bugs here? Dean P.S. In another message I also asked about why I can't digestify this list. My mbox is getting swamped with individual cooker message which I would dearly love to have in digest form but sympa tells me that "SET cooker DIGEST" is not an allowed commend for this list. Can anyone tell me why? Thanks.
[Cooker] why can't I digestify this list?
I just sent the magic command SET cooker DIGEST to <[EMAIL PROTECTED]> The reply was that cooker does not allow digestification. Why in the world not? Dean
[Cooker] Bug in gcc-3.2.1 .src.rpm build
There's either a bug in the build procedure or a misconfig. on my system. In any case I'd appreciate some help. I tried to build the gcc-3.2.1 rpm's from gcc-3.2.1-2mdk.src.rpm (using rpm -bb gcc.spec) and the build bombs out during installation into /var/tmp/gcc-3.2.1-root/ Here are the final lines of the build: + rmdir /var/tmp/gcc-3.2.1-root/usr/include/java + mkdir -p /var/tmp/gcc-3.2.1-root/usr/include/libgcj-3.2.1/javax + mv /var/tmp/gcc-3.2.1-root/usr/include/javax/naming +/var/tmp/gcc-3.2.1-root/usr/include/javax/transaction +/var/tmp/gcc-3.2.1-root/usr/include/libgcj-3.2.1/javax/ + rmdir /var/tmp/gcc-3.2.1-root/usr/include/javax + mkdir -p /var/tmp/gcc-3.2.1-root/usr/include/libgcj-3.2.1/org + mv /var/tmp/gcc-3.2.1-root/usr/include/org/w3c +/var/tmp/gcc-3.2.1-root/usr/include/org/xml +/var/tmp/gcc-3.2.1-root/usr/include/libgcj-3.2.1/org/ + rmdir /var/tmp/gcc-3.2.1-root/usr/include/org + mv +/var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.1/include/gcj/libgcj-config.h + /var/tmp/gcc-3.2.1-root/usr/include/libgcj-3.2.1/gcj/ + rmdir +/var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.1/include/gcj + ln -s /usr/include/libgcj-3.2.1 +/var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.1/include/libgcj ln: `/var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.1/include/libgcj': File exists error: Bad exit status from /var/tmp/rpm-tmp.71143 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.71143 (%install) The problem is that there is already a file (link) in /var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/athlon-mandrake-linux-gnu/3.2.1/include/ called `libgcj'. It points to `root/etc/alternatives/libgcj' so when the above link is attempted, it fails. Surely other athlon users have run across this? But I've not seen anything mentioned. I went over the cooker archives and see nothing. Incidently, the packages build just fine on my nearly identically configured i686 laptop. The only differences are this machine is an SMP Athon MP and that is a UP i686 PIII. My System Information: * Linux distribution: o Mdk 9.0 with come selected cooker additions * kernel version: Linux medulla 2.4.19-16mdksmp #1 SMP Wed Sep 24 12:26:01 EDT 2003 i686 unknown unknown GNU/Linux * libc version: /lib/libc-2.2.5.so * X version: XFree86 Version 4.2.1 * gcc and ld versions: gcc -v: Reading specs from /usr/lib/gcc-lib/athlon-mandrake-linux-gnu/3.2/specs gcc version 3.2 (Mandrake Linux 9.0 3.2-4mdk) ld -v: GNU ld version 2.12.90.0.15 20020717 * binutils version: GNU assembler 2.12.90.0.15 20020717 * CPU info (this works on Linux only): processor : 0 vendor_id : AuthenticAMD cpu family: 6 model : 6 model name: AMD Athlon(tm) MP 1500+ stepping : 2 cpu MHz : 1333.410 cache size: 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp: yes flags : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips : 2660.76 processor: 1 same thing as processor 0. Dean S. Messing Display Algorithms & Visual Optimization Lab Information Systems Technologies Dept. Sharp Laboratories of America
