You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Rafael Schloming <rh...@alum.mit.edu> on 2012/12/20 20:02:27 UTC
0.3 RC1
Sources posted here: http://people.apache.org/~rhs/qpid-proton-0.3rc1/
Java binaries here:
https://repository.apache.org/content/repositories/orgapacheqpid-061/
Note that there are the following known issues:
- perl binding tarball has been omitted as the release script didn't work
(still installable via cmake)
- intermittent issues with java driver (java messenger tests are
currently skipped)
- java messenger connection leak
The above issues are fairly isolated, so I put out the RC anyways so they
wouldn't block testing of other areas.
--Rafael
Re: Updating versions (was: 0.3 RC1)
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Fri, Jan 04, 2013 at 03:56:54PM -0500, Rafael Schloming wrote:
> > Not difficult, no. We just have to pass it through a similar filter as
> > would be done when using autoconf. For development purposes the version
> > doesn't matter, just when we're creating those artifacts.
> >
> > So we could change release.sh to take the version number that's passed
> > in and use it, though that's duplicating what's in the root
> > CMakeLists.txt already. It just needs to be something we don't have to
> > pass into the build system for packaging, for example.
> >
>
> I think if we were to consolidate it into one place we'd pick a file in svn
> and have both release.sh and CMakeLists.txt pull it out of there and nix
> the release.sh parameter. That way the svn number encoded in the release
> will always point to a source tree that builds with the correct version.
+1 That sounds good to me.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Updating versions (was: 0.3 RC1)
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Fri, Jan 4, 2013 at 1:22 PM, Darryl L. Pierce <dp...@redhat.com> wrote:
> On Fri, Jan 04, 2013 at 11:21:07AM -0500, Rafael Schloming wrote:
> > > I pushed a patch this morning that bumped the Perl and Ruby versions.
> > > Can you please include that in RC2? Thanks.
> > >
> >
> > That will be picked up for RC2, but I really think we need one and only
> one
> > place to bump the version number for a given release. Is there a reason
> > that it is difficult to make those builds reference an external version
> > number somehow?
>
> Not difficult, no. We just have to pass it through a similar filter as
> would be done when using autoconf. For development purposes the version
> doesn't matter, just when we're creating those artifacts.
>
> So we could change release.sh to take the version number that's passed
> in and use it, though that's duplicating what's in the root
> CMakeLists.txt already. It just needs to be something we don't have to
> pass into the build system for packaging, for example.
>
I think if we were to consolidate it into one place we'd pick a file in svn
and have both release.sh and CMakeLists.txt pull it out of there and nix
the release.sh parameter. That way the svn number encoded in the release
will always point to a source tree that builds with the correct version.
--Rafael
Re: Updating versions (was: 0.3 RC1)
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Fri, Jan 04, 2013 at 11:21:07AM -0500, Rafael Schloming wrote:
> > I pushed a patch this morning that bumped the Perl and Ruby versions.
> > Can you please include that in RC2? Thanks.
> >
>
> That will be picked up for RC2, but I really think we need one and only one
> place to bump the version number for a given release. Is there a reason
> that it is difficult to make those builds reference an external version
> number somehow?
Not difficult, no. We just have to pass it through a similar filter as
would be done when using autoconf. For development purposes the version
doesn't matter, just when we're creating those artifacts.
So we could change release.sh to take the version number that's passed
in and use it, though that's duplicating what's in the root
CMakeLists.txt already. It just needs to be something we don't have to
pass into the build system for packaging, for example.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Updating versions (was: 0.3 RC1)
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Thu, Jan 3, 2013 at 7:11 AM, Darryl L. Pierce <dp...@redhat.com> wrote:
> On Wed, Jan 02, 2013 at 12:54:34PM -0500, Rafael Schloming wrote:
> > > We need to make it a part of the release process to bump the release
> > > number in the following files:
> > >
> > > proton-c/CMakeLists.txt
> > > proton-c/bindings/perl/Makefile.PL
> > > proton-c/bindings/perl/ChangeLog
> > > proton-c/bindings/ruby/lib/qpid_proton/version.rb
> > > proton-c/bindings/ruby/ChangeLog
> > >
> > > Though probably the easiest thing is, when we branch, the above files
> > > should all have their versions bumped on trunk. Right now we've got 0.2
> > > for proton-c in the 0.3 RC1 tarball, Ruby is saying 0.1 (my bad) and
> > > Perl is 0.2 (same).
> > >
> >
> > Can we make these all reference the same source? I noticed the proton-c
> was
> > off and was going to include a fix for that in RC2. It would be nice if
> the
> > other places picked up the correct version automatically.
>
> I pushed a patch this morning that bumped the Perl and Ruby versions.
> Can you please include that in RC2? Thanks.
>
That will be picked up for RC2, but I really think we need one and only one
place to bump the version number for a given release. Is there a reason
that it is difficult to make those builds reference an external version
number somehow?
--Rafael
Re: Updating versions (was: 0.3 RC1)
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Wed, Jan 02, 2013 at 12:54:34PM -0500, Rafael Schloming wrote:
> > We need to make it a part of the release process to bump the release
> > number in the following files:
> >
> > proton-c/CMakeLists.txt
> > proton-c/bindings/perl/Makefile.PL
> > proton-c/bindings/perl/ChangeLog
> > proton-c/bindings/ruby/lib/qpid_proton/version.rb
> > proton-c/bindings/ruby/ChangeLog
> >
> > Though probably the easiest thing is, when we branch, the above files
> > should all have their versions bumped on trunk. Right now we've got 0.2
> > for proton-c in the 0.3 RC1 tarball, Ruby is saying 0.1 (my bad) and
> > Perl is 0.2 (same).
> >
>
> Can we make these all reference the same source? I noticed the proton-c was
> off and was going to include a fix for that in RC2. It would be nice if the
> other places picked up the correct version automatically.
I pushed a patch this morning that bumped the Perl and Ruby versions.
Can you please include that in RC2? Thanks.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Updating versions (was: 0.3 RC1)
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Wed, Jan 2, 2013 at 11:42 AM, Darryl L. Pierce <dp...@redhat.com>wrote:
> On Thu, Dec 20, 2012 at 02:02:27PM -0500, Rafael Schloming wrote:
> > Sources posted here: http://people.apache.org/~rhs/qpid-proton-0.3rc1/
> > Java binaries here:
> > https://repository.apache.org/content/repositories/orgapacheqpid-061/
> >
> > Note that there are the following known issues:
> > - perl binding tarball has been omitted as the release script didn't
> work
> > (still installable via cmake)
> > - intermittent issues with java driver (java messenger tests are
> > currently skipped)
> > - java messenger connection leak
> >
> > The above issues are fairly isolated, so I put out the RC anyways so they
> > wouldn't block testing of other areas.
>
> We need to make it a part of the release process to bump the release
> number in the following files:
>
> proton-c/CMakeLists.txt
> proton-c/bindings/perl/Makefile.PL
> proton-c/bindings/perl/ChangeLog
> proton-c/bindings/ruby/lib/qpid_proton/version.rb
> proton-c/bindings/ruby/ChangeLog
>
> Though probably the easiest thing is, when we branch, the above files
> should all have their versions bumped on trunk. Right now we've got 0.2
> for proton-c in the 0.3 RC1 tarball, Ruby is saying 0.1 (my bad) and
> Perl is 0.2 (same).
>
Can we make these all reference the same source? I noticed the proton-c was
off and was going to include a fix for that in RC2. It would be nice if the
other places picked up the correct version automatically.
--Rafael
Updating versions (was: 0.3 RC1)
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Thu, Dec 20, 2012 at 02:02:27PM -0500, Rafael Schloming wrote:
> Sources posted here: http://people.apache.org/~rhs/qpid-proton-0.3rc1/
> Java binaries here:
> https://repository.apache.org/content/repositories/orgapacheqpid-061/
>
> Note that there are the following known issues:
> - perl binding tarball has been omitted as the release script didn't work
> (still installable via cmake)
> - intermittent issues with java driver (java messenger tests are
> currently skipped)
> - java messenger connection leak
>
> The above issues are fairly isolated, so I put out the RC anyways so they
> wouldn't block testing of other areas.
We need to make it a part of the release process to bump the release
number in the following files:
proton-c/CMakeLists.txt
proton-c/bindings/perl/Makefile.PL
proton-c/bindings/perl/ChangeLog
proton-c/bindings/ruby/lib/qpid_proton/version.rb
proton-c/bindings/ruby/ChangeLog
Though probably the easiest thing is, when we branch, the above files
should all have their versions bumped on trunk. Right now we've got 0.2
for proton-c in the 0.3 RC1 tarball, Ruby is saying 0.1 (my bad) and
Perl is 0.2 (same).
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: 0.3 RC1
Posted by Rajith Attapattu <ra...@gmail.com>.
Rafi,
If you are spinning another RC please include [1] ?
It's done to ensure we close tcp connections.
Please see [2] for details.
[1] http://svn.apache.org/viewvc?rev=1425124&view=rev
[2] https://reviews.apache.org/r/7934/diff/3/?file=236677#file236677line108
Rajith
On Fri, Dec 21, 2012 at 2:28 PM, Ken Giusti <kg...@redhat.com> wrote:
> I hit a python problem on Centos-5 - which uses python 2.4:
>
>
> [kgiusti@localhost tests]$ ./proton-test
> Traceback (most recent call last):
> File "./proton-test", line 553, in ?
> m = __import__(name, None, None, ["dummy"])
> File "/home/kgiusti/work/proton/RC3/qpid-proton-c-0.3/tests/proton_tests/__init__.py", line 20, in ?
> import proton_tests.codec
> File "/home/kgiusti/work/proton/RC3/qpid-proton-c-0.3/tests/proton_tests/codec.py", line 21, in ?
> from proton import *
> File "/home/kgiusti/work/proton/RC3/install/usr/local/lib/python2.4/site-packages/proton.py", line 857, in ?
> class Data:
> File "/home/kgiusti/work/proton/RC3/install/usr/local/lib/python2.4/site-packages/proton.py", line 1615, in Data
> put_mappings = {
> NameError: name 'bytes' is not defined
>
> The bytes type was added in 2.6
>
> -K
>
> ----- Original Message -----
>> On Fri, Dec 21, 2012 at 9:32 AM, Ken Giusti <kg...@redhat.com>
>> wrote:
>>
>> > Ok, thanks Darryl - I'll give it a try.
>> >
>> > In any case, the README file in the release candidate needs to be
>> > updated
>> > - I imagine most folks just starting out with proton want to be
>> > able to
>> > evaluate it without needing root privs.
>> >
>>
>> I'll update the README for RC2.
>>
>> FWIW, I think there are two pretty distinct scenarios for make
>> install as
>> non root. The one proton developers keep running into is doing a non
>> root
>> make install as a way to test what would have gotten installed had a
>> normal
>> make install been done. For this purpose 'make install
>> DESTDIR=test-root'
>> is a much more accurate and robust way to do this because it gives
>> you
>> sub-tree with *exactly* what would have been installed based on the
>> particular cmake configuration. Doing a cmake
>> -DCMAKE_INSTALL_PREFIX=$HOME/blah is actually testing how a non-root
>> configuration would get installed which isn't necessarily the same at
>> all.
>>
>> The second scenario is as Ken points out when a user that wants to
>> evaluate
>> proton without doing a full system install. Right now we don't really
>> cater
>> to this case as an install scenario per/se, however it is quite easy
>> to do
>> from an svn checkout via the config.sh that is in the proton root.
>> Going
>> forward (e.g. for 0.4) we could probably have make install set up
>> something
>> similar for non root installs if we want to cater to that scenario
>> more
>> directly.
>>
>> --Rafael
>>
Re: 0.3 RC1
Posted by Ken Giusti <kg...@redhat.com>.
I hit a python problem on Centos-5 - which uses python 2.4:
[kgiusti@localhost tests]$ ./proton-test
Traceback (most recent call last):
File "./proton-test", line 553, in ?
m = __import__(name, None, None, ["dummy"])
File "/home/kgiusti/work/proton/RC3/qpid-proton-c-0.3/tests/proton_tests/__init__.py", line 20, in ?
import proton_tests.codec
File "/home/kgiusti/work/proton/RC3/qpid-proton-c-0.3/tests/proton_tests/codec.py", line 21, in ?
from proton import *
File "/home/kgiusti/work/proton/RC3/install/usr/local/lib/python2.4/site-packages/proton.py", line 857, in ?
class Data:
File "/home/kgiusti/work/proton/RC3/install/usr/local/lib/python2.4/site-packages/proton.py", line 1615, in Data
put_mappings = {
NameError: name 'bytes' is not defined
The bytes type was added in 2.6
-K
----- Original Message -----
> On Fri, Dec 21, 2012 at 9:32 AM, Ken Giusti <kg...@redhat.com>
> wrote:
>
> > Ok, thanks Darryl - I'll give it a try.
> >
> > In any case, the README file in the release candidate needs to be
> > updated
> > - I imagine most folks just starting out with proton want to be
> > able to
> > evaluate it without needing root privs.
> >
>
> I'll update the README for RC2.
>
> FWIW, I think there are two pretty distinct scenarios for make
> install as
> non root. The one proton developers keep running into is doing a non
> root
> make install as a way to test what would have gotten installed had a
> normal
> make install been done. For this purpose 'make install
> DESTDIR=test-root'
> is a much more accurate and robust way to do this because it gives
> you
> sub-tree with *exactly* what would have been installed based on the
> particular cmake configuration. Doing a cmake
> -DCMAKE_INSTALL_PREFIX=$HOME/blah is actually testing how a non-root
> configuration would get installed which isn't necessarily the same at
> all.
>
> The second scenario is as Ken points out when a user that wants to
> evaluate
> proton without doing a full system install. Right now we don't really
> cater
> to this case as an install scenario per/se, however it is quite easy
> to do
> from an svn checkout via the config.sh that is in the proton root.
> Going
> forward (e.g. for 0.4) we could probably have make install set up
> something
> similar for non root installs if we want to cater to that scenario
> more
> directly.
>
> --Rafael
>
Re: 0.3 RC1
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Fri, Dec 21, 2012 at 9:32 AM, Ken Giusti <kg...@redhat.com> wrote:
> Ok, thanks Darryl - I'll give it a try.
>
> In any case, the README file in the release candidate needs to be updated
> - I imagine most folks just starting out with proton want to be able to
> evaluate it without needing root privs.
>
I'll update the README for RC2.
FWIW, I think there are two pretty distinct scenarios for make install as
non root. The one proton developers keep running into is doing a non root
make install as a way to test what would have gotten installed had a normal
make install been done. For this purpose 'make install DESTDIR=test-root'
is a much more accurate and robust way to do this because it gives you
sub-tree with *exactly* what would have been installed based on the
particular cmake configuration. Doing a cmake
-DCMAKE_INSTALL_PREFIX=$HOME/blah is actually testing how a non-root
configuration would get installed which isn't necessarily the same at all.
The second scenario is as Ken points out when a user that wants to evaluate
proton without doing a full system install. Right now we don't really cater
to this case as an install scenario per/se, however it is quite easy to do
from an svn checkout via the config.sh that is in the proton root. Going
forward (e.g. for 0.4) we could probably have make install set up something
similar for non root installs if we want to cater to that scenario more
directly.
--Rafael
Re: 0.3 RC1
Posted by Ken Giusti <kg...@redhat.com>.
Ok, thanks Darryl - I'll give it a try.
In any case, the README file in the release candidate needs to be updated - I imagine most folks just starting out with proton want to be able to evaluate it without needing root privs.
-K
----- Original Message -----
> On Thu, Dec 20, 2012 at 03:24:20PM -0500, Ken Giusti wrote:
> > make install (as per readme) fails on my Fedora 17 box when
> > installing ruby binding:
> >
> > $ cmake
> > -DCMAKE_INSTALL_PREFIX=/home/kgiusti/work/proton/RC3/install ..
> > <ok>
> > $ make all docs
> > <ok>
> > $ make install
> > [ 64%] Built target qpid-proton
> > [ 67%] Built target proton
> > <snip>
> > -- Installing:
> > /home/kgiusti/work/proton/RC3/install/lib64/python2.7/site-packages/proton.pyo
> > -- Installing:
> > /home/kgiusti/work/proton/RC3/install/lib64/python2.7/site-packages/_cproton.so
> > -- Removed runtime path from
> > "/home/kgiusti/work/proton/RC3/install/lib64/python2.7/site-packages/_cproton.so"
> > -- Installing: /usr/lib64/ruby/cproton.so
> > CMake Error at bindings/ruby/cmake_install.cmake:50 (FILE):
> > file INSTALL cannot copy file
> > "/home/kgiusti/work/proton/RC3/qpid-proton-c-0.3/build/bindings/ruby/cproton.so"
> > to "/usr/lib64/ruby/cproton.so".
> > Call Stack (most recent call first):
> > bindings/cmake_install.cmake:38 (INCLUDE)
> > cmake_install.cmake:137 (INCLUDE)
> >
> >
> > make: *** [install] Error 1
>
> You need to do the install with:
>
> make DESTDIR=$TOP_OF_INSTALL_DIR_YOU_WANT
>
> or else you have to "make install" as root since the language
> bindings
> don't use the CMAKE_INSTALL_PREFIX to modify their install location.
>
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
>
Re: 0.3 RC1
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Thu, Dec 20, 2012 at 03:24:20PM -0500, Ken Giusti wrote:
> make install (as per readme) fails on my Fedora 17 box when installing ruby binding:
>
> $ cmake -DCMAKE_INSTALL_PREFIX=/home/kgiusti/work/proton/RC3/install ..
> <ok>
> $ make all docs
> <ok>
> $ make install
> [ 64%] Built target qpid-proton
> [ 67%] Built target proton
> <snip>
> -- Installing: /home/kgiusti/work/proton/RC3/install/lib64/python2.7/site-packages/proton.pyo
> -- Installing: /home/kgiusti/work/proton/RC3/install/lib64/python2.7/site-packages/_cproton.so
> -- Removed runtime path from "/home/kgiusti/work/proton/RC3/install/lib64/python2.7/site-packages/_cproton.so"
> -- Installing: /usr/lib64/ruby/cproton.so
> CMake Error at bindings/ruby/cmake_install.cmake:50 (FILE):
> file INSTALL cannot copy file
> "/home/kgiusti/work/proton/RC3/qpid-proton-c-0.3/build/bindings/ruby/cproton.so"
> to "/usr/lib64/ruby/cproton.so".
> Call Stack (most recent call first):
> bindings/cmake_install.cmake:38 (INCLUDE)
> cmake_install.cmake:137 (INCLUDE)
>
>
> make: *** [install] Error 1
You need to do the install with:
make DESTDIR=$TOP_OF_INSTALL_DIR_YOU_WANT
or else you have to "make install" as root since the language bindings
don't use the CMAKE_INSTALL_PREFIX to modify their install location.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: 0.3 RC1
Posted by Ken Giusti <kg...@redhat.com>.
make install (as per readme) fails on my Fedora 17 box when installing ruby binding:
$ cmake -DCMAKE_INSTALL_PREFIX=/home/kgiusti/work/proton/RC3/install ..
<ok>
$ make all docs
<ok>
$ make install
[ 64%] Built target qpid-proton
[ 67%] Built target proton
<snip>
-- Installing: /home/kgiusti/work/proton/RC3/install/lib64/python2.7/site-packages/proton.pyo
-- Installing: /home/kgiusti/work/proton/RC3/install/lib64/python2.7/site-packages/_cproton.so
-- Removed runtime path from "/home/kgiusti/work/proton/RC3/install/lib64/python2.7/site-packages/_cproton.so"
-- Installing: /usr/lib64/ruby/cproton.so
CMake Error at bindings/ruby/cmake_install.cmake:50 (FILE):
file INSTALL cannot copy file
"/home/kgiusti/work/proton/RC3/qpid-proton-c-0.3/build/bindings/ruby/cproton.so"
to "/usr/lib64/ruby/cproton.so".
Call Stack (most recent call first):
bindings/cmake_install.cmake:38 (INCLUDE)
cmake_install.cmake:137 (INCLUDE)
make: *** [install] Error 1
-K
----- Original Message -----
> Sources posted here:
> http://people.apache.org/~rhs/qpid-proton-0.3rc1/
> Java binaries here:
> https://repository.apache.org/content/repositories/orgapacheqpid-061/
>
> Note that there are the following known issues:
> - perl binding tarball has been omitted as the release script
> didn't work
> (still installable via cmake)
> - intermittent issues with java driver (java messenger tests are
> currently skipped)
> - java messenger connection leak
>
> The above issues are fairly isolated, so I put out the RC anyways so
> they
> wouldn't block testing of other areas.
>
> --Rafael
>