Re: [riot-devel] Changing the workflow.

[Martine Lenders]

Hi Adam,

2015-02-25 2:03 GMT+01:00 Adam Hunt :

> I really like the idea of task force branches (OTA, net, filesystem,
> platform, etc..). They seem somewhat reminiscent of Linux's
> *net, net-next* and similar trees. Would they be implemented as git
> branches within the main repository (e.g
> https://github.com/RIOT-OS/RIOT/OTA) or fully independent repositories
> (e.g. https://github.com/RIOT-OS/RIOT-OTA)? In the case of branches, is
> it possible to give a person write access to a specific branch without
> giving them access to pull things into *master*?
>

Up until this point I confused GitHub with Gitlab, GitHub's Open Source
cousin ;-). In Gitlab you can hand out branch-specific permissions [1],
since they are (or were (?) - its been a little while since I last hosted a
Gitlab server) build upon gitolite which allows for such magic. GitHub on
the other hand has a much coarse permission system [2] that works only on
repository level. So it probably would make more sense to put it into
seperate Repositories, as Ludwig and Attilio already suggested, too.


> I ask because I can imagine cases where you may want to give someone
> access to pull work for a specific feature or subsystem but not give them
> access to pull changes into the main development or stable branches, or say
> tag a release reserving that level of access for core maintainers.
>

Cheers,
Martine

[1]
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/permissions/permissions.md
[2]
https://help.github.com/articles/permission-levels-for-an-organization-repository/
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Switch to BSD?

[Adam Hunt]

I'd be willing to bet that GNU Classpath is one of the oldest projects
licensed under the GPL with a linking exception.

Classpath is distributed under the terms of the GNU General Public License
> with the following clarification and special exception.
>


Linking this library statically or dynamically with other modules is making
> a combined work based on this library. Thus, the terms and conditions of
> the GNU General Public License cover the whole combination.
> ​​
>



As a special exception, the copyright holders of this library give you
> permission to link this library with independent modules to produce an
> executable, regardless of the license terms of these independent modules,
> and to copy and distribute the resulting executable under terms of your
> choice, provided that you also meet, for each linked independent module,
> the terms and conditions of the license of that module. An independent
> module is a module which is not derived from or based on this library. If
> you modify this library, you may extend this exception to your version of
> the library, but you are not obliged to do so. If you do not wish to do so,
> delete this exception statement from your version.
> ​[1 ]​
>

​--adam​


​[1] https://www.gnu.org/software/classpath/license.html​


On Tue Feb 24 2015 at 5:08:12 PM Oleg Hahm  wrote:

> Hi Matthias!
>
> >   but the name (or license branding). We had this discussion before.
> > Rather unknown licenses need to be explained. Using eCos license is
> > similar to use a RIOT license.
>
> Yes, I agree, but at least it's listed (approved?) by FSF. Another option
> (see
> citation from the OSI list from my previous mail) we could just state GPL
> as a
> license and point to the exception for commercial users. I think the text
> on
> the eCos page is pretty comprehensible.
>
> The Wikipedia is even claiming that the perception "that without applying
> the
> linking exception, code linked with GPL code may only be done using a
> GPL-compatible license" is "unsupported by any legal precedent or
> citation".
>
> >   I'm just wondering if eCos is the first license with the introduced
> > exception -- I will not research on this ;).
>
> I don't think so, but it's the only listed license from FSF that specifies
> the
> linking exception.
>
> >   I never said it's impossible. In this type of discussion you will
> > always find counterexamples. I just wanted to point out that I see it as
> > an advantage to use an OSI approved license.
>
> I agree, but if the choice is between a FSF approved license (as I
> understand
> eCos License is) that matches our needs and a less matching OSI approved
> license, I'm willing to bite this bullet.
>
> > > At least eCos, ERIKA and ChibiOS are very similar to RIOT from a
> > > software architecture point of view (OS for embedded hardware).
> > >
> >   No comment ;).
>
> For clarification: I was referring to the fact that these systems have a
> similar use case as RIOT, not that there concept or feature set is similar
> to
> RIOT.
>
> > > Long story short: I see your concerns, but for me GPL + Linking
> > > Exception is a common license model that works well for many
> > > well-known and mature projects. Personally, I would think that GPL +
> > > Linking Exception matches our needs far better than LGPL.
> > >
> >   Can you explain in one our two sentences why? Because it's more
> > inclusive?
>
> Again taken from the Wikipedia article: "the LGPL formulates more
> requirements
> to the linking exception: you must allow modification of the portions of
> the
> library you use and reverse engineering (of your program and the library)
> for
> debugging such modifications."
>
> > > As I see it now, we won't come to any conclusion for or against
> > > switching to a non-copyleft license that satisfies everyone, because
> > > the goals and visions where to go with RIOT are too different.
> > >
> >   At least we don't get new basic insights with this thread.
>
> Which is too bad.
>
> Cheers,
> Oleg
> --
> The problem with TCPIP jokes is that when I tell them, all I want is an
> ACK but
> usually get FINs and RSTs
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Switch to BSD?

[Oleg Hahm]

Hi Matthias!

>   but the name (or license branding). We had this discussion before. 
> Rather unknown licenses need to be explained. Using eCos license is 
> similar to use a RIOT license.

Yes, I agree, but at least it's listed (approved?) by FSF. Another option (see
citation from the OSI list from my previous mail) we could just state GPL as a
license and point to the exception for commercial users. I think the text on
the eCos page is pretty comprehensible.

The Wikipedia is even claiming that the perception "that without applying the
linking exception, code linked with GPL code may only be done using a
GPL-compatible license" is "unsupported by any legal precedent or citation".

