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...

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

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 in ExcludeArch MUST 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 corresponding ExcludeArch line. (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 as BuildRequires is 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

Below are a list of all the things that SHOULD be looked at or included but are not required.

• 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.

This is everything I could find while looking at the DXR-Release spec file, now onto actually auditing it.

Viewsource New Release!

Hello fellow community!

Well if you have been following my blogs you probably know that I was working on fixing some issues with Viewsource.

Well, the good news is I found out what the problem was!
The bad news is you might have to fix it yourself, haha. (I will explain in a bit)

Firstly, I had to change my viewsource.conf up a bit so that it looked like this:


Addhandler cgi-script .cgi .py .pyc .pyo
Options Indexes FollowSymLinks ExecCGI


That is to give the viewsource directory handlers for cgi and python and give it the Execute cgi option. I tested this out on a fedora 12 machine (india) and it worked, even with SeLinux. I thought it would probably work on the HongKong machine which I believe still has fedora 11 on it, sadly it did not.

I then had to turn on AVC denial messages because they were currently being suppressed due to saving space, I did this with the command: "semodule -DB"

I then issued the command: "ausearch -m avc -ts recent" to view the recent messages so I didn't waste time searching for them. To be honest, looking at AVC denial messages is like looking at the matrix, NO idea what it meant until I talked to Chris Tyler who helped me out a little.
After frustrating myself, I eventually found out that the boolean "httpd_enable_cgi" had to be turned on (which it was in india), and since this is not my personal machine I left it alone. Which is what I was talking about before when I mentioned you might have to fix it for yourself, if you have errors simply use the command: "setsebool -P httpd_enable_cgi on" and you are set. I also placed a README in my package for this.

I put a DXRDROP directory in my home so that my good friend Alex Vlahopoulos, who is in charge of the repo, to come and pick it up when he is ready for it.

I suppose I should probably suppress the AVC messages again so I don't cause hongkong to eat up too much memory : semodule -B.

Now, assuming there are no more issues with the package, (which we will find out soon when dehydra and jshydra are ready), I just have to clean up my spec file to comply with fedora regulations and I will be set!

Until next time, friends! :P