cmsgemos merge requestshttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests2021-02-04T18:45:47+01:00https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/9Templatize RPC calls in gemdaqmonitor2021-02-04T18:45:47+01:00Dylan Oliver TeagueTemplatize RPC calls in gemdaqmonitor<!--- Provide a general summary of your changes in the Title above -->
To match current code base of using templated RPC calls, gemdaqmonitor is being updated to follow that same convention
## Related Issue
<!--- This project only accep...<!--- Provide a general summary of your changes in the Title above -->
To match current code base of using templated RPC calls, gemdaqmonitor is being updated to follow that same convention
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- Please link to the issue here: -->
Issue referred to here #13
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
The code has not been extensively tested. So far, the code has been run in the context of the XDAQ code for the gemsupervisor on the coffin setup. Doing a limited run, the code does not show any apparently fatal errors, but variables are not updated correctly, so this still needs to be investigated. Likely the issue is less with the RPC calls themselves (the change is fairly minor) and more the setup itself. But this is still to be figured out.
Below is a screenshot of the current output of the Daqmonitoring code
## Screenshots (if appropriate):
![Screenshot_from_2020-04-24_14-23-52](/uploads/a66cb75617d0894e8aa93760b5cb732d/Screenshot_from_2020-04-24_14-23-52.png)
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.Mykhailo DalchenkoLaurent PetreCamilla GalloniMykhailo Dalchenkohttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/58Build libpqxx and make it available to CMake2021-01-26T16:29:18+01:00Louis MoureauxBuild libpqxx and make it available to CMakePostgreSQL will be used for the configuration database, and libpqxx is the C++ library of choice for its integration in cmsgemos.
Closes #131PostgreSQL will be used for the configuration database, and libpqxx is the C++ library of choice for its integration in cmsgemos.
Closes #131Dylan Oliver TeagueLaurent PetreCamilla GalloniDylan Oliver Teaguehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/44Embed rpcsvc inside the cmsgemos repository2020-09-01T12:11:38+02:00Laurent PetreEmbed rpcsvc inside the cmsgemos repository## Description
<!--- Describe your changes in detail -->
This MR aims at fixing #101. The minimal amount of sources has been copied from the [`APx-rpcsvc` GitHub repository](https://github.com/uwcms/APx-rpcsvc) and is built with the ...## Description
<!--- Describe your changes in detail -->
This MR aims at fixing #101. The minimal amount of sources has been copied from the [`APx-rpcsvc` GitHub repository](https://github.com/uwcms/APx-rpcsvc) and is built with the CMake build system used throughout the `cmsgemos` project. This MR does not aim at fixing the various RPC related issues nor merging `xHAL` and `rpcsvc` (see #102, #103, #104, #106).
The port number under which `rpcsvc` runs as well as the `memhub` semaphore name have been changed in order to allow the legacy and development software to be run in parallel.
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- If addressing multiple issues, comment on their relation if needed -->
<!--- Please link issues accordgin to the automation rules: -->
<!--- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
Fixes #101
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
The code compiles, and one is able to start a run on the `gem904daq04` test machine.
<!--- ## Screenshots (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Dylan Oliver TeagueLouis MoureauxCamilla GalloniDylan Oliver Teaguehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/43Add a spec file for RPM packaging2020-09-01T11:17:24+02:00Louis MoureauxAdd a spec file for RPM packaging## Description
<!--- Describe your changes in detail -->
This MR adds a `cmsgemos.spec` file that can be used to build RPM packages (source, binary and debug).
To do list:
* [x] The version number is hard-coded (to `1.0.0-1`). ...## Description
<!--- Describe your changes in detail -->
This MR adds a `cmsgemos.spec` file that can be used to build RPM packages (source, binary and debug).
To do list:
* [x] The version number is hard-coded (to `1.0.0-1`). Maybe this can be taken from `git` directly or passed by `cmake`.
*Decided not to do, better use a dedicated tool.*
* [x] The packages install themselves in `/usr`, maybe the sysadmins won't like it. *Up to the sysamdins*
* [x] The LICENSE and README files aren't included (should go somewhere in `prefix/share`).
* [x] The license is set to `Unknown`. *It's really unknown*
* [x] We could set environment variables by dropping the appropriate files in `/etc/profile.d`. This would reduce the equivalent of $1151 for system-wide installs. *Won't do*
* [x] The symlinks created in $1151 could be created in the post-install script and removed in pre-remove. *The `gemdaq` symlink is created correcly in `/opt/xdaq/htdocs`*
I tried to use `mock` but it doesn't have sufficient permissions in Gitlab CI. Since it starts from a generic image, the CI job should be roughly equivalent.
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- If addressing multiple issues, comment on their relation if needed -->
<!--- Please link issues accordgin to the automation rules: -->
<!--- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
#59
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
The CI tests that the packages can be built and installed on a pristine system. In particular, all run time dependencies that I know of are found and installed correctly.
<!--- ## Screenshots (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [x] I have added tests to cover my changes.
- [x] All new and existing tests passed.Dylan Oliver TeagueLaurent PetreCamilla GalloniDylan Oliver Teague