>   I'm just wondering if eCos is the first license with the introduced 
> exception -- I will not research on this ;).

I don't think so, but it's the only listed license from FSF that specifies the
linking exception.

>   I never said it's impossible. In this type of discussion you will 
> always find counterexamples. I just wanted to point out that I see it as 
> an advantage to use an OSI approved license.

I agree, but if the choice is between a FSF approved license (as I understand
eCos License is) that matches our needs and a less matching OSI approved
license, I'm willing to bite this bullet.

> > At least eCos, ERIKA and ChibiOS are very similar to RIOT from a 
> > software architecture point of view (OS for embedded hardware).
> >
>   No comment ;).

For clarification: I was referring to the fact that these systems have a
similar use case as RIOT, not that there concept or feature set is similar to
RIOT.

> > Long story short: I see your concerns, but for me GPL + Linking 
> > Exception is a common license model that works well for many 
> > well-known and mature projects. Personally, I would think that GPL + 
> > Linking Exception matches our needs far better than LGPL.
> > 
>   Can you explain in one our two sentences why? Because it's more 
> inclusive?

Again taken from the Wikipedia article: "the LGPL formulates more requirements
to the linking exception: you must allow modification of the portions of the
library you use and reverse engineering (of your program and the library) for
debugging such modifications."
 
> > As I see it now, we won't come to any conclusion for or against 
> > switching to a non-copyleft license that satisfies everyone, because 
> > the goals and visions where to go with RIOT are too different.
> > 
>   At least we don't get new basic insights with this thread.

Which is too bad.

Cheers,
Oleg
-- 
The problem with TCPIP jokes is that when I tell them, all I want is an ACK but
usually get FINs and RSTs


pgpIqv91lPag4.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Changing the workflow.

[Adam Hunt]

