Hi
The PDF and HTML versions of the new POSIX Issue 8 are now available.
I have copied the announcement below:
Dear all
I am pleased to announce that the html version of the 2024 edition is now
available to read online, more information and registration at
http://publications.opengroup.org/c243
This looks like a newlib patch we want to be sure to pick up in the next
newlib hash update.
-- Forwarded message -
From: Alexey Lapshin
Date: Mon, Jul 8, 2024 at 2:39 AM
Subject: [PATCH] stdatomic: make atomics compatible with GCC-14
To: new...@sourceware.org
https://gcc.gnu.
Thoughts on updating to this for rtems6?
-- Forwarded message -
From: Joel Brobecker via Gdb-announce via Gdb
Date: Sun, Jul 7, 2024 at 1:04 PM
Subject: [ANNOUNCEMENT] GDB 15.1 released!
To:
Cc: Joel Brobecker via Gdb-announce
GDB 15.1 released!
Release 15.1 of G
Thanks. What times?
On Thu, Jul 4, 2024, 12:12 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> - Am 4. Jul 2024 um 18:12 schrieb Joel Sherrill j...@rtems.org:
>
> > On Thu, Jul 4, 2024, 1:06 AM Sebastian Huber <
> > sebastian.hu..
On Thu, Jul 4, 2024, 1:06 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> - Am 3. Jul 2024 um 19:29 schrieb Joel Sherrill j...@rtems.org:
>
> > Hi
> >
> > When/how do the mirrors of gcc, binutlls, newlib, etc get updated?
>
> They are
Hi
When/how do the mirrors of gcc, binutlls, newlib, etc get updated?
I just patches to newlib this morning and one was to address a small
problem blocking part of a GSoC project.
Thanks.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtem
On Fri, Jun 28, 2024 at 7:30 PM Gedare Bloom wrote:
> On Fri, Jun 28, 2024 at 10:41 AM Gedare Bloom wrote:
> >
> > On Thu, Jun 27, 2024 at 11:39 PM Sebastian Huber
> > wrote:
> > >
> > > On 28.06.24 00:42, Gedare Bloom wrote:
> > > > I've been doing back through my third-party source code attri
On Sun, Jun 23, 2024, 12:43 PM John Howard wrote:
> Hello.
>
> I need Ada for RTEMS on Raspberry Pi. I will settle for whichever versions
> work together.
>
> After moving to gitlab, is Ada continuously built and tested for RTEMS?
>
> Today, my non-gitlab RSB 5.3 build failed on Debian with error
I reported this to newlib@ and someone posted a patch which is now
merged and mirrored to the RTEMS github.
I am updating the RSB to the new newlib hash and hopefully will push
the MR tomorrow for review.
--joel
On Mon, Apr 29, 2024 at 1:42 PM Joel Sherrill wrote:
>
>
> On Sun, Apr
Hi
The subject says it all. Doesn't look like the POSIX APIs are even
included, CMSIS Definitions is listed 27 times with at least some not
linking to content, etc. There are other headings which appear repeatedly.
I am basically ignoring the warning messages.
Can someone please look at this and
On Fri, May 31, 2024 at 2:57 AM wrote:
> Hello Joel,
>
> Am 30.05.24 um 17:04 schrieb Joel Sherrill:
> > Hi
> >
> > In reviewing ports for deprecation, I noticed that a few architectures
> > have some very old BSPs which are unlikely to be used anymore. Dropp
Hi
In reviewing ports for deprecation, I noticed that a few architectures have
some very old BSPs which are unlikely to be used anymore. Dropping
architectures and BSPs is beneficial for a few reasons:
+ Architecture removal cuts down on tool configurations when building all
architectures.
+ BSP
Hi
There does not appear to be any recent activity for this port in RTEMS.
Thread Local Storage is not supported yet. Dynamic loading has a mips
dependent file but it looks like the last work was a patch from 2016 which
was committed in 2020. No idea if this works.
MIPS Technologies is now a RISC
Hi
There does not appear to be any activity for this port and the Moxie
project does not have any recent activity.
Any objections to deprecating this for 6 and removing before 7?
Thanks
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.
.3.11 for the same toolchain. It is currently available in
> Linux and Baremetal toolchains since April/May. From a maintainence
> perspective, having it also in RTEMS6 releases sounds very good.
>
> Thanks, Daniel
>
>
> Den 5/30/2024 kl. 1:44 AM, skrev Joel Sherrill:
>
>
Thanks. It may be a couple of days before I have a merge request ready.
Thanks.
On Wed, May 29, 2024, 6:28 PM Chris Johns wrote:
> On 30/5/2024 7:22 am, Joel Sherrill wrote:
> > I am in the middle of updating gcc to the recent 13.3 release to move us
> off a
> > git hash.
&g
Hi
I am in the middle of updating gcc to the recent 13.3 release to move us
off a git hash.
Is there any reason we are still on gdb 13? gdb 14.1 was released in Dec
2023.
Is there any reason we are still on binutils 2.41? binutils 2.42 was
release in Jan 2024.
I don't mind updating them if no o
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 relea
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
> Chris
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 "CC_FOR_BUILD=g
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 RSB
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 wait
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 b/rtems
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 pat
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 s
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: D
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 in
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 deletions(-)
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 m
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 Bea
it also makes sense to have 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
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: ash
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:
> I
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
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 zac
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 w
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 mpfr.h
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-examples
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 ++--
rtems/config/tools/rtems-gcc-13-newlib-head.cf
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 a/rtems/config/tools/rtems-to
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 fi
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 b/linkers/rtems-score-thread.i
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 arm/tms570ls3137_hdk_with_load
-- 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
https://u15810271.ct.sendgrid.net/ls/click?upn=u001.A
-- 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
https://u15810271.ct.sendgrid.net/ls/cl
-- 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
https://u15810271.ct.sendgrid.net/ls/clic
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 no
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
*** /home/joel/rtems-6.
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
>
ou on 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 b
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 patche
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:
> patches/Make-lang.in-b09fb02bb4c0d16fc2c842bec4069c033897b5f2.
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 bd7cde628f..d480eb3971
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*
imx/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 b
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 s
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
> > Acco
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 testi
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, 2
---+-
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:
/home/joel/rtems-6.1rc1/rt
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 command
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(-)
>
> di
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. Wha
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 a/cpuk
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 d1dc08a5c4..675
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
> cpukit/lib
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 di
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:e31a0b22fe43e0
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
"/home/joel/rtems-work/rtems-doc
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 +-
>
1 - 100 of 2729 matches
Mail list logo
