[jira] [Resolved] (PROTON-903) UUID version should be in sixth octet
[ https://issues.apache.org/jira/browse/PROTON-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-903. --- Resolution: Fixed Fix Version/s: 0.10 UUID version should be in sixth octet - Key: PROTON-903 URL: https://issues.apache.org/jira/browse/PROTON-903 Project: Qpid Proton Issue Type: Improvement Reporter: Flavio Percoco Assignee: Gordon Sim Fix For: 0.10 Attachments: 0001-PROTON-903-Set-UUID-s-version-in-the-sixth-octet.patch Python's UUID fallback implementation sets the UUID version in the seventh octet instead of the sixth. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: something rotten in the state of... something or other
I'm not seeing that currently, but I have seen similar sort of things a couple of times in the past. As you mention, some files get created in the source tree (presumably by or due to use of Jython), outwith the normal build areas they would be (which would lead to them being cleaned up), and I think that is part of the problem sometimes. If the shim, binding or test files get updated in certain ways, some bits can become out of sync, leading to the type of issue you saw. CI doesnt see the issue as it blows away all unversioned files before each update. If I see it locally I've just used git-clean to tidy up my checkout. I'm not sure what we can do otherwise except put something togehter that targets all the extraneous files and removes them. Robbie On 9 June 2015 at 16:57, Gordon Sim g...@redhat.com wrote: I've recently started seeing errors[1] when running tests due to left over artefacts of previous builds. This happens even for a completely clean build directory, as some of the offending artefacts seem to be created in the source tree. Jython seems to be trying and failing to load cproton. With a completely clean source and build tree, everything passes, but it is kind of annoying to have to rely on that. Is anyone else seeing anything similar? Any ideas as to the cause (I've only seen it happening quite recently) or possible cures? [1]: --- T E S T S --- Running org.apache.qpid.proton.InteropTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.119 sec Running org.apache.qpid.proton.JythonTest 2015-06-09 16:49:29.705 INFO About to call Jython test script: '/home/gordon/projects/proton-git/tests/python/proton-test' with '/home/gordon/projects/proton-git/tests/python' added to Jython path Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.207 sec FAILURE! test(org.apache.qpid.proton.JythonTest) Time elapsed: 5.203 sec FAILURE! java.lang.AssertionError: Caught PyException on invocation number 2: Traceback (most recent call last): File /home/gordon/projects/proton-git/tests/python/proton-test, line 616, in module m = __import__(name, None, None, [dummy]) File /home/gordon/projects/proton-git/tests/python/proton_tests/__init__.py, line 20, in module import proton_tests.codec File /home/gordon/projects/proton-git/tests/python/proton_tests/codec.py, line 20, in module import os, common, sys File /home/gordon/projects/proton-git/tests/python/proton_tests/common.py, line 26, in module from proton import Connection, Transport, SASL, Endpoint, Delivery, SSL File /home/gordon/projects/proton-git/tests/../proton-c/bindings/python/proton/__init__.py, line 33, in module from cproton import * File /home/gordon/projects/proton-git/tests/../proton-c/bindings/python/cproton.py, line 29, in module import _cproton ImportError: No module named _cproton with message: null at org.junit.Assert.fail(Assert.java:93) at org.apache.qpid.proton.JythonTest.runTestOnce(JythonTest.java:120) at org.apache.qpid.proton.JythonTest.test(JythonTest.java:95) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at
something rotten in the state of... something or other
I've recently started seeing errors[1] when running tests due to left over artefacts of previous builds. This happens even for a completely clean build directory, as some of the offending artefacts seem to be created in the source tree. Jython seems to be trying and failing to load cproton. With a completely clean source and build tree, everything passes, but it is kind of annoying to have to rely on that. Is anyone else seeing anything similar? Any ideas as to the cause (I've only seen it happening quite recently) or possible cures? [1]: --- T E S T S --- Running org.apache.qpid.proton.InteropTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.119 sec Running org.apache.qpid.proton.JythonTest 2015-06-09 16:49:29.705 INFO About to call Jython test script: '/home/gordon/projects/proton-git/tests/python/proton-test' with '/home/gordon/projects/proton-git/tests/python' added to Jython path Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.207 sec FAILURE! test(org.apache.qpid.proton.JythonTest) Time elapsed: 5.203 sec FAILURE! java.lang.AssertionError: Caught PyException on invocation number 2: Traceback (most recent call last): File /home/gordon/projects/proton-git/tests/python/proton-test, line 616, in module m = __import__(name, None, None, [dummy]) File /home/gordon/projects/proton-git/tests/python/proton_tests/__init__.py, line 20, in module import proton_tests.codec File /home/gordon/projects/proton-git/tests/python/proton_tests/codec.py, line 20, in module import os, common, sys File /home/gordon/projects/proton-git/tests/python/proton_tests/common.py, line 26, in module from proton import Connection, Transport, SASL, Endpoint, Delivery, SSL File /home/gordon/projects/proton-git/tests/../proton-c/bindings/python/proton/__init__.py, line 33, in module from cproton import * File /home/gordon/projects/proton-git/tests/../proton-c/bindings/python/cproton.py, line 29, in module import _cproton ImportError: No module named _cproton with message: null at org.junit.Assert.fail(Assert.java:93) at org.apache.qpid.proton.JythonTest.runTestOnce(JythonTest.java:120) at org.apache.qpid.proton.JythonTest.test(JythonTest.java:95) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Results : Failed tests: test(org.apache.qpid.proton.JythonTest): Caught PyException on
Re: something rotten in the state of... something or other
A betting man would wager it has something to do with the recent changes to the python setup.py. I'll have a look into it. - Original Message - From: Gordon Sim g...@redhat.com To: proton@qpid.apache.org Sent: Tuesday, June 9, 2015 11:57:25 AM Subject: something rotten in the state of... something or other I've recently started seeing errors[1] when running tests due to left over artefacts of previous builds. This happens even for a completely clean build directory, as some of the offending artefacts seem to be created in the source tree. Jython seems to be trying and failing to load cproton. With a completely clean source and build tree, everything passes, but it is kind of annoying to have to rely on that. Is anyone else seeing anything similar? Any ideas as to the cause (I've only seen it happening quite recently) or possible cures? [1]: --- T E S T S --- Running org.apache.qpid.proton.InteropTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.119 sec Running org.apache.qpid.proton.JythonTest 2015-06-09 16:49:29.705 INFO About to call Jython test script: '/home/gordon/projects/proton-git/tests/python/proton-test' with '/home/gordon/projects/proton-git/tests/python' added to Jython path Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.207 sec FAILURE! test(org.apache.qpid.proton.JythonTest) Time elapsed: 5.203 sec FAILURE! java.lang.AssertionError: Caught PyException on invocation number 2: Traceback (most recent call last): File /home/gordon/projects/proton-git/tests/python/proton-test, line 616, in module m = __import__(name, None, None, [dummy]) File /home/gordon/projects/proton-git/tests/python/proton_tests/__init__.py, line 20, in module import proton_tests.codec File /home/gordon/projects/proton-git/tests/python/proton_tests/codec.py, line 20, in module import os, common, sys File /home/gordon/projects/proton-git/tests/python/proton_tests/common.py, line 26, in module from proton import Connection, Transport, SASL, Endpoint, Delivery, SSL File /home/gordon/projects/proton-git/tests/../proton-c/bindings/python/proton/__init__.py, line 33, in module from cproton import * File /home/gordon/projects/proton-git/tests/../proton-c/bindings/python/cproton.py, line 29, in module import _cproton ImportError: No module named _cproton with message: null at org.junit.Assert.fail(Assert.java:93) at org.apache.qpid.proton.JythonTest.runTestOnce(JythonTest.java:120) at org.apache.qpid.proton.JythonTest.test(JythonTest.java:95) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at
C++ binding naming conventions: Qpid vs. C++
C++ standard library uses lowercase_and_underscores, but Qpid C++ projects to date use JavaWobbleCaseIndentifiers. Is the C++ binding the time to start writing C++ like C++ programmers? Or will somebody's head explode if class names start with a lower case letter? In particular since the proton C library is written in typical c_style_with_underscores, I am finding the CamelCase in the C++ binding to be an ugly clash. DoesAnybodyReallyThinkThis is_easier_to_read_than_this? Cheers, Alan.
Re: Proton-c Null Messages
When I run the client I get: [0x5351db0]:0 - @transfer(20) [handle=0, delivery-id=0, delivery-tag=b, message-format=0, settled=true, more=true] (16363) \x00Sp\xc0\x07\x05B... And then the segfault occurs when transfering a 5 MB message, and it is only coming through as this 16 KB message. -- View this message in context: http://qpid.2158936.n2.nabble.com/Proton-c-Null-Messages-tp7625967p7626133.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: Proton-c Null Messages
On 06/09/2015 06:40 PM, logty wrote: When I run the client I get: [0x5351db0]:0 - @transfer(20) [handle=0, delivery-id=0, delivery-tag=b, message-format=0, settled=true, more=true] (16363) \x00Sp\xc0\x07\x05B... My guess would be that it is the delivery tag being null (or empty, can't tell which) that is the problem. From the spec: This field MUST be specified for the first transfer of a multi-transfer message and can only be omitted for continuation transfers. [section 2.7.5] So I think that whatever is sending that frame has a bug. Proton-c has a bug too of course, since it shouldn't segfault but should close the connection with a framing-error or similar. And then the segfault occurs when transfering a 5 MB message, and it is only coming through as this 16 KB message.
Re: Proton-c Null Messages
Can you give an example of how I would set the delivery tag? I have been using a messenger to send the messages, but I have been having a tough time finding the documentation on how to set the tag. -- View this message in context: http://qpid.2158936.n2.nabble.com/Proton-c-Null-Messages-tp7625967p7626141.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: Strange behaviour for pn_messenger_send on CentOS 6
Hi Folks, Just tried this and can recreate on a 64 bit laptop running CentOS 6.6 natively too. The send application never exits if a receiver is not yet ready. Can anyone else see this or am I going mad? Cheers, Frank On Thu, Jun 4, 2015 at 3:51 PM, Frank Quinn fquinn...@gmail.com wrote: Thanks Darryl, Also note this is on a VMWare VM if that makes a difference (clock types available perhaps?) and it is pinning CPU at the time. After seeing that a recompile didn't fix the problem, I nuked the newly compiled libraries and reverted to the EPEL RPMs: Installed Packages Name: qpid-proton-c-devel Arch: x86_64 Version : 0.8 Release : 1.el6 Size: 300 k Repo: installed From repo : epel Summary : Development libraries for writing messaging apps with Qpid Proton URL : http://qpid.apache.org/proton/ License : ASL 2.0 Description : Development libraries for writing messaging apps with Qpid Proton. The issue is with send not exiting, so after running the trace on send: [fquinn@omvmfq01 messenger]$ PN_TRACE_FRM=1 ./send [0x19ddf10]: - SASL [0x19ddf10]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b] recv: Connection refused [0x19ddf10]:0 - @open(16) [container-id=] [0x19ddf10]:0 - @close(24) [error=@error(29) [condition=:amqp:connection:framing-error, description=SASL header mismatch: '']] [0x19ddf10]:ERROR amqp:connection:framing-error SASL header mismatch: '' [0x19ddf10]: - EOS CONNECTION ERROR connection aborted (remote) Stack trace of hung application: (gdb) bt #0 clock_gettime (clock_id=0, tp=0x7fffac992580) at ../sysdeps/unix/clock_gettime.c:94 #1 0x7f5a1c00912e in pn_i_now () at /usr/src/debug/qpid-proton-0.8/proton-c/src/platform.c:31 #2 0x7f5a1c0079bf in pn_selector_select (selector=0x19da280, timeout=-1) at /usr/src/debug/qpid-proton-0.8/proton-c/src/posix/selector.c:161 #3 0x7f5a1c0052f9 in pn_messenger_tsync (messenger=0x19d9960, predicate=0x7f5a1c0020e0 pn_messenger_sent, timeout=value optimized out) at /usr/src/debug/qpid-proton-0.8/proton-c/src/messenger/messenger.c:1440 #4 0x00401335 in main () Another stack trace from the same instance: (gdb) bt #0 0x7f5a1b1e9e15 in clock_gettime (clock_id=0, tp=0x7fffac992560) at ../sysdeps/unix/clock_gettime.c:94 #1 0x7f5a1c00912e in pn_i_now ()at /usr/src/debug/qpid-proton-0.8/proton-c/src/platform.c:31 #2 0x7f5a1c004dce in pni_messenger_tick (messenger=0x19d9960)at /usr/src/debug/qpid-proton-0.8/proton-c/src/messenger/messenger.c:1330 #3 pn_messenger_process (messenger=0x19d9960)at /usr/src/debug/qpid-proton-0.8/proton-c/src/messenger/messenger.c:1367 #4 0x7f5a1c0052b8 in pn_messenger_tsync (messenger=0x19d9960, predicate=0x7f5a1c0020e0 pn_messenger_sent,timeout=value optimized out) at /usr/src/debug/qpid-proton-0.8/proton-c/src/messenger/messenger.c:1423 #5 0x00401335 in main () Cheers, Frank On Thu, Jun 4, 2015 at 3:38 PM, Darryl L. Pierce dpie...@redhat.com wrote: On Thu, Jun 04, 2015 at 03:12:51PM +0100, Frank Quinn wrote: I hit a strange issue today when setting up a qpid proton development environment on a fresh CentOS 6 VM. I first found the issue in our application, but when I went a little deeper, I realized I could recreate the issue with the qpid proton send and recv example applications. All you need to do is run ‘send’ on its own and the pn_messenger_send call hangs indefinitely. If you start ‘recv’ first, it works fine, but ‘send’ on its own hangs every time. This is contrary to its behaviour on my Fedora 21 laptop (latest yum provisioned 0.8 version) where it always attempts once, logs a failure, then exits (which is what I would expect). This effectively deadlocks our application. So far, I’ve tried compiling qpid proton c myself (both 0.8 and 0.9.1), setting pn_messenger_send timeout to 1 (it was previously -1), turning off iptables entirely and disabling selinux and rebooting but no luck. Is this something you folks have seen before? Hrm, this isn't something I've heard reported before. Does it do the same if you use the Python recv.py example as well? Also, can you do the following: $ PN_TRACE_FRM=1 ./recv [options] and share the output displayed? Also, is this solely with binaries you've built or are you installed RPMs from EPEL for Proton? -- 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: Proton-c Null Messages
On Mon, Jun 08, 2015 at 01:47:03PM -0700, logty wrote: The strange thing is pn_messenger_get is returning 0, I have code to throw an error if it isn't 0. Also, the large messages work fine on RabbitMQ but not on Apache Apollo. What's the output when you run your client with: $ PN_TRACE_FRM=1 [your client cmdline] ? Do you see the message being received on the client side? -- 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/ pgpxSErwfJzge.pgp Description: PGP signature
[jira] [Resolved] (PROTON-902) Make dependency on libuuid optional
[ https://issues.apache.org/jira/browse/PROTON-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-902. --- Resolution: Won't Fix A better approach is to avoid the libuuid dependency completely and use Flavio's uuid4 implementation. Let's open a new JIRA to track that. Make dependency on libuuid optional --- Key: PROTON-902 URL: https://issues.apache.org/jira/browse/PROTON-902 Project: Qpid Proton Issue Type: Improvement Reporter: Flavio Percoco Assignee: Ken Giusti Attachments: 0001-PROTON-902-Remove-the-dependency-on-uuid.patch The current proton-c version depends on libuuid for, well, generating uuids. The unfortunate thing of this dependency is that it's currently just required by the messenger and it's just being used for building the messengers name. It's really unfortunate to require this library and headers to be present for such a small case. It'd be possible to make this dependency optional by adding a built-in uuid4 generator that'd be enabled whenever libuuid is not around. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-902) Make dependency on libuuid optional
[ https://issues.apache.org/jira/browse/PROTON-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578847#comment-14578847 ] Flavio Percoco commented on PROTON-902: --- FWIW, I fully agree... I'll open a new JIRA Make dependency on libuuid optional --- Key: PROTON-902 URL: https://issues.apache.org/jira/browse/PROTON-902 Project: Qpid Proton Issue Type: Improvement Reporter: Flavio Percoco Assignee: Ken Giusti Attachments: 0001-PROTON-902-Remove-the-dependency-on-uuid.patch The current proton-c version depends on libuuid for, well, generating uuids. The unfortunate thing of this dependency is that it's currently just required by the messenger and it's just being used for building the messengers name. It's really unfortunate to require this library and headers to be present for such a small case. It'd be possible to make this dependency optional by adding a built-in uuid4 generator that'd be enabled whenever libuuid is not around. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-904) Remove dependency on libuuid
Flavio Percoco created PROTON-904: - Summary: Remove dependency on libuuid Key: PROTON-904 URL: https://issues.apache.org/jira/browse/PROTON-904 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco The current proton-c version depends on libuuid for, well, generating uuids. The unfortunate thing of this dependency is that it's currently just required by the messenger and it's just being used for building the messengers name. It's really unfortunate to require this library and headers to be present for such a small case. It'd be possible to remove this dependency by adding a built-in uuid4 generator since uuid4 is based on random bytes generation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-903) UUID version should be in sixth octet
[ https://issues.apache.org/jira/browse/PROTON-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578910#comment-14578910 ] ASF subversion and git services commented on PROTON-903: Commit 53b9184719762b44843832a642cc090a63f2d71c in qpid-proton's branch refs/heads/master from [~gsim] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=53b9184 ] PROTON-903: align fallback UUID implementation with spec. Patch from Flavio Percoco. UUID version should be in sixth octet - Key: PROTON-903 URL: https://issues.apache.org/jira/browse/PROTON-903 Project: Qpid Proton Issue Type: Improvement Reporter: Flavio Percoco Assignee: Gordon Sim Attachments: 0001-PROTON-903-Set-UUID-s-version-in-the-sixth-octet.patch Python's UUID fallback implementation sets the UUID version in the seventh octet instead of the sixth. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-904) Remove dependency on libuuid
[ https://issues.apache.org/jira/browse/PROTON-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578861#comment-14578861 ] Flavio Percoco commented on PROTON-904: --- reviewboard link: https://reviews.apache.org/r/35252/ Remove dependency on libuuid Key: PROTON-904 URL: https://issues.apache.org/jira/browse/PROTON-904 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco The current proton-c version depends on libuuid for, well, generating uuids. The unfortunate thing of this dependency is that it's currently just required by the messenger and it's just being used for building the messengers name. It's really unfortunate to require this library and headers to be present for such a small case. It'd be possible to remove this dependency by adding a built-in uuid4 generator since uuid4 is based on random bytes generation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