I really like the idea of task force branches (OTA, net, filesystem,
platform, etc..). They seem somewhat reminiscent of Linux's *net, net-next*
and similar trees. Would they be implemented as git branches within the
main repository (e.g https://github.com/RIOT-OS/RIOT/OTA) or fully
independent repositories (e.g. https://github.com/RIOT-OS/RIOT-OTA)? In the
case of branches, is it possible to give a person write access to a
specific branch without giving them access to pull things into *master*?

I ask because I can imagine cases where you may want to give someone access
to pull work for a specific feature or subsystem but not give them access
to pull changes into the main development or stable branches, or say tag a
release reserving that level of access for core maintainers.

--adam

On Tue Feb 24 2015 at 7:44:19 AM Martine Lenders 
wrote:

> Hi Attilio,
>
> 2015-02-24 16:30 GMT+01:00 Attilio Dona :
>
>> Just for add a bit of documentation for helping discovering the best
>> workflow:
>>
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> The post contains some good points in my opinion, for example the
>> guideline that a feature branch have to exists in developer repo and not in
>> origin.
>>
>>
> But that is how it is currently basically: A dev opens a branch in her
> repository, makes changes and offers them to origin in form of a Pull
> Request. The idea of the "feature branches" (let's rebrand this as task
> force branches, since this is where I know I differ from the "normal" Git
> workflow) is to collect the efforts of a task force in bulk first to add
> them to the origin later, to avoid WIP APIs popping up in master. For
> external (to the core community) task forces or similar groups it might be
> the better solution to do their work in an external repository and merge
> their work in a collective PR, but for internal task forces e.g. the NSTF
> and OTA-TF (and when they start development the Timer TF) it makes much
> more sense to push this kind of work directly to the main repository, but
> to a different branch.
>
> Cheers,
> Martine
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Switch to BSD?

[Matthias Waehlisch]

Hi Oleg,

On Wed, 25 Feb 2015, Oleg Hahm wrote:

> >   I thought that we already decided to exclude exotic licenses.
> 
> Yes. GPL + Linker Exception is not exotic.
> 
  but the name (or license branding). We had this discussion before. 
Rather unknown licenses need to be explained. Using eCos license is 
similar to use a RIOT license.

> >   With respect to this specific license:
> > 
> >   (1) We cannot use the license because the license text is specific to 
> > eCos (e.g., "eCos is distributed [...]").
> 
> And original BSD license 
> (http://directory.fsf.org/wiki/License:BSD_4Clause) is specific to 
> "Computer Systems Engineering group at Lawrence Berkeley Laboratory", 
> which is obviously no blocker to be adopted elsewhere. I don't see why 
> replacing the name of the project should invalidate a license.
>  
  Misunderstanding.

  I'm just wondering if eCos is the first license with the introduced 
exception -- I will not research on this ;).

> >   (2) We should not use the license because it is not approved by the 
> > Open Source Initiative. OSI approval is important for some open source 
> > funding programmes etc.
> 
> Seems to work quite successfully for eCos, ERIKA [1], GNU Guile [2], 
> libgcc [3], NetBeans [4], ChibiOS [5] and several other bigger 
> projects. Would be interesting what FSF says about it.
>
  I never said it's impossible. In this type of discussion you will 
always find counterexamples. I just wanted to point out that I see it as 
an advantage to use an OSI approved license.

> At least eCos, ERIKA and ChibiOS are very similar to RIOT from a 
> software architecture point of view (OS for embedded hardware).
>
  No comment ;).
 
> >   If you want to spend more time on this, I recommend the thread 
> > http://projects.opensource.org/pipermail/license-review/2014-August/000853.html,
> >  
> > in particular 
> > http://projects.opensource.org/pipermail/license-review/2014-September/000910.html.
> 
> I haven't found any clear answers in these two mails and don't want to 
> spend the rest of the evening reading through another license 
> discussion, I have enough with this one here. From what I've read, I 
> gather that oSI doesn't want to approve it, because there's no need to 
> approve it: "why not simply stop referring to 'the eCos License 2.0' 
> as though it were a special license and instead characterize eCos as 
> being licensed as 'GPLv2 or later' with a permissive exception? I've 
> encountered other projects using similarly-worded GPL exceptions but 
> to my recollection those projects characterize themselves as being 
> GPL-licensed."
> 
> Long story short: I see your concerns, but for me GPL + Linking 
> Exception is a common license model that works well for many 
> well-known and mature projects. Personally, I would think that GPL + 
> Linking Exception matches our needs far better than LGPL.
> 
  Can you explain in one our two sentences why? Because it's more 
inclusive?


> As I see it now, we won't come to any conclusion for or against 
> switching to a non-copyleft license that satisfies everyone, because 
> the goals and visions where to go with RIOT are too different.
> 
  At least we don't get new basic insights with this thread.



Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehli...@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Switch to BSD?

[Oleg Hahm]

Hi Matthias!

>   I thought that we already decided to exclude exotic licenses.

Yes. GPL + Linker Exception is not exotic.

>   With respect to this specific license:
> 
>   (1) We cannot use the license because the license text is specific to 
> eCos (e.g., "eCos is distributed [...]").

And original BSD license (http://directory.fsf.org/wiki/License:BSD_4Clause)
is specific to "Computer Systems Engineering group at Lawrence Berkeley
Laboratory", which is obviously no blocker to be adopted elsewhere. I don't
see why replacing the name of the project should invalidate a license.
 
>   (2) We should not use the license because it is not approved by the 
> Open Source Initiative. OSI approval is important for some open source 
> funding programmes etc.

Seems to work quite successfully for eCos, ERIKA [1], GNU Guile [2], libgcc
[3], NetBeans [4], ChibiOS [5] and several other bigger projects. Would be
interesting what FSF says about it. At least eCos, ERIKA and ChibiOS are very
similar to RIOT from a software architecture point of view (OS for embedded
hardware).

>   If you want to spend more time on this, I recommend the thread 
> http://projects.opensource.org/pipermail/license-review/2014-August/000853.html,
>  
> in particular 
> http://projects.opensource.org/pipermail/license-review/2014-September/000910.html.

I haven't found any clear answers in these two mails and don't want to spend
the rest of the evening reading through another license discussion, I have
enough with this one here. From what I've read, I gather that oSI doesn't
want to approve it, because there's no need to approve it:
"why not simply stop referring to 'the eCos License 2.0' as though it were a
special license and instead characterize eCos as being licensed as 'GPLv2 or
later' with a permissive exception? I've encountered other projects using
similarly-worded GPL exceptions but to my recollection those projects
characterize themselves as being GPL-licensed."


Long story short: I see your concerns, but for me GPL + Linking Exception is a
common license model that works well for many well-known and mature projects.
Personally, I would think that GPL + Linking Exception matches our needs far
better than LGPL.

As I see it now, we won't come to any conclusion for or against switching to a
non-copyleft license that satisfies everyone, because the goals and visions
where to go with RIOT are too different.

Cheers,
Oleg

[1] http://erika.tuxfamily.org/
[2] https://www.gnu.org/software/guile/
[3] https://gcc.gnu.org/
[4] http://netbeans.org/
[5] http://www.chibios.org/dokuwiki/doku.php?id=chibios:license
-- 
The bad thing about IPv6 jokes is that nobody wants to tell them first.


pgp1cZZ9i0yrl.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Switch to BSD?

[Matthias Waehlisch]

Hi Oleg,

  I thought that we already decided to exclude exotic licenses.

  With respect to this specific license:

  (1) We cannot use the license because the license text is specific to 
eCos (e.g., "eCos is distributed [...]").

  (2) We should not use the license because it is not approved by the 
Open Source Initiative. OSI approval is important for some open source 
funding programmes etc.

  If you want to spend more time on this, I recommend the thread 
http://projects.opensource.org/pipermail/license-review/2014-August/000853.html,
 
in particular 
http://projects.opensource.org/pipermail/license-review/2014-September/000910.html.


Cheers
  matthias

On Tue, 24 Feb 2015, Oleg Hahm wrote:

> Dear RIOTers,
> 
> I just found the eCos license: [1]
> http://ecos.sourceware.org/license-overview.html
> 
> It's basically a modified version of the GPL with linker exception. The
> interesting point: it is officially recognised as a GPL-compatible Free
> Software License:
> https://www.gnu.org/licenses/license-list.html#eCos20
> and it seems to enable exactly what most of us want for RIOT: it makes it
> possible to implement proprietary applications on top of the OS, but any
> changes to the OS have to be made freely available. It seems also possibly to
> apply this exception on device drivers if this driver is implemented in a
> particular way. A very quick search revealed immediately one commercial user
> of this rule:
> https://help.eyefi.com/hc/en-us/articles/301754-eCos-Open-Source-License
> 
> To me this looks very promising. What do you think?
> 
> Cheers,
> Oleg
> 
> [1] eCos is another "free open source real-time operating system intended for
> embedded applications."
> 

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehli...@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] [PROJECT][RIOT-OS][STM32-L152RE]

[Thomas Eichinger]

Hi Tararaina,

for helping you with your problem, could share a link to your 
code with us? Or/and could you run `make` with command line option
`QUIET=0` and paste the output to pastepin [1] or a gist [2]?

Best, Thomas

[1] pastebin.com
[2] gist.github.com


On 24 Feb 2015, at 15:19 CET(+0100), Tararaina Klipffel wrote:

> Hello,
>
> We are 4 French students in engineering school. We are currently working on
> a robotic project of telepresence. We have set up RIOT-OS on a STM32 L152RE
> board and we are now attempting to add an external library in our project.
> We have a library libmded.a that contains every .o precompiled provided by
> mbed, and a folder with the corresponding headers. Then we added the .h
> path to the INCLUDES var in the makefile and the library to the USEMODULE
> var. But when we're trying to compile it, it seems that the makefile isn't
> able to find the functions include in this lib. That's why we would be
> grateful for any advice that could guide us.
>
> Kind regards.
> Tara
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] [PROJECT][RIOT-OS][STM32-L152RE]

