Re: Proposed RTEMS Community Code of Conduct
On 11/12/2014 08:49 PM, Thomas Doerfler wrote: What I don't understand in your posting: On the one hand you mention, that the topics of the proposed CCoC have never been an issue on the RTEMS list and on the other hand you point out, that other CCoCs on other lists may have made some users leave the list. Experience tells, in longer terms "project leaders" tend to instrumentalize "Code of Conducts" as a means of oppression and suppression, just to silence opposition. Do you think one of the porposed CCoC's topics would make people leave this project? Yes, definitely - CoCs endanger people to being banned from lists because of having expressing opions. To not expose themselves to this danger, they often simply do not express their opinions. They implement a climate of uncertainty and fear. This is counterproductive to OSS-projects. OSS-projects need open minds, and needs tolerance - not censorship. I see no harm in the CCoC, and always appreciate clear words. IMO, "clear words" and a CCoC are self-contractory and mutally exclusive. Ralf ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Proposed RTEMS Community Code of Conduct
Ralf, I agree that a "Community Code of Conduct" might be formulated that enables it to be used as a means of oppression. But we are talking about a certain recommended document code. Reading it I do not see any request which seem inappropriate. And "breaking" the code would not mean to be silently thrown out of the community, it would just start a discussion on staying within reasonable behaviour. So, can you clarify, noting the parts in Joel's recommended "RTEMS Code of Conduct", which you fear to be used sa a means of oppression? If I look at the chapter headlines and their content, I don't see anything - Be considerate - Be respectful - Be collaborative - Be pragmatic - Support others in the community - Get support from others in the community Which point actually makes you fear something? wkr, Thomas. Am 15.11.2014 17:01, schrieb Ralf Corsepius: > On 11/12/2014 08:49 PM, Thomas Doerfler wrote: >> >> What I don't understand in your posting: On the one hand you mention, >> that the topics of the proposed CCoC have never been an issue on the >> RTEMS list and on the other hand you point out, that other CCoCs on >> other lists may have made some users leave the list. > > Experience tells, in longer terms "project leaders" tend to > instrumentalize "Code of Conducts" as a means of oppression and > suppression, just to silence opposition. > >> Do you think one of the porposed CCoC's topics would make people leave >> this project? > > Yes, definitely - CoCs endanger people to being banned from lists > because of having expressing opions. To not expose themselves to this > danger, they often simply do not express their opinions. They implement > a climate of uncertainty and fear. > > This is counterproductive to OSS-projects. OSS-projects need open minds, > and needs tolerance - not censorship. > >> I see no harm in the CCoC, and always appreciate clear words. > IMO, "clear words" and a CCoC are self-contractory and mutally exclusive. > > Ralf > > -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Proposed RTEMS Community Code of Conduct
On 11/15/2014 05:28 PM, Thomas Doerfler wrote: Ralf, I agree that a "Community Code of Conduct" might be formulated that enables it to be used as a means of oppression. But we are talking about a certain recommended document code. Reading it I do not see any request which seem inappropriate. And "breaking" the code would not mean to be silently thrown out of the community, it would just start a discussion on staying within reasonable behaviour. So, can you clarify, noting the parts in Joel's recommended "RTEMS Code of Conduct", which you fear to be used sa a means of oppression? If I look at the chapter headlines and their content, I don't see anything - Be considerate - Be respectful - Be collaborative - Be pragmatic - Support others in the community - Get support from others in the community Which point actually makes you fear something? The Code of Conduct doesn't allow me to be more explicit ;) Ralf ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Proposed RTEMS Community Code of Conduct
On 11/15/2014 10:56 AM, Ralf Corsepius wrote: > On 11/15/2014 05:28 PM, Thomas Doerfler wrote: >> Ralf, >> >> I agree that a "Community Code of Conduct" might be formulated that >> enables it to be used as a means of oppression. But we are talking about >> a certain recommended document code. Reading it I do not see any request >> which seem inappropriate. And "breaking" the code would not mean to be >> silently thrown out of the community, it would just start a discussion >> on staying within reasonable behaviour. >> >> So, can you clarify, noting the parts in Joel's recommended "RTEMS Code >> of Conduct", which you fear to be used sa a means of oppression? >> >> If I look at the chapter headlines and their content, I don't see anything >> >> - Be considerate >> - Be respectful >> - Be collaborative >> - Be pragmatic >> - Support others in the community >> - Get support from others in the community >> >> Which point actually makes you fear something? > The Code of Conduct doesn't allow me to be more explicit ;) You must also have trouble with the Fedora Community Code of Conduct. http://fedoraproject.org/code-of-conduct > Ralf > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: gdb patches to RBS
On 11/15/2014 01:14 AM, Chris Johns wrote:
>>> Excellent. I suggest you provide git patches for the rtems-tools.git repo
>>> to add the patches and then provide RSB patches for the sparc gdb build to
>>> use them. There are specific sparc patches already present which need
>>> updating as they are currently stopping us moving off
>>> gdb-7.7.
>>
>> I tried to move RBS to gdb-7.8.1, but there were several other
>> dependency problems that I could not (easily) fix.
>
> Are these gdb, RSB, or rtems-tools patch issues ?
I have fixed this now, and attached a patch to switch rtems-sparc to gdb-7.8.1.
The patch goes on top of the previous, and could probably be squished with it.
The culprit was that FSF does not distribute .bz2 files of gdb-7.8.1, only .gz
and .xz .
I fixed this by adding a new source-builder/config/gdb-7.8.1-1.cfg file. The
sis patch
for gdb-7.7 also applies on gdb-7.8.1 so no need to update rtems-tools.
Jiri.
>From fff12ec9eb81f6078b5078db866b61c70810739d Mon Sep 17 00:00:00 2001
From: Jiri Gaisler
Date: Sat, 15 Nov 2014 20:56:43 +0100
Subject: [PATCH] rtems-sparc: switch to gdb-7.8.1
---
rtems/config/4.11/rtems-sparc.bset | 4 +-
rtems/config/tools/rtems-gdb-7.8.1-1.cfg | 28 +++
source-builder/config/gdb-7.8.1-1.cfg| 122 +++
3 files changed, 152 insertions(+), 2 deletions(-)
create mode 100644 rtems/config/tools/rtems-gdb-7.8.1-1.cfg
create mode 100644 source-builder/config/gdb-7.8.1-1.cfg
diff --git a/rtems/config/4.11/rtems-sparc.bset b/rtems/config/4.11/rtems-sparc.bset
index b1e7ba4..a98b8d3 100644
--- a/rtems/config/4.11/rtems-sparc.bset
+++ b/rtems/config/4.11/rtems-sparc.bset
@@ -15,7 +15,7 @@
# GDB patches
#
%patch add gdb %{rtems_gdb_patches}/sparc/gdb-7.7-sis-leon2-leon3-fixup.diff
-%hash md5 gdb-7.7-sis-leon2-leon3-fixup.diff e1c551487a516eee2931a6ee932047b6
+%hash md5 gdb-7.7-sis-leon2-leon3-fixup.diff afa25717cd54de8bfd103daaa754b6d7
#
# If Windows (MinGW) do not build the simulator.
@@ -29,6 +29,6 @@
devel/expat-2.1.0-1
tools/rtems-binutils-2.24-1
tools/rtems-gcc-4.9.2-newlib-git-1
-tools/rtems-gdb-7.7-1
+tools/rtems-gdb-7.8.1-1
tools/rtems-tools-4.11-1
tools/rtems-kernel-4.11
diff --git a/rtems/config/tools/rtems-gdb-7.8.1-1.cfg b/rtems/config/tools/rtems-gdb-7.8.1-1.cfg
new file mode 100644
index 000..297650d
--- /dev/null
+++ b/rtems/config/tools/rtems-gdb-7.8.1-1.cfg
@@ -0,0 +1,28 @@
+#
+# GDB 7.8.1
+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gdb_version 7.8.1
+
+%hash md5 gdb-%{gdb_version}.tar.gz 997492cc3475c96f35ecc8775248c9b1
+
+#
+# Clean up the sim-arange inline code so it builds.
+#
+%patch add gdb %{rtems_gdb_patches}/gdb-sim-arange-inline.diff
+%hash md5 gdb-sim-arange-inline.diff 11bb2936ea29afeaa023077191fd4705
+%patch add gdb %{rtems_gdb_patches}/gdb-sim-cgen-inline.diff
+%hash md5 gdb-sim-cgen-inline.diff e6f7d6d7295cdba99f51aab514ea9778
+
+%if %{_build_os} == freebsd
+ %patch add gdb -p0 %{rtems_gdb_patches}/patch-gdb-python-python-config.py
+ %hash md5 patch-gdb-python-python-config.py c0260fcca4c1a5509635049c0094eee3
+%endif
+
+#
+# The gdb build instructions. We use 7.xx Release 1.
+#
+%include %{_configdir}/gdb-7.8.1-1.cfg
diff --git a/source-builder/config/gdb-7.8.1-1.cfg b/source-builder/config/gdb-7.8.1-1.cfg
new file mode 100644
index 000..45d3272
--- /dev/null
+++ b/source-builder/config/gdb-7.8.1-1.cfg
@@ -0,0 +1,122 @@
+#
+# GDB 7.xx Version 1.
+#
+# This configuration file configure's, make's and install's gdb.
+#
+
+#
+# See if the simulator has been disabled for Windows.
+#
+%if %{_host_os} == mingw32
+ %if %{defined win32-gdb-disable-sim}
+ %define gdb-disable-sim 1
+ %endif
+%endif
+
+#
+# Default to building simulators.
+#
+%ifn %{defined gdb-disable-sim}
+ %define gdb-disable-sim 0
+%else
+ %undefine gdb-sim-options
+%endif
+
+%include %{_configdir}/checks.cfg
+
+#
+# Select Snapshot Macro Maps
+#
+%select gdb-snapshot
+%select expat-snapshot
+
+#
+# The description.
+#
+Name: %{_target}-gdb-%{gdb_version}-%{release}
+Summary: GDB v%{gdb_version} for target %{_target} on host %{_host}
+Version: %{gdb_version}
+Release: %{release}
+URL: http://www.gnu.org/software/gdb/
+BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
+
+#
+# Source
+#
+%source set gdb http://ftp.gnu.org/gnu/gdb/gdb-%{gdb_version}.tar.gz
+
+#
+# Disable Python on Cxc builds for now.
+#
+%if "%{_build}" != "%{_host}"
+ %define without_python
+%endif
+
+#
+#
+# Prepare the source code.
+#
+%prep
+ build_top=$(pwd)
+
+ source_dir_gdb="gdb-%{gdb_version}"
+ %source setup gdb -q -n gdb-%{gdb_version}
+ %patch setup gdb -p1
+
+ cd ${build_top}
+
+%build
+ build_top=$(pwd)
+
+ %{build_directory}
+
+ mkdir -p ${build_dir}
+ cd ${build_dir}
+
+ %{host_build_flags}
+
+ if test "%{_build}" != "%{_host}" ; then
+GDB_LIBS_STATIC="-lexpat"
+ else
+GDB_LIBS_STATIC="-lexpat"
+GDB_LIBS="%{_forced_static}"
+ fi
+
+ LIBS_S
