Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
On 30/9/2022 5:01 pm, Christian MAUDERER wrote: > The rtems-deployment repo doesn't have a .gitlab-ci.yml. Did you keep that > separate? Sorry missed this. The plumbing is outside of that repo. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
On 30/9/2022 5:01 pm, Christian MAUDERER wrote: > Am 30.09.22 um 08:48 schrieb Chris Johns: >> On 30/9/2022 4:08 pm, Christian MAUDERER wrote: >>> Am 30.09.22 um 07:37 schrieb Chris Johns: On 30/9/2022 3:33 pm, Christian MAUDERER wrote: > Am 30.09.22 um 05:49 schrieb Chris Johns: >> On 29/9/2022 9:50 pm, Chris Johns wrote: >>> On 29/9/22 9:45 pm, Christian MAUDERER wrote: Hello Chris, thanks for the quick patch. With this qemu and microblaze work again like expected. I tested all tools starting with devel/* and from the ones that work only devel/autotools-internal didn't generate a tar archive. But that one has a comment "Do not use via the command line" in the bset file so that is most likely fine. Some of other devel/* packages didn't build in my test setup, but I have never tested or used them before so that is probably a problem of my build environment or maybe a known bug. >>> >>> Thanks for the testing. I will push to the devel branch and 5. >>> >> >> Tarfile creation is working however installing is not. I am working on >> fixing >> this. >> >> Chris > > Sorry that I missed that. I only tried to generate the tar archives. Same. Testing a fix but it takes time to check properly. I am wondering if I can create a test mode in the deployment repo. The hard part is how to automatically check the build has worked. Chris >>> >>> I'm currently trying to create a basic CI/CD setup for testing our embedded >>> brains patches using GitHub. At the moment it's still quite experimental and >>> still a bit thrown together but it basically runs: >>> >>> https://github.com/embedded-brains/rtems-source-builder/actions/runs/3151126889 >> >> Nice. >> >>> It didn't catch that bug because it doesn't use installed tools for the >>> simulator runs, but maybe I can change that. >>> >>> If it works well enough, we maybe could re-use some scripts or work flows >>> to set >>> up an official RTEMS CI/CD with whatever community preferred CI system. It >>> shouldn't be too big of a problem to port the logic to Gitlab CI, Cirrus CI >>> or >>> any other modern CI system. >> >> I have started https://git.rtems.org/chrisj/rtems-deployment.git/. I would >> like >> it to be the landing place for this type of stuff if it fits. The repo is >> being >> actively worked on by me. > > I have seen that repo after you mentioned it recently, but I have to admit I > haven't looked at it yet. From the name I have guessed that it is more for > building release versions and not for continuous checks. I'll take a more > detailed look. CI is something that would come under deployment, it is the same process. In your case the output is not used, it is for testing. The repo can build buildsets that will fail and show them as a pass. >> I can build RPMs on Rocky 8 and 9. These RPMs are the base for EPICS RPMs >> built >> into docker containers used to build Gemini's EPICS based systems. All >> handled >> via CI in gitlab. > > That's quite interesting. Do you have a public GitLab instance where you build > these or is that a private instance? https://gitlab.com/nsf-noirlab/gemini/rtsw/epics-base/epics-base > The rtems-deployment repo doesn't have a .gitlab-ci.yml. Did you keep that > separate? $ ./waf configure --prefix=/opt/rtems --rsb=../rtems-source-builder $ ./waf rpmspec $ rpmbuild -bb out/test/dtc.spec $ rpm -qi \ out/buildroot/RPMS/x86_64/rtems-dtc-5-ddfcc320ab74_modified.el9.x86_64.rpm Name: rtems-dtc Version : 5 Release : ddfcc320ab74_modified.el9 Architecture: x86_64 Install Date: (not installed) Group : Unspecified Size: 1191613 License : GPLv2, GPLv3, BSD-2 Signature : (none) Source RPM : rtems-dtc-5-ddfcc320ab74_modified.el9.src.rpm Build Date : Friday 30 September 2022 05:24:31 PM Build Host : rocky.contemporary.net.au Summary : RTEMS tools and board support package Description : This RPM is development tools and BSP for RTEMS If you switch the RSB branch from 6 to 5 the same process works. That is really important because users do not need to update their plumbing. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
Am 30.09.22 um 08:48 schrieb Chris Johns: On 30/9/2022 4:08 pm, Christian MAUDERER wrote: Am 30.09.22 um 07:37 schrieb Chris Johns: On 30/9/2022 3:33 pm, Christian MAUDERER wrote: Am 30.09.22 um 05:49 schrieb Chris Johns: On 29/9/2022 9:50 pm, Chris Johns wrote: On 29/9/22 9:45 pm, Christian MAUDERER wrote: Hello Chris, thanks for the quick patch. With this qemu and microblaze work again like expected. I tested all tools starting with devel/* and from the ones that work only devel/autotools-internal didn't generate a tar archive. But that one has a comment "Do not use via the command line" in the bset file so that is most likely fine. Some of other devel/* packages didn't build in my test setup, but I have never tested or used them before so that is probably a problem of my build environment or maybe a known bug. Thanks for the testing. I will push to the devel branch and 5. Tarfile creation is working however installing is not. I am working on fixing this. Chris Sorry that I missed that. I only tried to generate the tar archives. Same. Testing a fix but it takes time to check properly. I am wondering if I can create a test mode in the deployment repo. The hard part is how to automatically check the build has worked. Chris I'm currently trying to create a basic CI/CD setup for testing our embedded brains patches using GitHub. At the moment it's still quite experimental and still a bit thrown together but it basically runs: https://github.com/embedded-brains/rtems-source-builder/actions/runs/3151126889 Nice. It didn't catch that bug because it doesn't use installed tools for the simulator runs, but maybe I can change that. If it works well enough, we maybe could re-use some scripts or work flows to set up an official RTEMS CI/CD with whatever community preferred CI system. It shouldn't be too big of a problem to port the logic to Gitlab CI, Cirrus CI or any other modern CI system. I have started https://git.rtems.org/chrisj/rtems-deployment.git/. I would like it to be the landing place for this type of stuff if it fits. The repo is being actively worked on by me. I have seen that repo after you mentioned it recently, but I have to admit I haven't looked at it yet. From the name I have guessed that it is more for building release versions and not for continuous checks. I'll take a more detailed look. I can build RPMs on Rocky 8 and 9. These RPMs are the base for EPICS RPMs built into docker containers used to build Gemini's EPICS based systems. All handled via CI in gitlab. That's quite interesting. Do you have a public GitLab instance where you build these or is that a private instance? The rtems-deployment repo doesn't have a .gitlab-ci.yml. Did you keep that separate? Best regards Christian To build an RPM you configure with the path to the RSB and then run `./waf rpmspec`. A spec file is created you can use with `rpmbuild` to make an RPM. I am keeping the generation and building of the RPM separate. By default the repo builds a tarfile. Once this repo stabilises I would like to see if it can move to the top level. I am working on better documentation for it and with that some constraints about what is offered. Deployment is something varies and I hope this repo can grow to make common solutions widely available. I am fine for organisation to send in specific configurations if they are open to having them in the repo. Chris -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
On 30/9/2022 4:08 pm, Christian MAUDERER wrote: > Am 30.09.22 um 07:37 schrieb Chris Johns: >> On 30/9/2022 3:33 pm, Christian MAUDERER wrote: >>> Am 30.09.22 um 05:49 schrieb Chris Johns: On 29/9/2022 9:50 pm, Chris Johns wrote: > On 29/9/22 9:45 pm, Christian MAUDERER wrote: >> Hello Chris, >> >> thanks for the quick patch. With this qemu and microblaze work again like >> expected. >> >> I tested all tools starting with devel/* and from the ones that work only >> devel/autotools-internal didn't generate a tar archive. But that one has >> a >> comment "Do not use via the command line" in the bset file so that is >> most >> likely fine. >> >> Some of other devel/* packages didn't build in my test setup, but I have >> never >> tested or used them before so that is probably a problem of my build >> environment >> or maybe a known bug. > > Thanks for the testing. I will push to the devel branch and 5. > Tarfile creation is working however installing is not. I am working on fixing this. Chris >>> >>> Sorry that I missed that. I only tried to generate the tar archives. >> >> Same. Testing a fix but it takes time to check properly. >> >> I am wondering if I can create a test mode in the deployment repo. The hard >> part >> is how to automatically check the build has worked. >> >> Chris > > I'm currently trying to create a basic CI/CD setup for testing our embedded > brains patches using GitHub. At the moment it's still quite experimental and > still a bit thrown together but it basically runs: > > https://github.com/embedded-brains/rtems-source-builder/actions/runs/3151126889 Nice. > It didn't catch that bug because it doesn't use installed tools for the > simulator runs, but maybe I can change that. > > If it works well enough, we maybe could re-use some scripts or work flows to > set > up an official RTEMS CI/CD with whatever community preferred CI system. It > shouldn't be too big of a problem to port the logic to Gitlab CI, Cirrus CI or > any other modern CI system. I have started https://git.rtems.org/chrisj/rtems-deployment.git/. I would like it to be the landing place for this type of stuff if it fits. The repo is being actively worked on by me. I can build RPMs on Rocky 8 and 9. These RPMs are the base for EPICS RPMs built into docker containers used to build Gemini's EPICS based systems. All handled via CI in gitlab. To build an RPM you configure with the path to the RSB and then run `./waf rpmspec`. A spec file is created you can use with `rpmbuild` to make an RPM. I am keeping the generation and building of the RPM separate. By default the repo builds a tarfile. Once this repo stabilises I would like to see if it can move to the top level. I am working on better documentation for it and with that some constraints about what is offered. Deployment is something varies and I hope this repo can grow to make common solutions widely available. I am fine for organisation to send in specific configurations if they are open to having them in the repo. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
Am 30.09.22 um 07:37 schrieb Chris Johns: On 30/9/2022 3:33 pm, Christian MAUDERER wrote: Am 30.09.22 um 05:49 schrieb Chris Johns: On 29/9/2022 9:50 pm, Chris Johns wrote: On 29/9/22 9:45 pm, Christian MAUDERER wrote: Hello Chris, thanks for the quick patch. With this qemu and microblaze work again like expected. I tested all tools starting with devel/* and from the ones that work only devel/autotools-internal didn't generate a tar archive. But that one has a comment "Do not use via the command line" in the bset file so that is most likely fine. Some of other devel/* packages didn't build in my test setup, but I have never tested or used them before so that is probably a problem of my build environment or maybe a known bug. Thanks for the testing. I will push to the devel branch and 5. Tarfile creation is working however installing is not. I am working on fixing this. Chris Sorry that I missed that. I only tried to generate the tar archives. Same. Testing a fix but it takes time to check properly. I am wondering if I can create a test mode in the deployment repo. The hard part is how to automatically check the build has worked. Chris I'm currently trying to create a basic CI/CD setup for testing our embedded brains patches using GitHub. At the moment it's still quite experimental and still a bit thrown together but it basically runs: https://github.com/embedded-brains/rtems-source-builder/actions/runs/3151126889 It didn't catch that bug because it doesn't use installed tools for the simulator runs, but maybe I can change that. If it works well enough, we maybe could re-use some scripts or work flows to set up an official RTEMS CI/CD with whatever community preferred CI system. It shouldn't be too big of a problem to port the logic to Gitlab CI, Cirrus CI or any other modern CI system. Best regards Christian -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
On 30/9/2022 3:33 pm, Christian MAUDERER wrote: > Am 30.09.22 um 05:49 schrieb Chris Johns: >> On 29/9/2022 9:50 pm, Chris Johns wrote: >>> On 29/9/22 9:45 pm, Christian MAUDERER wrote: Hello Chris, thanks for the quick patch. With this qemu and microblaze work again like expected. I tested all tools starting with devel/* and from the ones that work only devel/autotools-internal didn't generate a tar archive. But that one has a comment "Do not use via the command line" in the bset file so that is most likely fine. Some of other devel/* packages didn't build in my test setup, but I have never tested or used them before so that is probably a problem of my build environment or maybe a known bug. >>> >>> Thanks for the testing. I will push to the devel branch and 5. >>> >> >> Tarfile creation is working however installing is not. I am working on fixing >> this. >> >> Chris > > Sorry that I missed that. I only tried to generate the tar archives. Same. Testing a fix but it takes time to check properly. I am wondering if I can create a test mode in the deployment repo. The hard part is how to automatically check the build has worked. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
Am 30.09.22 um 05:49 schrieb Chris Johns: On 29/9/2022 9:50 pm, Chris Johns wrote: On 29/9/22 9:45 pm, Christian MAUDERER wrote: Hello Chris, thanks for the quick patch. With this qemu and microblaze work again like expected. I tested all tools starting with devel/* and from the ones that work only devel/autotools-internal didn't generate a tar archive. But that one has a comment "Do not use via the command line" in the bset file so that is most likely fine. Some of other devel/* packages didn't build in my test setup, but I have never tested or used them before so that is probably a problem of my build environment or maybe a known bug. Thanks for the testing. I will push to the devel branch and 5. Tarfile creation is working however installing is not. I am working on fixing this. Chris Sorry that I missed that. I only tried to generate the tar archives. Best regards Christian -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
On 29/9/2022 9:50 pm, Chris Johns wrote: > On 29/9/22 9:45 pm, Christian MAUDERER wrote: >> Hello Chris, >> >> thanks for the quick patch. With this qemu and microblaze work again like >> expected. >> >> I tested all tools starting with devel/* and from the ones that work only >> devel/autotools-internal didn't generate a tar archive. But that one has a >> comment "Do not use via the command line" in the bset file so that is most >> likely fine. >> >> Some of other devel/* packages didn't build in my test setup, but I have >> never >> tested or used them before so that is probably a problem of my build >> environment >> or maybe a known bug. > > Thanks for the testing. I will push to the devel branch and 5. > Tarfile creation is working however installing is not. I am working on fixing this. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
On 29/9/22 9:45 pm, Christian MAUDERER wrote: > Hello Chris, > > thanks for the quick patch. With this qemu and microblaze work again like > expected. > > I tested all tools starting with devel/* and from the ones that work only > devel/autotools-internal didn't generate a tar archive. But that one has a > comment "Do not use via the command line" in the bset file so that is most > likely fine. > > Some of other devel/* packages didn't build in my test setup, but I have never > tested or used them before so that is probably a problem of my build > environment > or maybe a known bug. Thanks for the testing. I will push to the devel branch and 5. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
Hello Chris,
thanks for the quick patch. With this qemu and microblaze work again
like expected.
I tested all tools starting with devel/* and from the ones that work
only devel/autotools-internal didn't generate a tar archive. But that
one has a comment "Do not use via the command line" in the bset file so
that is most likely fine.
Some of other devel/* packages didn't build in my test setup, but I have
never tested or used them before so that is probably a problem of my
build environment or maybe a known bug.
Best regards
Christian
Am 29.09.22 um 10:52 schrieb chr...@rtems.org:
From: Chris Johns
Closes #4730
---
source-builder/sb/setbuilder.py | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/source-builder/sb/setbuilder.py b/source-builder/sb/setbuilder.py
index 3e16111..5921eed 100644
--- a/source-builder/sb/setbuilder.py
+++ b/source-builder/sb/setbuilder.py
@@ -433,19 +433,11 @@ class buildset:
interrupted = False
#
-# If this is the outter most buildset it's files are installed. Nested
-# build sets staged their installed file. The staged files are install
-# when the outtter most build finishes.
+# If installing switch to staging. Not sure if this is still
+# needed.
#
-if nesting_count != 1:
-if self.installing():
-self.macros['install_mode'] = 'staging'
-
-#
-# Only the outter build set can have staging to install. Get the
staging
-# root via the config because it could require a valid config.
-#
-have_staging = False
+if self.installing():
+self.macros['install_mode'] = 'staging'
try:
configs = self.load()
@@ -453,7 +445,7 @@ class buildset:
log.trace('_bset: %2d: %s: configs: %s' % (nesting_count,
self.bset, ',
'.join(configs)))
-if nesting_count == 1 and len(configs) > 1:
+if nesting_count == 1:
#
# Prepend staging areas, bin directory to the
# path. Lets the later package depend on the earlier
@@ -485,8 +477,6 @@ class buildset:
'=' * (74 -
len(configs[s]
bs = buildset(configs[s], self.configs, opts, macros)
bs.build(deps, nesting_count, mail)
-if self.installing():
-have_staging = True
del bs
elif configs[s].endswith('.cfg'):
if mail:
@@ -620,7 +610,7 @@ class buildset:
#
# If builds have been staged install into the final prefix.
#
-if have_staging and not have_errors:
+if not have_errors:
stagingroot = macro_expand(self.macros, '%{stagingroot}')
have_stagingroot = path.exists(stagingroot)
do_install = not self.opts.no_install()
--
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