[Martine Lenders]

Hi again

2015-02-24 20:16 GMT+01:00 Martine Lenders :

> […]
>
> 2 things: Have you added the Makefile.base to the directory
> "YOUR_PATH"/RIOT-master/examples/test?
>

Sorry I meant the Makefile, not the Makefile.base here.
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] [PROJECT][RIOT-OS][STM32-L152RE]

[Martine Lenders]

Hi Tara,
[quotet from your digest reply]:

I tried to include my external library as an external module, but it
> doesn't work ! I have still the same issue. When we're trying to compile
> it, it seems that the makefile isn't able to find the functions include in
> this libmbed.a.
> As you can see in my Makefile, I use this var:
>   # AJOUT MODULE MBED
>   EXTERNAL_MODULE_DIRS += “YOUR_PATH”/RIOT-master/examples/test
>   USEMODULE += libmbed
>   INCLUDES += -I/”YOUR_PATH”/RIOT-master/MBED


2 things: Have you added the Makefile.base to the directory
"YOUR_PATH"/RIOT-master/examples/test?

It has to contain the following

MODULE = libmbed
include $(RIOTBASE)/Makefile.base

You can leave out the first line, if the directory it resides in is called
libmbed (in your example you would need to rename
"YOUR_PATH"/RIOT-master/examples/test to
"YOUR_PATH"/RIOT-master/examples/libmbed).

I export all .o depending on my board and create the libmed.a with the
> command "ar -q libmed.a" . I use the mbed export to gcc, compile it with
> the "GCC ARM Embedded 4.7 update 4" Toolchain and it works ! But when I
> tried to compile with RIOT-OS, its like it isn't able to find the functions
> include in this lib.


Mind that the external module approach only works if you have the source
files (the .c(pp) or .s files) in this directory. If you only have the
object files, try copying them into the directory "YOUR_PATH"/RIOT-master/
examples/bin/YOUR_BOARD/".

Good luck,
Martine

2015-02-24 15:39 GMT+01:00 Martine Lenders :

> Hi Tara,
> have you tried to include your external library as an external module [1]?
>
> Kind regards,
> Martine
>
> [1] https://github.com/RIOT-OS/RIOT/wiki/Creating-external-modules
>
> 2015-02-24 15:19 GMT+01:00 Tararaina Klipffel :
>
>> Hello,
>>
>> We are 4 French students in engineering school. We are currently working
>> on a robotic project of telepresence. We have set up RIOT-OS on a STM32
>> L152RE board and we are now attempting to add an external library in our
>> project. We have a library libmded.a that contains every .o precompiled
>> provided by mbed, and a folder with the corresponding headers. Then we
>> added the .h path to the INCLUDES var in the makefile and the library to
>> the USEMODULE var. But when we're trying to compile it, it seems that the
>> makefile isn't able to find the functions include in this lib. That's why
>> we would be grateful for any advice that could guide us.
>>
>> Kind regards.
>> Tara
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] devel Digest, Vol 24, Issue 55

[Tararaina Klipffel]

Hi Martine,

I tried to include my external library as an external module, but it
doesn't work ! I have still the same issue. When we're trying to compile
it, it seems that the makefile isn't able to find the functions include in
this libmbed.a.
As you can see in my Makefile, I use this var:
  # AJOUT MODULE MBED
  EXTERNAL_MODULE_DIRS += “YOUR_PATH”/RIOT-master/examples/test
  USEMODULE += libmbed
  INCLUDES += -I/”YOUR_PATH”/RIOT-master/MBED


Hi Jan,

 I export all .o depending on my board and create the libmed.a with the
command "ar -q libmed.a" . I use the mbed export to gcc, compile it with
the "GCC ARM Embedded 4.7 update 4" Toolchain and it works ! But when I
tried to compile with RIOT-OS, its like it isn't able to find the functions
include in this lib.

Regards

Tara.





2015-02-24 16:43 GMT+01:00 :

