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.
Wednesday, February 3, 2010
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
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
Wednesday, January 27, 2010
Progress Report (Viewsource)
From my last post many of you might remember that the web application of viewsource was only displaying the python script code rather than executing it, this issue has been resolved.
CHANGES
httpd.conf
--------------------------------------------------------------------------------------
--- httpd1.conf 2010-01-25 23:07:00.000000000 -0500
+++ httpd.conf 2010-01-21 19:06:51.000000000 -0500
@@ -193,6 +193,8 @@
LoadModule cache_module modules/mod_cache.so
LoadModule suexec_module modules/mod_suexec.so
LoadModule disk_cache_module modules/mod_disk_cache.so
+#LoadModule file_cache_module modules/mod_file_cache.so (Had to comment out, errors)
+#LoadModule mem_cache_module modules/mod_mem_cache.so (errors, commented out)
LoadModule cgi_module modules/mod_cgi.so
#
@@ -314,7 +316,7 @@
# http://httpd.apache.org/docs/2.2/mod/core.html#options
# for more information.
#
- Options Indexes FollowSymLinks
+ Options Indexes FollowSymLinks ExecCGI
#
# AllowOverride controls what directives may be placed in .htaccess files.
@@ -558,7 +560,7 @@
# The same rules about trailing "/" apply to ScriptAlias directives as to
# Alias.
#
-ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
+#ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
#
# "/var/www/cgi-bin" should be changed to whatever your ScriptAliased
@@ -755,8 +757,8 @@
# Despite the name similarity, the following Add* directives have nothing
# to do with the FancyIndexing customization directives above.
#
-#AddEncoding x-compress .Z
-#AddEncoding x-gzip .gz .tgz
+AddEncoding x-compress .Z
+AddEncoding x-gzip .gz .tgz
# If the AddEncoding directives above are commented-out, then you
# probably should define those extensions to indicate media types:
@@ -778,7 +780,7 @@
# To use CGI scripts outside of ScriptAliased directories:
# (You will also need to add "ExecCGI" to the "Options" directive.)
#
-#AddHandler cgi-script .cgi
+AddHandler cgi-script .cgi (probably the issue, however viewsource.conf should have handled this and it wasn't)
#
# For files that include their own HTTP headers:
@@ -992,3 +994,24 @@
# ErrorLog logs/dummy-host.example.com-error_log
# CustomLog logs/dummy-host.example.com-access_log common
#
+
+# David Humphrey - enable gzip compression
+
+ AddOutputFilterByType DEFLATE text/plain
+ AddOutputFilterByType DEFLATE text/html
+ AddOutputFilterByType DEFLATE text/xml
+ AddOutputFilterByType DEFLATE text/css
+ AddOutputFilterByType DEFLATE application/xml
+ AddOutputFilterByType DEFLATE application/xhtml+xml
+ AddOutputFilterByType DEFLATE application/rss+xml
+ AddOutputFilterByType DEFLATE application/javascript
+ AddOutputFilterByType DEFLATE application/x-javascript
+
+ DeflateCompressionLevel 9
+
+ DeflateFilterNote Input instream
+ DeflateFilterNote Output outstream
+ DeflateFilterNote Ratio ratio
+
+ LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
+
--------------------------------------------------------------------------------
If anyone knows if I can simply add this stuff to viewsource.conf so that I don't have to deal with making a patch for httpd.conf and deal with permission it would be greatly appreciated.
CHANGES 2
Viewsource.conf
Addhandler cgi-script .cgi .py .pyc .pyo (bold added)
ISSUES LEFT
Web application only displays errors when "setenforce 0" if "setenforce 1" then a pop up comes up saying error but does not describe the error. I need to figure out how to fix the permissions within my spec file so that it will work while in "setenforce 1" mode. Any suggestions would be greatly appreciated.
Stay tuned for the soon to come release...
CHANGES
httpd.conf
--------------------------------------------------------------------------------------
--- httpd1.conf 2010-01-25 23:07:00.000000000 -0500
+++ httpd.conf 2010-01-21 19:06:51.000000000 -0500
@@ -193,6 +193,8 @@
LoadModule cache_module modules/mod_cache.so
LoadModule suexec_module modules/mod_suexec.so
LoadModule disk_cache_module modules/mod_disk_cache.so
+#LoadModule file_cache_module modules/mod_file_cache.so (Had to comment out, errors)
+#LoadModule mem_cache_module modules/mod_mem_cache.so (errors, commented out)
LoadModule cgi_module modules/mod_cgi.so
#
@@ -314,7 +316,7 @@
# http://httpd.apache.org/docs/2.2/mod/core.html#options
# for more information.
#
- Options Indexes FollowSymLinks
+ Options Indexes FollowSymLinks ExecCGI
#
# AllowOverride controls what directives may be placed in .htaccess files.
@@ -558,7 +560,7 @@
# The same rules about trailing "/" apply to ScriptAlias directives as to
# Alias.
#
-ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
+#ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
#
# "/var/www/cgi-bin" should be changed to whatever your ScriptAliased
@@ -755,8 +757,8 @@
# Despite the name similarity, the following Add* directives have nothing
# to do with the FancyIndexing customization directives above.
#
-#AddEncoding x-compress .Z
-#AddEncoding x-gzip .gz .tgz
+AddEncoding x-compress .Z
+AddEncoding x-gzip .gz .tgz
# If the AddEncoding directives above are commented-out, then you
# probably should define those extensions to indicate media types:
@@ -778,7 +780,7 @@
# To use CGI scripts outside of ScriptAliased directories:
# (You will also need to add "ExecCGI" to the "Options" directive.)
#
-#AddHandler cgi-script .cgi
+AddHandler cgi-script .cgi (probably the issue, however viewsource.conf should have handled this and it wasn't)
#
# For files that include their own HTTP headers:
@@ -992,3 +994,24 @@
# ErrorLog logs/dummy-host.example.com-error_log
# CustomLog logs/dummy-host.example.com-access_log common
#
+
+# David Humphrey - enable gzip compression
+
+ AddOutputFilterByType DEFLATE text/plain
+ AddOutputFilterByType DEFLATE text/html
+ AddOutputFilterByType DEFLATE text/xml
+ AddOutputFilterByType DEFLATE text/css
+ AddOutputFilterByType DEFLATE application/xml
+ AddOutputFilterByType DEFLATE application/xhtml+xml
+ AddOutputFilterByType DEFLATE application/rss+xml
+ AddOutputFilterByType DEFLATE application/javascript
+ AddOutputFilterByType DEFLATE application/x-javascript
+
+ DeflateCompressionLevel 9
+
+ DeflateFilterNote Input instream
+ DeflateFilterNote Output outstream
+ DeflateFilterNote Ratio ratio
+
+ LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
+
--------------------------------------------------------------------------------
If anyone knows if I can simply add this stuff to viewsource.conf so that I don't have to deal with making a patch for httpd.conf and deal with permission it would be greatly appreciated.
CHANGES 2
Viewsource.conf
Addhandler cgi-script .cgi .py .pyc .pyo (bold added)
ISSUES LEFT
Web application only displays errors when "setenforce 0" if "setenforce 1" then a pop up comes up saying error but does not describe the error. I need to figure out how to fix the permissions within my spec file so that it will work while in "setenforce 1" mode. Any suggestions would be greatly appreciated.
Stay tuned for the soon to come release...
Friday, January 22, 2010
Release Plan
As some of you might remember I was working on packaging viewsource last semester and ran into some issues with the web application only pulling up the python script when the buttons were pushed instead of executing the script.
This semester in SBR700 I am working on it again and here is my rough plan for the semester.
Week 1- 3 - Working on resolving issues with viewsource python script displaying code instead of executing it (not as quick of a fix as many of you are probably thinking). By the end of week three I should have the issue resolved.
Week 4 + 5 - Cleaning up my spec file
Week 6 - Reviewing the guidelines for releasing and packaging in fedora and cleaning/modifying my packaging likewise
week 7+ - To be discussed.
This semester in SBR700 I am working on it again and here is my rough plan for the semester.
Week 1- 3 - Working on resolving issues with viewsource python script displaying code instead of executing it (not as quick of a fix as many of you are probably thinking). By the end of week three I should have the issue resolved.
Week 4 + 5 - Cleaning up my spec file
Week 6 - Reviewing the guidelines for releasing and packaging in fedora and cleaning/modifying my packaging likewise
week 7+ - To be discussed.
Subscribe to:
Posts (Atom)