[Bug 470696] New: Review Request: rubygem-passenger - Passenger Ruby on Rails deployment system
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: Review Request: rubygem-passenger - Passenger Ruby on Rails deployment system
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Summary: Review Request: rubygem-passenger - Passenger Ruby on Rails deployment system Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Package Review AssignedTo: nobody@fedoraproject.org ReportedBy: kanarip@kanarip.com QAContact: extras-qa@fedoraproject.org CC: notting@redhat.com, fedora-package-review@redhat.com Estimated Hours: 0.0 Classification: Fedora
Spec URL: http://www.kanarip.com/custom/SPECS/rubygem-passenger.spec SRPM URL: http://www.kanarip.com/custom/f9/SRPMS/rubygem-passenger-2.0.3-1.fc9.src.rpm Description: Phusion Passenger is a deployment system for Ruby on Rails applications on Apache, i.e. a 'mod_rails'. Rails deployment becomes an "upload & done" process.
rpmlint output:
[jmeeuwen@ghandalf packages]$ rpmlint ~/rpmbuild/RPMS/x86_64/rubygem-passenger-* ~/rpmbuild/RPMS/x86_64/mod_passenger-2.0.3-1.fc9.x86_64.rpm rubygem-passenger.x86_64: W: devel-file-in-non-devel-package /usr/bin/passenger-config rubygem-passenger-devel.x86_64: W: no-documentation rubygem-passenger-doc.x86_64: W: no-documentation mod_passenger.x86_64: W: no-documentation
koji scratch builds fail atm. because of a required rubygem-fastthread update/upgrade (built and pushed already) and a missing required package rubygem-rack (See #470694)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Jeroen van Meeuwen kanarip@kanarip.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |470694
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|nobody@fedoraproject.org |mtasaka@ioa.s.u-tokyo.ac.jp Flag| |fedora-review?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #1 from Jeroen van Meeuwen kanarip@kanarip.com 2008-11-09 08:25:12 EDT --- Updated the SPEC and SRPM for better placement of the mod_passenger.so file (in %{_libdir}/httpd/modules instead of %{ruby_sitearch}/apache2/mod_passenger.so) so that the configuration file %{_sysconfdir}/httpd/conf.d/mod_passenger.so can actually load it independent of the architecture.
New SPEC: http://www.kanarip.com/custom/SPECS/rubygem-passenger.spec New SRPM: http://www.kanarip.com/custom/f9/SRPMS/rubygem-passenger-2.0.3-2.fc9.src.rpm
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tcallawa@redhat.com Blocks| |182235
--- Comment #2 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2008-11-09 10:40:14 EDT --- Umm... spot, would you answer my question below?
! First of all please unpack passenger-2.0.3.gem in the srpm by below: $ mkdir TMP ; cd TMP $ tar xf ../*gem (gem can be unpacked by tar) $ mkdir TMP ; cd TMP $ tar xzf ../data.tar.gz Then: First of all, the overall license this package is GPLv2 (not GPLv2+) Then ext/apache2/LICENSE-CNRI.TXT says: ///////////////////////////////////////////////////////////////////////// A few functions in ext/apache2/Hooks.cpp are based on the source code of mod_scgi version 1.9. Its license is included in this file. Please note that these licensing terms *only* encompass those few functions, and not Passenger as a whole. ------------------------------------------------------------------------ CNRI OPEN SOURCE LICENSE AGREEMENT
(CNRI = Python 1.6 i.e. GPL incompatible license follows) /////////////////////////////////////////////////////////////////////////
What I am in trouble is that - What functions in ext/apache2/Hooks.cpp are actually based on mod_scgi codes - And I don't know for now how these functions are used in the other parts of passenger source codes - So I am not sure if the code in Hooks.cpp under CNRI license won't conflict with GPL.
spot, how do you think about this. For me the current status seems very obscure.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #3 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2008-11-09 11:17:39 EDT --- By the way some pre-remarks
* BuildRequires - This package won't build without "BR: rubygem(fastthread)". - "BR: gcc-c++ findutils" are redundant.
* Requires - Please check if all needed Requires are correctly added. It seems that at least "Requires: rubygem(rack) rubygem(fastthread)" are needed.
* boost dependency - Well, when I try below to make build log more verbose (please consider this) ------------------------------------------------------- %prep %setup -q -c -T
mkdir BINDIR cat > BINDIR/rake <<EOF #!/bin/bash %{_bindir}/rake -v $@ EOF chmod 0755 BINDIR/rake
%build export CONFIGURE_ARGS="--with-cflags='%{optflags}'" export PATH=$(pwd)/BINDIR:$PATH gem install \ ...... ------------------------------------------------------- build log shows (attached) ------------------------------------------------------- 1525 DEBUG: cd /builddir/build/BUILD/rubygem-passenger-2.0.3/usr/lib/ruby/gems/1.8/gems/passenger-2.0.3 1526 DEBUG: rake clean apache2 1527 DEBUG: rm -rf Utils.o Bucket.o Logging.o System.o Configuration.o Hooks.o mod_passenger.o mod_passenger.so ApplicationPoolSe rverExecutable 1528 DEBUG: (in /builddir/build/BUILD/rubygem-passenger-2.0.3/usr/lib/ruby/gems/1.8/gems/passenger-2.0.3) 1529 DEBUG: ### In ext/apache2: 1530 DEBUG: rm -r pkg 1531 DEBUG: make clean 1532 DEBUG: ### In ext/passenger: 1533 DEBUG: rm -f Makefile 1534 DEBUG: rm -f libboost_thread.a *.o 1535 DEBUG: ### In ext/boost/src: 1536 DEBUG: rm -f Apache2ModuleTests *.o 1537 DEBUG: ### In test: 1538 DEBUG: rm -f DummyRequestHandler ApplicationPool 1539 DEBUG: ### In benchmark: 1540 DEBUG: g++ -g -DPASSENGER_DEBUG -fPIC -I../.. -D_REENTRANT -DNDEBUG -c *.cpp 1541 DEBUG: ### In ext/boost/src: 1542 DEBUG: g++ -g -DPASSENGER_DEBUG -fPIC -I../.. -D_REENTRANT -DNDEBUG -c pthread/exceptions.cpp 1543 DEBUG: g++ -g -DPASSENGER_DEBUG -fPIC -I../.. -D_REENTRANT -DNDEBUG -c pthread/once.cpp 1544 DEBUG: g++ -g -DPASSENGER_DEBUG -fPIC -I../.. -D_REENTRANT -DNDEBUG -c pthread/thread.cpp 1545 DEBUG: ar cru libboost_thread.a *.o 1546 DEBUG: ranlib libboost_thread.a ------------------------------------------------------- Here - This package seem to be using internal libboost_thread library. This should be changed so that mod_passenger.so uses external (system- widely provided) libboost_thread-mt.so library - Anyway Fedora specific compilation flags are not correctly honored.
* Redundant output - I guess the "-v" option of "chmod -v 644 $script" is not needed... (Actually you are not using -v option for chmod on the below lines) - Also I guess rm -r"v"f is redundant...
* Document files - You don't have to write %doc attribute for files under %_mandir (as these are automatically regarded as %doc)
* Directory ownership issue - Please own %{ruby_sitearch}/passenger/ - Please also check the directory ownership issues between subpackages. ! For example - The directory %{geminstdir}/doc is owned by -doc subpackage - -devel subpackage has %{geminstdir}/doc/definitions.h - -devel subpackage does not have "Requires: -doc" - So when -devel subpackage is installed with_out_ -doc subpackage installed, %{geminstdir}/doc is not owned by any packages
* %defattr - is missing on mod_passenger subpackage.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #4 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2008-11-09 11:22:39 EDT --- Created an attachment (id=323017) --> (https://bugzilla.redhat.com/attachment.cgi?id=323017) mock build log for dist-f11
Forgot to attach mock build log...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #5 from Jeroen van Meeuwen kanarip@kanarip.com 2008-11-09 15:29:23 EDT --- (In reply to comment #2)
First of all, the overall license this package is GPLv2 (not GPLv2+)
The license tag actually says GPLv2, not GPLv2+
(In reply to comment #3)
By the way some pre-remarks
- BuildRequires
- This package won't build without "BR: rubygem(fastthread)".
Added BuildRequires: rubygem(fastthread) >= 1.0.1
- "BR: gcc-c++ findutils" are redundant.
Removed these.
- Requires
- Please check if all needed Requires are correctly added. It seems that at least "Requires: rubygem(rack) rubygem(fastthread)" are needed.
Added these requires
- boost dependency
- Well, when I try below to make build log more verbose (please consider this)
(...snip...)
Here - This package seem to be using internal libboost_thread library. This should be changed so that mod_passenger.so uses external (system- widely provided) libboost_thread-mt.so library - Anyway Fedora specific compilation flags are not correctly honored.
I seem unable to do this. Logfile attached
- Redundant output
- I guess the "-v" option of "chmod -v 644 $script" is not needed... (Actually you are not using -v option for chmod on the below lines)
- Also I guess rm -r"v"f is redundant...
It's redundant, but it shows which files are chmod'ed or rm'ed; since it's a find with a couple of parameters I'd like to be able to track down what happens.
- Document files
- You don't have to write %doc attribute for files under %_mandir (as these are automatically regarded as %doc)
Fixed.
- Directory ownership issue
- Please own %{ruby_sitearch}/passenger/
- Please also check the directory ownership issues between subpackages. ! For example
- The directory %{geminstdir}/doc is owned by -doc subpackage
- -devel subpackage has %{geminstdir}/doc/definitions.h
- -devel subpackage does not have "Requires: -doc"
- So when -devel subpackage is installed with_out_ -doc subpackage installed, %{geminstdir}/doc is not owned by any packages
Made %{geminstdir} shared between -devel and -doc package.
- %defattr
- is missing on mod_passenger subpackage.
Fixed.
New SPEC: http://www.kanarip.com/custom/SPECS/rubygem-passenger.spec New SRPM: http://www.kanarip.com/custom/f9/SRPMS/rubygem-passenger-2.0.3-3.fc9.src.rpm
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #6 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2008-11-09 22:33:00 EDT --- (In reply to comment #5)
- boost dependency
- Well, when I try below to make build log more verbose (please consider this)
(...snip...)
Here - This package seem to be using internal libboost_thread library. This should be changed so that mod_passenger.so uses external (system- widely provided) libboost_thread-mt.so library - Anyway Fedora specific compilation flags are not correctly honored.I seem unable to do this. Logfile attached
Well, would you attach the log?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #7 from Tom "spot" Callaway tcallawa@redhat.com 2008-11-10 11:43:29 EDT --- (In reply to comment #2)
What I am in trouble is that
- What functions in ext/apache2/Hooks.cpp are actually based on mod_scgi codes
- And I don't know for now how these functions are used in the other parts of passenger source codes
- So I am not sure if the code in Hooks.cpp under CNRI license won't conflict with GPL.
spot, how do you think about this. For me the current status seems very obscure.
Problem 1: The functions which are copied are not marked, thus, the code is being reused without proper attribution. This means that the upstream for rubygem-passenger is in violation of the terms of the CNRI License:
"3. In the event Licensee prepares a derivative work that is based on or incorporates scgi-1.9 or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to scgi-1.9."
No such summary exists.
Problem 2: You cannot copy code which is under a GPLv2-incompatible license into a source file which is marked as GPLv2, then compile it into a larger GPLv2 program. So, even if we knew which functions were copied, it almost certainly wouldn't matter. This code is non-distributable.
Unfortunately, there seems to be no easy way to fix Problem 2 (Problem 1 is easy enough to fix by the rubygem-passenger upstream). All releases of the mod_scgi code are under the CNRI license (although, changes made after 1.10 are under MIT). Some methods of fixing this issue would be:
1. Removing all of the copied code from mod_scgi 1.09, then replacing it either with clean-room written code (aka, code written by someone who has never looked at mod_scgi) or restructuring the rubygem-passenger code so that it is not necessary.
2. Getting permission from CNRI to use that code under different (GPLv2 compatible) terms. They seem to use MIT for changes to that codebase these days, perhaps they would give permission for the copied code to be used under those terms?
However, until this issue is resolved, this one can't go any farther, sorry.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #8 from Jeroen van Meeuwen kanarip@kanarip.com 2008-11-10 18:50:25 EDT --- (In reply to comment #7)
(In reply to comment #2)
(...snip...)
Unfortunately, there seems to be no easy way to fix Problem 2 (Problem 1 is easy enough to fix by the rubygem-passenger upstream). All releases of the mod_scgi code are under the CNRI license (although, changes made after 1.10 are under MIT). Some methods of fixing this issue would be:
- Removing all of the copied code from mod_scgi 1.09, then replacing it either
with clean-room written code (aka, code written by someone who has never looked at mod_scgi) or restructuring the rubygem-passenger code so that it is not necessary.
- Getting permission from CNRI to use that code under different (GPLv2
compatible) terms. They seem to use MIT for changes to that codebase these days, perhaps they would give permission for the copied code to be used under those terms?
However, until this issue is resolved, this one can't go any farther, sorry.
Would another solution be to use mod_scgi >= 1.10?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #9 from Jeroen van Meeuwen kanarip@kanarip.com 2008-11-10 18:55:20 EDT --- Created an attachment (id=323134) --> (https://bugzilla.redhat.com/attachment.cgi?id=323134) output on a compile with attached diff (1)
Attach output from a rake -v when compiling against the system-wide provided boost-static libraries
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #10 from Jeroen van Meeuwen kanarip@kanarip.com 2008-11-10 18:57:27 EDT --- Created an attachment (id=323135) --> (https://bugzilla.redhat.com/attachment.cgi?id=323135) diff to Rakefile to compile against %{_libdir}/libboost_thread-mt.a
Attach diff for Rakefile
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #11 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2008-11-11 03:30:18 EDT --- (In reply to comment #9)
Created an attachment (id=323134)
--> (https://bugzilla.redhat.com/attachment.cgi?id=323134) [details]
output on a compile with attached diff (1)
Attach output from a rake -v when compiling against the system-wide provided boost-static libraries
You should link against libboost_thread-mt.so, not against static archive libboost_thread-mt.a. But anyway linkage fails by other reasons like ----------------------------------------------------------------- ApplicationPoolServerExecutable.cpp:86: undefined reference to `boost::this_thread::interruption_requested()' ----------------------------------------------------------------- (and many errors). It seems that this is because Fedora ships boot 1.34 while these symbols are introduced on 1.36+. So until Fedora upgrades boost we have to use internal boost. In this case Fedora compilation flags must be treated correctly. The following seems to fix this issue: ------------------------------------------------------------------ --- Rakefile.orig 2008-11-11 16:23:45.000000000 +0900 +++ Rakefile 2008-11-11 17:23:32.000000000 +0900 @@ -88,7 +88,7 @@
subdir 'ext/boost/src' do file 'libboost_thread.a' => Dir['*.cpp'] + Dir['pthread/*.cpp'] do - flags = "#{OPTIMIZATION_FLAGS} -fPIC -I../.. #{THREADING_FLAGS} -DNDEBUG #{MULTI_ARCH_FLAGS}" + flags = "#{OPTIMIZATION_FLAGS} #{APACHE2::CXXFLAGS} -fPIC -I../.. #{THREADING_FLAGS} -DNDEBUG #{MULTI_ARCH_FLAGS}" compile_cxx "*.cpp", flags # NOTE: 'compile_cxx "pthread/*.cpp", flags' doesn't work on some systems, # so we do this instead. -------------------------------------------------------------------
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #12 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2008-11-11 03:38:59 EDT --- (In reply to comment #8)
(In reply to comment #7)
(In reply to comment #2)
(...snip...)
Unfortunately, there seems to be no easy way to fix Problem 2 (Problem 1 is easy enough to fix by the rubygem-passenger upstream). All releases of the mod_scgi code are under the CNRI license (although, changes made after 1.10 are under MIT). Some methods of fixing this issue would be:
- Removing all of the copied code from mod_scgi 1.09, then replacing it either
with clean-room written code (aka, code written by someone who has never looked at mod_scgi) or restructuring the rubygem-passenger code so that it is not necessary.
Would another solution be to use mod_scgi >= 1.10?
Current mod_scgi seems 1.13. http://python.ca/scgi/releases/scgi-1.13.tar.gz
However LICENSE.txt of mod_scgi 1.13 contains -------------------------------------------------------------------- This version of the SCGI package is derived from scgi 1.10, released by CNRI. See doc/LICENSE_110.txt for the licensing terms of that release. Changes made since that release are summarized in the CHANGES.txt file along with a list of authors. Those changes are made available under the following terms (commonly known as the MIT/X license). -------------------------------------------------------------------- This reads that the codes derived from scgi 1.10 codes are still under CNRI license, and only what is changed compared to 1.10 are under MIT. So I don't think using latest mod_scgi will solve this issue.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(kanarip@kanarip.c | |om)
--- Comment #13 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2008-12-07 11:09:10 EDT --- Any news from upstream?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Jeroen van Meeuwen kanarip@kanarip.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(kanarip@kanarip.c | |om) |
--- Comment #14 from Jeroen van Meeuwen kanarip@kanarip.com 2008-12-08 07:39:15 EDT --- (In reply to comment #13)
Any news from upstream?
I'm not sure what I can ask them to do?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #15 from Tom "spot" Callaway tcallawa@redhat.com 2008-12-08 10:25:58 EDT --- Talk to upstream and CNRI about getting permission to use the mod_scgi derived code under different (GPL compatible terms), perhaps MIT?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Jeroen van Meeuwen kanarip@kanarip.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(tcallawa@redhat.c | |om)
Bug 470696 depends on bug 470694, which changed state.
Bug 470694 Summary: Review Request: rubygem-rack - Common API for connecting web frameworks, web servers and layers of software https://bugzilla.redhat.com/show_bug.cgi?id=470694
What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE
--- Comment #16 from Jeroen van Meeuwen kanarip@kanarip.com 2008-12-11 19:13:08 EDT --- I've contacted both upstream for CNRI as well as Phusion Passenger;
= CNRI =
I've requested taking into consideration re-licensing the original mod_scgi code-base to a GPLv2-compatible license, and they promised me to have their CEO look into it. Should they choose to do so, I think that would kill both birds with one stone, wouldn't it?
= Phusion Passenger =
They are considering re-licensing Phusion Passenger (thus rubygem-passenger) to the MIT license. Would that solve the incompatibility issue? And, would that make the package's license acceptable for inclusion in Fedora/EPEL?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Tom "spot" Callaway tcallawa@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(tcallawa@redhat.c | |om) |
--- Comment #17 from Tom "spot" Callaway tcallawa@redhat.com 2008-12-12 09:24:34 EDT --- So, if CNRI gives permission for rubygem-passenger to use mod_scgi 1.10 under GPLv2, that would resolve the licensing issue. Note that I said 1.10. If they only relicense their latest version, that won't do the trick.
If rubygem-passenger is relicensed to MIT, they're no longer incompatible with the mod_scgi 1.10 licensing, but they're _still_ in violation of the mod_scgi 1.10 licensing terms, which state:
"3. In the event Licensee prepares a derivative work that is based on or incorporates scgi-1.9 or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to scgi-1.9."
They need to add a summary of the changes made to the mod_scgi code used, and then they'd be in the clear.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #18 from Jeroen van Meeuwen kanarip@kanarip.com 2008-12-12 09:39:57 EDT --- (In reply to comment #17)
So, if CNRI gives permission for rubygem-passenger to use mod_scgi 1.10 under GPLv2, that would resolve the licensing issue. Note that I said 1.10. If they only relicense their latest version, that won't do the trick.
I've asked for re-licensing of mod_scgi-1.09 and later versions (including mod_scgi-1.10)
If rubygem-passenger is relicensed to MIT, they're no longer incompatible with the mod_scgi 1.10 licensing, but they're _still_ in violation of the mod_scgi 1.10 licensing terms, which state:
"3. In the event Licensee prepares a derivative work that is based on or incorporates scgi-1.9 or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to scgi-1.9."
They need to add a summary of the changes made to the mod_scgi code used, and then they'd be in the clear.
Phusion Passenger's upstream told me they would list the changes anyway.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(kanarip@kanarip.c | |om)
--- Comment #19 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-01-17 08:25:07 EDT --- Please let me know if there is any news from the upstream.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #20 from Johan Kok johan-fedora@deds.nl 2009-03-03 06:41:54 EDT --- (In reply to comment #18)
Phusion Passenger's upstream told me they would list the changes anyway.
Jeroen, do you have any news on licensing and/or listing changes from upstream?
After a quick look at the Phusion Passenger 2.1.1 (beta, released this week), I can't find a new license and/or a listing of those changes to the mod_scgi code in there.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Jeroen van Meeuwen kanarip@kanarip.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(kanarip@kanarip.c | |om) |
--- Comment #21 from Jeroen van Meeuwen kanarip@kanarip.com 2009-03-04 17:47:09 EDT --- phusion.nl, the upstream for mod_passenger promised me they would include a list of changes.
The CEO of CNRI (owner of the license and original mod_scgi code) has not responded to my inquiries but some of their employees have; long story short, no result from that angle either.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #22 from Jeroen van Meeuwen kanarip@kanarip.com 2009-03-15 18:28:36 EDT --- Would it be allowed to drop mod_passenger from the package (and thus not use the CNRI licensed code in the package for Fedora)?
Could we then continue the review just for rubygem-passenger?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #23 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-03-16 14:11:16 EDT --- (In reply to comment #22)
Would it be allowed to drop mod_passenger from the package (and thus not use the CNRI licensed code in the package for Fedora)?
Could we then continue the review just for rubygem-passenger?
If this package is still useful even if mod_passenger part is dropped, you can just do it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #24 from Jeroen van Meeuwen kanarip@kanarip.com 2009-03-17 09:33:28 EDT --- I'll explain my plan a little further because it may be a little controversial.
Since this package is a little hard to package (with or without mod_passenger), I was thinking I could ship rubygem-passenger, and out-comment all the parts that have to do with mod_passenger (and thus not ship, compile or include mod_passenger itself, just the .spec semantics, out-commented). That way, downstream users that want mod_passenger can derive from the .spec and .srpm already in Fedora.
However, my primary concern is that we would be shipping an intolerable SRPM (since the conflicting licenses prevent the sources from being shipped together as one).
Could you let me know what you think? Thanks!
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #25 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-03-26 10:22:33 EDT --- Sorry for late reply.
(In reply to comment #24)
I'll explain my plan a little further because it may be a little controversial.
Since this package is a little hard to package (with or without mod_passenger), I was thinking I could ship rubygem-passenger, and out-comment all the parts that have to do with mod_passenger (and thus not ship, compile or include mod_passenger itself, just the .spec semantics, out-commented). That way, downstream users that want mod_passenger can derive from the .spec and .srpm already in Fedora.
However, my primary concern is that we would be shipping an intolerable SRPM (since the conflicting licenses prevent the sources from being shipped together as one).
Could you let me know what you think? Thanks!
I don't think we can provide srpm which cannot build within Fedora's policy and which needs fixing to compile.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |herlo1@gmail.com
--- Comment #26 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-04-22 09:04:43 EDT --- *** Bug 496941 has been marked as a duplicate of this bug. ***
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Matthew Kent matt@bravenet.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matt@bravenet.com
--- Comment #27 from Matthew Kent matt@bravenet.com 2009-05-05 00:07:44 EDT --- Looking at the 2.2.2 release it looks like they've gone to to the MIT license and carry attribution for the functions.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #28 from Tom "spot" Callaway tcallawa@redhat.com 2009-05-05 08:34:46 EDT --- When I see a 2.2.2 SRPM, I'll audit it to make sure everything looks okay from a licensing perspective.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #29 from Jeroen van Meeuwen kanarip@kanarip.com 2009-05-05 10:38:27 EDT --- New SPEC: http://www.kanarip.com/custom/SPECS/rubygem-passenger.spec New SRPM: http://www.kanarip.com/custom/f11/SRPMS/rubygem-passenger-2.2.2-1.fc11.src.r...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Tom "spot" Callaway tcallawa@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|182235(FE-Legal) |
--- Comment #30 from Tom "spot" Callaway tcallawa@redhat.com 2009-05-05 10:57:33 EDT --- The source looks clean of licensing issues. You should really use:
License: MIT and CNRI
Lifting FE-Legal.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #31 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-05-05 14:28:38 EDT --- ell, for 2.2.2-1:
* %define -> %global - Please use %global instead of %define:
https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over...
* Gem guidelines - First of all, this does not follow RubyGem packaging guidelines A This srpm is not created from original gem file B And actually the binary "rubygem-passenger" rpm does not work as gem. For example, "$ gem list passenger returns nothing. This is because specification .gemspec file is missing. Also, cached gem file is not installed.
Well, for A: - When using gem as source, applying patches may be difficult. However if you want gem file can be expanded as tar archive. Also, usually I guess rake file supports "rake gem" to create modified gem file The issue B is more critical than A.
* Functionality - Note that some of (maybe all) scripts under %_bindir don't work. For example: ---------------------------------------------------------------- $ passenger-config --version /usr/bin/passenger-config:27:in `require': no such file to load -- phusion_passenger/constants (LoadError) from /usr/bin/passenger-config:27 ----------------------------------------------------------------
* Issues from build.log ---------------------------------------------------------------- 92 mkdir -p ext/nginx/libboost_oxt/boost 93 g++ -Iext -D_REENTRANT -I/usr/local/include -Wall -g -DPASSENGER_DEBUG -DBOOST_DISABLE_ASSERTS -o ext/nginx/libboost_oxt/boost/exceptions.o -c ext/boost/src/pthread/exceptions.cpp 94 g++ -Iext -D_REENTRANT -I/usr/local/include -Wall -g -DPASSENGER_DEBUG -DBOOST_DISABLE_ASSERTS -o ext/nginx/libboost_oxt/boost/once.o -c ext/boost/src/pthread/once.cpp ---------------------------------------------------------------- - This still uses internal boost library. Please try to use system-wide boost library. Note that F-11/12 boost is 1.37.
And: ---------------------------------------------------------------- 106 g++ -Iext -Iext/common -D_REENTRANT -I/usr/local/include -Wall -g -DPASSENGER_DEBUG -DBOOST_DISABLE_ASSERTS -o ext/nginx/libpassenger_common/Utils.o -c ext/common/Utils.cpp 107 g++ -Iext -Iext/common -D_REENTRANT -I/usr/local/include -Wall -g -DPASSENGER_DEBUG -DBOOST_DISABLE_ASSERTS -o ext/nginx/libpassenger_common/Logging.o -c ext/common/Logging.cpp ---------------------------------------------------------------- - Fedora specific compilation flags are not correctly honored.
* Misc cleanups ! Note: Before fixing below, please change to use gem file as source first. ---------------------------------------------------------------- mkdir -p %{buildroot}/%{geminstdir} mkdir -p %{buildroot}/%{geminstdir} %{buildroot}/%{geminstdir}/lib/ext/ cp -a * %{buildroot}/%{geminstdir} ---------------------------------------------------------------- - The middle line is not needed.
- What is the following line for? ---------------------------------------------------------------- cp -a ext/phusion_passenger/native_support.so %{buildroot}/%{geminstdir}/lib/ext/. ----------------------------------------------------------------
* Directory ownership issue - The following directories should be owned by main package, not by -devel subpackage: ---------------------------------------------------------------- %{geminstdir}/ext/ %{geminstdir}/ext/apache2/ %{geminstdir}/ext/boost/ ----------------------------------------------------------------
- The ownership of the following directories is unclear: ---------------------------------------------------------------- %{geminstdir}/test/ %{geminstdir}/test/support/ ----------------------------------------------------------------
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?(kanarip@kanarip.c | |om)
--- Comment #32 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-05-21 10:35:00 EDT --- ping?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #33 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-06-06 12:17:45 EDT --- ping again?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Hongli Lai honglilai@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |honglilai@gmail.com
--- Comment #34 from Hongli Lai honglilai@gmail.com 2009-06-07 07:12:47 EDT --- Hi Mamoru. I am one of the authors of Phusion Passenger, and I want to comment on several issues here:
== Vendoring Boost
We actually use a modified version of Boost, so Phusion Passenger will not compile against a stock Boost. I understand your concerns with regard to security, but please rest assured because we fully understand the security implications of vendoring a library. We will take full responsibilities for any security problems; that is, we will either backport security fixes or upgrade our vendored Boost to a newer version.
I hope this addresses any concerns that you might have with regard to vendoring Boost. If not then I'm eager to hear your thoughts on it.
== native_support.so
I don't think the cp command there is correct. Phusion Passenger loads native_support.so by calling "require 'phusion_passenger/native_support'", so the file must be inside a 'phusion_passenger' directory.
== -devel subpackage
Phusion Passenger should not be split into a regular and a -devel subpackage. We do not provide developer headers or libraries.
The source files in the ext subdirectory are not used during runtime, so they can be safely omitted from the RPMs. The lib subdirectory however must be present.
== test subdirectory
The test subdirectory contains unit tests and integration tests, and are only useful for Phusion Passenger developers, not for Phusion Passenger users. You can safely omit this subdirectory in the RPMs.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #35 from Hongli Lai honglilai@gmail.com 2009-06-07 07:13:59 EDT --- Also, could you wait for the 2.2.3 release, which is scheduled for next week? *A lot* of bugs have been fixed in this release.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |a.badger@gmail.com
--- Comment #36 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-06-07 11:03:33 EDT --- (In reply to comment #34)
== Vendoring Boost
We actually use a modified version of Boost, so Phusion Passenger will not compile against a stock Boost. I understand your concerns with regard to security, but please rest assured because we fully understand the security implications of vendoring a library. We will take full responsibilities for any security problems; that is, we will either backport security fixes or upgrade our vendored Boost to a newer version.
I hope this addresses any concerns that you might have with regard to vendoring Boost. If not then I'm eager to hear your thoughts on it.
CC-ing to Toshio. Would you comment on this issue?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #37 from Toshio Kuratomi tkuratom@redhat.com 2009-06-07 16:08:02 EDT --- Short answer: vendoring or bundling of libraries is not allowed.
Long answer: you can request an exception from FESCo but it's not likely to be granted with just the reasons you've given here. When you bundle a library and, on top of that, modify it so it no longer matches upstream, you are starting the process of forking the library. This may not seem like much of an issue to a developer. (Hey, I just have one or two forked libraries, no problem for me to track security issues.) But it makes life much more difficult for distributions. There are places that this shows up.
* Security. You touched on the fact that you've heard the security arguments but I'll go ahead on specify them here since there's many different places that this touches: - When a security flaw is discovered in a library and bundling is not allowed, The library can be fixed in a single package, that package rebuilt, and when users download it, all the applications that use it are immediately protected. When bundling is allowed, the distribution has to find all the packages that the library occurs in by auditing source code or running a special tool over all elf files in all packages, then all of those packages have to be fixed, all of those packages have to be built, and users have to download and update each of the ones that they are using on their system before they are protected. There is much more work involved when bundled libraries are involved. - With security issues, people want to remove as much lag as they can between announcement of a problem and the fix being available for users. When libraries are unbundled, tools like vendor-sec can be used to alert distributions of problems that need patching in their packages before the announcement is made and then they can fix them with zero days of vulnerability. If bundling of libraries occurs, then the problem becomes how to get fixes out to all affected packages. If the distribution patches those packages, they must be careful to not leak the fact that there is a security vulnerability before they are allowed (which means they need to be careful who they share the information and what information they share with others). OTOH, if they do not patch the packages bundling libraries, then those packages are not protected on zero day, but only afterwards. - When a security flaw appears, the program has to either update to a non-affected version of the library or backport a fix. This can be problematic when the code of the library has undergone many API and code changes since the version that is being bundled and the security fixing patch is very widespread. Many conflicts can arise that need time to fix when trying to backport the fixes but porting the application code to the new API version can also take a lot of time. - We cannot implicitly trust an upstream application to be on top of security issues that are released in the packages that they care about. What happens if you are not following boost development and don't know that a security release has been made? What happens if the developer that is responsible for watching boost development goes on vacation or quits your project? What happens if your application ceases active development? What happens if boost stops active development and security fixes start originating with distro patches? * Forking is occurring. Once an application starts bundling libraries, it's easy for the project to include local patches to the library to add features that upstream doesn't have or fix bugs that upstream hasn't addressed. This has several negative effects. - When a security issue appears, it becomes harder to fix the application bundling the library. If you attempt to upgrade to a newer version, you have to make sure your important local modifications get ported to the new version. If you attempt to backport, you have to merge the upstream fix to your own code-base which may have conflicts with the local modifications. - When working with the library that comes from upstream, there is a community of people who are interested in that library to fall back on for help. When working on your own private copy that community may not be interested in helping you work on your modified sources since they don't have control or knowledge of what your modified sources do. - Forking dilutes one of the strengths of open-source development. Instead of a project getting stronger with more people supplying patches to help drive the project and build a bigger community, the community of people interested in it are splintering, developing more and more divergent code-bases, solving the same problem over and over in different ways in different private copies of the library. Instead of everyone benefiting, everyone has to pay. * Bugfixes. Are usually of lesser importance from security issues but share the same issues arise. * Old versions of code linger on. If the application can bundle its own version of a library, the incentive to port to newer versions of the library are reduced. This exacerbates the problems of security and bugfix issues. Instead of progressively porting to newer versions of a library as time goes on, porting to newer versions becomes a chore that has to be performed at the same time as addressing a security flaw. This puts time pressure on the project when the work could have been spread out over a longer period if only the porting had been done all along. * Licensing. Although licensing issues can crop up in any project, projects which bundle code from different sources together are a special source of concern. They make auditing for license issues a larger project.
One last note related more to what you wrote than to the reasons that bundling is not allowed in Fedora. You write that you are willing to:
"take full responsibilities for any security problems; that is, we will either backport security fixes or upgrade our vendored Boost to a newer version."
However, I wonder what that means to you. Are you guaranteeing that you will be able to produce zero day updates of your packages that include the fixes to your bundled boost at the same time as boost itself is updated? Are you saying that you will always be around to handle the problems that can arise? What happens if your responses are not timely enough to meet the needs of our users? Are you making a monetary guarantee? I think that attempting to say that you take full responsibility in this context should be approached with caution on your part as what it entails could be interpreted in many different ways.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #38 from Hongli Lai honglilai@gmail.com 2009-06-07 16:57:35 EDT --- Toshio, I totally understand your points. We are well aware of all of those disadvantages of bundling/forking that you mentioned, but given our circumstances we decided that bundling/forking Boost is the best solution, despite all the aforementioned disadvantages. We made this decision a year ago, and to date we still think that it's the right decision.
Regarding responsibility: what I meant is that we take security very seriously, and that we will do our best to address any security problems, including those in Boost, as opposed to neglecting Boost security issues and happily keeping on vendoring the old, insecure version. We treat any problems in Boost as if they are problems in our own code. Is this explanation sufficient for you? If not, what are your concerns?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Jeroen van Meeuwen kanarip@kanarip.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(kanarip@kanarip.c | |om) |
--- Comment #39 from Jeroen van Meeuwen kanarip@kanarip.com 2009-06-09 18:37:51 EDT --- (In reply to comment #35)
Also, could you wait for the 2.2.3 release, which is scheduled for next week? *A lot* of bugs have been fixed in this release.
This is a package review for admitting the package in Fedora, not a bug-tracker ;-)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #40 from Jeroen van Meeuwen kanarip@kanarip.com 2009-06-09 19:12:10 EDT --- (In reply to comment #38)
Toshio, I totally understand your points. We are well aware of all of those disadvantages of bundling/forking that you mentioned, but given our circumstances we decided that bundling/forking Boost is the best solution, despite all the aforementioned disadvantages. We made this decision a year ago, and to date we still think that it's the right decision.
Note that what we're saying is that forking (and forming another upstream) actually is better then bundling (whether forked or not).
Also, we'd like to see an effort made to have the changes applied to boost be sent and accepted upstream even though that would include more work (*NIX -> win32 compat). Upstream would then at least stand a chance in whether they want to make stuff win32 compat. or whether to ignore/reject the patch at all. If you decide to do so, please keep me in the loop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #41 from Toshio Ernie Kuratomi a.badger@gmail.com 2009-06-09 19:55:39 EDT --- (In reply to comment #38)
Toshio, I totally understand your points. We are well aware of all of those disadvantages of bundling/forking that you mentioned, but given our circumstances we decided that bundling/forking Boost is the best solution, despite all the aforementioned disadvantages. We made this decision a year ago, and to date we still think that it's the right decision.
Bundling may be the right decision for an upstream development shop. However, it is definitely not the right decision for software that is shipped in many distributions or for the conscientious system administrators. Bundling shifts the cost of forking so that developers bear less up front costs but distributions and system administrators bear more costs later on. In the case of embargoed security fixes the cost is paid when there is time pressure to get a fix created before a certain deadline is reached. In the case of bug-fixes and enhancements (features, performance), the cost penalty is less urgent but still occurs in the form of duplicate bugs, analysis, and debugging against the bundled version of the library when that work has already gone into the system library and resolved there via a patch or upgrade.
Not only is the cost shifted around but the benefits are decreased when the forked library is bundled instead of released separately. If the changes that prompt you to bundle the library are useful for you, why won't they be useful for others as well? If they're useful for others, then bundling the library forces them to reinvent the same types of changes you've made instead of working with you to get their make a better product overall.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?
--- Comment #42 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-07-15 13:51:18 EDT --- What is the status of this bug?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Hongli Lai honglilai@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo? |
--- Comment #43 from Hongli Lai honglilai@gmail.com 2009-07-16 02:45:06 EDT --- Toshio, Mamoru, as a startup company with finite resources we cannot afford to spend lots of resources on getting our changes accepted into Boost. If this means that Phusion Passenger will not be packaged by Fedora, then so be it; our users will find us and will use our software regardless.
Of course, if Red Hat can provide man power to get the changes accepted into Boost for us, or if Red Hat can hire us to get it done, then it would be a different story.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #44 from Toshio Ernie Kuratomi a.badger@gmail.com 2009-07-16 10:27:03 EDT --- (In reply to comment #43)
Toshio, Mamoru, as a startup company with finite resources we cannot afford to spend lots of resources on getting our changes accepted into Boost. If this means that Phusion Passenger will not be packaged by Fedora, then so be it; our users will find us and will use our software regardless.
Of course, if Red Hat can provide man power to get the changes accepted into Boost for us, or if Red Hat can hire us to get it done, then it would be a different story.
You're so close to understanding the power of open source software, you just need to take a few more steps! :-) Here's how I would have phrased it as an open source developer trying to leverage his community:
""" I can see how bundling libraries can be a problem for distributions. We just went through similar issues with Debian as well. Unfortunately, that's not the market that we're actively pursuing at the moment so we're spending our time working on other areas of the code rather than trying to get our changes integrated into boost. If you want to get those changes integrated into boost, the current code is here: URL_TO_GIT_REPO. The current code is based on boost BOOST_VERSION. The diff between the two will show you that we're basically doing: OVERVIEW_OF_CHANGES. This is essential because WHY_IS_THIS_AN_ESSENTIAL_BUGFIX,_FEATURE,_ETC. This has to touch MANY_FILES/FEW_FILES/INVASIVE_CHANGE/UNOBTRUSIVE_CHANGE. The changes OTHER_NOTES_THAT_WILL_HELP_US_UNDERSTAND_THE_CODE_WELL_ENOUGH_TO_EXPLAIN_IT_TO_BOOST_UPSTREAM.
We've tried to get this into upstream boost before. Here's a link to the mailing list discussion of that where boost upstream outlines the issues they had with our present code: URL_TO_PREVIOUS_DISCUSSION_WITH_BOOST.
If you can get this into boost's upstream we'd be happy to TAKE_PATCHES/MAKE_OUR_OWN_CHANGES to phusion passenger to UNBUNDLE/ONLY_BUNDLE_IF_SYSTEM_BOOST_IS_UNAVAILABLE boost.
Hope that helps! """
In open source, people help write code because they have an itch to scratch. Red Hat doesn't ship phusion passenger so you need to address the people who actually have an itch instead. Jeroen and a number of people CC'd to this bug fit that bill as they want to see phusion passenger shipped on Fedora and understand that bundling libraries is a drawback for their deployments. Since they didn't write the modifications to boost, be sure to give them the tools and knowledge they need to successfully discuss the changes with boost upstream so that there's a chance of getting the changes integrated. Whether phusion passenger gets into Fedora will depend on whether you get one of them to pick up the task and get the changes merged upstream.
Also remember that getting changes integrated upstream is often like a negotiating session. Since you're trying to get someone else to do your negotiating for you, be sure they understand what your requirements are before sending them off to work. Maybe boost will give you the feature you want but it can't use the API you wrote. Maybe the feature is unacceptable but boost will make changes so you can write the feature into your application layer instead. It's important for the person who takes up this task to know what things are negotiable and which are not.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #45 from Hongli Lai honglilai@gmail.com 2009-07-16 10:53:14 EDT --- Toshio, you are absolutely right. I apologize for the short reply that I sent; I hadn't given it a lot of time and thought because my hands are full with client work right now. Lately I'm not even able keep up with providing community support for Phusion Passenger, let alone going through the negotiation process of getting changes or similar features accepted into Boost.
It is possible for me to provide an overview of changes and rationale for the changes, but that takes time as well, and I cannot spare any. Even my weekends and evenings are fully scheduled. I estimate to have more time by October so if you can wait until then then perhaps we can work something out.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #46 from Jeroen van Meeuwen kanarip@kanarip.com 2009-07-16 13:54:02 EDT --- Look, I perfectly understand your challenges, and I myself as undoubtedly many other people as well are in quite the same situation.
Like Toshio suggested, I'm doing this because I have an itch to scratch. Even though of particular benefit to myself (I don't have time to run in circles supporting weird versions of boost), it could result in huge benefit to you as well as your customers.
So, if you could please take the time to press "Print" on the documentation, I can come and pick it up next week in Apeldoorn.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #47 from Hongli Lai honglilai@gmail.com 2009-07-16 18:27:18 EDT --- Thanks for the offer, but there is no documentation at this time that describes what the Boost changes are and why they were made, except for the Git commit logs. Writing one will take some time and the earliest date at which I can do that is probably October.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #48 from Jeroen van Meeuwen kanarip@kanarip.com 2009-07-17 02:33:39 EDT --- Is there any other way I can help you, besides going renegade and attempting to fix this by working on the code myself, without help?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #49 from Jeroen van Meeuwen kanarip@kanarip.com 2009-07-26 05:49:10 EDT --- Created an attachment (id=355185) --> (https://bugzilla.redhat.com/attachment.cgi?id=355185) diff between boost in passenger/master and boost/tags/Version_1_35_0
Attached a diff between ext/boost in the master branch of passenger and the boost/ directory in boost's tags/Version_1_35_0
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #50 from Hongli Lai honglilai@gmail.com 2009-07-26 06:54:31 EDT --- Sorry, I haven't had the time to post a proper reply.
Please feel free to go renegade if you can't wait until October.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #51 from Jeroen van Meeuwen kanarip@kanarip.com 2009-07-26 07:57:33 EDT --- I can wait until October, but I do want to understand in full what changes we're talking about so that we may actually get some work done in October ;-)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #52 from Hongli Lai honglilai@gmail.com 2009-07-26 10:09:27 EDT --- I'll give a few quick hints then. - You see I modified the boost::thread class. The modifications are necessary in order to implement oxt::thread. - Some exception classes like thread_resource_error are modified to inherit from oxt::tracable_exception.
oxt::thread and oxt::tracable_exception and their purposes are documented in their respective header files.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Michael Stahnke mastahnke@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mastahnke@gmail.com
--- Comment #53 from Michael Stahnke mastahnke@gmail.com 2009-11-03 23:37:36 EDT --- So, October is over, and there still a ruby community eager to have passenger on Fedora/RHEL. Are we any closer to reaching an end to this?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #54 from Jeroen van Meeuwen kanarip@kanarip.com 2009-11-04 03:05:05 EDT --- My status is I'm slowly growing some more C coding skills to fold oxt/boost/passenger back onto what is available outside of the passenger realm ;-)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #55 from Hongli Lai honglilai@gmail.com 2009-11-04 04:17:30 EDT --- Sorry, still too busy.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #56 from Michael Stahnke mastahnke@gmail.com 2010-04-16 17:37:06 EDT --- And now?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #57 from Hongli Lai honglilai@gmail.com 2010-04-16 18:40:30 EDT --- Right now I'm working on a client project with a tight deadline.
Now, since this issue has been opened for about a year now I'll just be honest with you. As part of a bootstrapping company I find it very hard to invest time in getting my changes merged upstream. You mentioned that by submitting changes upstream it'll alleviate myself of having to maintain the changes. This is correct, but the flip side of the coin is that I'll have to get the changes accepted in the first place. Some of the changes we made to Boost are quite intrusive and change source and binary compatibility (we've modified some basic classes to derive from classes in our own library, for example) and getting all changes accepted into Boost will be a long, hard process. So what's easier, maintaining the changes ourselves or going through the trouble of submitting the changes upstream? I still think the former is easier.
Debian is already packaging Phusion Passenger and they know about our usage of Boost. We already have contacts with people who are willing to maintain third party yum repositories. Unlike the official Fedora repository, these third party repositories can collaborate closely with us and won't lag behind official releases for weeks or months.
So all in all I do not see any benefits in getting the Boost changes submitted upstream; in fact, I only see drawbacks. If you want to do it I won't stop you, but without some sort of financial compensation for my time I won't do it. I have to work to pay for my food after all.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Jason Smith smithj4@bnl.gov changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |smithj4@bnl.gov
--- Comment #58 from Jason Smith smithj4@bnl.gov 2010-08-21 15:20:16 EDT --- Is there any chance that this will ever get packaged into an rpm? It is disappointing that there are packages for Ubuntu but not for RedHat.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #59 from Jeroen van Meeuwen kanarip@kanarip.com 2010-08-22 15:22:54 EDT --- You can only be as disappointed as much as you're willing to sink your teeth into solving the actual problems stated above.
That said, before such aforementioned work is actually done, chances are this package will not be included in the regular Fedora distribution or EPEL add-on repository.
That said, there are packages;
http://mirror.nl.ergo-project.org/repositories/
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #60 from Jason Smith smithj4@bnl.gov 2010-08-22 16:39:05 EDT --- (In reply to comment #59)
You can only be as disappointed as much as you're willing to sink your teeth into solving the actual problems stated above.
That would be very difficult since I know absolutely nothing about ruby. My only interest is in setting up a scalable puppet system and as a sysadmin, for obvious reasons, I would prefer to use the native OS package manager, rather than a package management system built-in to and only useful for one specific software tool.
That said, before such aforementioned work is actually done, chances are this package will not be included in the regular Fedora distribution or EPEL add-on repository.
Why does this have no chance of being included in a RedHat distribution? Is it a licensing issue or something else?
That said, there are packages;
Thanks, I will take a look at this next week.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #61 from Jeroen van Meeuwen kanarip@kanarip.com 2010-08-25 10:33:41 EDT --- (In reply to comment #60)
(In reply to comment #59)
You can only be as disappointed as much as you're willing to sink your teeth into solving the actual problems stated above.
That would be very difficult since I know absolutely nothing about ruby. My only interest is in setting up a scalable puppet system and as a sysadmin, for obvious reasons, I would prefer to use the native OS package manager, rather than a package management system built-in to and only useful for one specific software tool.
Then maybe reconsider declaring yourself disappointed -others do in fact (attempt to) sink their teeth into solving the actual problem, so that you can sleep at night without having to worry whether there is a new problem on the horizon.
That said, before such aforementioned work is actually done, chances are this package will not be included in the regular Fedora distribution or EPEL add-on repository.
Why does this have no chance of being included in a RedHat distribution? Is it a licensing issue or something else?
I said Fedora distribution and EPEL add-on repository, and I did not say Red Hat distribution. These are completely different. The Fedora Project will not accept it as part of it's Fedora distribution or EPEL add-on repository, and Red Hat can do as it wishes -however it is still very much unlikely they'll ship it as it is.
As to the reason this package is not / can not / will not be included; Please read the comments in this bug/review request. Long story short, Passenger ships a forked version of the C++ Boost libraries -and lags behind a dozen versions or so.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Mohammed Morsi mmorsi@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mmorsi@redhat.com
--- Comment #62 from Mohammed Morsi mmorsi@redhat.com 2010-09-13 17:33:56 EDT --- I just spent a little while going through this and trying to figure out what exactly would need to be done to get passenger working with the stock boost in Fedora. The following are issues we may run into:
Issues which shouldn't post a problem: * Additional 'defined' checks simply check for netbsd or solaris, neither of which is applicable here
* elif BOOST_PP_INTERATION_DEPTH changes, made for gcc 4.4 compatibility. Since boost is already working against gcc in Fedora, this change isn't needed (correct me if I'm wrong)
* whitespace changes in non_type.hpp, which I'm guessing shouldn't be there as nothing else is different
Issues which might pose a problem: * the vendorized boost is at version 1.35 while in Fedora 14 we are going to be at 1.44. I believe this just about summarizes the issue Fedora has with vendorized libs, and I'm not sure if the thread library between these two versions are compatible.
* the condition_varaible and mutex destructors and the condition_variable::wait method try to repeat the necessary pthread destruction code until it is successful, as opposed to attempting it once and verifying the result with BOOST_VERIFY. As of right now I'm not sure why it does this, it seems to me that if the pthread destruction call fails once, it'll fail everytime, and if this is necessary on Linux. It may not be, this change maybe only for solaris or something; some additional clarification would be great. If it is required this is going to be very hard if not impossible to remove as if assertions in boost are enabled, BOOST_VERIFY will terminate a running program (if the condition being verified is false) and there isn't much we can do about it.
* changes to the exception hierarchy and additional exception information has been added to thread_exception, thread_resource_error, and thread_interrupted, to add backtrace and system_error_code support. Unless I'm mistaken these are purely informational only (for debugging) and thus this shouldn't pose an issue (once again correct me if I'm wrong). The apache hooks may have to be modified though to remove the TRACE_POINTs (or perhaps not, still needs more exploration)
* the thread constructor and start_thread method take an optional stack size.
From my current understanding this is platform specific, and since boost is
already working on Fedora Linux x86 and x86_64 as is, this is unneeded.
That about covers it, I am going to attempt to see if I can passenger working against boost in Fedora, but might not be able to for the aforementioned reasons. If anyone knows any fault in my analysis above, or some other reason why I won't be able to, please correct me, so that I don't invest a ton of time into this. Also if I am successful, it may come at the price of a heavily modified passenger source, but we'll tackle that if/when we get to that point.
P.S. would creating a separate upstream project resolve this issue without any of this? Obviously someone would have to maintain this, but would something like a passenger-boost project work?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #63 from Hongli Lai honglilai@gmail.com 2010-09-14 04:08:55 EDT --- Passenger 3's Boost is actually based on 1.42.0. A lot of API breakages have happened between Boost 1.35 and 1.42. I believe it's impossible to support multiple Boost versions without making our code a mess with #ifdefs everywhere. We only support one specific version of Boost for the time being: the one we use during development.
The condition_variable and mutex error checks do not retry on all errors: they only retry on EINTR. BOOST_VERIFY aborts even on EINTR but EINTR is usually not fatal, it just means you need to try later. This issue bit us on one of our customers' production systems.
Exception hierarchy change: yes they're informational. If a thread fails to spawn (i.e. thread_resource_error is thrown) then we'll want to show a backtrace. This is not possible without patching Boost and changing the ABI. Please do not remove TRACE_POINTs. They're an essential part of our system inspection features. Right now it's possible to query the backtrace of all threads in Phusion Passenger during runtime thanks to the TRACE_POINTs. If you get rid of that then our users will lose their ability to see what's going on and will introduce a lot of headaches when things go wrong.
Thread constructor: it is not unnecessary, we do this intentionally to reduce the VM size. We create a lot of threads. The default thread stack size on Linux is 8 MB, so unless we reduce the stack sizes we can't create many threads and the VM size will grow very large, giving users the impression that we're memory hungry.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #64 from Mohammed Morsi mmorsi@redhat.com 2010-09-14 12:53:29 EDT --- (In reply to comment #63)
Passenger 3's Boost is actually based on 1.42.0. A lot of API breakages have happened between Boost 1.35 and 1.42. I believe it's impossible to support multiple Boost versions without making our code a mess with #ifdefs everywhere. We only support one specific version of Boost for the time being: the one we use during development.
Can you please elaborate on this. Looking at the passenger repository, it seems boost is still marked as being on version 1.35
http://github.com/FooBarWidget/passenger/blob/master/ext/boost/VERSION.TXT
and the last commit I see relating to 'updating boost' is the update to 1.35
http://github.com/FooBarWidget/passenger/commits/master/ext/boost
At what point did you update to 1.42? In any case for this submission, boost is still at 1.35 which I hope isn't so incompatible with 1.44 (shipping on F14) that it won't compile against it.
The condition_variable and mutex error checks do not retry on all errors: they only retry on EINTR. BOOST_VERIFY aborts even on EINTR but EINTR is usually not fatal, it just means you need to try later. This issue bit us on one of our customers' production systems.
This is good to know that this was to solve an edge case on a production system. Which OS was this customer running btw? If it something other than Linux (and maybe even if it's another distro) we might not run into this onto Fedora and thus this can be omitted.
Exception hierarchy change: yes they're informational. If a thread fails to spawn (i.e. thread_resource_error is thrown) then we'll want to show a backtrace. This is not possible without patching Boost and changing the ABI. Please do not remove TRACE_POINTs. They're an essential part of our system inspection features. Right now it's possible to query the backtrace of all threads in Phusion Passenger during runtime thanks to the TRACE_POINTs. If you get rid of that then our users will lose their ability to see what's going on and will introduce a lot of headaches when things go wrong.
I would like to include this (and everything else), but it looks like there is no way to include passenger in Fedora without this being removed (eg passenger needs to work against the stock boost). So its either remove this debugging stuff or not ship passenger at all. Like you said in a previous comment, if anyone wants any of these features I'm removing they can simply get passenger via gem.
Thread constructor: it is not unnecessary, we do this intentionally to reduce the VM size. We create a lot of threads. The default thread stack size on Linux is 8 MB, so unless we reduce the stack sizes we can't create many threads and the VM size will grow very large, giving users the impression that we're memory hungry.
Have you guys ever considered using thread pools? Launching many threads indiscriminately is often considered bad practice, and you may get a performance boost by making use of a pool. Regardless its good to know that this is simply to make the memory footprint smaller, and it should work without this. Just curious is there any way to reduce the default thread stack size, systemwide lets say, without modifying/recompiling every program?
I'm starting to hack at this to see if I can get it working. Based on your response the only thing that makes me not sure if this will work is the discrepancy between boost versions, but we'll just see if that poses and issue.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #65 from Hongli Lai honglilai@gmail.com 2010-09-14 13:37:24 EDT ---
Can you please elaborate on this. Looking at the passenger repository, it seems boost is still marked as being on version 1.35
Passenger 3 will be based on 1.42. Passenger 3 isn't out yet but will soon be.
Which OS was this customer running btw?
Debian. But even if it was a different OS, the checks should remain. Returning EINTR is POSIX compliant behavior I believe, so apps should take care of it properly.
I would like to include this (and everything else), but it looks like there is
no way to include passenger in Fedora without this being removed (eg passenger
needs to work against the stock boost). So its either remove this debugging
stuff or not ship passenger at all.
In that case I prefer to decline packaging. We cannot agree on having an important feature like that removed. We want every user who uses Phusion Passenger to experience the same quality, and we will find it unacceptable if quality differs among different OS packages.
Have you guys ever considered using thread pools?
Yes. Thread pools will not do. We really need all those threads, they're used for I/O concurrency so limiting them will not solve the problem.
The default stack size can be changed through ulimit. However I disagree with the notion that the default stack size should be respected. There's a reason why pthread_attr_setstacksize() exists, and we use it for a good reason.
It is certainly possible to patch Phusion Passenger to work with normal Boost. However doing so degrades the user experience in such a way that we cannot approve of such changes. Please note that Phusion Passenger is a registered trademark in the European Union and a pending trademark in the United States. If you want to ship a patched version of Phusion Passenger with changes that we do not approve of, we have to ask you to rename it something else.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
David Lutterkort lutter@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bkoz@redhat.com
--- Comment #66 from David Lutterkort lutter@redhat.com 2010-09-14 18:46:10 EDT --- I am putting Benjamin Kosnick on cc since he maintains the boost package in Fedora, and hopefully can shed some light on some of the points that seem to be shortcomings in the boost API (not being able to set stack size for threads, handling of EINTR after waiting)
Benjamin can you weigh in on the discussion starting with comment #62 ? I suspect that some of these things would be welcome enhancements to boost.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #67 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2010-09-15 02:46:16 EDT --- (In reply to comment #65)
Please note that Phusion Passenger is a registered trademark in the European Union and a pending trademark in the United States. If you want to ship a patched version of Phusion Passenger with changes that we do not approve of, we have to ask you to rename it something else.
??? Then would you clarify the license? If Phusion Passenger upstream has such policy, I guess we will anyway has to rename such software on Fedora - Note that Debian does not accept "firefox" or so due to the same reason. And there are so many discussion also on Fedora about whether we should rename "firefox" to something else.
And if we decide the license is "not free", we won't accept such software anyway.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #68 from Hongli Lai honglilai@gmail.com 2010-09-15 13:19:24 EDT --- The license is just MIT license. It has got nothing to do with any trademark rights. I find it interesting that you see this as an issue. Red Hat does the same thing: one cannot modify RHEL and call it Red Hat, which is why Fedora and CentOS are named Fedora and CentOS and not "Red Hat Community Edition" or whatever.
It is fine if you do not accept it. We will work with third party packagers instead.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #69 from Tom "spot" Callaway tcallawa@redhat.com 2010-09-15 13:40:32 EDT --- Hongli, I believe he is asking if you have a separate license for use of the "Phusion Passenger" trademark. For example, Fedora's trademark guidelines are here:
https://fedoraproject.org/wiki/Legal:Trademark_guidelines
Also, here is Mozilla's trademark policy:
http://www.mozilla.org/foundation/trademarks/policy.html
It would clarify things for us significantly if you could put into writing the terms under which use of your trademark is permitted.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #70 from Hongli Lai honglilai@gmail.com 2010-09-15 14:03:55 EDT --- I believe we have a fundamental disagreement in packaging policies. I believe it's easier for both of us if you close this issue and that we work with third party packagers instead.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #71 from Benjamin Kosnik bkoz@redhat.com 2010-09-15 14:10:28 EDT ---
In regards to #62, from my analysis of the modified boost diff, the major sticking point is the hack to boost::thread_exception.
I suggest a different error handling design. Instead of making thread_exception into what phusion passenger wants, derive
oxt::traceable_thread_exception from the un-molested boost::thread_exception and your custom tracing bits add your changes there. This will cleanly separate out the client code (phusion passenger) from the library code (boost), remove the need to deal with upstream boost, help with packaging your software by removing your need to ship a custom boost, and allow you to use C++0x threads in the future. Win, win, win. Please consider it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #72 from Hongli Lai honglilai@gmail.com 2010-09-15 14:34:23 EDT --- The point of the modification was to have Boost.Thread itself throw exceptions that are derived from thread_exception. Making a seperate tracable_thread_exception won't solve that problem. But, as I've stated earlier, there are fundamental packaging policy disagreements between us and I believe it's easier to maintain the status quo.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #73 from Jason Smith smithj4@bnl.gov 2010-09-15 16:18:54 EDT --- Wow, this is amazing how this has degenerated. Ruby has to be one of the only popular languages without a standard apache module. Do the Phusion people not see the value in getting their software packaged into a major distribution like RedHat? And getting it into Fedora would be the first step towards that happening. Do they not realize the wide acceptance and popularity they would get (at least in the US and maybe worldwide) by being bundled with a large vendor's OS out of the box? Instead they want their customers to jump through hoops to install their software.
Why do software tools have to reinvent packaging systems outside of the OS package management system anyway, like Ruby's Gems, Perl's CPAN & Python's Eggs. From a sysadmin perspective, this is horrible and should be avoided at all costs.
Anyway, since my main objective was to install a scalable puppet server, and since puppet recently released 2.6.1 which supports JRuby, I guess I will now be forced to look into that as an alternative, with tomcat.
I'm sorry I reopened this can of worms.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #74 from Mohammed Morsi mmorsi@redhat.com 2010-09-15 16:33:58 EDT --- (In reply to comment #72)
The point of the modification was to have Boost.Thread itself throw exceptions that are derived from thread_exception. Making a seperate tracable_thread_exception won't solve that problem. But, as I've stated earlier, there are fundamental packaging policy disagreements between us and I believe it's easier to maintain the status quo.
Can't you simply catch the Boost Thread exceptions, and in the error handler throw your own custom exceptions? You can interpret the thread errors in your catch blocks and add as much debugging information as you need there. I'm actually surprised that hacking boost took less time than doing it this way. I suppose if you don't know all the boost thread exceptions, you'd want the backtraces all the way though boost, but this doesn't seem like the best practice.
Also what environments are you passenger on. It may be more than Linux/g++ but if it isn't doesn't gcc have some non-standard means of obtaining backtrace information for c++ exceptions?
I think everyone loses out with the status quo. There are Linux users who _must_ use rpm / yum to install software on their systems, and using gem is not an option. Thus you lose potential users of your software and we lose another supported / tested deployment scenario. It would be great if we can all work together to find and develop and acceptable solution that works for everyone. I understand that time is very tight nowadays, but this is why we're volunteering to help come up with and develop a solution.
(btw no flamewars here please, everyone is right for their own reasons, just need to come up with the right solution)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Nathan Anderson air1npa@ups.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |air1npa@ups.com
--- Comment #75 from Nathan Anderson air1npa@ups.com 2010-11-17 15:57:03 EST --- I'm one of those users who *must* use yum/rpm to install software. Custom compiled software, be they gems, perl modules, c programs, etc, are forbidden. I'd love to see this included in Fedora, because then I could request it for the RHEL 6 EPEL repo. Are there still these two issues outstanding?
1. Vendored boost library 2. License incompatibility with scgi functions
Thanks, Nathan
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #76 from Hongli Lai honglilai@gmail.com 2010-11-17 18:13:53 EST --- Nathan, Jason: yes, the license incompatibility has been solved. As for RPM/YUM packages, we are working on setting up a third party YUM repository as we speak, and we expect packages to be available in the near future. Please keep an eye on our blog for updates.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #77 from Jeroen van Meeuwen kanarip@kanarip.com 2010-11-21 11:29:47 EST --- I'm working on getting the necessary people to understand this package needs an exception in order to get Real Life Problems fixed.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #78 from Hongli Lai honglilai@gmail.com 2011-01-04 04:56:54 EST --- We are pleased to announce third party RPMs for Phusion Passenger: http://blog.phusion.nl/2011/01/04/phusion-passenger-native-packages-for-redh...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Bernie Innocenti bernie@codewiz.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernie@codewiz.org
--- Comment #79 from Bernie Innocenti bernie@codewiz.org 2011-01-19 18:41:24 EST --- Can someone please clarify why this review is stuck?
Does the packager need to take action? Or does the reviewer need to analyze again the package after the licencing issue has been resolved?
Thanks,
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #80 from Toshio Ernie Kuratomi a.badger@gmail.com 2011-01-19 18:57:06 EST --- The package contains a bundled library and upstream is unwilling to have it unbundled and still use the passenger trademark. No one has put in a request to the FPC to grant an exception for this package to bundle libraries so that's still a possibility to resolve the bundled library issue but there doesn't seem to be any good exception material here so I'm unsure that it would pass. Another option would be to fork the code and unbundle using a non-trademarked name.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Nick Bebout nb@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nb@fedoraproject.org Blocks| |182235(FE-Legal)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |658489(FE-BUNDLEDLIBS)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #81 from cpg cpg@rocketmail.com 2011-01-19 19:22:16 EST --- Who has the technology to "put in a request to the FPC to grant an exception for this package to bundle libraries" ?
Can I do it, if so can someone explain how?
Things are getting to the point that Fedora is going down the drain ... we cannot even purchase VPS servers with Fedora on them due to the lack of long term support, fast cycles and lack of proper support for things like RoR, in most part due to this very issue with passenger. Thanks the unwise people upstream that are dragging their feet.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #82 from Jason Tibbitts tibbs@math.uh.edu 2011-01-19 19:27:28 EST --- The instructions are at http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries Please be sure you answer all of the questions presented there. It is wise to avoid hyperbole such as "Fedora is going down the drain".
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #83 from Hongli Lai honglilai@gmail.com 2011-01-20 03:12:03 EST --- cpg, we now provide third party packages so I believe it's no longer necessary for Fedora to ship Phusion Passenger. Our packages are updated very quickly against official releases too. http://blog.phusion.nl/2011/01/04/phusion-passenger-native-packages-for-redh...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #84 from Greg Swift greg_swift@aotx.uscourts.gov 2011-01-20 11:31:40 EST --- Hongli,
those of us that need this for clean RoR installations in our RH based environment will take those and suffer through, but at the end of the day I'm sure many of us would rather the packages were actually capable of being provided by Fedora/CentOS/EPEL. The points behind the No Bundled Libraries restriction are very valid, and speaking from experience I can say we've been burned over the long run by vendors with good intentions and poor follow through on staying up with changes.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #85 from Hongli Lai honglilai@gmail.com 2011-01-20 11:53:43 EST --- Greg, if you look at our reputation we have a very strong follow through of staying up with security updates. Organizations like New York Times, Wikipedia, Pixar etc don't use our stuff for no reason. On top of that, trying seeing our use of Boost in perspective. We pretty much only use the threading and smart pointer stuff. The former is a thin wrapper around the OS APIs. Neither of them are responsible for processing user or network input. I would be very surprised if they even make vulnerabilities possible, ever.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #86 from Bernie Innocenti bernie@codewiz.org 2011-01-28 15:29:28 EST --- (In reply to comment #83)
cpg, we now provide third party packages so I believe it's no longer necessary for Fedora to ship Phusion Passenger. Our packages are updated very quickly against official releases too. http://blog.phusion.nl/2011/01/04/phusion-passenger-native-packages-for-redh...
Thanks for maintaining these packages externally, but I think Fedora users would be served better if passenger were distributed along with the rest of the OS.
Maintaining a system using multiple disparate repositories is a PITA, especially with yum.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #87 from Vít Ondruch vondruch@redhat.com 2011-02-17 09:45:48 EST --- What about keep Passanger as it is and provide boost-passenger for fedora, i.e. fork of boost? It may be even just subset of boost required by passenger? Of course I expcet that this boost fork would be maintained by Phussion, since they have to do it anyway IMO.
Don't take me wrong, I know it is workarond. However forking of project is very natural in opensource, nobody will say "Oh, we cannot have LibreOffice in Fedora, because it is fork of OpenOffice.org". The same would apply for boost-passenger.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Bobby Powers bobby@laptop.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bobby@laptop.org
--- Comment #88 from Bobby Powers bobby@laptop.org 2011-03-15 13:02:13 EDT --- another reason to get it in Fedora, Hongli, is that your rpms are broken (bad signature). This was reported on your blog entry about the repos in January and still happens for me as of last week.
Well, passenger 3 is out and none of the srpm or spec files listed above, so I modified the latest srpm release to get something close to what we want I think. Since this original packaging request, it looks like the passenger available through phusion's repos also bundles a version of nginx. My changes to the spec file basically are to remove that (as a consequence, it only builds the apache plugin, not the nginx one as well). The srpm is available at http://dev.laptop.org/~bobbyp/passenger/rubygem-passenger-3.0.4-2.fc14.src.r... I'll attach the modified specfile (and a diff between the original and it) to this bug.
It still has the vendored boost, but I'm hoping we can apply to get an exemption as api and functionality has changed. The biggest problem I see is this note on [1]: 'If no attempt has been made to push the changes upstream, we shouldn't be supporting people forking out of laziness'.
And if phusion won't allow us to use passenger, we can probably rename the library to 'straphanger' or some such fairly easily.
Regards.
1 - http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #89 from Bobby Powers bobby@laptop.org 2011-03-15 13:03:04 EDT --- Created attachment 485557 --> https://bugzilla.redhat.com/attachment.cgi?id=485557 passenger 3.0 specfile without nginx support
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #90 from Bobby Powers bobby@laptop.org 2011-03-15 13:03:39 EDT --- Created attachment 485558 --> https://bugzilla.redhat.com/attachment.cgi?id=485558 diff between attached 3.0 spec and original
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #91 from Bobby Powers bobby@laptop.org 2011-03-15 13:06:35 EDT --- one last thing, there are 2 deps for passenger 3.0 that are not in Fedora (14, at least). rubygem-file-tail and rubygem-spruz. I used the versions from Phusion's repos, but these would need to be accepted into the fedora repos too
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #92 from Hongli Lai honglilai@gmail.com 2011-03-15 13:48:49 EDT --- Our Boost changes are highly Unix-specific. Phusion Passenger makes no attempt to support Windows. However Boost must support Windows. I do not want to waste my time on writing Windows support for our patches.
Furthermore we're getting rid of the file-tail (and, indirectly, spurz) dependency for the next release.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #93 from Greg Swift greg_swift@aotx.uscourts.gov 2011-04-21 16:23:22 EDT --- Is it just me or does the RPM lay down source files and expect the resulting system to compile the module? I've had this happen on 3 systems now. I would think this would not be expected behavior for an RPM.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Brett Lentz blentz@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blentz@redhat.com
--- Comment #94 from Brett Lentz blentz@redhat.com 2011-09-22 14:18:50 EDT --- Hongli -
Like many others, I'd like to see Passenger be accepted into Fedora (and EPEL). I am willing to put some time and effort into making it happen.
In comment #43, it seems that you are/were amicable to your modifications being pushed upstream. I'd be happy to take on the task of working with the Boost community to get your changes merged. So, let me ask you directly: If I can get your modifications upstream, will you be willing to drop your bundled version of Boost?
I will caveat this somewhat by saying that, after having read over your changes, the Boost folks may want to recommend some changes to your implementation. I will do my best to make sure your code gets upstreamed with as few changes as possible, but I think it's reasonable to expect that it won't be perfect.
I'd like to have you be involved in that dialogue as much as possible. I realize you're a busy person and can't really dedicate much time to something that doesn't provide you with immediate benefits. However, if you're willing to exchange a few e-mails with me through this process, it will help me work through any issues that come up that much more quickly.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #95 from Brett Lentz blentz@redhat.com 2011-09-28 13:23:56 EDT --- I have started discussion on the boost mailing list about upstreaming the two biggest portions of passenger's boost fork: the optional stack_size argument in thread::start_thread and the additional stack tracing and exception handling.
Initial response to these potential features is very positive. The thread is archived here, among other places: http://marc.info/?t=131722868200003&r=1&w=2
The patches will require some clean-up and adjustments to support Boot's requirement for cross-platform compatibility. However, I don't think that's a show stopper.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #96 from Bobby Powers bobby@laptop.org 2011-09-28 13:33:22 EDT --- very encouraging! Thanks for getting this rolling again Brett.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #97 from Hongli Lai honglilai@gmail.com 2011-09-28 14:03:16 EDT --- Hi Brett. If you can get the changes bundled in Boost then what we can do is adding an option to disable compiling against the bundled Boost, and instead compile against the system Boost. We'll still want to continue bundling Boost for the sake of platforms on which installing Boost is a hassle (e.g. OS X), but I believe adding such a compile option should solve your issue as well.
I do not mind it if the API that the Boost folks develop is slightly different than ours.
It should be noted that our backtrace support is not automatic. It relies on the user manually specifying backtrace points with TRACE_POINT() macros. It's documented here: https://github.com/FooBarWidget/passenger/blob/master/ext/oxt/backtrace.hpp The backtrace system is built in such a way that it can be integrated with oxt::thread. oxt::thread is like boost::thread but also registers each thread on a global thread list, each of which has its own thread-local backtrace list. This way, one can obtain the backtraces of all threads during runtime.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #98 from Brett Lentz blentz@redhat.com 2011-09-28 18:33:23 EDT --- Hongli - A disable option works for me. Do you need me to report a bug/feature request, or can I just look for it in an upcoming release?
Thanks for the heads-up about the macros. I know being able to opt-in is a concern for the Boost folks, so I'll make sure to highlight that.
Lastly, if you have the time to follow the conversation on the boost-list, please let me know if there are any proposals that you have any objection to or will have difficulty working with. Also, if I misrepresent your code at all, don't hesitate to ping me either here or directly at blentz@redhat.com.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #99 from Hongli Lai honglilai@gmail.com 2011-09-29 02:22:41 EDT --- You can just look for it.
Thanks for the effort.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #100 from Brett Lentz blentz@redhat.com 2011-12-01 09:12:15 EST --- I've got a couple patches that I'm pushing the Boost folks to merge. I'm still unravelling the stack trace exception patch into something workable.
Discussion on EINTR patch: http://marc.info/?t=132269010900002&r=1&w=2%5C
Discussion on configurable stack size patch: http://marc.info/?t=132266986500004&r=1&w=2
Hongli - If you have a moment to take a look at the discussion around your EINTR modifications. According to the Boost folks, POSIX specifically forbids pthreads from returning EINTR. You already mentioned that this happened on a customer's system in production, do you recall what OS it was?
It might make that particular patch a bit more palatable if we can couch it in some ifdefs, so that it's only necessary on the broken platform.
Additionally, it might allow us to file a bug with the upstream OS if the behavior still exists.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #101 from Hongli Lai honglilai@gmail.com 2011-12-01 12:39:38 EST --- If I remember correctly it was Debian. It's very important to me that lock() handles EINTR. I don't think couching it with #ifdefs is a good idea though because compiling a whitelist or blacklist is just too much work. Even in the same OS, some versions of the threading library may be broken while some versions may not, and later versions may introduce regressions. It's just easier to always check for EINTR.
While it is technically correct that returning EINTR indicates a bug in the OS, relying on the OS vendor to fix the bug is not a good practical solution. - Different vendors fix bugs at different paces. Fixing the bug can take months or years but the user wants the software to work yesterday. He does not care which party is to blame. - Some users use old versions of an OS by choice. - Some users are part of an organization whose IT department does not allow OS upgrades, for whatever reason. - Upgrading Phusion Passenger is far easier than upgrading the entire OS and is less risky.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #102 from Brett Lentz blentz@redhat.com 2011-12-01 13:50:38 EST --- Ah, it was some flavor of Linux, not OS X or some other non-Linux OS?
Among other things, I am trying to anticipate next steps if the Boost folks decide to not accept that portion of your fork. Being that it's a violation of POSIX, it's totally fair for them to say that it's not within the scope of their library to workaround a broken threading library. The "correct" fix would be to fix the threading library itself. (I don't like this possibility, but I must acknowledge that it exists.)
However, I completely agree with you about all of the implications of what a decision like that means.
For now, I'm hopeful that they'll still accept it because it makes the whole library's threading support more robust.
In the meantime, if you saw this behavior on Linux, I will look into whether this issue has already been reported and fixed in pthread. That information would be good to know, regardless.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #103 from Brett Lentz blentz@redhat.com 2011-12-02 10:35:03 EST --- Update on the stack size patch:
It looks like the Boost folks are going with a more general solution, which is detailed in this ticket: https://svn.boost.org/trac/boost/ticket/2741
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #104 from Brett Lentz blentz@redhat.com 2011-12-07 19:39:22 EST --- I'm pleased to report that Boost has accepted the EINTR patch in its entirety.
https://svn.boost.org/trac/boost/ticket/6200
This just leaves the stack trace bits as the last major portion to be upstreamed, AFAIK.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #105 from Hongli Lai honglilai@gmail.com 2011-12-08 00:25:26 EST --- Glad to hear.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #106 from Stijn Hoop stijn@sandcat.nl 2012-01-20 10:40:08 EST --- Just FYI, the stack trace bits appear to have been commited to be part of boost 1.49.0 (at least the more generic version as mentioned by Brett Lentz):
https://svn.boost.org/trac/boost/ticket/2741#comment:9
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #107 from John Florian john_florian@dart.biz 2012-01-20 11:14:47 EST --- I'm glad to hear progress is being made here on this as I'm really hoping Passenger will make my puppet server scale to bigger loads better.
Can someone here that is more familiar with all the gory details of getting Passenger into Fedora give me some kind of estimate of how close we are now? Are these recent gains that have been announced just a few of many more that will have to be gained or do they represent some of the final bits falling into place? Are we 25%, 50%, 75% or 99.8% the way there?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #108 from Brett Lentz blentz@redhat.com 2012-01-20 12:55:46 EST --- John -
I believe there are three modifications that Passenger has done to the base Boost libraries. Two of these three have been upstreamed, and we're actively working on getting the third modification ready for upstreaming.
However, one of the two upstreamed changes was addressed with a more generic patch, and will require modifications to how Passenger handles that particular detail.
I can't provide any specific estimates on when Passenger will land in Fedora. However, I can say that we're actively working on it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #109 from John Florian john_florian@dart.biz 2012-01-20 15:52:33 EST --- Brett,
Thanks for that update and I really appreciate all the hours you and others are putting in to make this happen. I'm anxious to see how it will improve things .... but not so anxious that I have a need to wander outside of yum repos to find out.
It sounds as though Boost is the big challenge ATM, although I also recall reading somewhere that there was a whole slew of other packages that would need to be brought into Fedora as well; hopefully those are all moving along well too.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
Brett Lentz brett.lentz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brett.lentz@gmail.com
--- Comment #110 from Brett Lentz brett.lentz@gmail.com 2012-04-12 19:51:56 EDT --- Okay, so...
After the Boost community has raised some valid concerns about certain portions of the changes in Passenger's fork, I've applied for a bundling exception with the FPC.
The bundling exception was GRANTED, conditional that I would be the package's maintainer. (See: https://fedorahosted.org/fpc/ticket/160 )
With that, it appears that we're finally clear to resume the package review.
I will be posting a new spec and srpm sometime in the next few days.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #111 from Hongli Lai honglilai@gmail.com 2012-04-13 02:55:18 EDT --- Good to hear that things have been solved.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #112 from Jeroen van Meeuwen kanarip@kanarip.com 2012-04-14 07:50:44 EDT --- I'll update these to the later version and the new Ruby ABI requirements for rawhide/f17 later today:
New SPEC: http://git.kolabsys.com/rpm/rubygem-passenger/plain/rubygem-passenger.spec New SRPM: http://mirror.kolabsys.com/pub/redhat/kolab-2.4/el6/development/SRPMS/rubyge...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #113 from Jeroen van Meeuwen kanarip@kanarip.com 2012-04-14 11:57:09 EDT --- Still a work in progress, and only shipping the gem and apache module.
Builds using mock for el5, el6, f16, f17 and rawhide.
New SPEC: http://kanarip.fedorapeople.org/rubygem-passenger.spec New SRPM: http://kanarip.fedorapeople.org/rubygem-passenger-3.0.12-1.fc16.src.rpm
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #114 from Brett Lentz brett.lentz@gmail.com 2012-04-14 13:11:19 EDT --- Jeroen -
Thanks for posting your specs. I'll look them over and incorporate them into my final version on Monday. I've got a few things I want to do a bit differently.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #115 from Jeroen van Meeuwen kanarip@kanarip.com 2012-04-14 15:10:22 EDT --- Now including nginx-passenger as well:
New SPEC: http://kanarip.fedorapeople.org/rubygem-passenger.spec New SRPM: http://kanarip.fedorapeople.org/rubygem-passenger-3.0.12-1.fc16.src.rpm
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #116 from Vít Ondruch vondruch@redhat.com 2012-04-16 04:37:48 EDT --- Guys,
could you please update the spec according to the new Ruby packaging guidelines, i.e. use rubygems-devel, there is no need for declaration of
gemdir geminstdir ruby_sitearch ruby_sitelib
and more over the ruby_vendorarch and ruby_vendorlib should be used instead of their "site" equivalents.
Thank you.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #117 from Hongli Lai honglilai@gmail.com 2012-04-16 04:51:19 EDT --- I submitted some bug fixes upstream which hadn't been submitted before: https://svn.boost.org/trac/boost/ticket/6796
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #118 from Brett Lentz brett.lentz@gmail.com 2012-04-16 15:16:34 EDT --- Here's the spec I've been working on, with several portions of Jeroen's spec incorporated. This should comply with the current Ruby packaging guidelines.
SRPM: http://wakko666.fedorapeople.org/rubygem-passenger/rubygem-passenger-3.0.12-... SPEC: http://wakko666.fedorapeople.org/rubygem-passenger/rubygem-passenger.spec
There's a few things in the built package that rpmlint isn't too happy about, including a few false warnings about misspellings. None of the warnings rpmlint throws appear to be critical.
I'm currently not including the nginx bits, as there doesn't appear to be any way to ship a module for nginx in the same way we ship apache modules, and shipping a statically compiled version of nginx in the passenger package isn't really acceptable.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #119 from Vít Ondruch vondruch@redhat.com 2012-04-16 15:41:03 EDT --- I have few notes again:
* rubygem-fastthread was deprecated and removed from F17. The functionality was integrated into Ruby
* I'd like to see removed the "Requires: rubygem(rake)". It is typically not required for runtime. However, I am not passenger specialist, so it might be needed at the end.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #120 from Brett Lentz brett.lentz@gmail.com 2012-04-16 17:04:36 EDT --- Updated my spec and SRPM to fix the Requires. URLs are unchanged.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #121 from Vít Ondruch vondruch@redhat.com 2012-04-17 04:44:07 EDT --- (In reply to comment #120)
Updated my spec and SRPM to fix the Requires. URLs are unchanged.
Hi Bret, the condition for fastthread should be "%if 0%{?rhel} <= 6 && 0%{?fedora} <= 16". Thank you.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=470696
--- Comment #122 from Brett Lentz brett.lentz@gmail.com 2012-04-17 08:31:23 EDT --- Updated my spec and SRPM to fix the fastthread logic. URLs are unchanged.
package-review@lists.fedoraproject.org
-
Red Hat Bugzilla