> Send devel mailing list submissions to
> devel@riot-os.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.riot-os.org/mailman/listinfo/devel
> or, via email, send a message with subject or body 'help' to
> devel-requ...@riot-os.org
>
> You can reach the person managing the list at
> devel-ow...@riot-os.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of devel digest..."
>
>
> Today's Topics:
>
>1. Re: [PROJECT][RIOT-OS][STM32-L152RE] (Jan Wagner)
>2. Re: Changing the workflow. (Oleg Hahm)
>3. Re: Changing the workflow. (Attilio Dona)
>4. Re: Changing the workflow. (Martine Lenders)
>
>
> --
>
> Message: 1
> Date: Tue, 24 Feb 2015 15:53:47 +0100 (CET)
> From: Jan Wagner 
> To: RIOT OS kernel developers 
> Subject: Re: [riot-devel] [PROJECT][RIOT-OS][STM32-L152RE]
> Message-ID:
> <
> 1866946737.134735.1424789627222.javamail.open-xcha...@oxbsltgw09.schlund.de
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Tara,
>
> how was the lib.a created? - maybe you can use "
> arm-none-linux-gnueabi-readelf"
> to get more info about the library.
> to understand your problem better - so you used the mbed export to gcc
> functionality and now you get errors
> like in this post fe. (different cpu etc)
>
> http://developer.mbed.org/questions/2524/gcc-arm-embedded-export-for-LPC4088/
> ?
>
> ps. for general testing you should maybe first test with a minimal .a that
> includes only a minimum of .o
>
> regards
>
> Jan
>
> > Martine Lenders  hat am 24. Februar 2015 um
> 15:39
> > geschrieben:
> >
> >  Hi Tara,
> >  have you tried to include your external library as an external module
> [1]?
> >
> >  Kind regards,
> >  Martine
> >
> >  [1] https://github.com/RIOT-OS/RIOT/wiki/Creating-external-modules
> >
> >  2015-02-24 15:19 GMT+01:00 Tararaina Klipffel  > <mailto:tei...@gmail.com> >:
> >> >Hello,
> > >
> > >We are 4 French students in engineering school. We are currently
> working
> > > on a robotic project of telepresence. We have set up RIOT-OS on a STM32
> > > L152RE board and we are now attempting to add an external library in
> our
> > > project. We have a library libmded.a that contains every .o precompiled
> > > provided by mbed, and a folder with the corresponding headers. Then we
> added
> > > the .h path to the INCLUDES var in the makefile and the library to the
> > > USEMODULE var. But when we're trying to compile it, it seems that the
> > > makefile isn't able to find the functions include in this lib. That's
> why we
> > > would be grateful for any advice that could guide us.
> > >
> > >Kind regards.
> > >Tara
> > >
> > >___
> > >devel mailing list
> > >devel@riot-os.org <mailto:devel@riot-os.org>
> > >http://lists.riot-os.org/mailman/listinfo/devel
> > >  >  ___
> >  devel mailing list
> >  devel@riot-os.org
> >  http://lists.riot-os.org/mailman/listinfo/devel
> >
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.riot-os.org/pipermail/devel/attachments/20150224/a458c3f5/attachment-0001.html
> >
>
> --
>
> Message: 2
> Date: Tue, 24 Feb 2015 15:57:12 +0100
> From: Oleg Hahm 
> To: RIOT OS kernel developers 
> Subject: Re: [riot-devel] Changing

Re: [riot-devel] Switch to BSD?

[Oleg Hahm]

Dear RIOTers,

I just found the eCos license: [1]
http://ecos.sourceware.org/license-overview.html

It's basically a modified version of the GPL with linker exception. The
interesting point: it is officially recognised as a GPL-compatible Free
Software License:
https://www.gnu.org/licenses/license-list.html#eCos20
and it seems to enable exactly what most of us want for RIOT: it makes it
possible to implement proprietary applications on top of the OS, but any
changes to the OS have to be made freely available. It seems also possibly to
apply this exception on device drivers if this driver is implemented in a
particular way. A very quick search revealed immediately one commercial user
of this rule:
https://help.eyefi.com/hc/en-us/articles/301754-eCos-Open-Source-License

To me this looks very promising. What do you think?

Cheers,
Oleg

[1] eCos is another "free open source real-time operating system intended for
embedded applications."
-- 
The problem with TCP jokes is that people keep retelling them slower until you
get them.


pgpkfyDMFCHtk.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Changing the workflow.

[Martine Lenders]

Hi Attilio,

2015-02-24 16:30 GMT+01:00 Attilio Dona :

> Just for add a bit of documentation for helping discovering the best
> workflow:
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> The post contains some good points in my opinion, for example the
> guideline that a feature branch have to exists in developer repo and not in
> origin.
>
>
But that is how it is currently basically: A dev opens a branch in her
repository, makes changes and offers them to origin in form of a Pull
Request. The idea of the "feature branches" (let's rebrand this as task
force branches, since this is where I know I differ from the "normal" Git
workflow) is to collect the efforts of a task force in bulk first to add
them to the origin later, to avoid WIP APIs popping up in master. For
external (to the core community) task forces or similar groups it might be
the better solution to do their work in an external repository and merge
their work in a collective PR, but for internal task forces e.g. the NSTF
and OTA-TF (and when they start development the Timer TF) it makes much
more sense to push this kind of work directly to the main repository, but
to a different branch.

Cheers,
Martine
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Changing the workflow.

[Attilio Dona]

Just for add a bit of documentation for helping discovering the best
workflow:

http://nvie.com/posts/a-successful-git-branching-model/

The post contains some good points in my opinion, for example the guideline
that a feature branch have to exists in developer repo and not in origin.

ciao
Attilio

On Sat, Feb 21, 2015 at 7:02 PM, Martine Lenders 
wrote:

> Hello coding RIOTers,
> After I needed to rebase several PRs multiple times last week I'm really
> fed up with our current workflow. Furthermore, I discovered three things
> that show that we are in need of a more established workflow.
>
>1. our community is growing
>2. our master branch is changing constantly and has features in it
>that are sometimes thrown out the window weeks after they where introduced
>(e.g. radio_types.h or the older versions of netapi/netdev)
>3. we introduced feature-centric task forces to our communities
>
> This is why I propose we change to a slightly adapted topic branch
> workflow (also known as feature branch) workflow [1]:
>
>- the main RIOT-OS/RIOT repository will get the following branches
>   - master: points to the stable version of our latest release
>  - one stable branch for every major release (?)
>   - devel: points to current development version (what is currently
>   our master), hot fixes can be cherry-picked to the master from here.
>   - branching from devel: feature branch for every task force that is
>   currently in active development, current changes will be merged 
> regularly
>   from devel by the branches maintainers
>- Pull Requests will be made either to devel (default) or the
>corresponding feature branch
>- feature branches will be merged into devel if the feature reaches
>sufficient stability.
>- devel will be merged into master, when a new release is out and
>master's new HEAD tagged with the release number.
>
> I observed two extra benefits from that:
>
>- accidentally merged "SQUASH ME" commits can be squashed further
>upstream, before we add the commits to master or devel
>- we can make maintenance of features more granular (and maybe solve
>our maintenance problem) by enacting the "Dictator and Lieutenants
>Workflow", where the "Dictator(s)" are responsible for master and devel,
>and the feature branches can be maintained by the central persons of the
>Task Force (the Lieutenants).
>
> What do you think?
>
> Cheers,
> Martine
>
> [1]
> http://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows#Topic-Branches
> [2]
> http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#Dictator-and-Lieutenants-Workflow
>
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Changing the workflow.

