I got Boris to make me an account on the cdot machine known as ireland and I downloaded the gcc trunk using the command: "svn co http://gcc.gnu.org/svn/gcc/trunk" which downloaded it to my home directory.
I then ran "./configure --prefix=/home/jddeni/gcc/dist --disable-multilib" to disable multi-library support and let that finish. I then ran make and it went for an hour or so after coming to an end and there seems to be no errors.
I will not run make install unless its on a vm because I am just too paranoid I will ruin something lol so we will set up a vm and then run make install and see if that works, then onto the spec file.
To be continued...
Tuesday, April 6, 2010
Progress report
Me and Boris have been working on gcc (Boris moreso over the past week due to intense workload)
the errors we were getting were related to bootstrap so we found a command to disable the bootstrap upon build "--disable-bootstrap" this did get us a little further in the build process however it ultimately ended up in failure.
Boris spoke to someone on IRC, ehren (who has actually been pretty helpful, even now he is aiding us), and he mentioned to try the configure/make process of the tarball on ireland. Upon first run we kept getting the same errors as before, however we then tried building with the "--disable-multilib" option (which is where it was failing before you are keeping up with my blogs) and it is still running with no errors as of yet (it has been going for 1 hour).
If (and this is a very good chance) the build is successful we will then start our spec file from scratch.
to be continued.....
the errors we were getting were related to bootstrap so we found a command to disable the bootstrap upon build "--disable-bootstrap" this did get us a little further in the build process however it ultimately ended up in failure.
Boris spoke to someone on IRC, ehren (who has actually been pretty helpful, even now he is aiding us), and he mentioned to try the configure/make process of the tarball on ireland. Upon first run we kept getting the same errors as before, however we then tried building with the "--disable-multilib" option (which is where it was failing before you are keeping up with my blogs) and it is still running with no errors as of yet (it has been going for 1 hour).
If (and this is a very good chance) the build is successful we will then start our spec file from scratch.
to be continued.....
Tuesday, March 30, 2010
gcc progress
Heh, funny title because that's exactly what we aren't having...progress lol.
Well recently me and Boris had a good scare when we tried building gcc on the cdot machine known as india and it was completely skipping all the steps and finishing the "build" in literally seconds. We thought that we completely messed something up in our spec files but I think it had to do with all the cdot machines being powered down last weekend.
Today, or rather yesterday, we tried building again and it worked....well the process was working, we still ran into the same errors as before. This is the error.
We decided to see if anyone in the fedora-devel channel knew anything about the error, only one person responded and he didn't have any idea. He, however, suggested that we try running rpmbuild on the spec file we got out of the gcc tarball just to see if its our system that is giving us the grief and not the spec file. Turns out it was a bit of both because although it did get further in the build process, it failed in the install process.
We tried asking about our problem in the gcc channel but either they were all busy or they just didn't like our question, whatever the case may be we are still progress-less lol.
We have a few options now, we could get in touch with a gcc developer and see what their package list is, to see what the difference is between our system and their system, and we can also ask about the spec file, basically get as much info out of them as possible.
Boris also suggested that we build the spec file from scratch, I can tell you all thats going to be a tough road but I guess since I am already along for the ride I might as well tackle it with him.
Well, thats all for now, until next time!
Well recently me and Boris had a good scare when we tried building gcc on the cdot machine known as india and it was completely skipping all the steps and finishing the "build" in literally seconds. We thought that we completely messed something up in our spec files but I think it had to do with all the cdot machines being powered down last weekend.
Today, or rather yesterday, we tried building again and it worked....well the process was working, we still ran into the same errors as before. This is the error.
We decided to see if anyone in the fedora-devel channel knew anything about the error, only one person responded and he didn't have any idea. He, however, suggested that we try running rpmbuild on the spec file we got out of the gcc tarball just to see if its our system that is giving us the grief and not the spec file. Turns out it was a bit of both because although it did get further in the build process, it failed in the install process.
We tried asking about our problem in the gcc channel but either they were all busy or they just didn't like our question, whatever the case may be we are still progress-less lol.
We have a few options now, we could get in touch with a gcc developer and see what their package list is, to see what the difference is between our system and their system, and we can also ask about the spec file, basically get as much info out of them as possible.
Boris also suggested that we build the spec file from scratch, I can tell you all thats going to be a tough road but I guess since I am already along for the ride I might as well tackle it with him.
Well, thats all for now, until next time!
Tuesday, March 2, 2010
GCC progress
Continuing from my last blog post I fixed the error I was having by naming the directory gcc4.5 instead of gcc-4.5. After that I ran rpmbuild -ba gcc.spec and it was giving me hunk errors due to the patches so I decided to take all the patches out.
After the patches were completely gone the build ran longer and did its whole "matrix" compiling thing. I ran into errors that said gcc needs certain packages to build, gmp, mpfr, and mpc.
Building gcc requires
GMP 4.2+ - version on comp -> 4.3.1-5 (buggy but acceptable)
MPFR 2.3.1+ - version on comp -> 2.4.1-5 (buggy but acceptable)
MPC 0.8.0+ - needed updating -> 0:0.16-2
As you can see mpc needed updating so I decided to yum install mpc which seemed to download an updated version of mpc but the compile was still failing there. I had to manually download mpc from the ftp site, after that I had to extract the file and run ./configure, make, and make install on it. Make install would not run without admin privileges so I had to be root for that.
After that was installed I ran rpmbuild again and it compiled for about what seemed like half an hour until getting to an error "make: *** [profiledbootstrap] Error 2". I looked online and a lot of people seemed to get this error while building gcc and they said that disabling ccache would fix it.
Everywhere I looked online it seemed that the way to do that was to add "%configure --disable-ccache" inside the %build section but that still did not work. As of right now I am stumped, as soon as my friend Boris, who is working on this project with me, wakes up he will have a look.
Until next time, ciao.
After the patches were completely gone the build ran longer and did its whole "matrix" compiling thing. I ran into errors that said gcc needs certain packages to build, gmp, mpfr, and mpc.
Building gcc requires
GMP 4.2+ - version on comp -> 4.3.1-5 (buggy but acceptable)
MPFR 2.3.1+ - version on comp -> 2.4.1-5 (buggy but acceptable)
MPC 0.8.0+ - needed updating -> 0:0.16-2
As you can see mpc needed updating so I decided to yum install mpc which seemed to download an updated version of mpc but the compile was still failing there. I had to manually download mpc from the ftp site, after that I had to extract the file and run ./configure, make, and make install on it. Make install would not run without admin privileges so I had to be root for that.
After that was installed I ran rpmbuild again and it compiled for about what seemed like half an hour until getting to an error "make: *** [profiledbootstrap] Error 2". I looked online and a lot of people seemed to get this error while building gcc and they said that disabling ccache would fix it.
Everywhere I looked online it seemed that the way to do that was to add "%configure --disable-ccache" inside the %build section but that still did not work. As of right now I am stumped, as soon as my friend Boris, who is working on this project with me, wakes up he will have a look.
Until next time, ciao.
Wednesday, February 24, 2010
Viewsource to GCC
Well friends, since pretty much my viewsource is done and I really have nothing to do I have moved on to helping Boris Chao with building gcc 4.5 which is in pre-release stages right now.
I downloaded it to my file on the Germany cdot machine and compressed it into a .tgz file and placed that into my SOURCES directory. I then found a older gcc 4.4 src.rpm and used that to get the gcc4.4 spec file as a file to work from.
When attempting to build it had certain build dependencies that werent available in the repo that was configured on germany therefore I had to move my files over to the Hongkong machine which was updated to fedora 12 and therefore was linked to more updated repos. After getting all the dependencies taken care of I used rpmlint on the spec file, there was only one error which had to do with $RPM_BUILD_ROOT.
Error: use-of-RPM_SOURCE_DIR
Explanation: You use $RPM_SOURCE_DIR or %{_sourcedir} in your spec file. If you have to use a directory for building, use $RPM_BUILD_ROOT instead.
Correction: Changed $RPM_SOURCE_DIR to $RPM_BUILD_ROOT
I started to build and I was getting another error talking about a certain file or directory not existing, me and Boris are working on it now.
To be continued...
I downloaded it to my file on the Germany cdot machine and compressed it into a .tgz file and placed that into my SOURCES directory. I then found a older gcc 4.4 src.rpm and used that to get the gcc4.4 spec file as a file to work from.
When attempting to build it had certain build dependencies that werent available in the repo that was configured on germany therefore I had to move my files over to the Hongkong machine which was updated to fedora 12 and therefore was linked to more updated repos. After getting all the dependencies taken care of I used rpmlint on the spec file, there was only one error which had to do with $RPM_BUILD_ROOT.
Error: use-of-RPM_SOURCE_DIR
Explanation: You use $RPM_SOURCE_DIR or %{_sourcedir} in your spec file. If you have to use a directory for building, use $RPM_BUILD_ROOT instead.
Correction: Changed $RPM_SOURCE_DIR to $RPM_BUILD_ROOT
I started to build and I was getting another error talking about a certain file or directory not existing, me and Boris are working on it now.
To be continued...
Sunday, February 14, 2010
Auditing Repo Master's Files
In my previous post I pointed out all the things that needed to be looked at, here I will post the results of fixing these issues.
-------------------------------------------
MUST: rpmlint must be run on every package. The output should be posted in the review
[root@scotland SPECS]# rpmlint DXR-release.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
The spec file seems to be okay in terms of rpmlint.
[root@scotland SRPMS]# rpmlint DXR-release-1-1.1.src.rpm
DXR-release.src: W: summary-not-capitalized repository files
DXR-release.src: E: description-line-too-long repository contains open source and other distributable software for Fedora. This package contains
1 packages and 0 specfiles checked; 1 errors, 1 warnings.
ERROR
[root@scotland SPECS]# rpmlint -I description-line-too-long
description-line-too-long:
Your description lines must not exceed 79 characters. If a line is exceeding
this number, cut it to fit in two lines.
Before: repository contains open source and other distributable software for Fedora. This package contains the repository GPG key as well as configuration for Yum.
After: repository contains open source and other distributable software for Fedora.
This package contains the repository GPG key as well as configuration for Yum.
WARNING
[root@scotland SRPMS]# rpmlint -I summary-not-capitalized
summary-not-capitalized:
Summary doesn't begin with a capital letter.
This is not a big issue, however I still changed it within the DXR-Release.spec
Before: Summary: repository files
After: Summary: Repository files
---------------------------------------
MUST: The License field in the package spec file must match the actual license.
In order to fix this I simply had to change the license from BSD to GPLv2 which is what it should be.
Before: License: BSD
After: License: GPLv2
---------------------------------------
To be continued
-------------------------------------------
MUST: rpmlint must be run on every package. The output should be posted in the review
[root@scotland SPECS]# rpmlint DXR-release.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
The spec file seems to be okay in terms of rpmlint.
[root@scotland SRPMS]# rpmlint DXR-release-1-1.1.src.rpm
DXR-release.src: W: summary-not-capitalized repository files
DXR-release.src: E: description-line-too-long repository contains open source and other distributable software for Fedora. This package contains
1 packages and 0 specfiles checked; 1 errors, 1 warnings.
ERROR
[root@scotland SPECS]# rpmlint -I description-line-too-long
description-line-too-long:
Your description lines must not exceed 79 characters. If a line is exceeding
this number, cut it to fit in two lines.
Before: repository contains open source and other distributable software for Fedora. This package contains the repository GPG key as well as configuration for Yum.
After: repository contains open source and other distributable software for Fedora.
This package contains the repository GPG key as well as configuration for Yum.
WARNING
[root@scotland SRPMS]# rpmlint -I summary-not-capitalized
summary-not-capitalized:
Summary doesn't begin with a capital letter.
This is not a big issue, however I still changed it within the DXR-Release.spec
Before: Summary: repository files
After: Summary: Repository files
---------------------------------------
MUST: The License field in the package spec file must match the actual license.
In order to fix this I simply had to change the license from BSD to GPLv2 which is what it should be.
Before: License: BSD
After: License: GPLv2
---------------------------------------
To be continued
DXR Spec File Review
Upon reviewing the DXR release package spec file made by Alexandros Vlahopoulos and comparing it to the Fedora Packaging Review Guidelines the following are a list of guidelines that have yet to be met or need to be looked at.
- MUST: rpmlint must be run on every package. The output should be posted in the review
- MUST: The package must meet the Packaging Guidelines .
- MUST: The License field in the package spec file must match the actual license. (Change BSD to GPLv2)
- MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in
ExcludeArch. Each architecture listed inExcludeArchMUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the correspondingExcludeArchline. (Find out if theres an architecture it doesnt work on) - MUST: All build dependencies must be listed in
BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those asBuildRequiresis optional. Apply common sense. (Was there any dependencies?) - MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.(wasnt sure about this one)
- MUST: Each package must consistently use macros. ($RPM_BUILD_ROOT, should probably be changed to %{buildroot})
- MUST: The package must contain code, or permissable content.
- MUST: All filenames in rpm packages must be valid UTF-8
- SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
- SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
- SHOULD: The reviewer should test that the package builds in mock.
- SHOULD: The package should compile and build into binary rpms on all supported architectures.
- SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.
- SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. (once again, if there are any dependencies)
- SHOULD: your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense.
Subscribe to:
Posts (Atom)