I'm not sure if they were already put into the official codetree, but this is
the last communication I was shown regarding the fixes:
It turned out that getting the basic build to work on RHEL 9 was not
that hard. It required only minimal changes on the qpid-cpp side [1] and
relatively modest changes on the qpid-python [2] side after all
[1] https://issues.apache.org/jira/browse/QPID-8635
[2] https://issues.apache.org/jira/browse/QPID-8631 (up to commit
6d96be6 QPID-8631: make package version string in setup.py compliant with
PEP-440)
As you can see in the CI, the current main of qpid-cpp is running
through the install and only fails on running the tests [3]. In the job, the
current main of qpid-python is installed before trying to install qpid-cpp. To
do this, the GitHub workflow does, in essence
```
git clone https://github.com/apache/qpid-python.git
cd qpid-python
python3 setup.py install --user
```
which is what I am putting into the Containerfile.
[3]
https://github.com/apache/qpid-cpp/actions/runs/4699600134/jobs/8341756181?pr=39#step:18:1283
Here is a GitHub pull request that adds a Dockerfile/Containerfile
based on CentOS 9 that builds qpid-cpp, similarly to how the build from Irina
(https://github.com/irinabov/docker-qpid-cpp-broker) worked.
Please try it out, whether what is built there seems sufficient for
your use: https://github.com/apache/qpid-cpp/pull/40
docker build -f Containerfile -t jdanekrh/jd_qpid-cpp .
docker run --name qpidd --rm -it -p 5672:5672 jdanekrh/jd_qpid-cpp
Regarding what's missing, and the issues I am aware of:
1) bindings (perl, python, ruby client) don't work. the binding code
requires swig3 but rhel9 only has swig4, leading to runtime crashes due to
incompatibilities when trying to use the bindings
2) qpid-tools (for managing the broker, such as `docker exec qpidd
qpid-stat`) don't work, the broker has to be managed by qpid-tools running
somewhere else, where python2 is available
> Hi Jiri,
>
> I downloaded qpid-cpp-4b1afd9.tar.gz and was able to build and
> complete the install.
That includes the fixes in
https://github.com/apache/qpid-cpp/commit/9f711b8863b8c16d1df2de7116adc1f388c970d4
and in
https://github.com/apache/qpid-cpp/commit/dd442da25a7d175467d7f0348d88ce6a6df1ceff,
which means that cmake no longer fails on trying to byte-compile python
and installing the resulting pyc files.
The fact that installing qpid-python still fails and the build script
seems to ignore that is immensely convenient here, but probably actually a
build script bug in qpid-cpp ;)
Hope that helps.
As it turns out, qpidd was already in the files we had compiled, but I guess I
missed it in my initial pass, and the actual problem was the service file to
run it, not the binary itself. Next time it might be helpful for me to redirect
error output to a file when running such a large setup script so I don't
paraphrase the problem.
-----Original Message-----
From: Tor Rune Skoglund <[email protected]>
Sent: Wednesday, July 10, 2024 4:07 AM
To: [email protected]
Subject: Re: [EXTERNAL]Re: Repackaging qpidd from Centos 7.9 for RHEL 9
Hi Darin,
great work with the python 3 fixes! Would it be possible to get those python 3
fixes into the official codetree? The python problems are one of the major
issues for continuous use of the C++ qpid broker.
- Tor Rune Skoglund
Den 09.07.2024 17:43, skrev Beaudreau, Darin:
> It appears that was a slight mistake on my part. My coworker pointed out that
> he built from the qpid-cpp-43d6b96.tar.gz snapshot and that his compiled
> version he called 1.40 because a developer provided an update to solve the
> python 3 issues.
>
> Regardless, I don't need qpid-cpp or qpid-proton. I need qpid-server for the
> qpidd binary and associated files.
>
> -----Original Message-----
> From: Gordon Sim <[email protected]>
> Sent: Tuesday, July 9, 2024 11:36 AM
> To: [email protected]
> Subject: [EXTERNAL]Re: Repackaging qpidd from Centos 7.9 for RHEL 9
>
> For qpid-proton the source is here:
> https://qpid.apache.org/releases/qpid-proton-0.38.0/index.html. For qpid-cpp
> I don't believe there has been a 1.40 release. The latest is
> https://archive.apache.org/dist/qpid/cpp/1.39.0/. Your 1.40 build is
> therefore probably built from main https://github.com/apache/qpid-cpp.
>
> On Tue, Jul 9, 2024 at 4:21 PM Beaudreau, Darin
> <[email protected]> wrote:
>
>> Hi,
>>
>>
>>
>> I’m reviving a project I inherited from a coworker who was trying to
>> migrate our system software from CentOS 7.9 to RedHat 9. Previously,
>> he had gone through the process of converting the *qpid-cpp* and
>> *qpid-proton* packages to RHEL 9 so that we could test them with our
>> software. I have since bundled these together into a single RPM to
>> make it simpler for us to deploy, but after deploying, it seems
>> there’s still a few components missing. I believe this is because he
>> had only converted the packages necessary to compile our code, which
>> uses QPID heavily, but he never got as far as actually testing it.
>> The main problem seems to be that I’m missing the *qpidd* binary from
>> *qpid-server*, as well as the associated system service to run it.
>>
>>
>>
>> According to this coworker, he had compiled *qpid-cpp * and
>> *qpid-proton* from source from the *qpid-cpp-43d6b96.tar.gz* snapshot.
>> It seems he had some initial issues with compiling due to the
>> *qpid-python* scripts involved having not been upgraded to Python 3
>> yet, but he was able to resolve that issue.
>>
>>
>>
>> My question is, how can I go about locating the correct source
>> package for the version of *qpid-server* that I need that would be
>> compatible with this version he built for RHEL 9 so that I can build
>> *qpidd* and any other required files to include in my deployment RPM?
>> And what steps might be required to build it? Are there any issues I
>> should be aware of in trying to build it for RHEL 9? The exact
>> versions of packages he built from
>> were:
>>
>>
>>
>> *qpid-cpp-1.40.0.x86_64*
>>
>> * qpid-proton-0.38.0.x86_64*
>>
>>
>>
>> I appreciate any assistance. Let me know if I’ve left out information
>> necessary to respond.
>>
>>
>>
>> *Darin Beaudreau*
>>
>> Software Engineer, Analogic Corporation
>>
>> 8 Centennial Drive, Peabody, MA 01960
>>
>> [email protected] |
>> http://www/.
>> a%2F&data=05%7C02%7CDBeaudreau%40analogic.com%7C9dd9a2d66fe143f632ac0
>> 8dca0b75d2f%7C8d6cef0176744e8e9b9f1753140a64ea%7C1%7C0%7C638561956789
>> 238465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
>> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=552qpDTKdhZu2gtcvAnqj
>> M7pMkULhxoJMJj2tKGyiNs%3D&reserved=0
>> nalogic.com%2F&data=05%7C02%7CDBeaudreau%40analogic.com%7Cd5a0cfb68a8
>> 5
>> 4d2f145608dca02d1d13%7C8d6cef0176744e8e9b9f1753140a64ea%7C1%7C0%7C638
>> 5
>> 61362910796939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>> l
>> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=cFsl5RhYTnTYp2
>> r
>> Dp%2Fqd6a9qQA7%2F762STBj5ZWXjYIg%3D&reserved=0
>>
>>
>>
>>
>>
>>
>>
>>
>>
> CAUTION: This email originated from outside of the organization. Please
> report any suspicious attachments, links, or requests for sensitive
> information.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected] For
> additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional
commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