[Oleg Hahm]

Hi Martine!

In general I like the concept and I think various people (including myself)
proposed a similar workflow already in the past, but it was always rejected
(IMO for good reasons), because of the introduced overhead and missing
personal resources.

> I don't get this argument: With my workflow the only new task is the
> merging of stable and devel and the maintenance of hot-fixes (which can be
> labeled as such and are thus easily spotable). The merging of devel into
> stable will happen at every release, and the merging of feature branches
> into devel if a milestone for the feature is reached.  

Cherry-picking of "hot-fixes" (which would probably occur quite often in
current state of RIOT) might be some work - particular, since there will be
probably a lot of conflicts.

> > >   - devel: points to current development version (what is currently
> > our
> > >   master), hot fixes can be cherry-picked to the master from here.
> >
> > According to my first remark there is no need for a devel branch, we
> > just keep using master.
> >
> 
> Sure we first need a stable version to have a stable branch, but my
> thinnking introducing it now was to avoid confusion we often encountered in
> the whole transceiver/netdev/ng_netdev situation.

I don't think this would help. Who would be willing to fix a problem in master
with e.g. the transceiver interface while everyone's working on NSTF? Let's
wait for RIOT 1.0, before we think about a "stable" master branch again.



I still like the idea of feature branches.

> > We could just as well use the decentralized hierarchical development
> > model as performed by the Linux community.
> > https://www.kernel.org/doc/Documentation/SubmittingPatches
> > This would mean less visibility of the "feature branches" (in
> > possession of a "Lieutenant" in your terminology), but also less
> > stress on the "Dictators", because they don't constantly see what
> > doesn't need to concern them. At least I guess the GitHub interface
> > would make it much easier to only follow repositories one is concerned
> > with.
> >
> 
> When you look at the text I've linked: they also give the Linux kernel as
> an example for the Dictator/Lieutenant workflow ;-). The terms branch and
> repository are more or less interchangable in this context (at least with
> Git). I guess in the end its a style choice if we decide for task force
> repositories or feature branches. I would welcome the visibility of
> development in the feature branch solution, but understand that some might
> not be interested in the development of some minor task force.

I'm not in favor of a hierarchical development model. One important advantage
of the current flat maintainer hierarchy in RIOT is that we're not dependent
on a single person - and no one of us has enough time to be the "Dictator".
I'm fine with having one, two, three people being responsible for a feature
branch or repository (I think branches would be fine at current point of
time), but the "Dictator" should stay the community.

Cheers,
Oleg
-- 
panic("Alas, I survived.\n");
linux-2.6.6/arch/ppc64/kernel/rtas.c


pgpJ6Sbh4T13a.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] [PROJECT][RIOT-OS][STM32-L152RE]

[Jan Wagner]

Hi Tara,
 
how was the lib.a created? - maybe you can use " arm-none-linux-gnueabi-readelf"
to get more info about the library.
to understand your problem better - so you used the mbed export to gcc
functionality and now you get errors
like in this post fe. (different cpu etc)
http://developer.mbed.org/questions/2524/gcc-arm-embedded-export-for-LPC4088/ ?
 
ps. for general testing you should maybe first test with a minimal .a that
includes only a minimum of .o
 
regards
 
Jan

> Martine Lenders  hat am 24. Februar 2015 um 15:39
> geschrieben:
> 
>  Hi Tara,
>  have you tried to include your external library as an external module [1]?
>   
>  Kind regards,
>  Martine
>   
>  [1] https://github.com/RIOT-OS/RIOT/wiki/Creating-external-modules
> 
>  2015-02-24 15:19 GMT+01:00 Tararaina Klipffel   >:
>> >Hello,
> > 
> >We are 4 French students in engineering school. We are currently working
> > on a robotic project of telepresence. We have set up RIOT-OS on a STM32
> > L152RE board and we are now attempting to add an external library in our
> > project. We have a library libmded.a that contains every .o precompiled
> > provided by mbed, and a folder with the corresponding headers. Then we added
> > the .h path to the INCLUDES var in the makefile and the library to the
> > USEMODULE var. But when we're trying to compile it, it seems that the
> > makefile isn't able to find the functions include in this lib. That's why we
> > would be grateful for any advice that could guide us.
> > 
> >Kind regards.
> >Tara
> > 
> >___
> >devel mailing list
> >devel@riot-os.org 
> >http://lists.riot-os.org/mailman/listinfo/devel
> >  >  ___
>  devel mailing list
>  devel@riot-os.org
>  http://lists.riot-os.org/mailman/listinfo/devel
> 

 ___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] [PROJECT][RIOT-OS][STM32-L152RE]

[Martine Lenders]

Hi Tara,
have you tried to include your external library as an external module [1]?

Kind regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/wiki/Creating-external-modules

