GCC is getting closer to a real release. When this drops, we need to switch
the RSB to it for 6 tools.
--joel
-- Forwarded message -
From: Jakub Jelinek via Gcc
Date: Tue, May 14, 2024, 11:33 AM
Subject: GCC 13.3 Release Candidate available from gcc.gnu.org
To:
The first
On Thu, May 2, 2024 at 11:48 PM Chris Johns wrote:
> Hi,
>
> This email ask for the rtems-deployment repo to be moved RTEMS/Tools in
> GitLab.
>
> It is a repo of RSB configs to build packages of common or user specific
> vertical stacks.
>
I am in favor of it moving.
--joel
>
> Thanks
>
Hi
If you have any patches that are still pending on the mailing list, please
get yourself an account on gitlab.rtems.org and submit them as a merge
request.
Instructions are linked to in Chris' emails.
Help is available on devel@ and Discord.
Thanks.
--joel
gitlab.rtems.org is now alive.
Please setup an account and follow the instructions for a merge request.
We need to see how well things are working. :)
--joel
On Sun, Apr 28, 2024 at 11:35 PM Muhammad Sulthan Mazaya <
msulthanmaz...@gmail.com> wrote:
> Bumping last update of last year's renode
On Sun, Apr 28, 2024 at 3:18 PM Joel Sherrill wrote:
>
>
> On Sun, Apr 28, 2024 at 6:17 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello,
>>
>> the m68k, sh, and sparc64 build fails with GCC 14 due to:
>>
>
> Two of
On Sun, Apr 28, 2024 at 6:17 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
>
> the m68k, sh, and sparc64 build fails with GCC 14 due to:
>
Two of those are scheduled to be removed after we branch 6.
So only the m68k really matters. More below.
>
> make
On Sun, Apr 28, 2024 at 6:13 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
>
> in order to build the nios2 GCC 14, you have to add --enable-obsolete to
> the configure command line. With this option, it builds fine. I am not
> sure how this option can be added to the
On Fri, Apr 26, 2024, 12:49 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 26.04.24 00:38, Chris Johns wrote:
> > Hi RTEMS Community
> >
> > The git repos on git.rtems.org are open and accepting patches. The
> GitLab repos
> > will move us to main, something we have been
On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:
>
> > Hi,
> >
> > There has been some discussion about when we will branch and it is
> timely we
> > discuss this. This is my input. :)
On Sat, Apr 20, 2024, 7:19 PM Chris Johns wrote:
> On 19/4/2024 7:15 pm, andrew.butterfi...@scss.tcd.ie wrote:
> > Will you also do this with the formal code in rtems-central/formal ?
>
> Sorry, I do not use it so would prefer not to update it just yet. I think
> it
> best left to the leaders of
Please apply both. I think this was the only bad issue with rc2 on CentOS 7
or 8.
On Thu, Apr 18, 2024 at 10:09 PM wrote:
> From: Chris Johns
>
> ---
> rtemstoolkit/execute.py | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/rtemstoolkit/execute.py
On Thu, Apr 18, 2024, 7:31 PM Chris Johns wrote:
> Hi,
>
> I would like to run the python code we own through yapf and it's default to
> standardise the formatting and to being it inline with the coding
> standards. It
> would be good to do this before we branch for RTEMS 6.
>
> I can crate a
On Thu, Apr 18, 2024 at 2:00 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hallo Joel,
>
> it would be nice to have the interrupt get/set priority directives in
> RTEMS 6. When do you want to create the RTEMS 6 branch?
>
Last spring.
Seriously, Chris has been cutting 6.1 rc
On Thu, Apr 18, 2024 at 9:50 AM Peter Dufault wrote:
>
>
> > On Apr 18, 2024, at 10:34 AM, Kinsey Moore
> wrote:
> >
> > A patch for EEXIST here should be fine. It would be nice if the caller
> were more resilient.
> >
>
> I also changed "default-network-init.h" to assert rtems_bsd_initialize()
We should track this but if the GNU tools drop support, this is normally
the trigger for RTEMS.
Unless the support situation changes, I think we will have to remove nios2
in RTEMS 7
--joel
-- Forwarded message -
From: Sandra Loosemore
Date: Wed, Apr 17, 2024, 10:28 PM
Subject:
Hi
6.1rc3 appears to be in pretty good shape on CentOS 7 (w/GCC 8 and Python 3
SCL). Results should be on the build@ list. One odd issue appears to be in
the rtems-tester.
Testing a riscv-bsp with spike, I get this output. It is repeated with
other spike/risc-v bsp tests. Any ideas?
Exception
This is ok to push.
Unfortunate but this is the reality. A GCC 14 release is still future tense.
On Sat, Apr 13, 2024, 8:49 PM wrote:
> From: Chris Johns
>
> Change back to gcc-13 branch and a git version as gcc-13.2 does
> not build on MacOS 14.4. The fixes are on the gcc-13 release branch.
This looks ok.
On Tue, Apr 9, 2024, 7:30 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> The processor mask implementation uses flsl() from which is
> only BSD visible. Move the implementation to a separate header file to
> hide it from the API level. This fixes build errors
Is 14 the version for RTEMS 7 tools? If so, that makes it easier to address
the issues.
And Chris says we need 13 for RTEMS 6 because older doesn't compile on new
Mac tools. So that needs action.
On Tue, Apr 9, 2024, 8:29 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
for
> readability.
>
> Kinsey
>
> On Wed, Apr 3, 2024 at 11:29 AM Joel Sherrill
> wrote:
>
>> This looks handy. I don't have an issue with it.
>>
>> On Tue, Apr 2, 2024 at 11:25 PM wrote:
>>
>>> From: Chris Johns
>>>
>>> ---
This looks handy. I don't have an issue with it.
On Tue, Apr 2, 2024 at 11:25 PM wrote:
> From: Chris Johns
>
> ---
> source-builder/sb-rtems-pkg | 29
> source-builder/sb/download.py | 5 +-
> source-builder/sb/git.py | 12 ++
> source-builder/sb/rtemspkg.py | 279
Looks good. I will push.
On Tue, Apr 2, 2024 at 11:23 PM wrote:
> From: Chris Johns
>
> ---
> rtems/config/tools/rtems-kernel-6.cfg | 4 ++--
> rtems/config/tools/rtems-libbsd-6.cfg | 4 ++--
> rtems/config/tools/rtems-tools-6.cfg | 6 +++---
> 3 files changed, 7 insertions(+), 7
This patch looks ok. We also need a screenshot of it running.
I hope you made the deadline of applying via the Google site.
We track proposals at https://devel.rtems.org/wiki/GSoC/2024
On Tue, Apr 2, 2024 at 2:47 PM SEAN TANG wrote:
>
> ___
> devel
On Tue, Apr 2, 2024, 9:28 AM Purva Yeshi wrote:
> Hello,
>
> I'm reaching out to seek clarification regarding the initial scope of the
> "Add BSP for Polarfire based Beagle" project that I've applied for.
>
> As outlined in the project description, the primary aim is to create a BSP
> for the
ve a way to avoid it.
>
It also leads to dead/unused code in any deployment whose BSP uses this file
Feel free to submit a patch
>
> > On Mar 29, 2024, at 2:05 PM, Joel Sherrill wrote:
> >
> > Hi
> >
> > Chris and I discussed this for a few minutes
You do not edit the master proposal template. You make a copy of it and
turn it into your proposal.
--joel
On Sat, Mar 30, 2024 at 12:29 AM ashish ashish
wrote:
> I requested on google docs for editing to write my proposal. and it needs
> approval.
> please approve it.
> request with email:
Hi
Chris and I discussed this for a few minutes last night and wondered if
code like this which includes arbitrary CPU model specific code could
be the culprit?
https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc_initialize.c#n65
There may be other sections that do this.
If
This is a great explanation. Would you mind filing a ticket with this
explanatino and referencing the ticket in the commit message of the patch?
When someone wonders about the change in the future, the ticket explanation
will be useful
On Fri, Mar 22, 2024 at 9:24 PM Matheus Pecoraro wrote:
>
On Thu, Mar 21, 2024 at 9:06 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 21.03.24 15:05, Joel Sherrill wrote:
> > Isn't this content generated from rtems-central?
>
> Yes, it is generated.
>
> >
> > Shouldn't there also be a change
Isn't this content generated from rtems-central?
Shouldn't there also be a change there?
--joel
On Wed, Mar 20, 2024 at 9:24 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Close #4986.
> ---
> c-user/config/general.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi
Did gprof support some along as a side-effect of gcov support?
Any hints on getting it working appreciated.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
This is generally ok but it contradicts the documented behavior
for CONFIGURE_TICKS_PER_TIMESLICE which states "The value of the
configuration option shall be greater than or equal to zero."
If zero is to be an error, then that needs to change.
Further, this series of changes has made me realize
No. Just a lesson to remember -- Everyone along the path should have built
rtems with all tests enabled.
This is something that should never happen after the upcoming transition to
GitLab. It definitely shows we need to build at least one BSP with tests
enabled.
On Mon, Mar 18, 2024, 7:45 PM
What does support for UTF-32 entail? Do you have an idea what software
functions you are looking for?
I see the International Components for Unicode (ICU) has a converter (
https://icu.unicode.org/download) which looks it might be part of a
solution.
Multibyte character methods defined by POSIX
Hi
I am going through the logs on the test sweep VMs to see why some builds
are failing. This is due to gdb's requirement for GMP and MPFR. What's the
recommended way to address this? Load native packages?
checking for the correct version of gmp.h... yes
checking for the correct version of
Thanks. All pushed now.
On Thu, Mar 14, 2024 at 6:46 PM Chris Johns wrote:
> OK
>
> Thanks
> Chris
>
> On 12/3/2024 1:06 am, Joel Sherrill wrote:
> > _Thread_Close no longer exists. There are multiple exapmles which
> > show tracing in rtems-e
This was driven by the increase in fdset size from 64 to 256
files.
---
rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 4 ++--
rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++--
rtems/config/tools/rtems-gcc-12-newlib-head.cfg | 4 ++--
In particular, the BSP set definitions for rtems-bsp-builder were
out of sync with RTEMS and caused unnecessary failures reported to
the build@ mailing list.
---
rtems/config/tools/rtems-tools-6.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
FWIW I am still waiting for an ACK on the fdset size increase patch to
newlib. Once that's in place, I will bump the rtems-tools hash and newlib
hash.
--joel
On Mon, Mar 11, 2024 at 10:16 PM Chris Johns wrote:
> On 11/3/2024 6:04 pm, Sebastian Huber wrote:
> > sorry for breaking the build. I
On Mon, Mar 11, 2024 at 12:14 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 09.03.24 22:39, Joel Sherrill wrote:
> > Hi
> >
> > The build sweep using rtems-bsp-builder reports that 8 build
> > configurations of arm/tms570ls3137_hdk_with_l
_Thread_Close no longer exists. There are multiple exapmles which
show tracing in rtems-examples which fail to link due to this.
---
linkers/rtems-score-thread.ini | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/linkers/rtems-score-thread.ini
Hi
In looking at the build sweep log, I see what looks like motorola_powerpc
and beatnik all have a common build failure that results in 53
configurations failing per
https://lists.rtems.org/pipermail/build/2024-March/051698.html
This is one but there are a lot.
debug powerpc/mvme2307 build:
Hi
The build sweep using rtems-bsp-builder reports that 8 build configurations
of arm/tms570ls3137_hdk_with_loader fail. See the following for more
details.
https://lists.rtems.org/pipermail/build/2024-March/051698.html
The first reported configuration is:
1 debug
-- Forwarded message -
From:
Date: Mon, Mar 4, 2024 at 7:49 PM
Subject: Coverity Scan: Analysis completed for RTEMS
To:
Your request for analysis of RTEMS has been completed successfully.
The results are available at
-- Forwarded message -
From:
Date: Mon, Mar 4, 2024 at 7:51 PM
Subject: Coverity Scan: Analysis completed for RTEMS-Newlib
To:
Your request for analysis of RTEMS-Newlib has been completed
successfully.
The results are available at
-- Forwarded message -
From:
Date: Mon, Mar 4, 2024 at 5:56 PM
Subject: Coverity Scan: Analysis completed for RTEMS-Tools
To:
Your request for analysis of RTEMS-Tools has been completed
successfully.
The results are available at
Hi
Coverity required an update of their client tool to keep doing scans. The
new client tool was based on a libc library version which was newer than
what was on the machine running the scans. This required setting this up
again on another computer with a newer OS.
I am forwarding three Coverity
On Fri, Mar 1, 2024 at 8:21 AM Kinsey Moore
wrote:
> A very similar change was made in 2017 to resolve the same warning for a
> different variable. The only real difference is that it is wrapped in
> __rtems__ ifdefs. I can move this change to the #ifdef'd section if that's
> preferable.
>
Do
Hi
Looks pretty good overall. This appears to be the only issue:
Testing: riscv rv64imac_spike
BSP to Build: rv64imac
'distclean' finished successfully (0.011s)
Regenerate build specification cache (needs a couple of seconds)...
real 0m25.545s
user 2m30.639s
sys 0m29.614s
***
Hi
rtems 6.1rc2 has a lot of tool build failures because I didn't have
gmp-devel installed.
hecking for gmp.h... no
configure: error: gmp.h header not found
This is reported as part of building gcc-newlib. Should the RSB account for
this by building gmp at the same time?
For now, I installed a
Based on Christian saying it works and me confirming that, I pushed this.
Thanks a lot Chris!
--joel
On Wed, Feb 21, 2024 at 2:22 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:
> Hello Chris,
>
> On 2024-02-21 06:16, Chris Johns wrote:
> > Hi,
> >
> > I have a patch for
I think this is ok also.
On Sun, Feb 18, 2024, 10:20 PM Chris Johns wrote:
> Looks good. Thanks
>
> Chris
>
> On 19/2/2024 3:16 pm, Kinsey Moore wrote:
> > This adds a pthread that runs the test as well to increase test
> > coverage. The original test would have passed if all threads returned
>
what to edit for this and
how to propagate it dull.
>
>
> On Wed, 14 Feb 2024 at 09:28, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>>
>>
>> On 14.02.24 15:18, Joel Sherrill wrote:
>> > I'm cc'ing Sebastian because you e
On Wed, Feb 14, 2024 at 1:37 PM Kinsey Moore
wrote:
> On Wed, Feb 14, 2024 at 9:14 AM Sam Price wrote:
>
>> I was wondering if you had any notes on your process of working with
>> qemu in the rtems builder.
>> I imagine you have your own xilinx qemu forked to work on, and then
>> take the
On Fri, Feb 16, 2024, 12:56 AM Chris Johns wrote:
> Hi,
>
> I have opened https://devel.rtems.org/ticket/4991 to track checksum
> errors in
> some of the sources being downloaded by the RSB such as:
>
> error: checksum failure file:
>
I'm cc'ing Sebastian because you edited the text in a generated file. He
should be able to point us to the right place to fix it.
On Mon, Feb 12, 2024 at 8:26 PM wrote:
> From: Zack leung
>
> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
> index
Hi
In looking at linkcmds code, one of the folks in the class noticed this
symbol which appears to be unused. This is a grep from the top of the tree.
It appears that bsp_stack_main_size is defined but never really used. If
someone can confirm this, it needs to be purged.
[joel@localhost rtems]$
Hi
While teaching a class this week, I noticed that some arm optcachedata.yml
files appear to reference BSP variants that are not associated with the BSP
whose directory the yml file is located in. These greps show the issue:
[joel@localhost arm]$ grep lm3s6965_qemu */optcachedat*
Hi
https://docs.rtems.org/branches/master/c-user/rate-monotonic/background.html#schedulability-analysis
has a bullet list which does not have bullets. But they are there in the
PDF version:
https://docs.rtems.org/branches/master/c-user.pdf
Is there something wrong with the markup? Is something
Ignoring any specific technical comments from others.
(1) Should this have a ticket? Seems impactful and odd enough to since that
shows up in release notes.
(2) Should it also be applied to 5.x with a separate ticket?
--joel
On Fri, Feb 2, 2024 at 4:40 PM Kinsey Moore
wrote:
> On JFFS2 file
On Wed, Jan 31, 2024 at 12:31 AM Karel Gardas
wrote:
> On 1/30/24 18:13, Frank Kühndel wrote:
> > Which name Rust accepts instead of "armv7a-rtems6-eabihf" depends on the
> > naming convention of the Rust community:
> > https://docs.rust-embedded.org/embedonomicon/custom-target.html
> >
On Tue, Jan 30, 2024 at 3:15 PM Joel Sherrill wrote:
>
>
> On Tue, Jan 30, 2024 at 11:13 AM Frank Kühndel <
> frank.kuehn...@embedded-brains.de> wrote:
>
>> Hello Jan,
>>
>> On 1/29/24 19:41, jan.som...@dlr.de wrote:
>> > Hi everyone,
>> >
On Tue, Jan 30, 2024 at 11:13 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:
> Hello Jan,
>
> On 1/29/24 19:41, jan.som...@dlr.de wrote:
> > Hi everyone,
> >
> > As mentioned in the other Rust thread, I am working on an initial Rust
> port for RTEMS.
> > The target platform for
Looksike some of the rece t activities around the tms750 BSP have not been
fully accounted for.
Remember that if the set of BSPs has changed, the tiers definition files in
rtems-tools need to be updated
-- Forwarded message -
From: OAR Tester for Ubuntu 22.04
Date: Sat, Jan 20,
---+-
Reporter: Joel Sherrill | Owner: Ralf Corsepius
Type: defect | Status: closed
Priority: normal | Milestone: 2
Component: bsps | Version: unknown
Severity: major | Resolution: fixed
Keywords
Looks like one of the commits has the wrong ticket number.
And this ticket should be closed anyway. We haven't used GNATS in a long
time.
-- Forwarded message -
From: RTEMS trac
Date: Mon, Jan 15, 2024, 3:37 AM
Subject: Re: [RTEMS Project] #60: GNATS: Additional state
To:
Cc:
Hi
I was trying to test rc1 and all of the tool builds fail like this:
==
script: 86: source_dir_rtems_tools=${rtems_tools_source}
source setup: rtems-tools-6.1-rc1-1: source rtems-tools -q -n
${rtems_tools_source}
making dir:
Chris.. an RSB feature submission question at the bottom.
Rest inlined.
On Tue, Jan 9, 2024 at 9:30 AM Michael G. South wrote:
>
> > On Jan 8, 2024, at 10:53 , Joel Sherrill wrote:
> >
> >
> >
> > On Mon, Jan 8, 2024 at 10:13 AM Frank Kühndel <
> f
On Mon, Jan 8, 2024 at 10:13 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:
> Hi Joel,
>
> have a great 2024!
>
> On 12/24/23 22:16, Joel Sherrill wrote:
> > Hi
> >
> > Trying to bring up Coverity builds on a Centos 8 machine, I ran into
&
On Thu, Jan 4, 2024, 5:47 PM zhengxiaojun <17935...@qq.com> wrote:
>
>
> 在 2024/1/5 4:25, Peter Dufault 写道:
> > I guess maybe the list went down for a while. I sent this on 12-30, and
> just got a bounce message today and no "devel" mail until today.
> >
> > On master when I type a shell
Don't we put a space after the (void)?
On Thu, Jan 4, 2024 at 12:55 PM Kinsey Moore
wrote:
> An error is already being reported. Checking the return value of this
> function is not useful.
> ---
> cpukit/libfs/src/dosfs/msdos_file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
https://docs.rtems.org/branches/master/eng/vc-users.html#commit-message-guidance
If that is missing something, please ask questions and we can address the
Software Engineering Guide.
--joel
On Thu, Jan 4, 2024 at 2:24 PM Bernd Moessner
wrote:
> Dear Kinsey,
>
> sry for the stupid question.
On Thu, Jan 4, 2024 at 12:49 PM Kinsey Moore
wrote:
> All of the patches here need an issue reference. Beyond that, this patch
> is good to go in. I'm still reviewing the remainder of the set and I'll
> leave the renaming discussion to Aaron.
>
I have only gotten this far into the patch set but
This looks ok to me. Just more name realignment which shouldn't impact much.
On Thu, Jan 4, 2024 at 12:34 PM wrote:
> From: Bernd Moessner
>
> ---
> cpukit/libmisc/shell/main_flashdev.c | 36 ++--
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git
This looks ok to me. Similar naming change.
On Thu, Jan 4, 2024 at 12:34 PM wrote:
> From: Bernd Moessner
>
> ---
> cpukit/dev/flash/flashdev.c | 72 +--
> cpukit/include/dev/flash/flashdev.h | 12 ++--
> .../libtests/flashdev01/test_flashdev.c
This looks ok to me.
On Thu, Jan 4, 2024 at 12:34 PM wrote:
> From: Bernd Moessner
>
> ---
> cpukit/include/dev/flash/flashdev.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/cpukit/include/dev/flash/flashdev.h
> b/cpukit/include/dev/flash/flashdev.h
> index
I'm ok with this. I like the subject/verb/direct object naming of the
ioctls.
--joel
On Thu, Jan 4, 2024 at 12:34 PM wrote:
> From: Bernd Moessner
>
> ---
> cpukit/dev/flash/flashdev.c | 16
> cpukit/include/dev/flash/flashdev.h | 16
>
Hi
Trying to bring up Coverity builds on a Centos 8 machine, I ran into this:
+ ../source-builder/sb-set-builder --log=l-sparc.txt
--prefix=/home/joel/rtems-cron-coverity/tools/6 --mail --mail-to=
bu...@rtems.org --mail-from=j...@rtems.org 6/rtems-sparc
/usr/bin/env: ‘python’: No such file or
Any suggestions on how to address these?
-- Forwarded message -
From:
Date: Sun, Dec 24, 2023, 1:18 PM
Subject: New Defects reported by Coverity Scan for RTEMS-Tools
To:
Hi,
Please find the latest report on new defect(s) introduced to RTEMS-Tools
found with Coverity Scan.
39
It is working for me on Rocky 9 with Sphinx 7.2.6 and a Texlive from this
summer.
The missing step was removing the older Sphinx version. Then I had to also
install PlantUML npm.
--joel
On Tue, Dec 19, 2023 at 3:45 PM Chris Johns wrote:
> On 20/12/2023 8:12 am, Joel Sherrill wrote:
&g
It didn't work on the CentOS 7 system because Chris pushed while I was
switching VMs.
I now get the same output on CentOS 7 as on Rocky 9. It has sphinx-build
5.3.0
--joel
On Tue, Dec 19, 2023 at 3:10 PM Chris Johns wrote:
> Module:rtems-docs
> Branch:master
> Commit:
I tried the patch on Rocky 9 with Python 3.9.14 and sphinx-build 5.3.0
from a pip local install.
(rtemsdocs) [joel@localhost rtems-docs]$ ./waf distclean
Waf: The wscript in '/home/joel/rtems-work/rtems-docs' is unreadable
Traceback (most recent call last):
File
On Tue, Nov 28, 2023 at 10:27 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> ---
> c-user/glossary.rst | 50 +++
> eng/fv/approaches.rst | 2 +-
> eng/fv/overview.rst | 6 +++---
> eng/glossary.rst | 26 +-
Since no one commented/complained and I saw no obvious issues, I took the
liberty to commit these.
Thanks.
--joel
On Tue, Nov 21, 2023 at 2:02 PM Bernd Moessner
wrote:
> From: Bernd Moessner
>
> ---
> spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml | 4 +++-
> 1 file changed, 3
Gdb now needs a couple of those installed. Perhaps they need to be in the
bset.
Also FreeBSD 12 and 13 regularly fail. See build@ for details.
On Sun, Nov 26, 2023, 6:53 PM Chris Johns wrote:
> On 27/11/2023 1:35 am, Sebastian Huber wrote:
> > Hello,
> >
> > could some issues on macOS be cased
On Tue, Nov 21, 2023 at 5:29 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 12.09.23 08:43, Sebastian Huber wrote:
> >
> >
> > On 12.09.23 08:40, Chris Johns wrote:
> >> On 12/9/2023 4:31 pm, Sebastian Huber wrote:
> >>> On 27.07.23 13:33, Sebastian Huber wrote:
>
Thanks.
Ask Kinsey some time the weird situation that caught this.
--joel
On Tue, Nov 21, 2023 at 3:05 PM Chris Johns wrote:
> OK to all 3 and thanks
>
> Chris
>
> On 21/11/2023 11:39 pm, Sebastian Huber wrote:
> > Pick up fixes for ARM/optimized-routines and the memory reclamation at
>
Thanks. I will pass this along and resubmit a patch to at least add a
comment and fix formatting issues.
Do we have a good place to add this information to the documentation?
On Tue, Nov 21, 2023, 5:35 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 20.11.23 18
Hi
I got a message from the last Coverity Scan run that I need to update the
Scan tool used to run them.
With this being a short week (US Thanksgiving), I don't know if I will get
to it in the next couple of days.
--joel
___
devel mailing list
Pushed.
Thanks.
On Sun, Nov 19, 2023 at 5:44 PM Chris Johns wrote:
> Looks good and thanks
>
> Chris
>
> On 18/11/2023 5:11 am, Joel Sherrill wrote:
> > This configuration file was missing for the mipstx39 gdb build for the
> > head/7 tools.
> >
> >
The loop that waits for another thread to complete the once
initialization was flagged as a potential infinite loop.
This is because there was no way to break out of the loop
inside the loop. The solution is to make the state variable
volatile which indicates it may be modified by another thread
This configuration file was missing for the mipstx39 gdb build for the
head/7 tools.
Closes #4935.
---
rtems/config/tools/rtems-mipstx39-gdb-head.bset | 7 +++
1 file changed, 7 insertions(+)
create mode 100644 rtems/config/tools/rtems-mipstx39-gdb-head.bset
diff --git
Ok. Push this.
On Fri, Nov 3, 2023, 9:19 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 03.11.23 14:56, Joel Sherrill wrote:
> > Does this mean that anything under tests and bsps will not have coverage?
>
> The tests itself are built without covera
Seems reasonable.
Does this mean that anything under tests and bsps will not have coverage?
--joel
On Fri, Nov 3, 2023 at 3:58 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> The goal is to get code and branch coverage from actual tests and not
> the test support itself.
>
Seems ok.
On Fri, Nov 3, 2023 at 3:58 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Move the RTEMS test printer and rtems_test_exit() to separate files, to
> remove dependencies from the begin/end test messsage support.
>
> Update #4963.
> ---
> cpukit/libtest/testbeginend.c
I noted a few cases where I don't think the value used is interesting
enough or an edge case. Hopefully I caught them all.
On Thu, Nov 2, 2023 at 7:12 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Test more compiler builtins which may use integer library routins:
>
routines.
Sorry. Not sure how this kept slipping through the cracks. The 13
September ping did coincide with me being on a trip and then sick.
This is the only revision I see in my inbox. There is an email which says
"how about this version?" but I don't see anything on it.
A few comments inline.
On
What caused all the recently posted tool build failures?
On Mon, Oct 9, 2023, 4:52 PM Chris Johns wrote:
> Ok to all patches in the series. Thanks for newlib changes for ARM, they
> will be
> nice to use.
>
> Chris
>
> On 10/10/2023 3:58 am, Sebastian Huber wrote:
> > Pick up latest changes
Random thought. Is there a gnat1? Can you build a native Ada hello world?
I'm not sure what that configure check is trying but looking at that is the
next step.
On Wed, Oct 4, 2023, 12:02 PM emanuel stiebler wrote:
> I just tried to compile the tools for rtems6,
> and just with "C",
---
cpukit/libfs/src/dosfs/fat_fat_operations.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cpukit/libfs/src/dosfs/fat_fat_operations.c
b/cpukit/libfs/src/dosfs/fat_fat_operations.c
index 24a408f9c7..1d94beb26a 100644
---
1 - 100 of 5850 matches
Mail list logo
