Re: can't build QPID cpp RPM under CentOS 6.4 64-bit
On Fri, 2013-11-01 at 14:42 -0400, Sam Jones wrote: > I've been unsuccessful in building an RPM for the 0.24 branch of QPID under > CentOS 6.4 64-bit. My version of cmake is 2.6.4. As Darryl implied further down the thread for Fedora and Red Hat Enterprise Linux we use a manually created rpm specfile, you would liekly have success if you pull the specfile from Fedora and build it for CentOS. Andrew - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: QPID does not compile on mac
On Tue, 2013-11-05 at 00:55 +0400, Dmitry Dneprov wrote: > Hi All ! > > I'm new to this list. > Hi there. > QPID does not compile on mac. > Are there plans to support QPID on OS X platform ? It sounds like you have tried to compile it - If you could provide some cmake or build output then we may be able to help you progress this. Qpid does build (or did build at least) under FreeBSD so it should be able to build under Darwin (the underlying OSX BSD unix like environment). Andrew - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: QPID does not compile on mac
Hi Dmitry, > Hi All ! > > I'm new to this list. Welcome! > QPID does not compile on mac. Correct. > Are there plans to support QPID on OS X platform ? I'm not immediately aware of any in-progress effort to support Qpid on OS X. If you would like to do the work to get Qpid running on OS X, that would be great. I encourage you to post any questions here, and any patches to a JIRA that you could open to track needed changes. If you find yourself in a position of desiring outside help to get Qpid running on OS X, I'd be pleased to discuss this with you. Please contact me any time. -- Steve Huston, Riverace Corporation Total Lifecycle Support for Your Networked Applications http://www.riverace.com - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
QPID does not compile on mac
Hi All ! I'm new to this list. QPID does not compile on mac. Are there plans to support QPID on OS X platform ? Regards, Dmitry - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Proton dependency on old(ish) bouncycastle version
Hey all, A couple of weeks ago when I first started playing with proton I got an issue in the early stages of running cmake. Locations of Bouncycastle 1.47 jars: BOUNCYCASTLE_BCPROV_JAR-NOTFOUND BOUNCYCASTLE_BCPKIX_JAR-NOTFOUND This was a little harder than you'd think to sort out 'cause bouncycastle is now at version 1.49 and there's no obvious link off their webpage (the ftp link that allegedly points to past releases appears to be broken). Is it worth updating the dependency to the latest bouncycastle - or alternatively bundling the jars with proton? I dug around on t'Interweb and /eventually/ found the 1.47 jars, but as I say it was harder than it should be :-) here are the links I came across: http://grepcode.com/snapshot/repo1.maven.org/maven2/org.bouncycastle/bcprov-jdk15on/1.47 http://grepcode.com/snapshot/repo1.maven.org/maven2/org.bouncycastle/bcpkix-jdk15on/1.47 The official site http://www.bouncycastle.org/latest_releases.html doesn't *seem* to have links to older versions as far as I can see. Once I got it working for myself I mentally parked it, but a colleague asked me about it this morning which prompted me to post this, is it worth updating to the latest version (or at least putting the above links in the comments). It wouldn't normally be an issue except that the required version seems to live in a slightly non-obvious place. Frase
Re: can't build QPID cpp RPM under CentOS 6.4 64-bit
On Mon, Nov 04, 2013 at 01:37:34PM -0500, Alan Conway wrote: > Just tried this myself on fedroa 18. My first attempt failed because > I had some root-owned files hanging around from a previous "sudo > make install". I built in a clean directory and it worked :) > > The generated RPM didn't install: > liblinearstoreutils.so()(64bit) is needed by qpid-cpp-0.25-1.x86_64 > which I tracked down to a missing install command linearstore.cmake. > > I added the install command (just checked in on trunk) and now I get > a little further but still not installing: > > sudo rpm -iv qpid-cpp-0.25-Linux.rpm > Preparing packages... > file /usr from install of qpid-cpp-0.25-1.x86_64 conflicts with > file from package filesystem-3.1-2.fc18.x86_64 > file /usr/lib from install of qpid-cpp-0.25-1.x86_64 conflicts with > file from package filesystem-3.1-2.fc18.x86_64 > file /usr/local from install of qpid-cpp-0.25-1.x86_64 conflicts > with file from package filesystem-3.1-2.fc18.x86_64 > file /usr/local/bin from install of qpid-cpp-0.25-1.x86_64 > conflicts with file from package filesystem-3.1-2.fc18.x86_64 > file /usr/local/etc from install of qpid-cpp-0.25-1.x86_64 > conflicts with file from package filesystem-3.1-2.fc18.x86_64 > file /usr/local/include from install of qpid-cpp-0.25-1.x86_64 > conflicts with file from package filesystem-3.1-2.fc18.x86_64 > file /usr/local/lib64 from install of qpid-cpp-0.25-1.x86_64 > conflicts with file from package filesystem-3.1-2.fc18.x86_64 > file /usr/local/libexec from install of qpid-cpp-0.25-1.x86_64 > conflicts with file from package filesystem-3.1-2.fc18.x86_64 > file /usr/local/sbin from install of qpid-cpp-0.25-1.x86_64 > conflicts with file from package filesystem-3.1-2.fc18.x86_64 > file /usr/local/share from install of qpid-cpp-0.25-1.x86_64 > conflicts with file from package filesystem-3.1-2.fc18.x86_64 > file /usr/local/share/man from install of qpid-cpp-0.25-1.x86_64 > conflicts with file from package filesystem-3.1-2.fc18.x86_64 > file /usr/local/share/man/man1 from install of > qpid-cpp-0.25-1.x86_64 conflicts with file from package > filesystem-3.1-2.fc18.x86_64 > file /usr/lib/python2.7 from install of qpid-cpp-0.25-1.x86_64 > conflicts with file from package python-libs-2.7.3-13.fc18.x86_64 > file /usr/lib/python2.7/site-packages from install of > qpid-cpp-0.25-1.x86_64 conflicts with file from package > python-libs-2.7.3-13.fc18.x86_64 > > which looks like the RPM is trying to create directories that > already exists, but I'm not sure whats up here. I'd really like to > get this to work because it is WAAAY faster than using rpmbuild > and it generates the spec file for you :) It looks like it's trying to install into live directories rather than into a chroot'd environment. What would be the advantage of having CMake create an RPM as opposed to using rpmbuild with a specfile to create the RPMs? -- 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/ pgpQ_VrK_yhyb.pgp Description: PGP signature
Re: QMF based tools do not display the authenticated identity of AMQP 0.10 users
Thanks Gordon (as usually)
Regards
Jakub
On Mon, Nov 4, 2013 at 7:39 PM, Gordon Sim wrote:
> On 11/04/2013 06:10 PM, Gordon Sim wrote:
>
>> On 11/04/2013 05:58 PM, Jakub Scholz wrote:
>>
>>> Hi,
>>>
>>> While playing with the latest trunk release of the C++ broker, I noticed
>>> that none of the QMF based tools (qpid-config, qpid-tool, qpid-stat)
>>> displays the username under which the AMQP 0.10 connection has been
>>> authenticated. This seems to apply to both PLAIN and EXTERNAL
>>> authentication.
>>>
>>> Object of type:
>>> org.apache.qpid.broker:connection:_data(6704caf8-
>>> 330d-7817-af91-bd463dd37e08)
>>>
>>> Attribute 133
>>>
>>>
>>>
>>>
>>> ==
>>>
>>> vhostRef 165
>>> addressqpid.127.0.0.1:2-127.0.0.1:54688
>>> incoming True
>>> SystemConnection False
>>> userProxyAuth False
>>> federationLink False
>>> authIdentity
>>> remoteProcessName qpid-tool
>>> remotePid 5148
>>> remoteParentPid5133
>>> shadow False
>>> saslMechanism PLAIN
>>> saslSsf0
>>> remoteProperties {u'product': u'qpid python client',
>>> u'qpid.client_ppid': 5133, u'qpid.client_process': u'qpid-tool',
>>> u'platform': u'posix', u'qpid.client_pid': 5148, u'version':
>>> u'development'}
>>> protocol AMQP 0-10
>>> closingFalse
>>> framesFromClient 2755
>>> framesToClient 7749
>>> bytesFromClient83850
>>> bytesToClient 3161804
>>> msgsFromClient 56
>>> msgsToClient 2551
>>>
>>> For AMQP 1.0, everything seems to be fine.
>>>
>>> Can someone confirm this problem? If yes, I can raise a JIRA for it.
>>>
>>
>> Yes, that seems to be a regression that somehow crept in from 0.22
>> onwards.
>>
>
> Looks like it was inadvertently removed along with the raising of
> connection events: http://svn.apache.org/viewvc?
> view=revision&revision=1424125.
>
> I've raised a JIRA: https://issues.apache.org/jira/browse/QPID-5292.
> Thanks for spotting this Jakub!
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
Re: QMF based tools do not display the authenticated identity of AMQP 0.10 users
On 11/04/2013 06:10 PM, Gordon Sim wrote:
On 11/04/2013 05:58 PM, Jakub Scholz wrote:
Hi,
While playing with the latest trunk release of the C++ broker, I noticed
that none of the QMF based tools (qpid-config, qpid-tool, qpid-stat)
displays the username under which the AMQP 0.10 connection has been
authenticated. This seems to apply to both PLAIN and EXTERNAL
authentication.
Object of type:
org.apache.qpid.broker:connection:_data(6704caf8-330d-7817-af91-bd463dd37e08)
Attribute 133
==
vhostRef 165
addressqpid.127.0.0.1:2-127.0.0.1:54688
incoming True
SystemConnection False
userProxyAuth False
federationLink False
authIdentity
remoteProcessName qpid-tool
remotePid 5148
remoteParentPid5133
shadow False
saslMechanism PLAIN
saslSsf0
remoteProperties {u'product': u'qpid python client',
u'qpid.client_ppid': 5133, u'qpid.client_process': u'qpid-tool',
u'platform': u'posix', u'qpid.client_pid': 5148, u'version':
u'development'}
protocol AMQP 0-10
closingFalse
framesFromClient 2755
framesToClient 7749
bytesFromClient83850
bytesToClient 3161804
msgsFromClient 56
msgsToClient 2551
For AMQP 1.0, everything seems to be fine.
Can someone confirm this problem? If yes, I can raise a JIRA for it.
Yes, that seems to be a regression that somehow crept in from 0.22 onwards.
Looks like it was inadvertently removed along with the raising of
connection events:
http://svn.apache.org/viewvc?view=revision&revision=1424125.
I've raised a JIRA: https://issues.apache.org/jira/browse/QPID-5292.
Thanks for spotting this Jakub!
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: can't build QPID cpp RPM under CentOS 6.4 64-bit
On 11/04/2013 06:15 AM, Gordon Sim wrote: On 11/01/2013 06:42 PM, Sam Jones wrote: I've been unsuccessful in building an RPM for the 0.24 branch of QPID under CentOS 6.4 64-bit. My version of cmake is 2.6.4. Steps: svn checkout http://svn.apache.org/repos/asf/qpid/branches/0.24/qpid qpid cd qpid/cpp mkdir BLD cd BLD cmake -D CMAKE_INSTALL_PREFIX:PATH=/usr -D CPACK_BINARY_RPM:BOOL=ON .. make package It seems to build fine, but it doesn't create the RPM. My final output is as follows: I didn't even know that cmake would automatically build rpms, I've never tried that and its quite possible no-one else has so maybe something is missing in the build files... ... [ 99%] Built target request-response_server [ 99%] Built target tradedemo_declare_queues [ 99%] Built target tradedemo_topic_listener [100%] Built target tradedemo_topic_publisher Run CPack packaging tool... CPack: Create package using RPM CPack: Install projects CPack: - Run preinstall target for: qpid-cpp CPack: - Install project: qpid-cpp CPack: Compress package CPack: Finalize package CPack Error: Problem copying the package: /home/sjones/qpid/cpp/BLD/_CPack_Packages/Linux/RPM/qpid-cpp-0.24-Linux.rpm to /home/sjones/qpid/cpp/BLD/qpid-cpp-0.24-Linux.rpm CPack Error: Error when generating package: qpid-cpp make: *** [package] Error 1 Any ideas? I assume the problem in 'copying' is that /home/sjones/qpid/cpp/BLD/_CPack_Packages/Linux/RPM/qpid-cpp-0.24-Linux.rpm doesn't actually exist? Are there any build logs in that directory with more detail/clues? Just tried this myself on fedroa 18. My first attempt failed because I had some root-owned files hanging around from a previous "sudo make install". I built in a clean directory and it worked :) The generated RPM didn't install: liblinearstoreutils.so()(64bit) is needed by qpid-cpp-0.25-1.x86_64 which I tracked down to a missing install command linearstore.cmake. I added the install command (just checked in on trunk) and now I get a little further but still not installing: sudo rpm -iv qpid-cpp-0.25-Linux.rpm Preparing packages... file /usr from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/lib from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/local from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/local/bin from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/local/etc from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/local/include from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/local/lib64 from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/local/libexec from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/local/sbin from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/local/share from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/local/share/man from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/local/share/man/man1 from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64 file /usr/lib/python2.7 from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package python-libs-2.7.3-13.fc18.x86_64 file /usr/lib/python2.7/site-packages from install of qpid-cpp-0.25-1.x86_64 conflicts with file from package python-libs-2.7.3-13.fc18.x86_64 which looks like the RPM is trying to create directories that already exists, but I'm not sure whats up here. I'd really like to get this to work because it is WAAAY faster than using rpmbuild and it generates the spec file for you :) Cheers, Alan. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: QMF based tools do not display the authenticated identity of AMQP 0.10 users
On 11/04/2013 05:58 PM, Jakub Scholz wrote:
Hi,
While playing with the latest trunk release of the C++ broker, I noticed
that none of the QMF based tools (qpid-config, qpid-tool, qpid-stat)
displays the username under which the AMQP 0.10 connection has been
authenticated. This seems to apply to both PLAIN and EXTERNAL
authentication.
Object of type:
org.apache.qpid.broker:connection:_data(6704caf8-330d-7817-af91-bd463dd37e08)
Attribute 133
==
vhostRef 165
addressqpid.127.0.0.1:2-127.0.0.1:54688
incoming True
SystemConnection False
userProxyAuth False
federationLink False
authIdentity
remoteProcessName qpid-tool
remotePid 5148
remoteParentPid5133
shadow False
saslMechanism PLAIN
saslSsf0
remoteProperties {u'product': u'qpid python client',
u'qpid.client_ppid': 5133, u'qpid.client_process': u'qpid-tool',
u'platform': u'posix', u'qpid.client_pid': 5148, u'version': u'development'}
protocol AMQP 0-10
closingFalse
framesFromClient 2755
framesToClient 7749
bytesFromClient83850
bytesToClient 3161804
msgsFromClient 56
msgsToClient 2551
For AMQP 1.0, everything seems to be fine.
Can someone confirm this problem? If yes, I can raise a JIRA for it.
Yes, that seems to be a regression that somehow crept in from 0.22 onwards.
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
QMF based tools do not display the authenticated identity of AMQP 0.10 users
Hi,
While playing with the latest trunk release of the C++ broker, I noticed
that none of the QMF based tools (qpid-config, qpid-tool, qpid-stat)
displays the username under which the AMQP 0.10 connection has been
authenticated. This seems to apply to both PLAIN and EXTERNAL
authentication.
Object of type:
org.apache.qpid.broker:connection:_data(6704caf8-330d-7817-af91-bd463dd37e08)
Attribute 133
==
vhostRef 165
addressqpid.127.0.0.1:2-127.0.0.1:54688
incoming True
SystemConnection False
userProxyAuth False
federationLink False
authIdentity
remoteProcessName qpid-tool
remotePid 5148
remoteParentPid5133
shadow False
saslMechanism PLAIN
saslSsf0
remoteProperties {u'product': u'qpid python client',
u'qpid.client_ppid': 5133, u'qpid.client_process': u'qpid-tool',
u'platform': u'posix', u'qpid.client_pid': 5148, u'version': u'development'}
protocol AMQP 0-10
closingFalse
framesFromClient 2755
framesToClient 7749
bytesFromClient83850
bytesToClient 3161804
msgsFromClient 56
msgsToClient 2551
For AMQP 1.0, everything seems to be fine.
Can someone confirm this problem? If yes, I can raise a JIRA for it.
Thanks & Regards
Jakub
Re: Suggested for 0.26: merging qpidt into qpid-config
On 11/01/2013 09:03 AM, Gordon Sim wrote: On 10/30/2013 12:30 PM, Gordon Sim wrote: I have finally overcome my fear and loathing of modifying qpid-config[1] and have added the capability to create, delete or list arbitrary broker objects. All the original options and uses remain unchanged. However now you can specify any type in conjunction with the 'add' and 'del' action and with the new 'list' action. This would make qpidt redundant and would provide a more convenient way of managing some of the new 1.0 related broker objects that have been added (domains, incoming and outgoing links, topics and soon queue- and topic- policies). For those interested there is a patch available for review and comment at: https://reviews.apache.org/r/15083/. I've updated this patch thanks to the excellent feedback received. The list action now has better formatting for results and allows the attributes to be shown to be selected by the user via a new --show-property option. There are further enhancements and tweaks that could be made and more feedback is certainly always welcome. However I would also like to suggest that we get this committed for the 0.26 release as an already much better alternative to the qpidt test utility. I would also probably remove the qpidt utility itself unless that would cause difficulty for anyone? Big +1 from me. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: qpid::messaging mocking Connection etc.
On 10/31/2013 02:06 PM, Fraser Adams wrote: Hi all, A colleague of mine is writing some client code and he wants to do the right thing by putting together unit tests around his client. He asked me about mocking Connection and to be honest I couldn't give him a good answer. I took a look at the qpid::messaging code and noticed the ProtocolRegistry code and my guess is that it would probably be possible to write mock classes and use this mechanism to register factories for them and have qpid::messaging::Connection use that as a concrete class - from quickly looking at the code this seems to be the way that the AMQP 0.10 and AMQP 1.0 concrete implementations are selected, so that all seems plausible. Unfortunately however my colleague is stuck on Qpid 0.18 and I'd guess that the ProtocolRegistry code is a lot more recent, probably put in to support AMQP 1.0, so probably Qpid 0.20 at the earliest. So my question really is: has anyone looked at doing pure unit tests of qpid client code and if so what approach have they taken to mocking out implementation code - I'm particularly interested in 0.18, but I guess if anyone has thought about it for more up to date releases that'd still be useful. There aren't any "pure" unit tests in the C++ qpid test suite for the messaging API. Instead the "unit" tests use the BrokerFixture, which can start a broker in the unit test process, rather than as a separate qpidd process. Have a look at qpid/cpp/src/tests: BrokerFixture.h, MessagingFixture.h and MessagingSessionTest.cpp if you're interested in that approach. Cheers, Alan. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: can't build QPID cpp RPM under CentOS 6.4 64-bit
> Date: Mon, 4 Nov 2013 11:15:55 + > From: g...@redhat.com > To: users@qpid.apache.org > Subject: Re: can't build QPID cpp RPM under CentOS 6.4 64-bit > > On 11/01/2013 06:42 PM, Sam Jones wrote: > > I've been unsuccessful in building an RPM for the 0.24 branch of QPID under > > CentOS 6.4 64-bit. My version of cmake is 2.6.4. > > > > Steps: > > > > svn checkout http://svn.apache.org/repos/asf/qpid/branches/0.24/qpid qpid > > cd qpid/cpp > > mkdir BLD > > cd BLD > > cmake -D CMAKE_INSTALL_PREFIX:PATH=/usr -D CPACK_BINARY_RPM:BOOL=ON .. > > make package > > > > It seems to build fine, but it doesn't create the RPM. My final output is > > as follows: > > I didn't even know that cmake would automatically build rpms, I've never > tried that and its quite possible no-one else has so maybe something is > missing in the build files... > > > ... > > [ 99%] Built target request-response_server > > [ 99%] Built target tradedemo_declare_queues > > [ 99%] Built target tradedemo_topic_listener > > [100%] Built target tradedemo_topic_publisher > > Run CPack packaging tool... > > CPack: Create package using RPM > > CPack: Install projects > > CPack: - Run preinstall target for: qpid-cpp > > CPack: - Install project: qpid-cpp > > CPack: Compress package > > CPack: Finalize package > > CPack Error: Problem copying the package: > > /home/sjones/qpid/cpp/BLD/_CPack_Packages/Linux/RPM/qpid-cpp-0.24-Linux.rpm > > to /home/sjones/qpid/cpp/BLD/qpid-cpp-0.24-Linux.rpm > > CPack Error: Error when generating package: qpid-cpp > > make: *** [package] Error 1 > > > > Any ideas? > > I assume the problem in 'copying' is that > /home/sjones/qpid/cpp/BLD/_CPack_Packages/Linux/RPM/qpid-cpp-0.24-Linux.rpm > doesn't actually exist? Are there any build logs in that directory with > more detail/clues? > > Yes, the RPM does not exist because it failed to build. Below is the directory listing and the output of rpmbuild.err: [sjones@qpid-builder RPM]$ pwd /home/sjones/qpid/cpp/BLD/_CPack_Packages/Linux/RPM [sjones@qpid-builder RPM]$ ls BUILD qpid-cpp-0.24-Linux rpmbuild.err rpmbuild.out RPMS SOURCES SPECS SRPMS tmp [sjones@qpid-builder RPM]$ cat rpmbuild.err + umask 022 + cd /home/sjones/qpid/cpp/BLD/_CPack_Packages/Linux/RPM/BUILD + LANG=C + export LANG + unset DISPLAY + LANG=C + export LANG + unset DISPLAY + exit 0 + umask 022 + cd /home/sjones/qpid/cpp/BLD/_CPack_Packages/Linux/RPM/BUILD + '[' /home/sjones/rpmbuild/BUILDROOT/qpid-cpp-0.24-1.x86_64 '!=' / ']' + rm -rf /home/sjones/rpmbuild/BUILDROOT/qpid-cpp-0.24-1.x86_64 ++ dirname /home/sjones/rpmbuild/BUILDROOT/qpid-cpp-0.24-1.x86_64 + mkdir -p /home/sjones/rpmbuild/BUILDROOT + mkdir /home/sjones/rpmbuild/BUILDROOT/qpid-cpp-0.24-1.x86_64 + LANG=C + export LANG + unset DISPLAY + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip /usr/bin/strip + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump + /usr/lib/rpm/brp-python-bytecompile + /usr/lib/rpm/redhat/brp-python-hardlink + /usr/lib/rpm/redhat/brp-java-repack-jars error: File not found by glob: /home/sjones/rpmbuild/BUILDROOT/qpid-cpp-0.24-1.x86_64/* File not found by glob: /home/sjones/rpmbuild/BUILDROOT/qpid-cpp-0.24-1.x86_64/*
Re: can't build QPID cpp RPM under CentOS 6.4 64-bit
On 11/01/2013 06:42 PM, Sam Jones wrote: I've been unsuccessful in building an RPM for the 0.24 branch of QPID under CentOS 6.4 64-bit. My version of cmake is 2.6.4. Steps: svn checkout http://svn.apache.org/repos/asf/qpid/branches/0.24/qpid qpid cd qpid/cpp mkdir BLD cd BLD cmake -D CMAKE_INSTALL_PREFIX:PATH=/usr -D CPACK_BINARY_RPM:BOOL=ON .. make package It seems to build fine, but it doesn't create the RPM. My final output is as follows: I didn't even know that cmake would automatically build rpms, I've never tried that and its quite possible no-one else has so maybe something is missing in the build files... ... [ 99%] Built target request-response_server [ 99%] Built target tradedemo_declare_queues [ 99%] Built target tradedemo_topic_listener [100%] Built target tradedemo_topic_publisher Run CPack packaging tool... CPack: Create package using RPM CPack: Install projects CPack: - Run preinstall target for: qpid-cpp CPack: - Install project: qpid-cpp CPack: Compress package CPack: Finalize package CPack Error: Problem copying the package: /home/sjones/qpid/cpp/BLD/_CPack_Packages/Linux/RPM/qpid-cpp-0.24-Linux.rpm to /home/sjones/qpid/cpp/BLD/qpid-cpp-0.24-Linux.rpm CPack Error: Error when generating package: qpid-cpp make: *** [package] Error 1 Any ideas? I assume the problem in 'copying' is that /home/sjones/qpid/cpp/BLD/_CPack_Packages/Linux/RPM/qpid-cpp-0.24-Linux.rpm doesn't actually exist? Are there any build logs in that directory with more detail/clues? - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Confluence wiki html export broken [WAS: IMPORTANT: Major Confluence Upgrade Coming Soon. Please review test instance now.]
On 11/04/2013 10:21 AM, Robbie Gemmell wrote: Took a little longer than hoped, but as per https://issues.apache.org/jira/browse/INFRA-6573 anyone visiting http://cwiki.apache.org/qpid/* will now be redirected to the following page on the actual Confluence instance, detailing why they ended up there and what they can do about it, rather than getting either a 404 or a stale page from the broken export. https://cwiki.apache.org/confluence/display/QPID/Wiki+Restructure Thanks, Robbie, thats much more useful! - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: qpid c++ broker deletes non exclusive queue when sessions are open
On 11/03/2013 10:06 PM, boden wrote:
On 11/3/2013 5:02 AM, boden wrote:
Sorry for resend; my previous email got marked as a response to a
different thread...
I'm running into an issue with the qpid C++ broker (version 0.22)
related to a non-exclusive exchange queue getting deleted when sessions
are still active.
Scenario:
- Open 2 connections/sessions to a single non-exclusive exchange. The
node is set to auto-delete, and link is not.
- Close connection 1.
- The close of connection 1 deletes the exchange queue, even though a
connection/session is still open to it (connection 2).
It was my understanding that the exchange queue would not get deleted
until the last session/connection disconnected, but it appears it gets
deleted on the 1st disconnect.
Is this proper behavior?
Sample program to repo:
from qpid.messaging import *
import time
conn = Connection("qpidclient/mypasswd@localhost:5672")
conn2 = Connection("qpidclient/mypasswd@localhost:5672")
try:
conn.open()
conn2.open()
session = conn.session()
session2 = conn2.session()
rev = session.receiver('nova/test ; {"node": {"x-declare":
{"auto-delete": true, "durable": true}, "type": "topic"}, "create":
"always", "link": {"x-declare": {"auto-delete": false, "exclusive":
false, "durable": false}, "durable": true, "name": "test"}}')
rev2 = session2.receiver('nova/test ; {"node": {"x-declare":
{"auto-delete": true, "durable": true}, "type": "topic"}, "create":
"always", "link": {"x-declare": {"auto-delete": false, "exclusive":
false, "durable": false}, "durable": true, "name": "test"}}')
print("sleeping...")
time.sleep(20)
print("closing conn 1")
conn.close()
time.sleep(30)
except MessagingError,m:
print str(m)
print("closing conn2")
conn2.close()
If you run the above on the version 0.22 c++ broker you'll get:
sleeping...
closing conn 1
closing conn2
Traceback (most recent call last):
File "./qpidc.py", line 26, in
conn2.close()
File "", line 6, in close
File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
line 321, in close
ssn.close(timeout=timeout)
File "", line 6, in close
File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
line 747, in close
link.close(timeout=timeout)
File "", line 6, in close
File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
line 1055, in close
if not self.session._ewait(lambda: self.closed, timeout=timeout):
File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
line 572, in _ewait
self.check_error()
File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
line 561, in check_error
raise self.error
qpid.messaging.exceptions.NotFound: not-found: Delete failed. No such
queue: test
(/opt/build/jenkins/workspace/rpmbuild-qpid-cpp-0.22-x86_64/rpmbuild/BUILD/qpid-0.22/cpp/src/qpid/broker/Broker.cpp:1184)(404)
Any feedback is appreciated.
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
It appears this might be my issue:
https://issues.apache.org/jira/browse/QPID-4903?jql=project%20in%20(QPID%2C%20PROTON)%20and%20text%20~%20'delete'%20order%20by%20updatedDate%20desc
if I'm reading properly, it looks like a small patch.. I will
investigate manually patching the diff on qpid 0.22 python client
Yes, that does look to be the issue. One other point is that at present
qpidd does not support the autodelete property on exchanges, so the
autodelete in the node properties is essentially ignored in your example.
(I'm going to look into implementing something there shortly).
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: Confluence wiki html export broken [WAS: IMPORTANT: Major Confluence Upgrade Coming Soon. Please review test instance now.]
Took a little longer than hoped, but as per https://issues.apache.org/jira/browse/INFRA-6573 anyone visiting http://cwiki.apache.org/qpid/* will now be redirected to the following page on the actual Confluence instance, detailing why they ended up there and what they can do about it, rather than getting either a 404 or a stale page from the broken export. https://cwiki.apache.org/confluence/display/QPID/Wiki+Restructure Robbie On 26 June 2013 16:13, Robbie Gemmell wrote: > Keith spotted earlier that any links to the wiki export no longer seem to > work, with links 404'ing other than the index page itself at > https://cwiki.apache.org/qpid/ > > The original email below would seem related, as the autoexport plugin used > to do the export is no longer going to be supported following a Confluence > upgrade and will not be coming back. Following some of the links in the > mail (e.g on the JIRA) suggest there are some manual alternatives such as a > maven based build project to do the equivalent of the export plugin. > > All that said, going to our actual Confluence instance just now says that > the major upgrade has actually *not* occurred yet as indicated in the mail, > with a banner instead saying "Upgraded to 3.5.17. Upgrade to 5.1 delayed." > Either way, our html export seems to be screwed currently. > > What would we like to do about this? > > I have said previously in the website threads that I would actually quite > like to get rid of the HTML export and move any remaining user > documentation of real use to the main documentation/website, deleting most > of what is on the wiki, and subsequently using the actual wiki (rather than > an export) for only the things that it is best suited to going forward. > > As such, I think my choice would just be to get > https://cwiki.apache.org/qpid/ redirected to the actual Confluence wiki > at https://cwiki.apache.org/confluence/display/qpid just now and then > start down the path of clearing most of the existing rubbish out. > > Robbie > > -- Forwarded message -- > From: gmcdonald > Date: 18 June 2013 12:56 > Subject: IMPORTANT: Major Confluence Upgrade Coming Soon. Please review > test instance now. > To: p...@apache.org, gene...@incubator.apache.org > > > [PMCs please forward to your dev list ; Incubator Mentors please forward to > your Podling dev list. > Note that this message may be received twice as it will also go to > committers@ list.] > > > Hi All, > > If your project has a Confluence Wiki then this is an IMPORTANT > announcement > for you and your project. Please read this email carefully. > > NOTICE: The ASF Confluence instance is planned to be upgraded this Saturday > 22nd June 2013. Judging by the time taken to upgrade the test instance, > please expect the service to be in a down or read only state for the entire > day. > > This email is to let you know that a test upgrade has already occurred and > is live for you to play with now. This gives us all an opportunity to test > for stability as well as any upgrade/plugin issues that might have happened > along the way. > > Our current confluence wiki is at version 3.4.9 from way back in February > 2011 and Atlassian have released a further 45 updates along the way, > including another 2 major versions. > The test instance has been upgraded several times along the way, with > database surgery, operating system and server changes along the way. > > There have been casualties. Most notably is the Autoexport Plugin has had > to > be disabled permanently as during extensive testing, this plugin stopped > working on version 4.3. Templates and Macros are also affected with major > changes from wiki markup to xhtml amongst other things. Some plugins > survived with upgrades all the way whilst some have been > decommissioned/replaced or have changed to 'paid for' versions that we need > to sort out licensing for. Nothing major that I can tell, but that's where > you lot come in with your testing of your own spaces. > > Please familiarise yourself with what's new in Confluence 5.1 at > https://confluence.atlassian.com/display/DOC/Confluence+5.1+Release+Notes > and also take a good look around our upgraded test instance. Do not worry > about mucking anything up on the test instance as that is what it is there > for. Any changes/additions made will be lost on Saturday when a new > migration will take place. The current confluence version will remain > online > in a read only state until the new version is completed. > > A jira ticket has been raised at > https://issues.apache.org/jira/browse/INFRA-6406 where projects can add > comments on any issues they are having with the test instance as compared > to > their old site. Just problems only please, do not turn it into a how to use > confluence 5 thread. In addition, if there are any features that you > currently use that do not work in the test instance, please replicate the > feature in the current production TEST space so that I can test the