2015-02-24 15:19 GMT+01:00 Tararaina Klipffel :

> Hello,
>
> We are 4 French students in engineering school. We are currently working
> on a robotic project of telepresence. We have set up RIOT-OS on a STM32
> L152RE board and we are now attempting to add an external library in our
> project. We have a library libmded.a that contains every .o precompiled
> provided by mbed, and a folder with the corresponding headers. Then we
> added the .h path to the INCLUDES var in the makefile and the library to
> the USEMODULE var. But when we're trying to compile it, it seems that the
> makefile isn't able to find the functions include in this lib. That's why
> we would be grateful for any advice that could guide us.
>
> Kind regards.
> Tara
>
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Changing the workflow.

[Martine Lenders]

Hi,

2015-02-21 20:06 GMT+01:00 Ludwig Ortmann :

> Hi,
>
> On Sat, Feb 21, 2015 at 07:02:58PM +0100, Martine Lenders wrote:
> > This is why I propose we change to a slightly adapted topic branch
> workflow
> > (also known as feature branch) workflow [1]:
> >
> >- the main RIOT-OS/RIOT repository will get the following branches
> >   - master: points to the stable version of our latest release
> >  - one stable branch for every major release (?)
>
> (I understand "stable" to denote non-changing APIs, and a "stable
> branch" to denote a branch which is stable in this sense, and gets
> bugfixes, and possibly new features.)
>
> We don't have enough people to support this at the moment.
> Also, we would definitely need to make sure the releases are sensible
> for this to make sense.
> Let's keep this one open until there is a need, time and a codebase
> that makes sense to put this effort into.
>

I don't get this argument: With my workflow the only new task is the
merging of stable and devel and the maintenance of hot-fixes (which can be
labeled as such and are thus easily spotable). The merging of devel into
stable will happen at every release, and the merging of feature branches
into devel if a milestone for the feature is reached. Or were you referring
to my optional proposal of release branches?


>
> >   - devel: points to current development version (what is currently
> our
> >   master), hot fixes can be cherry-picked to the master from here.
>
> According to my first remark there is no need for a devel branch, we
> just keep using master.
>

Sure we first need a stable version to have a stable branch, but my
thinnking introducing it now was to avoid confusion we often encountered in
the whole transceiver/netdev/ng_netdev situation.


>
> >   - branching from devel: feature branch for every task force that is
> >   currently in active development, current changes will be merged
> regularly
> >   from devel by the branches maintainers
>
> "will be merged regularly" sounds like the amount of merging will
> increase in total. I'd rather leave it to the respective maintainers
> how they work on their feature branch.
>

That's why I left it at "regularly" as in "when it's needed" (e. g. merge
into devel would yield conflicts). Also: more merges mean less merging
conflicts over time so why does it sound like you think merging is a bad
thing ;-)?


>
> >- feature branches will be merged into devel if the feature reaches
> >sufficient stability.
>
> What does "stability" mean in this context?
>

When a certain milestone is reached (e.g. the "current" (apart from two
follow-up PRs ^^") state in netdev/netapi context, or when all critical
protocols are ready)


>
> > I observed two extra benefits from that:
> >
> >- accidentally merged "SQUASH ME" commits can be squashed further
> >upstream, before we add the commits to master or devel
>
> Actually, that is not the case as feature branches will also need to
> be PR'd against master, and might need fixing as well.
>

The "dictator" (as suggested below) can do this on it's own computer, too.
Sure a PR is more transparent but I don't agree that we NEED (from a
technical standpoint) it.


> Also, we could as well "fix" these accidental commits in our master branch.
>

And catch the fury of everyone on their next pull ;-).


> >- we can make maintenance of features more granular (and maybe solve
> our
> >maintenance problem) by enacting the "Dictator and Lieutenants
> Workflow",
> >where the "Dictator(s)" are responsible for master and devel, and the
> >feature branches can be maintained by the central persons of the Task
> Force
> >(the Lieutenants).
>
> We could just as well use the decentralized hierarchical development
> model as performed by the Linux community.
> https://www.kernel.org/doc/Documentation/SubmittingPatches
> This would mean less visibility of the "feature branches" (in
> possession of a "Lieutenant" in your terminology), but also less
> stress on the "Dictators", because they don't constantly see what
> doesn't need to concern them. At least I guess the GitHub interface
> would make it much easier to only follow repositories one is concerned
> with.
>

When you look at the text I've linked: they also give the Linux kernel as
an example for the Dictator/Lieutenant workflow ;-). The terms branch and
repository are more or less interchangable in this context (at least with
Git). I guess in the end its a style choice if we decide for task force
repositories or feature branches. I would welcome the visibility of
development in the feature branch solution, but understand that some might
not be interested in the development of some minor task force.

Cheers,
Martine
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] [PROJECT][RIOT-OS][STM32-L152RE]

[Tararaina Klipffel]

Hello,

We are 4 French students in engineering school. We are currently working on
a robotic project of telepresence. We have set up RIOT-OS on a STM32 L152RE
board and we are now attempting to add an external library in our project.
We have a library libmded.a that contains every .o precompiled provided by
mbed, and a folder with the corresponding headers. Then we added the .h
path to the INCLUDES var in the makefile and the library to the USEMODULE
var. But when we're trying to compile it, it seems that the makefile isn't
able to find the functions include in this lib. That's why we would be
grateful for any advice that could guide us.

Kind regards.
Tara
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RPL (and more generally, networking) on border router

[Lotte Steenbrink]

Hi Emmanuel, hi all,

Am 23.02.2015 um 17:42 schrieb Emmanuel Baccelli :

