There was a mistaken push to the RTEMS main repository earlier. These things
happen so we have rewound the repository back to the latest safe commit.
This is 1425735.
If anyone did checkout the repository afterwards they will get an error when
trying to update as the repository has been
Several of our sites will be going down randomly starting this afternoon
2023-09-16 GMT to 2023-09-18 8AM GMT.
Given the importance of GSoC I hope to have this work done before the weekend.
The sites that will be down are:
lists.rtems.org
docs.rtems.org
git.rtems.org
devel.rtems.org
I will be updating the servers that host our primary services today 2023-02-10
until 2023-02-13 8AM GMT.
This means any WWW services on *.rtems.org, email, FTP will be disrupted at
some point.
The downtime should be contiguous anywhere from 2-4 hours.
I will prioritise these services before
Everything should be back up and running again please let me know if there are
any issues.
The only user-facing service we have using the database is
https://devel.rtems.org/ so no other service is affected by this.
Amar.
___
devel mailing list
At some point today 2022-02-09 https://devel.rtems.org/ will go down as the
machine that hosts our database goes through some upgrades. Any issues or
intermittent outages should be gone by 6AM GMT 2022-02-10.
Amar.
___
devel mailing list
On 2023-01-20 11:03 +1100, Chris Johns wrote:
> It is good to know the amount of python is small. It should be easy to add :)
Agreed.
> I have been OK with the headers and tests being generated this way because the
> agreement is files in rtems.git can be manually edited and rtems-central has
On 2023-01-19 08:21 +0100, Sebastian Huber wrote:
>
> In rtems-central.git there are Python modules and scripts which generate
> source, header, and documentation files from specification items. This
> repository contains the pre-qualification support for RTEMS. By
> accident, a part of the
On 2023-01-17 08:39 +0100, Sebastian Huber wrote:
>
> The Python modules to work with specification items are in
> rtems-central.git. This repository contains also a format specification
> of the build items. We could add an action to a Github work flow to
> check the build item format for
On 2020-03-30 00:43 +0530, Anmol Mishra wrote:
> Hello,
> While reading carefully, I can't completely understand regarding "high-level
> management utility"??Can you please elaborate on what is being asked or
> referenced?
Most if not all the utilities currently exist in their own respective
Hello Anmol.
Gedare covered essentially what this project covers.
To add a little further we want to push all the tools behind a common
accessible
API with the frontend tools being a thin wrapper.
This will allow us to have better testing of our tools as well as easing
maintenance by
On 2020-03-19 10:00 -0600, Gedare Bloom wrote:
> Thank you for kicking off this discussion. As with most style issues,
> a lot of personal preferences came out, but also some good reasoning
> was given on both sides.
Yeah, I know these conversations sometimes don't go well but everyone has been
The only one I would like to propose is the 80 character limit. This should be
moved to something more reasonable such as 120.
Code comments should remain below 80 however.
Python itself has not followed this rule for a long time you can see many lines
over 80 in the Python source itself.
On 2020-03-18 16:16 +1100, Chris Johns wrote:
>
> Are these plugins extra dependencies or are they part of our test code?
Dependencies on pytest but we can include them in the test suite just fine.
This is what I usually do. Most of them are a single Python file.
Amar.
On 2020-03-17 15:20 +0100, Sebastian Huber wrote:
>
> Ok, what would be a recommendation for the guidelines? Something like this:
>
> Place tests for a module in a directory. Use individual test files for tests
> related to a particular class or functionality, e.g. module/test_xyz.py.
>
> OR
>
On 2020-03-17 15:21 +0100, Sebastian Huber wrote:
>
> It seems that pytest recommends monkeypatch:
>
> https://docs.pytest.org/en/latest/monkeypatch.html
>
Yes, also I use this:
https://github.com/pytest-dev/pytest-mock
Plugins are extremely easy to use in pytest and are usually comprised
On 2020-03-17 06:52 +0100, Sebastian Huber wrote:
> So you would not use test classes to group tests for a specific class?
No I would not typically grouping tests involves keeping them in separate
files.
You gain no advantage to keeping them all in one large file. You can also use
directory
On 2020-03-17 10:55 +1100, Chris Johns wrote:
> On 17/3/20 7:21 am, Sebastian Huber wrote:
> > Chris, what do you think about using pytest in favour of the standard Python
> > unitttest?
>
> I am fine with pytest. Testing is a development feature and so we can have a
> different criteria for the
On 2020-03-16 21:21 +0100, Sebastian Huber wrote:
> >
> > https://lists.rtems.org/pipermail/devel/2020-March/058289.html
>
> I converted an example test from unittest to pytest:
There's no reason to use classes here you should use simple functions.
Classes are only useful if you want to
I should have also added some of my own reasons why pytest is better for
writing
tests in Python:
- Fantastic exception handling makes it far easier to debug test and code.
PDB works seamlessly.
- Far less overhead in creating initial tests.
- Trivial fixture support
-
On 2020-03-16 09:34 +0100, Sebastian Huber wrote:
> On 16/03/2020 00:57, Amar Takhar wrote:
>
> On 2020-03-16 09:20 +1100, Chris Johns wrote:
>
> Is pytest installed by default?
>
> No. It's a separate package the Python has 'unittest' which is shi
On 2020-03-16 09:40 +0100, Sebastian Huber wrote:
>
> I work currently on a draft for the Python development guidelines for the
> engineering manual. I hope to have something ready for review in the next
> days.
>
> Documenting the tests with with pydoc strings in general would be overkill
>
/conftest.py b/rtemstoolkit/conftest.py
new file mode 100644
index 000..3e1ec80
--- /dev/null
+++ b/rtemstoolkit/conftest.py
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: BSD-2-Clause
+
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright (C) 2020 Amar Takhar
+#
+# Redistribution and use
On 2020-03-15 21:18 -0600, Gedare Bloom wrote:
>
> I found what I was thinking about:
> http://google.github.io/styleguide/pyguide.html#313-imports-formatting
>
> PEP has similar guidance:
> https://www.python.org/dev/peps/pep-0008/#imports
PEP8 is so old that even the Python project breaks
On 2020-03-15 21:28 -0600, Gedare Bloom wrote:
> > +# Always find the parent directory of rtemstoolkit/ no matter where
> > +# pytest is run.
> > +def pytest_runtest_setup(item):
> > +path_toolkit = os.path.dirname(os.path.abspath(__file__))
> > +
On 2020-03-15 21:28 -0600, Gedare Bloom wrote:
> For new files, we should try to use the boilerplate recently suggested:
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#python-file-template
I'll fix this before pushing thanks.
> If that should be tweaked, now is the time to
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2020 Amar Takhar
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following
On 2020-03-16 11:48 +1100, Chris Johns wrote:
>
> That is understandable. Are the patches available in your personal repo?
They are not.
> I am fine with pieces being pushed after RTEMS 5 has branched. My concern is
> only related to the pending release. It is only a couple of weeks away if
>
On 2020-03-16 09:30 +1100, Chris Johns wrote:
> Hi,
>
> This looks good. Thank you for making the switch to pytest.
>
> Are you planning on moving all the exist "chris hacked" tests to pytest?
I don't know probably not I don't have the time this was to get someone started.
> If so I am
On 2020-03-14 11:12 +1100, Chris Johns wrote:
>
> I would like to hear what Sebastian is considering for the ESA work. I think
> we
> should follow what will be done there and ends up in the engineering manual.
If this is in regard to pytests that are being done for ESA work I agree I
would
On 2020-03-16 09:20 +1100, Chris Johns wrote:
>
> Is pytest installed by default?
No. It's a separate package the Python has 'unittest' which is shipped by
default. For our usage pyttest is more flexible and will create concise code
that is easy to contribute to. The biggest reason is that
On 2020-03-15 17:26 -0600, Gedare Bloom wrote:
> Make blank lines consistent, 1 or 2, between top-level definitions. (I
> know, we still haven't settled on a style, but let's aim for
> consistency.)
Okay.
> I think all imports should go at the top?
This is scoped it only runs under certain
On 2020-03-14 11:12 +1100, Chris Johns wrote:
>
> I would like to hear what Sebastian is considering for the ESA work. I think
> we
> should follow what will be done there and ends up in the engineering manual.
I'm talking about pytest specifically. The documentation is for the unit tests
not
On 2020-03-13 17:28 -0600, Gedare Bloom wrote:
> License/file header?
Oh, right I forgot about that, thank you.
> pydoc?
I've never added pydoc to this as it's a generic test class the documentation
is
in the test names eg, test_.*(). You can add a string above to add more
verbosity if
---
rtemstoolkit/darwin.py | 5 -
rtemstoolkit/freebsd.py | 5 -
rtemstoolkit/host.py| 14 --
rtemstoolkit/linux.py | 5 -
rtemstoolkit/netbsd.py | 5 -
rtemstoolkit/solaris.py | 5 -
---
rtemstoolkit/tests/test_error.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rtemstoolkit/tests/test_error.py b/rtemstoolkit/tests/test_error.py
index 85ceeae..fe768df 100644
--- a/rtemstoolkit/tests/test_error.py
+++ b/rtemstoolkit/tests/test_error.py
@@ -6,6 +6,6 @@
I'm aware of the typo in the internal test I've fixed this already.
Amar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Also check for 'pytest' during configure if not installed print a warning
about installing it to run new test suite.
---
wscript | 9 +
1 file changed, 9 insertions(+)
diff --git a/wscript b/wscript
index bd7c54d..79ab78e 100644
--- a/wscript
+++ b/wscript
@@ -104,6 +104,8 @@ def
This converts three files:
error.py:
- Check for exceptions and error messages
path.py:
- Test params and setting module variables
macros.py:
- Test class with setup and shared module access
This should cover the bulk of what is required to convert the rest to pytest.
Also removes the
On 2020-03-12 11:52 +0530, Anmol Mishra wrote:
> Hello,
> With whom can I discuss regarding douts, Any tentative??mentor open for
> guiding
> me, I have a few doubts regarding the project. Is Dr. Gedare going to be a
> tentative??mentor?
I am the mentor for this project. Can you please send any
On 2020-03-09 09:14 +1100, Chris Johns wrote:
> OK to push. Thank you for including the update to the tools with the tools
> change.
Sure, no prob.
Amar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
---
rtems/config/tools/rtems-tools-5-1.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
b/rtems/config/tools/rtems-tools-5-1.cfg
index cf097c4..e7f6183 100644
--- a/rtems/config/tools/rtems-tools-5-1.cfg
+++
On 2020-03-04 06:58 +0100, Sebastian Huber wrote:
>
> This is really nice. Getting mkimage for Windows was always a pain.
I've updated it to work under Python 2.7+ and switched to to use argparse plus
some other error checking.
Can you try this on your Windows machine to see how it works?
---
misc/wscript | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/misc/wscript b/misc/wscript
index d82bde3..b3faf7b 100644
--- a/misc/wscript
+++ b/misc/wscript
@@ -79,13 +79,13 @@ def build(bld):
'tools/cmd-tftpproxy.py',
On 2020-03-04 19:43 -0700, Gedare Bloom wrote:
> Reviewing on my phone: I see added blank lines, try to avoid unnecessary
> whitespace/format changes with functional changes in same commit. Although we
> haven't settled in a style, none of the proposed ones use more than 2 blank
> lines between
On 2020-03-04 19:37 -0700, Gedare Bloom wrote:
> Quick note sort copyright lines??earlier years below later years.
Whoops, I know this already I'll fix it thanks.
Amar.
___
devel mailing list
devel@rtems.org
On 2020-03-04 18:02 -0600, Joel Sherrill wrote:
> I think this is OK.??
>
> I will bump the newlib hash as soon as my patch to newlib is merged.
Great, thanks!
Amar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
---
rtems/config/tools/rtems-tools-5-1.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
b/rtems/config/tools/rtems-tools-5-1.cfg
index da22b4c..0c67901 100644
--- a/rtems/config/tools/rtems-tools-5-1.cfg
+++
---
misc/tools/mkimage.py | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
index 39a12a0..2b1524c 100755
--- a/misc/tools/mkimage.py
+++ b/misc/tools/mkimage.py
@@ -2,28 +2,28 @@
# A
Also changed 'python2' to 'python' in the shebang.
---
misc/tools/mkimage.py | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
index 0845ee4..38ed11e 100755
--- a/misc/tools/mkimage.py
+++ b/misc/tools/mkimage.py
--- a/misc/tools/mkimage.py
+++ b/misc/tools/mkimage.py
@@ -3,6 +3,7 @@
# A quickly bashed together replacement for u-boot's mkimage written in python
#
# Copyright 2010 Craig Barker
+# Copyright 2020 Amar Takhar
#
# Redistribution and use in source and binary forms, with or without
This is limited to Python 2.6+
---
misc/tools/mkimage.py | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
index 38ed11e..fd75f0a 100755
--- a/misc/tools/mkimage.py
+++ b/misc/tools/mkimage.py
@@ -27,6 +27,8 @@
#
On 2020-03-04 20:02 +1100, Chris Johns wrote:
>
> I am wondering how a user runs just the mkimake.py file once install. The
> rtems-tools repo normally packages a command in a wrapper that has has
> `/usr/bin/env python` and so $PATH etc works.
I added a python2 shebang in the 2nd commit it can
This script does work but needs some user friendliness added which is
acknowledged by the author as it was meant as a quick replacement.
---
misc/tools/mkimage.py | 2 ++
misc/wscript | 1 +
2 files changed, 3 insertions(+)
mode change 100644 => 100755 misc/tools/mkimage.py
diff --git
I emailed Craig Barker to ask if he would release his mkimage Python rewrite
as 2BSD. He graciously accepted and you can see his work here:
https://github.com/cmbarker83/pythonmkimage
This is a verbatim commit of 35d6d from his repository.
---
misc/tools/mkimage.py | 139
On 2020-03-02 09:41 +1100, Chris Johns wrote:
>
> I have managed to hack around the issue with the following command ...
>
> pip install sphinxcontrib-bibtex==0.4.1
>
> I am waiting for the build to be posted in the web server.
That sounds annoying sorry for the trouble. I use Python 3.7
On 2020-02-28 12:39 -0600, Joel Sherrill wrote:
>
> We can't blanket upgrade tools to Python 3. The only thing I think we agreed
> when this was recently discussed is that we have categories of tools in Python
> and some have to be compatible with Python 2 and 3.
I wasn't suggesting that. I
On 2020-02-28 09:25 -0700, Gedare Bloom wrote:
> >
> If there is enough work, and the work can be suitably identified, then
> it can also be a possible GSoC. There are also other possibilities to
> improve our existing Python code bases to adhere to some proposed
> Python coding conventions, which
On 2020-02-28 09:01 +1100, Chris Johns wrote:
> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit
> our
> users and simply linking the blobs into the executable would solve this.
> This also looks like a blocker for CI testing.
I agree with everything you said but
On 2020-02-27 20:06 +0100, Christian Mauderer wrote:
> > The only good way to handle this is to have it all in 1 giant repository we
> > work
> > with. Every other solution is a pain no matter how well thought out it is.
> > I
> > personally lean more on the service side of things that it
On 2020-02-27 08:45 +0100, Christian Mauderer wrote:
>
> It's just another problem that I noted sometimes on the mailing list
> with RTEMS and libbsd: Sometimes libbsd doesn't compile with some odd
> error messages like unresolved symbols. Most of the time the problem is
> that libbsd has been
On 2020-02-26 18:46 +0100, Christian Mauderer wrote:
> Hello Amar,
>
> somehow I missed your response this morning. My filter for the mailing
> list normally keeps stuff with my name in the inbox but your answer
> didn't contain it and therefore it was hidden in the mailing list folder.
No
Hi Niteesh, I have pushed the upgrade to the latest version of the theme.
Can you confirm this fixes the search box for you?
Thank you!
Amar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
I've had to deal with this issue quite a lot in the past it can be really
annoying having to maintain separate repositories where we have to 'pin' a
version to the main repo. We don't really have a choice here however I would
suggest we do a mix of the two.
1. Any source/permissive files
On 2020-02-26 15:27 +1100, Chris Johns wrote:
>
> Great, I am OK with the patch being pused. If it breaks on sync it will show
> in
> the build not updating and I am sure we can sort it out.
Okay great I'll do that now then thank you!
Amar.
___
On 2020-02-26 13:59 +1100, Chris Johns wrote:
>
> Does this work on sync.rtems.org with a suitable virtualenv?
>
> This is how I build the online docs. :)
Shouldn't be an issue at all it's in-source no new dependencies. Try the patch
and see if it works? :) Works here!
Amar.
I've been working on setting up hardware testing in my lab at home. The Device
Tree documentation we have currently is horrible:
https://docs.rtems.org/branches/master/user/exe/device-tree.html
It's a list of command and descriptions about what it is but not what they do.
For instance look
Hi Niteesh, I updated it and created a patch for this here:
https://devel.rtems.org/ticket/3880/
It does fix the issue once it's approved I will push the changes. Thank you
for
highlighting this issue!
Amar.
___
devel mailing list
I've been running this version for a while now. It should fix any issues we're
having I tested it and it works fine.
See here for a ticket the patch is rather large:
https://devel.rtems.org/ticket/3880
Amar.
___
devel mailing list
devel@rtems.org
On 2020-02-21 12:15 +1100, Chris Johns wrote:
>
> Does the Linux kernel rules apply to the 2 clause BSD license we have?
I don't think so but I've always included BSD licenses in the file as the
license expressly states that it should be included. This on top of adding an
SPDX marker.
Also,
On 2020-02-13 17:42 -0500, Peter Dufault wrote:
>
> Can you explain this to those of us who are part-time git users?
> I pulled during this time frame, so I must "re-clone" or do a "forced push
> back".
See below.
> I assume "re-clone" means I "rm -rf" a local repository and, well, "re-clone".
Due to a mishap the main repository has been rewound two commits back to
d252e20ab.
The two commits removed were 2272825 and a994e646. You may have to do a force
pull if you grabbed these two commits before this happened.
Amar.
___
devel mailing
On 2020-02-13 07:20 +0100, Christian Mauderer wrote:
> Hello Amar,
Hey!
> Understood it. It still works when build locally so it shouldn't be a
> big problem fixing it. I just wasn't really aware of the single page
> version before and therefore I wasn't sure whether it should work or
> not.
On 2020-02-13 15:16 +1100, Chris Johns wrote:
> It is useful if a user is deploying our documentation. I am not sure is
> something people building the docs normally do.
Yes it's actually the main method I've seen many use since it inlines all files
including images so it's just 1 HTML file
On 2020-02-10 13:05 +1100, Chris Johns wrote:
> On 8/2/20 11:13 am, Amar Takhar wrote:
> > I was going to start with the Beaglebone and do TFTP to load the tests.
>
> I suggest you start with getting rtems-run to run any of the built tests. You
> will need ...
>
> 1.
On 2020-02-08 09:31 +1100, Chris Johns wrote:
> >https://ftp.rtems.org/pub/rtems/people/amar/test1.jpg
> >
>
> That is flash. :)
Heh thanks, I set this up in August 2019 and it's been nagging at me since.
> You are not alone getting to this point. I know OAR has been setting
> something
On 2020-02-07 09:02 +0100, Sebastian Huber wrote:
> Currently, the build buildbot just build the BSPs with the tests. A next
> step could be to add test suite runs as well. It is a lot more easy to
> debug failures on one of the simulator BSPs even though they are not tier 1.
I actually have a
On 2020-02-07 16:17 +1100, Chris Johns wrote:
>
> Could we build an "always must build" BSP and if it builds a wider selection
> are
> built? The beaglebone black is my pick.
That's the way it already works now and has for years.
Look at the waterfall the process is:
1. Build snapshot
2.
On 2020-02-06 08:03 -0700, Gedare Bloom wrote:
> I agree with what you say. (And appreciate the unfunded work.)
Thank you.
> I still have reservations about the possibility to generate 250 emails
> all basically the same. Perhaps developers/committers should test
> every commit. Sometimes
On 2020-02-06 07:44 +0100, Christian Mauderer wrote:
> Like already said: I'm not against sending the mails. And the situation
> is quite unlikely in RTEMS core. But we should be aware of the
> possibility before enabling such an option.
Agreed and thank you for highlighting this. While I am
On 2020-02-06 07:19 +0100, Christian Mauderer wrote:
> Someone applied a FreeBSD patch directly to libbsd (which works well).
> In that case git noted that the original author is in the "from" header
> and send him an email that his patch has been applied. He was a bit
> astonished to receive
On 2020-02-05 20:28 -0700, Gedare Bloom wrote:
> I would like it to be a single email to indicate there is a new
> breakage. Enough to indicate "hey go take a look at the full build
> results! something is wrong here"
That's what it does. Breakage isn't always the same across builds. Waiting
On 2020-02-06 08:31 +1100, Chris Johns wrote:
> Can we enable this for one BSP from each tier 1 architectures?
Yes, can you provide a list?
> > Buildbot does support both Pushover and Pushjet as well.
>
> Is this like social media and that stuff? ;)
Both are apps that allow for android / ios
Currently emails sent out directly are limited to Joel, Chris and myself. This
was setup during a testing phase.
Typically what will happen is if a Builder within Buildbot changes from:
Working -> Broken
Broken -> Working
It will send an email to the 'responsible users'. You can see a
On 2020-02-05 07:49 +0100, Sebastian Huber wrote:
> Hello Amar,
>
> thanks for setting up the Buildbot. I will probably receive most of the
> Working -> Broken emails.
Sure. Yes I agree that is what I've seen. :)
> If you are subscribed to the bu...@rtems.org mailing list, do you
> already
On 2020-02-05 13:12 +1100, Chris Johns wrote:
> I am OK with that. What do others think?
For example in the last breakage you can see who was responsible by going here
and clicking 'Responsible Users':
https://buildbot.rtems.org/#/builders/19/builds/47
These two would have received direct
On 2020-02-05 10:16 +1100, Chris Johns wrote:
>
> Should fails be posted to devel?
I don't think that's a good idea since it's possible that a commit could break
every BSP and then we'll get 1 email per BSP as they each fail.
I think it's okay if the developer breaking the build gets those
On 2020-02-05 10:15 +1100, Chris Johns wrote:
>
> Many thanks for the buildbot effort and all you do. It is an important part of
> RTEMS's development.
Thank you.
Amar.
___
devel mailing list
devel@rtems.org
caught breakage from a commit made.
Currently only Joel, Chris and myself are on this list. If you wish to be
added
please send me your full email that you use to commit with in the format of:
Amar Takhar
Otherwise realtime status is available at
https://buildbot.rtems.org/
Found by Buildbot here!
https://buildbot.rtems.org/#/builders/19/builds/47
FYI if anyone does want to make a quick check to see if the error is
reproducible Buildbot creates a snapshot with bootstrap already run on every
build for example for this build:
On 2020-01-24 08:57 -0600, Joel Sherrill wrote:
>
> This failed because the tools are old.
Okay, I'll update those today thanks!
Amar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
I've mucked about with the Git hooks in a question to fix the issue with not
all
tickets updating in track. I belive I've fixed it see my note here:
https://devel.rtems.org/ticket/3561#comment:9
If you see any errors when committing please let me know directly it should be
fine but just in
On 2017-03-28 12:43 -0400, Gedare Bloom wrote:
> The main thing to avoid is any dependency between you and another
> student. If you can both work productively and create new code in
> parallel, then #1 can work out. But if it requires close interaction
> to work, and there is a chance one
The site is going down for some unplanned maintenance. While investigating
another issue I decided it was better to redo the entire site with a full
upgrade.
Sorry for the inconvenience it will be back tomorrow (2017-02-25) sometime!
Amar.
___
On 2016-05-02 09:57 +0200, Christian Mauderer wrote:
>
> Just two thoughts on the tools. Both doesn't need instant answers.
> Please note that I don't intend to contradict the tools.
>
> I just took a quick glance on the linked pages but from that it seems
> that both tools are quite
On 2016-04-30 23:50 +0800, printk wrote:
> Hi, will the new build system copy the headers to include too?
No, the new build system which you can see here:
https://git.rtems.org/amar/waf.git/
Does not do this.
You can see how to build it and get more details by following this thread:
On 2016-04-29 17:39 +1000, Chris Johns wrote:
> I had a long chat to Amar about this topic today and he told me we
> should follow the FreeBSD model for vendor software. FreeBSD has
> https://svnweb.freebsd.org/base/vendor/ and it contains the vendor
> source untouched and then the version
On 2016-01-06 08:03 -0600, Joel Sherrill wrote:
> Amar, etc.
>
> I committed this patch from rtbf64c. Where do I need to look for my name
> being??
> spelled incorrectly on this next line? I can't find it this morning.
Either in /.git/config or ~/.gitconfig or /etc/password
It checks these in
On 2016-01-06 14:42 -0600, Joel Sherrill wrote:
>
> Ahh.. that would be under Amar's control. :)
Oh, it was a vc email sorry I didn't notice.
I've fixed it now, surprised it took this long for someone to notice. :)
Amar.
___
devel mailing list
On 2015-07-04 19:10 +0530, Anand Krishnan wrote:
Hi,
Thanks for approving my midterm evaluation.
You're welcome.
Anyways, I have added the GUI class for String options. Will work on
StringList
now.
OK, this week I want to clean up the classes to simplify how it's stored
internally for
On 2015-06-18 05:57 +0530, Anand Krishnan wrote:
Hi all,
I've almost prepared the basic layout for the GUI. Also added some dummy event
handlers for File Menu.
Any more suggestions before fetching the options?
This is a great start!
Have you thought about how you are going to lay out the
1 - 100 of 133 matches
Mail list logo