> Hi Lotte,
> 
> on your blog posts for watr.li you mention using R-idge + 6LoWPAN on a Pi, 
> and you mention using RPL (or AODV) on top of that, in the near future, which 
> is a very interesting perspective.
> 
> My question is: how do you intend to go about this?
> 
Actually, we've already gone about this, and we're working on a blogpost about 
this right now. The approach we opted for is a bit... pragmatic due to time 
constraints, but I'd be very very interested in improving this situation in 
general. 

The situation we have right now is as follows:
Rosand Tech provides us with a RPL daemon [0] implementation, which Martin 
patched to make it work again with the latest Linux kernel. This daemon does 
its RPL-y thing, communicates with our RIOT nodes through the R-IDGE stick and 
writes all found routes to the Linux routing table. 
This all sounds very nice, but there's a catch: The rpld code seems to be a 
wrapper around contiki's native mode. So what it does is it spawns a contiki 
instance, let *that one* do all the RPL operations, tunnels the packets 
generated by the contiki instance through towards the R-IDGE and back, and in 
case it hears about any route updates from the contki instance, then sets these 
in the linux kernel, too.

As I said, it's probably a more pragmatic than perfect solution from Rosand, 
but there's one big benefit of this “hack”: we git a little bit of RIOT-RPL 
interop experience.
( This is where Martin's RPL improvement PRs came from. :) )
> It would be great to discuss approaches on the mailing list, because there 
> may be some cross-benefits at hand.
> 
> With Ubuntu people we had discussed using RIOT native instance running in 
> Linux to use RIOT network stack. Discussing with Ludwig today, he mentioned 
> another approach whereby the RIOT network stack could be straightforward to 
> port to Linux, and thus provide their missing IoT network stack to 
> communicate with RIOT devices (and still have a single code base to maintain 
> for us).
> 
> 

That sounds like a great idea. There seem to be some RPL implementations for 
linux around [1], but one of them seems to rely heavily on kernel modules 
(which could be avoided altogether with the oonf api's solution of listening on 
a tun/tap device which tunnels all unroutable packets into user space we talked 
about at the NSTF meeting), the second one was written in python, and the third 
one I couldn't completely make sense of ad-hoc. And I have no idea about the 
interoperability status of either of them.
> Do you already have a particular concept in mind? It would great to know 
> about this.
> 
> 

See above. :) If anybody else on the list has ben working on the same problem, 
please share!

Cheers,
Lotte
> Cheers,
> 
> Emmanuel
> 

[0] http://rosand-tech.com/downloads/index.html
[1] http://sixpinetrees.blogspot.de/2014/11/linux-rpl-router.html___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Notification: Biweekly virtual meeting @ Every 2 weeks from 10am to 11am on Wednesday (RIOT Events)

[Google Calendar]

This is a notification for:

Title: Biweekly virtual meeting
Developer discussions. Remote participation will be provided.
When: Every 2 weeks from 10am to 11am on Wednesday Berlin
Calendar: RIOT Events
Who:
* Ludwig Ortmann - creator

Event details:  
https://www.google.com/calendar/event?action=VIEW&eid=anBwMXUyaXZsdWVkOHFkdHA1MGpzYjFzZ2sgazNxbDhzZXR2N2w0OG9mbm9sMHRmdXU2dHNAZw


Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this email at the account peterschme...@gmail.com because  
you are subscribed for notifications on calendar RIOT Events.


To stop receiving these emails, please log in to  
https://www.google.com/calendar/ and change your notification settings for  
this calendar.
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Repository for Docker builds

[Matthias Waehlisch]

Hi,

  +1 for riotdocker, riotbuild is confusing.


Cheers
  matthias


On Tue, 24 Feb 2015, Joakim Gebart wrote:

> 
> riotdocker is more descriptive for the github repo name, I like it.
> 
> Best regards, Joakim
> 
> On Feb 24, 2015 8:20 AM, "Oleg Hahm"  wrote:
>   Hi Joakim!
> 
>   > What is a suitable name for the new repo?
>   > I have been using "riotbuild" for my Docker development at
>   > https://github.com/gebart/riotbuild
> 
>   I don't have any particular ideas for the name, so, for me "riotbuild" 
> (or
>   "riotdocker") would be fine.
> 
>   > Also, I need to have an organisation owner (Oleg, Kaspar, Emmanuel or
>   > Matthias Wählisch) create the repo since maintainers do not have the
>   proper
>   > access to do it.
> 
>   Sure, I can do so. Let's wait if no one objects against the proposed 
> name.
> 
>   Cheers,
>   Oleg
>   --
>   The problem with git jokes is everyone has their own version.
> 
>   ___
>   devel mailing list
>   devel@riot-os.org
>   http://lists.riot-os.org/mailman/listinfo/devel
> 
> 
> 

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehli...@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Repository for Docker builds

[Joakim Gebart]

riotdocker is more descriptive for the github repo name, I like it.

Best regards, Joakim
On Feb 24, 2015 8:20 AM, "Oleg Hahm"  wrote:

> Hi Joakim!
>
> > What is a suitable name for the new repo?
> > I have been using "riotbuild" for my Docker development at
> > https://github.com/gebart/riotbuild
>
> I don't have any particular ideas for the name, so, for me "riotbuild" (or
> "riotdocker") would be fine.
>
> > Also, I need to have an organisation owner (Oleg, Kaspar, Emmanuel or
> > Matthias Wählisch) create the repo since maintainers do not have the
> proper
> > access to do it.
>
> Sure, I can do so. Let's wait if no one objects against the proposed name.
>
> Cheers,
> Oleg
> --
> The problem with git jokes is everyone has their own version.
>
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel