Re: [riot-devel] [riot-users] Release 2019.10

2019-10-31 Thread Martine Lenders
Woohoo! Congratulations to everyone and thanks Ken for the great work!

Best regards,
Martine

Am Do., 31. Okt. 2019 um 14:29 Uhr schrieb Emmanuel Baccelli <
emmanuel.bacce...@inria.fr>:

> Yay! Congrats to all involved, and thanks a bunch Ken for managing this
> release!
> Cheers
> Emmanuel
>
> On Thu, Oct 31, 2019 at 2:17 PM Ken Bannister  wrote:
>
>> Dear RIOTers,
>>
>> We are happy to announce the 21st official release of RIOT:
>>
>> --- * RIOT 2019.10 * ---
>>
>> The 2019.10 release includes:
>>
>>   - initial support for SUIT firmware updates
>>   - USB CDC-ACM serial communication
>>   - complete rewrite of TI CC110x radio driver
>>   - initial support for IPv6 fragmentation
>>   - DTLS support in the sock networking stack
>>   - complete blockwise messaging for gcoap and nanocoap
>>   - as always, bug fixes and documentation updates
>>
>> About 460 pull requests, composed of 950 commits, have been merged since
>> the
>> last release, and about 60 issues have been solved. 57 people
>> contributed with
>> code in 105 days. Approximately 2000 files have been touched with 129000
>> insertions and 25000 deletions.
>>
>> You can download the RIOT release from Github by cloning the repository
>> and checkout the release tag [1] or by downloading the tarball [2], and
>> look up the release notes for further details [3].
>>
>> A big thank you to everybody who contributed! Special thanks to previous
>> release managers @miri64, @MrKevinWeiss, and @PeterKietzmann for offline
>> advice. Many thanks also to release testers @aabadie, @cladmi, @fjmolinas,
>> @jia200x, @leandrolanzieri, and @smlng.
>>
>> Your friendly neighborhood release manager,
>> Ken Bannister
>>
>>
>> [1] https://github.com/RIOT-OS/RIOT/tree/2019.10
>>
>> [2] https://github.com/RIOT-OS/RIOT/archive/2019.10.tar.gz
>>
>> [3] https://github.com/RIOT-OS/RIOT/releases/tag/2019.10
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
> ___
> users mailing list
> us...@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/users
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Notification: Hack'n'ACK @ Tue Oct 29, 2019 5pm - 10pm (CET) (RIOT Events)

2019-10-28 Thread Martine Lenders
Hi Kaspar,

The official start is still 5pm. Berlin and Paris just start early at 3pm
due to varying reasons.

Best regards,
Martine

PS: "Central European Time - Berlin" is the timezone indicator in the
quoted case ;-).

Am Mo., 28. Okt. 2019 um 20:13 Uhr schrieb Kaspar Schleiser <
kas...@schleiser.de>:

> Hey,
>
> On 10/28/19 5:00 PM, Google Calendar wrote:
> >   Hack'n'ACK
> >
> > /When/
> >   Tue Oct 29, 2019 5pm – 10pm Central European Time - Berlin
>
> Don't they start at 3pm now?
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Deprecation of `gnrc_nettest`

2019-10-28 Thread Martine Lenders
Hi there,

Jose and I proposed to deprecate `gnrc_nettest` [1]. It was originally
introduced to allow for integration tests of single GNRC modules, but it
never really got used and it is most often easier to just use
`gnrc_netreg_register()/unregister()` directly for that.

In the very unlikely case that anybody is using it, please speak up now!

Best regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/12593
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Deprecation of emb6

2019-10-08 Thread Martine Lenders
Hello,

I just proposed to deprecate emb6 [1] (the OS-independent version of
Contiki's uIP). Is anyone using this package? If yes, please speak up!

Kind regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/12389
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Updated invitation: Monthly RIOT developer meeting @ Monthly from 4pm to 5pm on the last Monday from Mon Oct 31, 2016 to Sun Sep 29 (CET) (RIOT Events)

2019-10-04 Thread Martine Lenders
FYI, that was me. The meeting didn't take place for a while now and I have
the feeling that this notification for a meeting that does not take place
was confusing some newer contributors. If we re-instate the meeting, we can
always recreate it :-).

Am Fr., 4. Okt. 2019 um 14:41 Uhr schrieb :

> *This event has been changed.*
> more details »
> <https://www.google.com/calendar/event?action=VIEW=NnFpMGh0a2RpajN0OWQ3bjhoa3VmdWdiMTEgazNxbDhzZXR2N2w0OG9mbm9sMHRmdXU2dHNAZw=1>
> Monthly RIOT developer meeting
>
> *When*
> *Changed: *Monthly from 4pm to 5pm on the last Monday from Mon Oct 31,
> 2016 to Sun Sep 29 Central European Time - Berlin
>
> *Where*
> Online (map <https://www.google.com/maps/search/Online?hl=en>)
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> 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 updated invitations 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.
>
> Forwarding this invitation could allow any recipient to send a response to
> the organizer and be added to the guest list, or invite others regardless
> of their own invitation status, or to modify your RSVP. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] devel Digest, Vol 79, Issue 14

2019-09-26 Thread Martine Lenders
Hi Adnan,
that tutorial seems horribly outdated. The last major edit before yours
were from 2014 and the fact that it refers to Mint Petra (which itself is
from 2014) is also underlining this. Since then we provided a vagrant
configuration [1] which gets rid of all the manual steps.

Kind regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/blob/master/dist/tools/vagrant/README.md

Am Do., 26. Sept. 2019 um 19:10 Uhr schrieb Adnan Rashid <
adnanrashi...@gmail.com>:

> Hi  Martine,
>
> Please check below link.
>
>
> https://github.com/RIOT-OS/RIOT/wiki/Howto:-Create-a-VirtualBox-Image-for-RIOT-development
>
>
> Moreover, In your documentation, I saw you people implemented RFC-6775.
> Can you please tell me what is the shortcoming in your code? What parts of
> the RFC is not implemented?
>
> Your prompt reply will be appreciated.
>
>
> On Thu, Sep 26, 2019 at 12:00 PM  wrote:
>
>> Send devel mailing list submissions to
>> devel@riot-os.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://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. How to Proceed? (Adnan Rashid)
>>2. Re: How to Proceed? (Martine Lenders)
>>
>>
>> --
>>
>> Message: 1
>> Date: Wed, 25 Sep 2019 12:50:03 +0200
>> From: Adnan Rashid 
>> To: devel@riot-os.org
>> Subject: [riot-devel] How to Proceed?
>> Message-ID:
>> > 8+v6ve98dtefmq4wst93ykosa4qdyvwht...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi Support Team,
>>
>> I want to simulate by using RIOT OS. What is the way forward? I had
>> followed your Wiki for the VMware installation, after step 7 I don't know
>> how to use RIOT OS.
>>
>> --
>>
>> Saluti,
>>
>>
>> ADNAN RASHID (Ph.D. Research Scholar)
>> Dpt. Ingegneria dell'Informazione
>> Universit? di Firenze
>>
>> via di S. Marta 3
>> 50139, Firenze-Italia
>>
>> email: adnan.ras...@unifi.it 
>>
>> Cell: (+39) 347 9821467
>>
>> Skype: adnanrashidpk
>>
>> ---
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.riot-os.org/pipermail/devel/attachments/20190925/6f304ecb/attachment-0001.htm
>> >
>>
>> --
>>
>> Message: 2
>> Date: Wed, 25 Sep 2019 12:56:49 +0200
>> From: Martine Lenders 
>> To: RIOT OS kernel developers 
>> Subject: Re: [riot-devel] How to Proceed?
>> Message-ID:
>> > w...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi Adnan,
>>
>> Can you refer us to the tutorial you are following? I'm not aware of any
>> that describes VMware integration.
>>
>> Kind Regards,
>> Martine
>>
>> Adnan Rashid  schrieb am Mi., 25. Sep. 2019,
>> 12:50:
>>
>> > Hi Support Team,
>> >
>> > I want to simulate by using RIOT OS. What is the way forward? I had
>> > followed your Wiki for the VMware installation, after step 7 I don't
>> know
>> > how to use RIOT OS.
>> >
>> > --
>> >
>> > Saluti,
>> >
>> >
>> > ADNAN RASHID (Ph.D. Research Scholar)
>> > Dpt. Ingegneria dell'Informazione
>> > Universit? di Firenze
>> >
>> > via di S. Marta 3
>> > 50139, Firenze-Italia
>> >
>> > email: adnan.ras...@unifi.it 
>> >
>> > Cell: (+39) 347 9821467
>> >
>> > Skype: adnanrashidpk
>> >
>> >
>> ---
>> > ___
>> > devel mailing list
>> > devel@riot-os.org
>> > https://lists.riot-os.org/mailman/listinfo/devel
>> >
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.riot-

Re: [riot-devel] How to Proceed?

2019-09-25 Thread Martine Lenders
Hi Adnan,

Can you refer us to the tutorial you are following? I'm not aware of any
that describes VMware integration.

Kind Regards,
Martine

Adnan Rashid  schrieb am Mi., 25. Sep. 2019, 12:50:

> Hi Support Team,
>
> I want to simulate by using RIOT OS. What is the way forward? I had
> followed your Wiki for the VMware installation, after step 7 I don't know
> how to use RIOT OS.
>
> --
>
> Saluti,
>
>
> ADNAN RASHID (Ph.D. Research Scholar)
> Dpt. Ingegneria dell'Informazione
> Università di Firenze
>
> via di S. Marta 3
> 50139, Firenze-Italia
>
> email: adnan.ras...@unifi.it 
>
> Cell: (+39) 347 9821467
>
> Skype: adnanrashidpk
>
> ---
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Remote Shell Commands

2019-09-09 Thread Martine Lenders
Hi,

I'm not sure we should migrate the shell to a completely structured output.
Though I can see the benefit of that wrt remote execution via CoAP/CBOR, a
shell should be primarily human readable. However, maybe there is some
middle ground to be found for that. Another interesting read with regards
of input parsing might be this draft by Carsten:
https://tools.ietf.org/html/draft-bormann-t2trg-slipmux-02.

Kind regards,
Martine

Am Mo., 9. Sept. 2019 um 15:41 Uhr schrieb Juan Ignacio Carrano <
j.carr...@fu-berlin.de>:

> Hi,
>
> During the Summit 2019 @vincent-d mentioned the possibility of remotely
> executing shell commands and @HendrikVE had a working shell-over-bluettoth.
>
> I just wanted to point out to you some work in that direction that may
> (or may not) be useful. With the PRs I mention below it should be easier
> to implement something like a CBOR/JSON based interface based on COAP or
> any other protocol.
>
> The first one is PR #10624 by @MrKevinWeiss which tries to define a
> common output format for shell commands. In particular, it provides a
> consistent way of reporting the return code of commands. The tricky part
> here is that it is still text based.
>
> The other is PR #9538 by me where I define some data structures to
> express the arguments to a command and also provide a parser. The parser
> is not important here, but the structures could allow arguments to be
> parsed from a document (e.g. JSON/CBOR/etc) and introspection by making
> the commands self-describing.
>
> Hope you can find that useful.
>
> Regards,
>
> Juan.
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Fragmentation in RIOT

2019-09-04 Thread Martine Lenders
Hi Adel,

And welcome to the RIOT community!

Adel Fuchs  schrieb am Mi., 4. Sep. 2019, 16:13:

> Hi,
>
> * Does RIOT support fragmentation in IPv6?
>

With https://github.com/RIOT-OS/RIOT/pull/11596 and
https://github.com/RIOT-OS/RIOT/pull/11623 merged, fragmentation is
supported by RIOT's default network stack, GNRC.

* Does RIOT support IPv4? If so, does it support fragmentation in IPv4?
>

GNRC does not support IPv4. However you can use LwIP as an alternative.
AFAIK it supports fragmentation, but I am not 100% sure.

Might I ask what you need fragmentation for?




> Thanks,
> Adel
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Notification: Hack'n'ACK @ Tue Aug 27, 2019 5pm - 10pm (CEST) (RIOT Events)

2019-08-27 Thread Martine Lenders
Hi,

with some delay we are now all set-up @ FU Berlin. Feel free to join us at
https://meet.jit.si/riot-hacknack
<https://www.google.com/url?q=https%3A%2F%2Fmeet.jit.si%2Friot-hacknack=D=2=AFQjCNFHTh1Q1XkmW41QP4foGqrtJCLhWQ>
.

Cheers,
Martine

Am Mo., 26. Aug. 2019 um 17:00 Uhr schrieb Google Calendar <
calendar-notificat...@google.com>:

> more details »
> <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxOTA4MjdUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=1>
> Hack'n'ACK
> https://meet.jit.si/riot-hacknack
> <https://www.google.com/url?q=https%3A%2F%2Fmeet.jit.si%2Friot-hacknack=D=2=AFQjCNFHTh1Q1XkmW41QP4foGqrtJCLhWQ>
> *When*
> Tue Aug 27, 2019 5pm – 10pm Central European Time - Berlin
>
> *Where*
> FU Berlin; HAW Hamburg (map
> <https://www.google.com/maps/search/FU+Berlin;+HAW+Hamburg?hl=en>)
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> 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.
>
> Forwarding this invitation could allow any recipient to send a response to
> the organizer and be added to the guest list, or invite others regardless
> of their own invitation status, or to modify your RSVP. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Deprecate NHDP module?

2019-08-09 Thread Martine Lenders
Hi,

I just proposed to deprecate the `nhdp` module [1], due to a stale code
base. If anyone is still using it or interested in maintaining it, please
let us know.

Kind regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/11987
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Notification: Hack'n'ACK @ Tue Jul 30, 2019 5pm - 10pm (CEST) (RIOT Events)

2019-07-30 Thread Martine Lenders
Hi,

we are all set-up in Berlin. https://meet.jit.si/riot-hacknack

Cheers,
Martine

Am Mo., 29. Juli 2019 um 17:00 Uhr schrieb Google Calendar <
calendar-notificat...@google.com>:

> more details »
> <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxOTA3MzBUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=1>
> Hack'n'ACK
> https://meet.jit.si/riot-hacknack
> <https://www.google.com/url?q=https%3A%2F%2Fjitsi.tools.ietf.org%2Friot-hacknack=D=2=AFQjCNGRLw_oWsexewHFmrgnEmXp-RJoRQ>
> *When*
> Tue Jul 30, 2019 5pm – 10pm Central European Time - Berlin
>
> *Where*
> FU Berlin; HAW Hamburg (map
> <https://www.google.com/maps/search/FU+Berlin;+HAW+Hamburg?hl=en>)
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> 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.
>
> Forwarding this invitation could allow any recipient to send a response to
> the organizer and be added to the guest list, or invite others regardless
> of their own invitation status, or to modify your RSVP. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] [riot-users] Release 2019.07

2019-07-25 Thread Martine Lenders
Hi,

Congretulations!

Cheers,
Martine

Am Do., 25. Juli 2019 um 11:46 Uhr schrieb Kevin Weiss <
kevin.we...@haw-hamburg.de>:

> Dear RIOTers,
>
> we are happy to announce the 20th official release of RIOT:
>
> --- * RIOT 2019.07 * ---
>
> The 2019.07 release includes a number of new features including many new
> boards and cpu, riotboot added to many new and old boards, USB is now 
> available,
> BLE improvements, Ethernet on stm32 platforms, as well as many bug fixes and
> documentation updates. Testing has also improved with both On-Target Testing
> increasing and now Hardware Assisted Automated Tests being run.
>
> About 300 pull requests with about 659 commits have been merged since the last
> release and about 50 issues have been solved. 26 people contributed with code
> in 106 days. Approximately 1377 files have been touched with 181993 insertions
> and 19668 deletions.
>
> You can download the RIOT release from Github by cloning the repository
> and checkout the release tag [1] or by downloading the tarball [2], and
> look up the release notes for further details [3].
>
>
> A big thank you to everybody who contributed!
>
> Best regards,
> Kevin Weiss
>
>
> [1]:https://github.com/RIOT-OS/RIOT/tree/2019.07
>
> [2]:https://github.com/RIOT-OS/RIOT/archive/2019.07.tar.gz
>
> [3]:https://github.com/RIOT-OS/RIOT/releases/tag/2019.07
>
> ___
> users mailing list
> us...@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/users
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] How to wait for a thread to end?

2019-07-24 Thread Martine Lenders
Hi,

not 100% sure if this can be done generally (apart from the state checks it
should AFAICS), but have a look how the pthread implementation how it
implements `pthread_join()` [1] which is essentially what you are trying to
do (see pthread_join(3)).

Cheers,
Martine

[1]
https://github.com/RIOT-OS/RIOT/blob/7eb579bf4f921d5246d4dccc80b48c8f2f307d06/sys/posix/pthread/pthread.c#L223-L255

Am Mi., 24. Juli 2019 um 19:06 Uhr schrieb Julian Holzwarth <
julian.holzwa...@fu-berlin.de>:

> Dear riot developers,
>
> while writing tests I want to wait for a thread I created to end. I tried
> something with changing my own priority but it did not work.
>
> How can I wait for a thread to end?
>
> Thank you in advance.
>
> Cheers,
> Julian
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Notification: Hack'n'ACK @ Tue Jun 25, 2019 5pm - 10pm (CEST) (RIOT Events)

2019-06-25 Thread Martine Lenders
Hi,

We are a little late with our early start in Berlin, but we are now online
https://meet.jit.si/riot-hacknack

Cheers,
Martine

Am Mo., 24. Juni 2019 um 17:00 Uhr schrieb Google Calendar <
calendar-notificat...@google.com>:

> more details »
> <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxOTA2MjVUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=1>
> Hack'n'ACK
> https://meet.jit.si/riot-hacknack
> <https://www.google.com/url?q=https%3A%2F%2Fjitsi.tools.ietf.org%2Friot-hacknack=D=2=AFQjCNGRLw_oWsexewHFmrgnEmXp-RJoRQ>
> *When*
> Tue Jun 25, 2019 5pm – 10pm Central European Time - Berlin
>
> *Where*
> FU Berlin; HAW Hamburg (map
> <https://www.google.com/maps/search/FU+Berlin;+HAW+Hamburg?hl=en>)
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> 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.
>
> Forwarding this invitation could allow any recipient to send a response to
> the organizer and be added to the guest list, or invite others regardless
> of their own invitation status, or to modify your RSVP. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Release 2019.07 - dates and feature requests

2019-06-04 Thread Martine Lenders
Hi,

would also be nice to add IPv6 fragmentation [1] and reassembly [2]. I
think the feature will be finished today for the most part (only tests for
fragmentation are missing). However, 6LoWPAN NHC adaption for extension
headers (on which IPv6 fragmentation is based on) is still missing. This
isn't a blocker, 6Lo packets won't just not be compressed starting with the
extension headers, though.

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/11623
[2] https://github.com/RIOT-OS/RIOT/pull/11596

Am Di., 4. Juni 2019 um 12:48 Uhr schrieb José Alamos <
jose.ala...@haw-hamburg.de>:

> Hi,
>
> I would like to manage to get GNRC LoRaWAN [1] merged into master. The
> PR is in good shape and only needs some testing/review.
>
> With this into master, I would like to move forward into a common API
> for all LoRaWAN implementations in RIOT (and of course, add more
> interesting features to the stack).
>
> Cheers,
> José
>
> [1]: https://github.com/RIOT-OS/RIOT/pull/11022
> On Mon, 2019-06-03 at 09:56 +0200, Gaëtan Harter wrote:
> > Hi,
> >
> > I would personally like to manage to get the migration to FLASHFILE
> > finally finished https://github.com/RIOT-OS/RIOT/pull/8838 (I only
> > have
> > the tracking PR currently, so it's my fault if it did not move) and
> > the
> > fix for flashers on the board I use for testing the release
> > https://github.com/RIOT-OS/RIOT/pull/10870 as I currently use them
> > for
> > testing anyway. I could need help for that last one if you have
> > examples
> > that put any of the mentioned boards in a no more flashable state
> > with RIOT.
> >
> > Cheers,
> > Gaëtan
> >
> >
> > On 6/1/19 6:42 PM, Dylan Laduranty wrote:
> > > Hi all,
> > > #11077 and #11085 could be in the incoming release but it will
> > > require to
> > > have #11075 and #10916 merged first.
> > > Hopefully, #11075 should be pretty straightforward and #10916
> > > (which
> > > introduces the stack) is in the final review state.
> > > Any help with the review and/or test process will be highly
> > > appreciated !
> > > Cheers,
> > >
> > > Le sam. 1 juin 2019 à 01:40, Hauke Petersen <
> > > hauke.peter...@fu-berlin.de> a
> > > écrit :
> > >
> > > > Hej,
> > > >
> > > > big +1! Getting the USB+Ethernet slave mode to work would be a
> > > > major
> > > > milestone towards simple to deploy border routers and such.
> > > >
> > > > So ~4 more weeks seems doable, right?!
> > > >
> > > > Cheers,
> > > > Hauke
> > > >
> > > >
> > > > On 5/31/19 10:11 PM, Mario Gómez wrote:
> > > >
> > > > Hi all!
> > > >
> > > > My grain of salt:
> > > >
> > > > For high impact features:
> > > >
> > > > PR #11085 (Serial console over USB) & PR #11077 (USB CDC ECM
> > > > support)
> > > >
> > > > Those two combined with something like the SAM-BA bootloader
> > > > (Arduino SAMD
> > > > bootloader compatible with BOSSA) would allow us to make easy-
> > > > upgradeable
> > > > one-chip border-router USB dongles based on the ATSAMR21. USB CDC
> > > > ECM
> > > > essentially could remove the need for ethos.
> > > >
> > > > Regards,
> > > > Mario.
> > > >
> > > > On Fri, May 31, 2019 at 6:51 AM Kevin Weiss <
> > > > kevin.we...@haw-hamburg.de>
> > > > wrote:
> > > >
> > > > > Dear RIOTers,
> > > > >
> > > > >
> > > > > The release dates for the upcoming release cycle are fixed as
> > > > > follows:
> > > > >
> > > > > - 28.06.2019 - soft feature freeze, for high impact features
> > > > >
> > > > > - 08.07.2019 - hard feature freeze, for all features
> > > > >
> > > > > - 31.07.2019 - Release date
> > > > >
> > > > > Could you please send your suggestions for features which you
> > > > > would like
> > > > > to see merged during this release cycle.
> > > > >
> > > > >
> > > > > Best regards, and happy hacking!
> > > > >
> > > > > Kevin Weiss
> > > > > ___
> > > > > devel mailing list
> > > > > devel@riot-os.org
> > > > > https://lists.riot-os.org/mailman/listinfo/devel
> > > > >
> > > >
> > > > ___
> > > > devel mailing listde...@riot-os.org
> > > > https://lists.riot-os.org/mailman/listinfo/devel
> > > >
> > > >
> > > > ___
> > > > devel mailing list
> > > > devel@riot-os.org
> > > > https://lists.riot-os.org/mailman/listinfo/devel
> > > >
> > >
> > >
> > > ___
> > > devel mailing list
> > > devel@riot-os.org
> > > https://lists.riot-os.org/mailman/listinfo/devel
> > >
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Notification: Hack'n'ACK @ Tue May 28, 2019 5pm - 10pm (CEST) (RIOT Events)

2019-05-27 Thread Martine Lenders
Hi,

this is a reminder or maybe new information for some: The Hack'n'ACK this
month will start in Berlin (and Paris?) tomorrow already at 3pm. If we see
a success in the number of attendance, this might become a regular thing.

Kind regards,
Martine

Am Mo., 27. Mai 2019 um 17:01 Uhr schrieb Google Calendar <
calendar-notificat...@google.com>:

> more details »
> <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxOTA1MjhUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=1>
> Hack'n'ACK
> https://meet.jit.si/riot-hacknack
> <https://www.google.com/url?q=https%3A%2F%2Fjitsi.tools.ietf.org%2Friot-hacknack=D=2=AFQjCNGRLw_oWsexewHFmrgnEmXp-RJoRQ>
> *When*
> Tue May 28, 2019 5pm – 10pm Central European Time - Berlin
>
> *Where*
> FU Berlin; HAW Hamburg (map
> <https://maps.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>)
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> 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.
>
> Forwarding this invitation could allow any recipient to send a response to
> the organizer and be added to the guest list, or invite others regardless
> of their own invitation status, or to modify your RSVP. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Release 2019.04

2019-04-29 Thread Martine Lenders
Congratulations, everyone!

Am Mo., 29. Apr. 2019 um 16:02 Uhr schrieb Daniel Petry <
daniel.pe...@fu-berlin.de>:

> Dear RIOTers,
>
> we are happy to announce the 19th official release of RIOT:
>
> --- * RIOT 2019.04 * ---
>
> The 2019.04 release includes a number of new features including porting of
> riotboot to a number of new platforms, 802.15.4 support on the nRF52, and
> the
> ability for firmware to flash images into a separate boot slot. Support for
> several new boards and new sensors was added. Additionally, this release
> contains a number of bug fixes and test improvements.
>
> About 320 pull requests with about 569 commits have been merged since the
> last
> release and about 40 issues have been solved. 44 people contributed with
> code
> in 88 days. Approximately 825 files have been touched with 32716 insertions
> and 5149 deletions.
>
> You can download the RIOT release from Github by cloning the repository
> and checkout the release tag [1] or by downloading the tarball [2], and
> look up the release notes for further details [3].
>
>
> A big thank you to everybody who contributed!
>
> Best regards,
> Dan
>
>
> [1]:https://github.com/RIOT-OS/RIOT/tree/2019.04
>
> [2]:https://github.com/RIOT-OS/RIOT/archive/2019.04.tar.gz
>
> [3]:https://github.com/RIOT-OS/RIOT/releases/tag/2019.04
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Notification: Hack'n'ACK @ Tue Mar 26, 2019 5pm - 10pm (CET) (RIOT Events)

2019-03-26 Thread Martine Lenders
Hi,

We are all set up @ IETF in Prague now. We did not set up any remote
participation setup as most of the usual participants are here. So if you
want to join in remotely, we'll see each other here, on GitHub or the IRC.

Have fun,
Martine

Am Mo., 25. März 2019 um 17:00 Uhr schrieb Google Calendar <
calendar-notificat...@google.com>:

> more details »
> <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxOTAzMjZUMTYwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=1>
> Hack'n'ACK
> https://jitsi.tools.ietf.org/riot-hacknack
> <https://www.google.com/url?q=https%3A%2F%2Fjitsi.tools.ietf.org%2Friot-hacknack=D=2=AFQjCNGRLw_oWsexewHFmrgnEmXp-RJoRQ>
> *When*
> Tue Mar 26, 2019 5pm – 10pm Central European Time - Berlin
>
> *Where*
> IETF 104 Code Lounge (map
> <https://maps.google.com/maps?q=IETF+104+Code+Lounge=en>)
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> 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.
>
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Updated invitation: Hack'n'ACK @ Tue Mar 26, 2019 5pm - 10pm (CET) (RIOT Events)

2019-03-25 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20190326T17
DTEND;TZID=Europe/Berlin:20190326T22
DTSTAMP:20190325T102915Z
UID:lbk4mfucqdomcf7c8o9cg4cmsg_r20181127t160...@google.com
RECURRENCE-ID;TZID=Europe/Berlin:20190326T17
CREATED:20150319T120715Z
DESCRIPTION:https://jitsi.tools.ietf.org/riot-hacknack\n\n-::~:~::~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPle
 ase do not edit this section of the description.\n\nView your event at http
 s://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvO
 WNnNGNtc2dfMjAxOTAzMjZUMTYwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=
 1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~::~:~::-
LAST-MODIFIED:20190325T102913Z
LOCATION:IETF 104 Code Lounge
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Hack'n'ACK
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Clocksync in RIOT OS

2019-01-30 Thread Martine Lenders
Hi Nitin,

Am Mi., 30. Jan. 2019 um 09:25 Uhr schrieb Nitin Shivaraman <
nitin.shivara...@tum-create.edu.sg>:

> Hello,
>
>
>
> I’m working on implementing a custom clock synchronization protocol on
> Riot OS.
>
> I saw that the earlier branch having well-known protocols (FTSP, GTSP,
> etc) implementation was merged to RIOT OS main branch and removed.  Is
> there a separate branch in which these protocols are included now?
>
> https://github.com/RIOT-OS/RIOT/pull/1538
>
>
>
> Would it still work if I locally added the old protocol files and to the
> latest version and test it? Please advise.
>

No that won't work, sadly. That PR is from a time before netdev [1] and
before GNRC [2], the two components we nowadays do most of our networking
over.


> Any directions in this regard would be a great help. Awaiting your
> response. Thanks.
>

You might be able to re-use some code of PR 1537 and rework it to work with
GNRC and netdev, but the quality of the PR isn't up to our current
expectations anymore (e.g. `desvirt` doesn't really belong in there), so
you would need to do a lot of cleanup.

I hope I was able to help.

Best Regards,
Martine

[1] http://doc.riot-os.org/group__drivers__netdev__api.html
[2] http://doc.riot-os.org/group__net__gnrc.html


>
>
> Best Regards,
>
> Nitin.
>
>
>
>
> *Research Associate **Electrification Suite and Test Lab (ESTL)*
>
> *TUMCREATE *
> Tel. + 65-93742855
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] RIOT-OS assembly @ 35C3

2018-12-27 Thread Martine Lenders
Hi,
In case you are searching for us. We were switched around a little:
https://35c3.c3nav.de/l/c:0:438.09:481.89/@0,439.08,482.83,5

Kind Regards,
Martine

Am Di., 25. Dez. 2018, 21:10 hat Martine Lenders 
geschrieben:

> Oops forgot the link: https://35c3.c3nav.de/l/riotos/
>
> Am Di., 25. Dez. 2018, 21:07 hat Martine Lenders 
> geschrieben:
>
>> Hi everyone,
>>
>> We now have a location for the RIOT assembly @ 35C3. See you there!
>>
>> Regards,
>> Martine
>>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] RIOT-OS assembly @ 35C3

2018-12-25 Thread Martine Lenders
Oops forgot the link: https://35c3.c3nav.de/l/riotos/

Am Di., 25. Dez. 2018, 21:07 hat Martine Lenders 
geschrieben:

> Hi everyone,
>
> We now have a location for the RIOT assembly @ 35C3. See you there!
>
> Regards,
> Martine
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] RIOT-OS assembly @ 35C3

2018-12-25 Thread Martine Lenders
Hi everyone,

We now have a location for the RIOT assembly @ 35C3. See you there!

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


Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)

2018-12-18 Thread Martine Lenders
See [1] for a fix.

[1] https://github.com/RIOT-OS/RIOT/pull/10627

Am Mo., 17. Dez. 2018 um 12:21 Uhr schrieb Martine Lenders <
m...@martine-lenders.eu>:

> Hi Thomas,
>
> Am Mo., 17. Dez. 2018 um 11:57 Uhr schrieb Thomas C. Schmidt <
> t.schm...@haw-hamburg.de>:
>
>> Hi Martine,
>>
>> On 17/12/2018 11:17, Martine Lenders wrote:
>>
>> > at first glance this seems to be indeed a bug. If the prefix
>> > `2001:db8::/64` is configured for one interface, this should be hint
>> > enough for the NDP to use that interface to multicast the NS there.
>> I'll
>> > investigate that.
>> >
>> > However, I have to add that RFC 6775 (which applies for the border
>> > router) makes the neighbor discovery very destination-oriented (so
>> > typically NS are only send upstream performing address registration
>> with
>> > the upstream router). So that might also be a legitimate behavior, as
>> > downstream nodes should usually be registered via Address registration
>> > with the border router or at least a route should be configured to the
>> > downstream node with a routing protocol of your choosing ;-).
>> >
>>
>> Yes, but forwarding to the default upstream should be a failure in this
>> case: The packet would then come back from upstream in a loop.
>>
>
> Yes indeed. Forwarding to the default route is definitely an error.
>
>
>>
>> Cheers,
>>   Thomas
>>
>> > Am Mo., 17. Dez. 2018 um 10:13 Uhr schrieb Thomas C. Schmidt
>> > mailto:t.schm...@haw-hamburg.de>>:
>> >
>> > Hi Joakim,
>> >
>> > On 17/12/2018 09:37, Joakim Nohlgård wrote:
>> >
>> >  > Thank you for your answer. OK I think I understand what you
>> mean, but
>> >  > is this really the correct behavior?
>> >  > It was certainly unexpected to me to have the packets go out the
>> >  > default route instead of on the interface with the configured
>> prefix.
>> >  >
>> >  > I will try to elaborate:
>> >  > I have a prefix 2001:db8::/64 configured for the wireless
>> interface.
>> >  > When I run ping6 2001:db8::1234 from the shell on the RIOT node,
>> I
>> >  > expect the system to first attempt to find 2001:db8::1234 on the
>> >  > interface which has been configured for that prefix, instead of
>> >  > immediately falling back and taking the default route when the
>> >  > destination does not already exist in the NIB neighbor table.
>> >  >
>> >
>> > I would expect so, too: This should be the correct routing decision
>> and
>> > default routing is wrong. Sorry, I didn't see that in your previous
>> > mail.
>> > I'm not sure such fallback makes sense at all, if a specific,
>> globally
>> > routable prefix is configured. If 2001:db8::1234 is not reachable
>> via
>> > 2001:db8::/64, a 'destination unreachable' should be triggered.
>> >
>> > Cheers,
>> >thomas
>> >
>> >  > On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt
>> >  > mailto:t.schm...@haw-hamburg.de>>
>> wrote:
>> >  >>
>> >  >> Hi Joakim,
>> >  >>
>> >  >> it appears that you are experimenting with a special case.
>> >  >>
>> >  >> Normally, a sending node decides on the outgoing interface based
>> > on the
>> >  >> destination IP prefix. If you don't have a more specific routing
>> > entry,
>> >  >> the default IF is correctly chosen in your case.
>> >  >>
>> >  >> After the interface is selected, the source needs to decide on
>> the
>> >  >> Layer2 framing. Most link-layer technologies use an addressing
>> >  >> (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In
>> your
>> >  >> case, you mention SLIP. A serial line interface does not use L2
>> >  >> addresses and does not need ND.
>> >  >>
>> >  >> Best,
>> >  >>Thomas
>> >  >>
>> >  >> On 17/12/2018 08:59, Joakim Nohlgård wrote:
>> >  >>> Hi developers,
>> >  >>> When using the shell on the gnrc_border_router application
>> > tryin

Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)

2018-12-17 Thread Martine Lenders
Hi Thomas,

Am Mo., 17. Dez. 2018 um 11:57 Uhr schrieb Thomas C. Schmidt <
t.schm...@haw-hamburg.de>:

> Hi Martine,
>
> On 17/12/2018 11:17, Martine Lenders wrote:
>
> > at first glance this seems to be indeed a bug. If the prefix
> > `2001:db8::/64` is configured for one interface, this should be hint
> > enough for the NDP to use that interface to multicast the NS there. I'll
> > investigate that.
> >
> > However, I have to add that RFC 6775 (which applies for the border
> > router) makes the neighbor discovery very destination-oriented (so
> > typically NS are only send upstream performing address registration with
> > the upstream router). So that might also be a legitimate behavior, as
> > downstream nodes should usually be registered via Address registration
> > with the border router or at least a route should be configured to the
> > downstream node with a routing protocol of your choosing ;-).
> >
>
> Yes, but forwarding to the default upstream should be a failure in this
> case: The packet would then come back from upstream in a loop.
>

Yes indeed. Forwarding to the default route is definitely an error.


>
> Cheers,
>   Thomas
>
> > Am Mo., 17. Dez. 2018 um 10:13 Uhr schrieb Thomas C. Schmidt
> > mailto:t.schm...@haw-hamburg.de>>:
> >
> > Hi Joakim,
> >
> > On 17/12/2018 09:37, Joakim Nohlgård wrote:
> >
> >  > Thank you for your answer. OK I think I understand what you mean,
> but
> >  > is this really the correct behavior?
> >  > It was certainly unexpected to me to have the packets go out the
> >  > default route instead of on the interface with the configured
> prefix.
> >  >
> >  > I will try to elaborate:
> >  > I have a prefix 2001:db8::/64 configured for the wireless
> interface.
> >  > When I run ping6 2001:db8::1234 from the shell on the RIOT node, I
> >  > expect the system to first attempt to find 2001:db8::1234 on the
> >  > interface which has been configured for that prefix, instead of
> >  > immediately falling back and taking the default route when the
> >  > destination does not already exist in the NIB neighbor table.
> >  >
> >
> > I would expect so, too: This should be the correct routing decision
> and
> > default routing is wrong. Sorry, I didn't see that in your previous
> > mail.
> > I'm not sure such fallback makes sense at all, if a specific,
> globally
> > routable prefix is configured. If 2001:db8::1234 is not reachable via
> > 2001:db8::/64, a 'destination unreachable' should be triggered.
> >
> > Cheers,
> >thomas
> >
> >  > On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt
> >  > mailto:t.schm...@haw-hamburg.de>>
> wrote:
> >  >>
> >  >> Hi Joakim,
> >  >>
> >  >> it appears that you are experimenting with a special case.
> >  >>
> >  >> Normally, a sending node decides on the outgoing interface based
> > on the
> >  >> destination IP prefix. If you don't have a more specific routing
> > entry,
> >  >> the default IF is correctly chosen in your case.
> >  >>
> >  >> After the interface is selected, the source needs to decide on
> the
> >  >> Layer2 framing. Most link-layer technologies use an addressing
> >  >> (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In
> your
> >  >> case, you mention SLIP. A serial line interface does not use L2
> >  >> addresses and does not need ND.
> >  >>
> >  >> Best,
> >  >>Thomas
> >  >>
> >  >> On 17/12/2018 08:59, Joakim Nohlgård wrote:
> >  >>> Hi developers,
> >  >>> When using the shell on the gnrc_border_router application
> > trying to
> >  >>> send to an unknown address with its designated prefix, the
> > application
> >  >>> does not send any neighbor solicitations on the wireless
> network.
> >  >>> When I type ping6 2001:db8::1234 I expected that a neighbor
> >  >>> solicitation query to go out on the interface that has been
> > configured
> >  >>> with the routing destination for 2001:db8::/64, but wireshark
> shows
> >  >>> that nothing is sent on the wireless, but instead the ICMPv

Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)

2018-12-17 Thread Martine Lenders
Hi,

at first glance this seems to be indeed a bug. If the prefix
`2001:db8::/64` is configured for one interface, this should be hint enough
for the NDP to use that interface to multicast the NS there. I'll
investigate that.

However, I have to add that RFC 6775 (which applies for the border router)
makes the neighbor discovery very destination-oriented (so typically NS are
only send upstream performing address registration with the upstream
router). So that might also be a legitimate behavior, as downstream nodes
should usually be registered via Address registration with the border
router or at least a route should be configured to the downstream node with
a routing protocol of your choosing ;-).

Best regards,
Martine

Am Mo., 17. Dez. 2018 um 10:13 Uhr schrieb Thomas C. Schmidt <
t.schm...@haw-hamburg.de>:

> Hi Joakim,
>
> On 17/12/2018 09:37, Joakim Nohlgård wrote:
>
> > Thank you for your answer. OK I think I understand what you mean, but
> > is this really the correct behavior?
> > It was certainly unexpected to me to have the packets go out the
> > default route instead of on the interface with the configured prefix.
> >
> > I will try to elaborate:
> > I have a prefix 2001:db8::/64 configured for the wireless interface.
> > When I run ping6 2001:db8::1234 from the shell on the RIOT node, I
> > expect the system to first attempt to find 2001:db8::1234 on the
> > interface which has been configured for that prefix, instead of
> > immediately falling back and taking the default route when the
> > destination does not already exist in the NIB neighbor table.
> >
>
> I would expect so, too: This should be the correct routing decision and
> default routing is wrong. Sorry, I didn't see that in your previous mail.
> I'm not sure such fallback makes sense at all, if a specific, globally
> routable prefix is configured. If 2001:db8::1234 is not reachable via
> 2001:db8::/64, a 'destination unreachable' should be triggered.
>
> Cheers,
>   thomas
>
> > On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt
> >  wrote:
> >>
> >> Hi Joakim,
> >>
> >> it appears that you are experimenting with a special case.
> >>
> >> Normally, a sending node decides on the outgoing interface based on the
> >> destination IP prefix. If you don't have a more specific routing entry,
> >> the default IF is correctly chosen in your case.
> >>
> >> After the interface is selected, the source needs to decide on the
> >> Layer2 framing. Most link-layer technologies use an addressing
> >> (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In your
> >> case, you mention SLIP. A serial line interface does not use L2
> >> addresses and does not need ND.
> >>
> >> Best,
> >>Thomas
> >>
> >> On 17/12/2018 08:59, Joakim Nohlgård wrote:
> >>> Hi developers,
> >>> When using the shell on the gnrc_border_router application trying to
> >>> send to an unknown address with its designated prefix, the application
> >>> does not send any neighbor solicitations on the wireless network.
> >>> When I type ping6 2001:db8::1234 I expected that a neighbor
> >>> solicitation query to go out on the interface that has been configured
> >>> with the routing destination for 2001:db8::/64, but wireshark shows
> >>> that nothing is sent on the wireless, but instead the ICMPv6 packet is
> >>> sent immediately over the slip/ethos interface, which is configured as
> >>> the default route.
> >>>
> >>> Is this behavior correct or is this a routing bug?
> >>>
> >>> Configurations:
>  ifconfig
> >>> Iface  6  HWaddr: 02:DA:F1:03:BC:48
> >>> MTU:1500  HL:64  RTR
> >>> RTR_ADV  Source address length: 6
> >>> Link type: wired
> >>> inet6 addr: fe80::da:f1ff:fe03:bc48  scope: local  TNT[1]
> >>> inet6 addr: fe80::2  scope: local  VAL
> >>> inet6 group: ff02::2
> >>> inet6 group: ff02::1
> >>> inet6 group: ff02::1:ff03:bc48
> >>> inet6 group: ff02::1:ff00:2
> >>>
> >>> Iface  7  Channel: 26  Page: 0  NID: 0x23
> >>> Long HWaddr: 23:31:53:29:36:B7:6E:5A
> >>>  TX-Power: 0dBm  State: IDLE  max. Retrans.: 3  CSMA
> Retries: 4
> >>> ACK_REQ  CSMA  MTU:1280  HL:64  RTR
> >>> RTR_ADV  IPHC
> >>> Source address length: 8
> >>> Link type: wireless
> >>> inet6 addr: fe80::2131:5329:36b7:6e5a  scope: local  VAL
> >>> inet6 addr: 2001:db8::2131:5329:36b7:6e5a  scope: global
> VAL
> >>> inet6 group: ff02::2
> >>> inet6 group: ff02::1
> >>> inet6 group: ff02::1:ffb7:6e5a
> >>> routing:
>  nib route
> >>> 2001:db8::/64 dev #7
> >>> default* via fe80::1 dev #6
> >>>
> >>> Best regards,
> >>> Joakim
> >>> ___
> >>> devel mailing list
> >>> devel@riot-os.org
> >>> https://lists.riot-os.org/mailman/listinfo/devel
> >>>
> >>
> >> --
> >>
> >> Prof. Dr. Thomas C. Schmidt
> >> ° Hamburg 

[riot-devel] Updated invitation: Hack'n'ACK @ Monthly from 5pm to 10pm on the last Tuesday from Tue Mar 29, 2016 to Mon Nov 26 (CEST) (RIOT Events)

2018-11-16 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20160329T17
DTEND;TZID=Europe/Berlin:20160329T22
RRULE:FREQ=MONTHLY;UNTIL=20181126T225959Z;BYDAY=-1TU
DTSTAMP:20181116T142819Z
UID:lbk4mfucqdomcf7c8o9cg4cmsg_r20160329t150...@google.com
CREATED:20150319T120715Z
DESCRIPTION:-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the descriptio
 n.\n\nView your event at https://www.google.com/calendar/event?action=VIEW;
 eid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfUjIwMTYwMzI5VDE1MDAwMCBrM3FsOHNldHY
 3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20181116T142818Z
LOCATION:FU Berlin\; HAW Hamburg
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Hack'n'ACK
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Updated invitation: Hack'n'ACK @ Tue Dec 18, 2018 5pm - 10pm (CET) (RIOT Events)

2018-11-16 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VEVENT
DTSTART:20181218T16Z
DTEND:20181218T21Z
DTSTAMP:20181116T142748Z
UID:342g2u690uk4sq40pv7rh9g...@google.com
CREATED:20181116T142601Z
DESCRIPTION:https://jitsi.tools.ietf.org/riot-hacknack\n\n-::~:~::~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPle
 ase do not edit this section of the description.\n\nView your event at http
 s://www.google.com/calendar/event?action=VIEW=MzQyZzJ1NjkwdWs0c3E0MHB2N
 3JoOWdsaGEgazNxbDhzZXR2N2w0OG9mbm9sMHRmdXU2dHNAZw=1.\n-::~:~::~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20181116T142748Z
LOCATION:FU Berlin\; HAW Hamburg
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Hack'n'ACK
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] New event: Hack'n'ACK @ Tue Dec 18, 2018 5pm - 10pm (CET) (RIOT Events)

2018-11-16 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VEVENT
DTSTART:20181218T16Z
DTEND:20181218T21Z
DTSTAMP:20181116T142602Z
UID:342g2u690uk4sq40pv7rh9g...@google.com
CREATED:20181116T142601Z
DESCRIPTION:-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the descriptio
 n.\n\nView your event at https://www.google.com/calendar/event?action=VIEW;
 eid=MzQyZzJ1NjkwdWs0c3E0MHB2N3JoOWdsaGEgazNxbDhzZXR2N2w0OG9mbm9sMHRmdXU2dHN
 AZw=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20181116T142601Z
LOCATION:FU Berlin\; HAW Hamburg
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Hack'n'ACK
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] 35C3 CfP

2018-11-07 Thread Martine Lenders
Hi,

I now registered an assembly for RIOT [1]. Since there were a few of you
interested in joining the assembly, I asked for 8 seats (incl. space for
Laptops and power supply) for now.

Kind regards,
Martine

[1]
https://signup.c3assemblies.de/assembly/981320b8-784c-4e8c-b32d-ba0865e44be1



Am Mi., 10. Okt. 2018 um 21:18 Uhr schrieb Martine Lenders <
m...@martine-lenders.eu>:

> Hi,
>
> to everyone interested FYI: The presale dates are set:
> https://events.ccc.de/2018/10/10/35c3-tickets-presale/
>
> Regards,
> Martine
>
> Am Mo., 24. Sep. 2018 um 15:51 Uhr schrieb Simon Brummer <
> simon.brum...@posteo.de>:
>
>> Hi Martine,
>>
>> I would like to be part of a RIOT assembly. ;)
>>
>> Cheers Simon
>>
>> Am 2018-09-19 18:04 schrieb Martine Lenders:
>> > Hi,
>> >
>> > FYI, the CfP for 35C3 is out [1] since last week.
>> >
>> > My current plan is to represent the RIOT community there with an
>> > high-level introductory talk on ICN within the Science track there.
>> >
>> > As every year: If we get enough people together, I would like to start
>> > a RIOT assembly.
>> >
>> > Kind regards,
>> > Martine
>> >
>> > [1]
>> >
>> https://events.ccc.de/2018/09/11/35c3-call-for-participation-and-submission-guidelines/
>> >
>> > ___
>> > devel mailing list
>> > devel@riot-os.org
>> > https://lists.riot-os.org/mailman/listinfo/devel
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Preparing release 2018.10

2018-10-16 Thread Martine Lenders
Hi Gunar,

Am Sa., 6. Okt. 2018 um 13:56 Uhr schrieb Gunar Schorcht :

> Hi Jose,
>
> is it necessary to tell you also features that were merged into master
> since last release or are they included automatically, e.g., the ESP8266
> platform?
>

Usually the features added during a release cycle are collected when we
start drafting the release notes, so there is still time for that ;-)
(however, Jose might already want to collect them elsewhere beforehand).

Regards,
Martine


>
> Regards
> Gunar
>
> Am 4. Oktober 2018 15:09:06 MESZ schrieb "Alamos, Jose" <
> jose.ala...@haw-hamburg.de>:
>>
>> Dear RIOTers,
>>
>>
>> The 2018.10 release is on its way!
>>
>>
>> This is my first time taking care of the release process so all feedback
>> is welcome.
>>
>>
>>
>> Here is a summary of the important dates
>>
>>
>>- Preliminary/soft feature release for high impact features: October
>>16th, 2018.
>>- Final/hard feature freeze: October 23rd, 2018.
>>- Planned release date: November 1st, 2018.
>>
>> The exact definition of high impact is up to the maintainers.
>>
>>
>> Please contact me if you have features that you would like to have and
>> you think can be ready for the release.
>>
>>
>> As I reminder, the project currently have 416 PRs and 433 open issues. If
>> you are assigned, mentioned or have review requested to one of them, please
>> try to put as much efforts in order to fix/ack/merge.
>>
>>
>> Also remember to update and rebase your PR in order to make the review
>> easier.
>>
>>
>> Keep on the good work!
>>
>>
>> José
>>
>
> --
> Sent from my Android mobile
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] 35C3 CfP

2018-10-10 Thread Martine Lenders
Hi,

to everyone interested FYI: The presale dates are set:
https://events.ccc.de/2018/10/10/35c3-tickets-presale/

Regards,
Martine

Am Mo., 24. Sep. 2018 um 15:51 Uhr schrieb Simon Brummer <
simon.brum...@posteo.de>:

> Hi Martine,
>
> I would like to be part of a RIOT assembly. ;)
>
> Cheers Simon
>
> Am 2018-09-19 18:04 schrieb Martine Lenders:
> > Hi,
> >
> > FYI, the CfP for 35C3 is out [1] since last week.
> >
> > My current plan is to represent the RIOT community there with an
> > high-level introductory talk on ICN within the Science track there.
> >
> > As every year: If we get enough people together, I would like to start
> > a RIOT assembly.
> >
> > Kind regards,
> > Martine
> >
> > [1]
> >
> https://events.ccc.de/2018/09/11/35c3-call-for-participation-and-submission-guidelines/
> >
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Lifting the 50 characters commit first line limit?

2018-10-10 Thread Martine Lenders
Hi Pekka,

feel free to change the check script [1] to whatever is most comfortable to
you :-) (sorry today I'm very busy so I can't do it myself; but I'm happy
to review it once ready).

Regards,
Martine

[1]
https://github.com/RIOT-OS/RIOT/blob/master/dist/tools/commit-msg/check.sh

Am Mi., 10. Okt. 2018 um 12:14 Uhr schrieb Nikander Pekka <
pekka.nikan...@aalto.fi>:

> Thanks Martine and all!
>
> My memory is bad.  Now that I saw your answer, Martine, I remembered that
> I have asked about this before, in some other forum, and have got the same
> answer.  But I didn't remember it.
>
> That is, Travis tricked me again.
>
> If possible, it would be very nice if Travis (and make static-test) was
> changed so that I won't get tricked again and won't again start doing work
> which is not needed.
>
> In more precise terms, could the string
>
>   Commit message is longer than 50 characters:
>
> be changed to
>
>  Warning: Commit message is longer than 50 characters (but still < 70
> characters):
>
> Had there been at least that one more word, "Warning:", this whole noise
> would not have taken place.
>
> --Pekka
>
> On 10.10.2018, at 12:50, Ken Bannister  wrote:
>
> Martine and I discussed this over a PR a few months ago. The outcome was
> to update the Good Pull Request wiki page [1], which basically says what
> has just been discussed on this thread. Good to spread the word and share
> the link. :-)
>
> Ken
>
> [1]
> https://github.com/RIOT-OS/RIOT/wiki/Guidelines-for-Creating-a-Good-Pull-Request
>
> On 10/10/2018 03:31 AM, Joakim Nohlgård wrote:
>
> +1 what Martine wrote.
>
> (I was composing a similar message when you beat me to it)
> /Joakim
>
> Den ons 10 okt. 2018 08:51Martine Lenders  skrev:
>
>> Hi Pekka,
>>
>> the 50 chars is just the warning bound. You can go up to 70 until the
>> commit message check fails on you. Longer will make GitHub break the commit
>> message in the webview with the dreaded […] ;-).
>>
>> My usual approach is to boil down the summary to the bare minimum within
>> these constraints (even using just the module name instead of the full
>> path) and go into details in the following lines of the commit message.
>>
>> Regards,
>> Martine
>>
>> Am Mi., 10. Okt. 2018 um 08:06 Uhr schrieb Nikander Pekka <
>> pekka.nikan...@aalto.fi>:
>>
>>> [Refactoring the nRF520 mega-PR to follow the standards...]
>>>
>>> I guess this has been bashed to death, but I am annoyed.
>>>
>>> With long paths, the 50 characters limit on the first line
>>> of the commit message makes it impossible to have any meaningful
>>> explanation of what the commit actually does.  Actually,
>>> the limitation makes the commit messages unintelligible.
>>>
>>> _Any_ change of increasing the limit to e.g. 72 characters?
>>>
>>> --Pekka
>>>
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Lifting the 50 characters commit first line limit?

2018-10-10 Thread Martine Lenders
Hi Pekka,

the 50 chars is just the warning bound. You can go up to 70 until the
commit message check fails on you. Longer will make GitHub break the commit
message in the webview with the dreaded […] ;-).

My usual approach is to boil down the summary to the bare minimum within
these constraints (even using just the module name instead of the full
path) and go into details in the following lines of the commit message.

Regards,
Martine

Am Mi., 10. Okt. 2018 um 08:06 Uhr schrieb Nikander Pekka <
pekka.nikan...@aalto.fi>:

> [Refactoring the nRF520 mega-PR to follow the standards...]
>
> I guess this has been bashed to death, but I am annoyed.
>
> With long paths, the 50 characters limit on the first line
> of the commit message makes it impossible to have any meaningful
> explanation of what the commit actually does.  Actually,
> the limitation makes the commit messages unintelligible.
>
> _Any_ change of increasing the limit to e.g. 72 characters?
>
> --Pekka
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Unit test code coverage using gcov

2018-10-09 Thread Martine Lenders
Hi,

as there is some discussion to split the unittests into several
applications [1] and some stuff isn't included into them for good reasons
(driver test e.g.), I'm not sure if this should be constrained to unittests
(though they are indeed a good starting point).

Regards,
Martine

PS: I'm not aware of work going into that direction, so +1 in general.

[1] https://github.com/RIOT-OS/RIOT/issues/8941

Am Di., 9. Okt. 2018 um 16:17 Uhr schrieb STEGEN Toon <
tste...@nalys-group.com>:

> Hi Guys,
>
>
> Has anybody succeeded in getting gcov to work to check code coverage of
> the unit tests?
>
> We will try to add support for this, but I want to make sure we're not
> spending our time on unnecessary work.
>
>
> Greets,
>
> Toon Stegen
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Git submodule in RIOT-OS/applications

2018-09-26 Thread Martine Lenders
Hi Jose,

while I agree that this would be easier for new users, I don't see how this
would help with applications being in a working state.

First of all, continuous integration is missing for those applications
anyways (IMHO we should change that), so a working state isn't guaranteed
in the first place. A submodule wouldn't help with that.

Second, if any problem arises with the application, we would be "stuck" on
that release (or would have to have hotfixes backported into the release,
specifically tailored to the application). So I'd rather would like to have
it synced with current master but included into the continous integration.

Regards,
Martine

Am Mi., 26. Sep. 2018 um 09:47 Uhr schrieb Jose :

> Hello RIOT developers,
>
>
> Does it make sense to provide a RIOT (git submodule) folder in the
> RIOT-OS/applications, pointing to the latest RIOT release?
>
> I can see some reasons:
>
> - Applications will always be in a working state
>
> - Might be easier for new users to clone and use
>
>
> We would require to update the submodule at the end of a Release.
>
> Any comments?
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Murdock compiling with LLVM now for several Cortex-M boards

2018-09-25 Thread Martine Lenders
Dear RIOTers,

with #9809 [1] merged we now we also test compiling (and running the
resulting binary) with LLVM, so please if your PR has some build older than
the merge date (2018-09-25 18:40 +02:00), re-run the build on Murdock (by
un- and re-setting the "CI: ready for build" label), to make sure it
doesn't introduce errors when compiling with LLVM that were not visible
before.

Thanks and kind regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/9809
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Updated invitation: Monthly RIOT developer meeting @ Monthly from 4pm to 5pm on the last Monday (CET) (RIOT Events)

2018-09-22 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20161031T16
DTEND;TZID=Europe/Berlin:20161031T17
RRULE:FREQ=MONTHLY;WKST=MO;BYDAY=-1MO
DTSTAMP:20180922T090826Z
UID:6qi0htkdij3t9d7n8hkufug...@google.com
CREATED:20171110T142417Z
DESCRIPTION:-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the descriptio
 n.\n\nView your event at https://www.google.com/calendar/event?action=VIEW;
 eid=NnFpMGh0a2RpajN0OWQ3bjhoa3VmdWdiMTEgazNxbDhzZXR2N2w0OG9mbm9sMHRmdXU2dHN
 AZw=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20180922T090825Z
LOCATION:Online
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Monthly RIOT developer meeting
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Livestream @ RIOT-Summit

2018-09-13 Thread Martine Lenders
Hi,

we have a livestream this year [1]. It's our first try so please forgive is
there are some hick-ups.

Cheers,
Martine (miri64) & Sebastian (smlng)

[1] https://www.youtube.com/watch?v=FFvJANMkShg
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Activation of modules by make command line

2018-09-06 Thread Martine Lenders
Hi Gunar,

Of course it is possible to do it from command-line. You were pretty close,
but you don't need an intermediate variable. Just set the variable
USEMODULE in your environment:

USEMODULE="sdcard_spi mrf24j40" BOARD=... make ...

Regards,
Martine

Am Do., 6. Sep. 2018 um 10:33 Uhr schrieb Gunar Schorcht :

> Hi,
>
> It is often necessary to enable or disable various functions at
> compilation time, for example, to test dependencies. In RIOT, features
> are activated using the module concept:
>
> USEMODULE + = feature
>
> I'm wondering whether there is a possibility to enable modules without
> changing the makefile when the make command is called, for example:
>
> make BOARD=... USE_MODULES="sdcard_spi mrf24j40"
>
> I was looking through the documentation and the makefile structure for
> something like
>
> USEMODULE += $(USE_MODULES)
>
> Did I miss something? If it is not possible, would it be worth to
> realize it?
>
> Regards
> Gunar
>
> --
> Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
> kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Release 2018.07

2018-08-14 Thread Martine Lenders
Wooohhooo!1!! Thanks for hanging in there Gaëtan and thanks to everyone who
contributed!

Best,
Martine

Am Di., 14. Aug. 2018 um 08:12 Uhr schrieb Gaëtan Harter <
gaetan.har...@fu-berlin.de>:

> Dear RIOTers,
>
> we are happy to announce the 16th official release of RIOT:
>
> --- * RIOT 2018.07 * ---
>
> The 2018.07 release includes new features, like NimBLE (ble stack),
> a MQTT-SN client, SHA-1 based PRNG, an UUID implementation. The RISC-V
> CPU architecture support used by the hifive1 board.
> Effort was done on refactoring, documentation, test improvements and bug
> fixes.
>
> During the last release, maintainers contributed by running the
> automated test suites on their boards. This gave valuable feedback on
> the board support state, test reliability and where to focus effort to
> make testing easier and more reliable.
>
> About 380 pull requests with about 675 commits have been merged since
> the last release and about 27 issues have been solved. 45 people
> contributed with code in 93 days. Approximately 1678 files have been
> touched with 147122 insertions and 16060 deletions.
>
> You can download the RIOT release from Github by cloning the repository
> and checkout the release tag [1] or by downloading the tarball [2], and
> look up the release notes for further details [3].
>
> Many thanks to all of you contributing in so many different ways to make
> RIOT worthwhile!
>
> Best Regards,
> Gaëtan - @cladmi
>
> [1]: https://github.com/RIOT-OS/RIOT/tree/2018.07
> [2]: https://github.com/RIOT-OS/RIOT/archive/2018.07.tar.gz
> [3]: https://github.com/RIOT-OS/RIOT/releases/tag/2018.07
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] A general fragmentation/reassembly library for GNRC

2018-06-13 Thread Martine Lenders
Hi,

Triggered by an issue a short while ago [1], and the necessity for IPv6
fragmentation/reassembly that crystalized out of that, I remembered that
Cenk and Jose were in the talks of a general fragmentation/reassembly
library for GNRC. Is this still on the table? If yes, I think we should
discuss this, so I collected some requirements from the existing
specifications.

Currently, I'm aware of three types of fragmentation/reassembly that are of
interest for RIOT:

1. 6Lo fragmentation [2] for local/personal-area-based link-layers that
don't support fragmentation themselves and which adoption is handled by the
6lo working group [3] (AFAIK this only includes IEEE 802.15.4 and PLC
[which is currently in draft stage [4]). This also includes ICNLoWPAN [5].
Fragmentation is handled hop-by-hop, but there are also solutions put
forward [6] [7], to allow fragment forwarding. Fragments are distinguished
between 1st fragments and subsequent fragments, and are identified for
reassembly by tuple of link-layer source address, link-layer destination
address, datagram size, and a sequential datagram tag (created by the
source node). For mesh-under mode, the soruce and destination address are
replaced with the originator's and and final destination's address from the
mesh header. In case of 6Lo fragmentation, the first header always needs to
include all compressed headers (ICNLoWPAN does not have this restriction)
and the overall datagram size denotes the size *before* compression*.
Fragments might be received out of order.
2. IPv6 fragmentation [8] for IPv6 packets that are larger than the path
MTU. Fragmentation is handled end-to-end, so the fragments are identified
by a tuple of IPv6 source address, IPv6 destination address and a Fragment
identifier, which generation is up to the source and for which some example
algorithms are provided in [9]. Notable fragment types first fragment,
subsequent fragment and last fragment. All IPv6 extension headers and the
upper layer header need to fit into the first fragment. Fragments might be
received out of order.
3. Lastly there is SCHC F/R [10] for wide-area-based link-layer that don't
support fragmentation themselves and which adoption is handled by the lpwan
working group [11] (like e.g. LoRAWAN or SigFox). It assumed fragments are
not delivered out of order and provides several reliability modes. Due to
latter there are several types of fragments (which I'm not quite sure yet
how they interact with each other, but maybe some people more knowledgeable
in LPWAN can interject here). Fragments are identified by a tuple of the
link-layer source address (if present), the link-layer destination address
(if present), the Rule ID (which describes the type of fragment header
format) and a sequential datagram tag (if present). Again lpwan people,
please fill in the holes, I might have left.

As can be seen, there are some similarities, which is why I think a common
library could be useful to avoid code duplication and reduce overall
codesize, but there are also several differences that need to be dealt with.

Kind Regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/issues/9286
[2]  
https://tools.ietf.org/html/rfc4944#section-5.3
[3] https://datatracker.ietf.org/wg/6lo/documents/
[4] https://datatracker.ietf.org/doc/draft-hou-6lo-plc/
[5] https://datatracker.ietf.org/doc/draft-gundogan-icnrg-ccnlowpan/
[6]
https://datatracker.ietf.org/doc/draft-bormann-lwig-6lowpan-virtual-reassembly/
[7] https://datatracker.ietf.org/doc/draft-watteyne-6lo-minimal-fragment/
[8] https://tools.ietf.org/html/rfc8200#section-4.5
[9] https://tools.ietf.org/html/rfc7739#section-5
[10]
https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-13#section-7
[11] https://datatracker.ietf.org/wg/lpwan/documents/
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Canceled event: Hack'n'ACK @ Tue Dec 25, 2018 5pm - 10pm (CET) (RIOT Events)

2018-05-29 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20181225T17
DTEND;TZID=Europe/Berlin:20181225T22
DTSTAMP:20180529T144945Z
UID:lbk4mfucqdomcf7c8o9cg4cmsg_r20160329t150...@google.com
RECURRENCE-ID;TZID=Europe/Berlin:20181225T17
CREATED:20150319T120715Z
DESCRIPTION:
LAST-MODIFIED:20180529T144945Z
LOCATION:FU Berlin\; HAW Hamburg
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:Hack'n'ACK
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Canceled event: Monthly RIOT developer meeting @ Mon Dec 31, 2018 5pm - 6pm (CET) (RIOT Events)

2018-05-29 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20181231T17
DTEND;TZID=Europe/Berlin:20181231T18
DTSTAMP:20180529T144940Z
UID:6qi0htkdij3t9d7n8hkufug...@google.com
RECURRENCE-ID;TZID=Europe/Berlin:20181231T17
CREATED:20171110T142417Z
DESCRIPTION:
LAST-MODIFIED:20180529T144940Z
LOCATION:Online
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:Monthly RIOT developer meeting
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Updated invitation: Monthly RIOT developer meeting @ Mon Sep 23, 2019 5pm - 6pm (CEST) (RIOT Events)

2018-05-29 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20190923T17
DTEND;TZID=Europe/Berlin:20190923T18
DTSTAMP:20180529T144921Z
UID:6qi0htkdij3t9d7n8hkufug...@google.com
RECURRENCE-ID;TZID=Europe/Berlin:20190930T17
CREATED:20171110T142417Z
DESCRIPTION:-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the descriptio
 n.\n\nView your event at https://www.google.com/calendar/event?action=VIEW;
 eid=NnFpMGh0a2RpajN0OWQ3bjhoa3VmdWdiMTFfMjAxOTA5MzBUMTUwMDAwWiBrM3FsOHNldHY
 3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20180529T144921Z
LOCATION:Online
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Monthly RIOT developer meeting
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] TCP on RIOT OS

2018-05-22 Thread Martine Lenders
Hi Theresa,

were you using link local addresses (i.e. are they prefixed `fe80::/64`)
for your trials? If yes, newer versions require to also provide an
interface with that (as it is the case e.g. also on Linux) so this might be
your problem. The client and server needs to be fixed then of course to
have the interface provided or warn the user that it is missing..

Best regards,
Martine

2018-05-22 9:37 GMT+02:00 "Theresa Müller" :

> Hi everyone,
>
> I am currently trying to use TCP on RIOT, but I'm having problems with it,
> since the "gnrc_tcp_server" and "gnrc_tcp_client" tests are not working on
> the latest version of RIOT. I tried to run these tests on the 2017.01
> release where they were added the first time and everything works fine
> here, but when I run them on the 2018.01 or 2018.04 release, wireshark
> doesn't show any TCP pakets and the client always receives a timeout after
> a while, so somehow the client and the server aren't able to establish a
> connection. Maybe one of you knows what caused this change in behaviour and
> how this could be fixed.
>
> Thanks a lot for your help!
>
> Best regards,
> Theresa
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] PIC programmer with Linux support?

2018-05-22 Thread Martine Lenders
Hi,

if its still needed and if it helps: I have a PICkit3 (my property) at my
office that I don't really need and am willing to donate to the cause. I
needed it years ago for a private project that I gave away (and was able to
confirm that it is still running after all those years during my vacation
^^) and I'm not really involved into MIPS development, so I really don't
need it.

Cheers,
Martine

2018-05-18 15:28 GMT+02:00 Francisco Acosta :

> Hi Joakim!
>
> On 18 May 2018 at 10:44:29, Joakim Nohlgård (joakim.nohlg...@eistec.se)
> wrote:
> > Is this for pic32 HIL tests?
> > Do the pic32 boards support jtag like the cortex boards? In that case you
> > could maybe use one of the ftdi ft2232 based jtag programmers out there.
> >
>
> Unfortunately that’s not the case. They have a kind of serial programming
> interface
> which is not super standard. However there are several tools out there
> which might
> be useful here.
>
> I’m thinking about pickit2 clones and compatible firmware which might be
> the
> solution in this case.
>
> I’ll let you know whenever I have a more concrete solution.
>
> Cheers,
>
> Paco.
>
>
> > /Joakim
> >
> > On Fri, May 18, 2018, 10:30 Kaspar Schleiser wrote:
> >
> > > Hey fellow RIOTers,
> > >
> > > I'm looking for a readily available PIC programmer with Linux support.
> > >
> > > Main requirements are:
> > >
> > >
> > > - can flash the boards that RIOT supports
> > > - has a CLI application that runs on Linux (both x86 and ARM/RasPi)
> > > (- not too expensive)
> > >
> > > Any suggestions?
> > >
> > > Kaspar
> > > ___
> > > devel mailing list
> > > devel@riot-os.org
> > > https://lists.riot-os.org/mailman/listinfo/devel
> > >
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
> >
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Porting RIOT to ESP8266

2018-04-07 Thread Martine Lenders
(or, since I just saw that you provide ports for several board variations,
several PRs)

2018-04-07 14:49 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:

> Hi Gunar,
>
> Cool, do you think you can get it in a state where you can provide a PR?
>
> Cheers,
> Martine
>
> 2018-04-07 14:00 GMT+02:00 Gunar Schorcht <gu...@schorcht.net>:
>
>> Hello,
>>
>> I just want to inform that I have commited a first working version of
>> the RIOT port to ESP8266 to my fork at
>>
>> g...@github.com:gschorcht/RIOT-Xtensa-ESP8266.git
>>
>> Regards
>> Gunar
>>
>> --
>> Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
>> kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
>>
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Porting RIOT to ESP8266

2018-04-07 Thread Martine Lenders
Hi Gunar,

Cool, do you think you can get it in a state where you can provide a PR?

Cheers,
Martine

2018-04-07 14:00 GMT+02:00 Gunar Schorcht :

> Hello,
>
> I just want to inform that I have commited a first working version of
> the RIOT port to ESP8266 to my fork at
>
> g...@github.com:gschorcht/RIOT-Xtensa-ESP8266.git
>
> Regards
> Gunar
>
> --
> Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
> kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Notification: Hack'n'ACK @ Tue Mar 27, 2018 5pm - 10pm (CEST) (RIOT Events)

2018-03-27 Thread Martine Lenders
Hi,

we are all set-up now in Berlin. As always ou can join the Hack'n'ACK
virtually via Jitsi [1].

Happy hacking,
Martine

[1] https://jitsi.tools.ietf.org/riot-hacknack

2018-03-26 17:00 GMT+02:00 Google Calendar <calendar-notificat...@google.com
>:

> more details »
> <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxODAzMjdUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=1>
> Hack'n'ACK
>
> *When*
> Tue Mar 27, 2018 5pm – 10pm Berlin
>
> *Where*
> FU Berlin; HAW Hamburg (map
> <https://maps.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>)
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> 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.
>
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] RIOT integration options for Whitefield

2018-03-21 Thread Martine Lenders
Hi Rahul,

(context for the rest of the list: we talked f2f today about this after
lwig @ IETF101)

I agree with Ludwig that option 2 is the best option to implement this. If
you looking for a template to implement against netdev, have a look at
`socket_zep` [1] (and ignore what I proposed at our F2F meeting ;-)). I
think this can give you a good idea, since it is also an emulated network
device, based on IEEE 802.15.4 (though it is lacking some features like
channel selection and other radio related options).

Cheers,
Martine

[1]
https://github.com/RIOT-OS/RIOT/blob/master/cpu/native/socket_zep/socket_zep.c

2017-07-31 20:25 GMT+01:00 Rahul Jadhav :

> Hi Ludwig,
>
> Communication  between whitefield and riot would be using sysv msgq
> IPC.(Having said that, this layer is loosely coupled and may change in
> future, if required). Note that these IPC calls are wrapped in a library
> provided by whitefield.
>
> So if I have to picture it, I would add a driver for whitefield in riot
> which would essentially be of 802154_type. Would override the recv/send
> callback in this driver to send /recv the packet over to whitefield. I
> assume I can override USEMODULES in the specific example app to use this
> driver and automatically 6lo would come into effect(because driver is of
> type 802154_type) and I will get 6lo adapted packets in the send callback
> of this driver.
>
> Just to add more details here about how whitefield operates: whitefield
> creates a virtual node (which essentially is an instantiation of node in
>  ns3 which provides for realistic RF) for every riot node which runs in
> its own individual linux process space. Whenever riot calls a send in the
> 802154_type driver, the packet would be passed on to the virtual node in
> whitefield. The packet would then be received by one or more of other
> virtual nodes. The packet will be sent on the IPC Interface and passed on
> to the appropriate riot node(s) process(es) calling the corresponding
> 802154_type driver's recv call, thus completing the packet lifecycle.
>
>  The main page of whitefield github repo (https://github.com/
> whitefield-framework/whitefield) has a block diagram which would give a
> clear picture.
>
> Also, Writing a driver would give finer control which would help in
> providing advanced OAM commands.
>
> Regards,
> Rahul
>
> On 31-Jul-2017, at 10:59 PM, Ludwig Knüpfer 
> wrote:
>
> Hi Rahul,
>
> Regarding implementation proposal 2:
> As I don't know anything about Whitefield: what would that implementation
> look like in detail? In particular: how would RIOT communicate with
> Whitefield? (Unix) socket/thread messages/other IPC?
>
> Cheers,
> Ludwig
>
> Am 30. Juli 2017 17:13:51 MESZ schrieb Rahul Jadhav  >:
>
> Hello team RIOT,
>
>
> I m trying to integrate RIOT with a simulation framework called as
>
> Whitefield (which i m developing for interop testing) ... For details:
>
> https://github.com/whitefield-framework/whitefield
>
>
> I ll use RIOT in native mode. Whitefield will provide for 802.15.4
>
> phy/mac
>
> and RIOT will provide for 6lo/ipv6/udp/blah.
>
>
> As far as possible i wanted to check integration options which do not
>
> involve changing RIOT.
>
>
> For integration i ve thought of foll options:
>
> 1. using tapX interface (but without tapbrX intf) ... i.e. RIOT will
>
> send
>
> packets on tap and whitefield will sniff in promiscous mode on tap and
>
> then
>
> redirect the packets to the whitefield RF layer ... similarly sending
>
> pkts
>
> to the RIOT node by using raw sockets and then injecting on tap
>
> interface.
>
> **The problem here is that with netdev_tap, 6lo adaptation is not
>
> included** ... I saw an option to use gnrc_zep + gnrc_nomac which could
>
> ve
>
> enabled 6lo for tap (
>
> https://github.com/RIOT-OS/RIOT/wiki/Testing-6LoWPAN-on-
> Ethernet-based-devices)
>
> but seems these two modules are no more part of RIOT.
>
>
> 2. writing a driver for whitefield in RIOT ... This would be a
>
> clean/easy
>
> solution (and this is what i did for contiki integration) ...  But this
>
> would mean changes to RIOT, and i m not sure if RIOT team would be
>
> interested in such PR.
>
>
> 3. Another option is to use fakelb, which simulates a 802.15.4 phy intf
>
> on
>
> linux. Thus i assume RIOT 6lo will work on this phy device. Then i go
>
> about
>
> the same way with integration, the way i planned for tap interface as
>
> in 1.
>
> Problem here is, fakelb is not available by default, thus there are
>
> clumsy
>
> (kernel module compilation) setup steps and i m still not sure if this
>
> is
>
> the right way to go.
>
>
> Wanted to seek advise from RIOT team regarding which option to use.
>
>
> Thanks,
>
> Rahul
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
> ___
> devel mailing list
> 

Re: [riot-devel] hwrnd how to implement

2018-03-05 Thread Martine Lenders
Hi,

the `random` should IMHO also stay strictly an API for *pseudo* random
number generators, I agree however with Michel's issue, that hwnrg should
be used for seed generation if available.

Cheers,
Martine

2018-03-05 17:08 GMT+01:00 Michel Rottleuthner <
michel.rottleuth...@haw-hamburg.de>:

> Hi Josua,
>
> IMO: cpu/periph is right if its part of the SOC (as you already said,
> there should be no dependency to the at86rf2xx driver -if possible- ).
>
> Regarding your other question: I think the answer is no, at the moment its
> not guaranteed that calls to random32 are directed to hwrng, see [1].
>
>
> regards,
>
> Michel
>
> [1]: https://github.com/RIOT-OS/RIOT/issues/8663
>
> On 03/05/2018 04:31 PM, Arndt, Josua wrote:
>
> Thanks Martine,
>
>
>
> But as the atmegarfr2 is a soc this is the hwrng for this device.
>
>
>
> So what would be the best place to put it if not as cpu/periph in this
> special case?
>
>
>
> I would then implement it as CPU feature and remove the depency to the
> at86rf2xx driver.
>
>
>
> Still the remaining question is it made sure that random32 calls or any
> calls to random are directed to hwrng_read
>
> Is this already done by just enabling the module when building with
> FEATURES_REQUIRED = periph_hwrng ?
>
>
>
>
>
> *Von:* devel <devel-boun...@riot-os.org> <devel-boun...@riot-os.org> *Im
> Auftrag von *Martine Lenders
> *Gesendet:* Montag, 5. März 2018 15:47
> *An:* RIOT OS kernel developers <devel@riot-os.org> <devel@riot-os.org>
> *Betreff:* Re: [riot-devel] hwrnd how to implement
>
>
>
> Hi Josua,
>
>
>
> when the RNG component of the at86rf2xx driver was provided in [1] we
> decided to not implement the `periph/hwnrg` with it.
>
> Main reasons are that it is
>
>
>
> 1. Not a `periph` (i.e. a CPU feature)
>
> 2. Hard to integrate when e.g. the CPU already provides a `hwnrg`.
>
>
>
> Hope this helps,
>
> Martine
>
>
>
> [1] https://github.com/RIOT-OS/RIOT/pull/4989
>
>
>
> 2018-03-05 15:04 GMT+01:00 Arndt, Josua <jar...@ias.rwth-aachen.de>:
>
> Hello all,
>
>
>
> While implementing the at86rfr2 transceiver for the jiminy board I thought
> of also implement the hwrng.
>
>
>
> What I did is implementing in cpu/atmega256rfr2/periph/hwnrg.c
>
> hwrng_init
>
> hwrng_read
>
>
>
> Added feature and module to makefiles.
>
>
>
> Now I have some questions:
>
>1. How do I best include the depency to 
> $(RIOTBASE)/drivers/at86rf2xx/include/at86rf2xx_internal.h,
>of hwrng.c in cpu folder?
>2. How is it ensured that hardware random is used in all cases? And
>all other are not linked?
>3. Where to find howto, concept description, implementation guide?
>
>
>
> Best Regards
>
> Josua
>
> [image: rwth_ias_bild_rgb_logo]
>
> *Josua Arndt, M.Sc.*
> *RWTH Aachen Univers**ity*
>
> *Integrated Analog Circuits and RF Systems*
>
> Kopernikusstraße 16, ICT Cube North, Room 209, D-52074 Aachen
>
> Email: josua.ar...@ias.rwth-aachen.de
> Phone: +49 241 / 80 - 27750 <+49%20241%208027750>
>
>
>
>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] hwrnd how to implement

2018-03-05 Thread Martine Lenders
Hi Josua,

when the RNG component of the at86rf2xx driver was provided in [1] we
decided to not implement the `periph/hwnrg` with it.
Main reasons are that it is

1. Not a `periph` (i.e. a CPU feature)
2. Hard to integrate when e.g. the CPU already provides a `hwnrg`.

Hope this helps,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/4989

2018-03-05 15:04 GMT+01:00 Arndt, Josua :

> Hello all,
>
>
>
> While implementing the at86rfr2 transceiver for the jiminy board I thought
> of also implement the hwrng.
>
>
>
> What I did is implementing in cpu/atmega256rfr2/periph/hwnrg.c
>
> hwrng_init
>
> hwrng_read
>
>
>
> Added feature and module to makefiles.
>
>
>
> Now I have some questions:
>
>1. How do I best include the depency to 
> $(RIOTBASE)/drivers/at86rf2xx/include/at86rf2xx_internal.h,
>of hwrng.c in cpu folder?
>2. How is it ensured that hardware random is used in all cases? And
>all other are not linked?
>3. Where to find howto, concept description, implementation guide?
>
>
>
> Best Regards
>
> Josua
>
> [image: rwth_ias_bild_rgb_logo]
>
> *Josua Arndt, M.Sc.*
> *RWTH Aachen Univers**ity*
>
> *Integrated Analog Circuits and RF Systems*
>
> Kopernikusstraße 16, ICT Cube North, Room 209, D-52074 Aachen
>
> Email: josua.ar...@ias.rwth-aachen.de
> Phone: +49 241 / 80 - 27750 <+49%20241%208027750>
>
>
>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Notification: Hack'n'ACK @ Tue Feb 27, 2018 5pm - 10pm (CET) (RIOT Events)

2018-02-27 Thread Martine Lenders
Hi,

with some delay we are now online at the usual (new) location:

https://jitsi.tools.ietf.org/riot-hacknack

Cheers,
Martine

2018-02-26 16:59 GMT+01:00 Google Calendar <calendar-notificat...@google.com
>:

> more details »
> <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxODAyMjdUMTYwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn>
> Hack'n'ACK
>
> *When*
> Tue Feb 27, 2018 5pm – 10pm Berlin
>
> *Where*
> FU Berlin; HAW Hamburg (map
> <https://maps.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>)
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> 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.
>
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Timers

2018-02-27 Thread Martine Lenders
Hi,

There might also be some kind of `offset` setter for the `now()` return
value required, when considering that this new timer API should also be
backended by RTC and/or RTT. This can come in handy to set the system time
with time synchronization protocols like (S)NTP.

Cheers,
Martine

2018-01-24 23:37 GMT+01:00 Kaspar Schleiser :

> Hi all,
>
> I guess it is time to coordinate improving RIOT's timers - again.
>
> IMO xtimer is a dead end. It was designed with good intentions, but
> unfortunately with not much real-world experience. It has also
> (d)evolved into a complex and inflexible #ifdef-mess...
>
> Here's what I think is bad about it:
>
> - it allows only one type of base timer. On most platforms it tries to
> use one 1MHz periph/timer. there are PR's and hacks to make it use e.g.,
> 32KHz RTTs or low power timers, but they didn't make it to master. The
> API basically enforces 1us ticks, and mapping unchanged code bases to
> very different timers is just too error prone. Also, the API would
> require choosing at compile time, which is just too inflexible.
>
> - xtimer still doesn't support pm
>
> - by forcing 1us time, xtimer also requires 64bit time functions in
> order to support > 2**32us (~71min) timeouts
>
> - xtimer is not ISR safe (xtimer_now() with <16bit base timers can break)
>
> - xtimer_t is quite large (20b on 32bit platforms)
>
> - xtimer's code has become very complex due to us/tick conversion and
> the many #ifdefs that grew into it
>
> Here's what I propose:
>
> - re-write from scratch
>
> - in the API, allow "instances", e.g.:
>
> timer_now(instance);
> timer_set(instance, timer_object);
>
> where an "instance" provides state and function pointers.
>
> - implement backends for periph/timer, rtt, rtc, lptim, systick, whatever
>
> - provide global instance aliases that every board provides, e.g.,
> "TIMER_USEC", "TIMER_MSEC", "TIMER_SEC". Map those to available timer
> backends. Make it possible to enable / disable them as needed.
>
> - allow application specific timers to use the same API (e.g., allow
> setting up a very high speed timer, which can be used alongside
> "default" timers)
>
> - provide stackable "converters"
>   e.g., if there's no MSEC resolution low power timer that can be mapped
> to "TIMER_MSEC", use "TIMER_USEC", but transparently convert all values
>   or if periph/timer doesn't support 32bit, create a "timer instance"
> that transparently handles the extension.
>   Maybe stack those (e.g., if the rtt backend only supports 1024hz and
> 16bit, stack a 1024 to 1000 converter on that, stack a 16bit to 32bit on
> that and map the result to "TIMER_MSEC".
>  this would lead to re-usable components that can also be individually
> tested (think unittests using a software-controlled fake timer).
>
> - provide either clear convention (e.g., TIMER_USEC stops when sleeping,
> unless a timer using it is set, TIMER_MSEC keeps running in low power
> mode) or controlling API (e.g., "timer_block_sleep(TIMER_USEC)" for
> behaviour in sleep modes
>
> - try to slim down the timer struct (if possible)
>
> - drop the 64bit API (usec resolution over 64bit range is unrealistic on
> real hardware. if, for larger ranges, TIMER_MSEC or TIMER_SEC can be
> used, the range that 64bit provides is not needed anymore. thus all the
> expensive 64bit arithmetic can be dropped)
>
> - consider new insights like the clock domain issue fixed by [1]
>
> - obviously, avoid long-standing xtimer bugs like the ISR unsafeness
>
> The main point I would like to push is the introduction of "timer
> instances", which would basically make the timer interface object
> oriented. This would allow having multiple implementations with
> different tradeoffs without changing actual application code.
>
> What do you think?
>
> Kaspar
>
> [1] https://github.com/RIOT-OS/RIOT/pull/7053
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Updated invitation: Monthly RIOT developer meeting @ Mon Mar 26, 2018 4pm - 5pm (CEST) (RIOT Events)

2018-02-26 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20180326T16
DTEND;TZID=Europe/Berlin:20180326T17
DTSTAMP:20180226T122531Z
UID:6qi0htkdij3t9d7n8hkufug...@google.com
RECURRENCE-ID;TZID=Europe/Berlin:20180326T17
CREATED:20171110T142417Z
DESCRIPTION:-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the descriptio
 n.\n\nView your event at https://www.google.com/calendar/event?action=VIEW;
 eid=NnFpMGh0a2RpajN0OWQ3bjhoa3VmdWdiMTFfMjAxODAzMjZUMTUwMDAwWiBrM3FsOHNldHY
 3bDQ4b2Zub2wwdGZ1dTZ0c0Bn.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20180226T122531Z
LOCATION:Online
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Monthly RIOT developer meeting
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Notification: Monthly RIOT developer meeting @ Mon Feb 26, 2018 5pm - 6pm (CET) (RIOT Events)

2018-02-26 Thread Martine Lenders
Hi,

when are we finally moving up the meeting to 16:00 CET? I'll need to leave
again at 17:30.

Best,
Martine

2018-02-25 20:08 GMT+01:00 Francisco Acosta <francisco.aco...@inria.fr>:

> Hi devs!
>
> Just a gentle reminder for our next developers meeting which will take
> place this Monday February 26th at 17:00 CET.
>
> Proposed agenda:
>
> - Next release goals
> - Testing the RIOT
>
> As always, you're invited to propose topics you'd like to discuss. I'll
> open a pad asap for the meeting notes and to list the topics.
>
> Thanks in advance for you attendance!
>
> Best,
>
> Francisco.
>
>
>
> On 25 February 2018 16:59:58 CET, Google Calendar <
> calendar-notificat...@google.com> wrote:
> >This is a notification for:
> >
> >Title: Monthly RIOT developer meeting
> >When: Mon Feb 26, 2018 5pm – 6pm Berlin
> >Where: Online
> >Calendar: RIOT Events
> >Who:
> > * Martine Lenders - creator
> >
> >Event details:
> >https://www.google.com/calendar/event?action=VIEW=
> NnFpMGh0a2RpajN0OWQ3bjhoa3VmdWdiMTFfMjAxODAyMjZUMTYwMDAwWiBr
> M3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn
> >
> >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.
> >
> >Forwarding this invitation could allow any recipient to modify your
> >RSVP
> >response. Learn more at
> >https://support.google.com/calendar/answer/37135#forwarding
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Ceedling

2018-01-10 Thread Martine Lenders
Hi Francisco,

as far as I know Cenk looked into that a few months back. I don't know
however what came out of that?

Cheers,
Martine

2018-01-10 21:10 GMT+01:00 Francisco Molina :

> Following up with Baptiste question. Has anyone integrated other testing
> tools into RIOT like Unity?. And how easily (or not) could this integration
> be achieved, how much tinkering with the actual build system would have to
> be done for this? Cheers!
>
> Francisco
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Pull request

2017-12-18 Thread Martine Lenders
Hi JP,

First of all, welcome to the RIOT community and thank you for your
contribution!

There are two steps to our CI at the moment. The first one is Travis, which
provides you with some preliminary static check regarding our coding
conventions, documentation and also some static code analysis. When someone
was able to review your PR they will task our build bot Murdock, the second
step, to try to build your PR for most known build configurations.

For now, I suggest that you review the results of Travis to make sure the
PR is ready for review. Here are the most important ones to fix right
now  (links are from the latest build of your PR as of writing this PR, you
can view the most current version by clicking on "Details" next to the
Travis build result at the bottom of the PR):

* Commit messages (
https://travis-ci.org/RIOT-OS/RIOT/builds/318473955#L705-L709): we are
loosely enforcing the 50/72 rule [1]. In our case this means: a commit
message should at most contain 50 characters, in special cases it may be
longer, but never longer than 72 characters. It is also preferable to
prefix the commit message with the module you manipulate / add
* Whitespaces (
https://travis-ci.org/RIOT-OS/RIOT/builds/318473955#L711-L1008): The only
whitespace a line should and with is `\n`. If you are on Windows and *have
your Git configured as such* it is also possible to have `\r\n`, Git will
than automatically strip the `\r`. Also use 4 spaces for indendentation and
don't mix spaces and tabs
* License (https://travis-ci.org/RIOT-OS/RIOT/builds/318473955#L1011-L1030):
The code you provided seems to be Apache 2 license. Please make sure it is
compatible to our LGPLv2.1 and update our license pattern list [2]
accordingly, if so (or ask for help in the PR).
* C++ compatible headers (
https://travis-ci.org/RIOT-OS/RIOT/builds/318473955#L1033-L1049): RIOT has
C++ support, thus it's headers need to be C++-compatible. Have a look [3]
[4] at existing headers how to achieve this.
* cppcheck's static code analysis (
https://travis-ci.org/RIOT-OS/RIOT/builds/318473955#L1051-L1055): Always
useful to review what it says. If it's a false positive suppress the
warning. Ask in the PR how to do that, if that's the case.
* The PR check (
https://travis-ci.org/RIOT-OS/RIOT/builds/318473955#L1057-L1077) you can
ignore for now. After the review is done, the reviewer will ask you to
squash your commits down to a sensible number.
* Header guards (
https://travis-ci.org/RIOT-OS/RIOT/builds/318473955#L1080-L1097): Header
guards should be the path of the header file, starting after the "include",
but all upper-case. E.g. boards/hifive1/include/sifive/hifive1.h would have
the header guard `SIFIVE_HIFIVE1_H`.

In general, have a look at our coding conventions [5]. Most of what I
paraphrased here is described there in more detail.

Cheers,
Martine

[1] https://gist.github.com/vecano/8494051#committing
[2] https://github.com/RIOT-OS/RIOT/tree/master/dist/tools/licenses/patterns
[3]
https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/include/periph_conf.h#L30-L32
[4]
https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/include/periph_conf.h#L281-L283
[5] https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions

2017-12-18 20:47 GMT+01:00 JP <
jpbonn-keyword-riotos.ae0...@corniceresearch.com>:

> I just created a pull request for merging support for the SiFive HiFive1
> board.  I've never used the pull request mechanism before so hopefully
> nothing is too buggered.  What need to be done for the CI integration?
> Those checks are failing.
>
> JP
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] RIOT Code of Conduct

2017-12-08 Thread Martine Lenders
Hi all,

with the Code of Conduct now merged, it is in effect now effective
immediately. Keep being awesome to each other!

Kind regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/8116

2017-11-24 15:30 GMT+01:00 Martine Lenders <mlend...@riot-os.org>:

> Hi *,
>
> as some of you might have noticed, I proposed an initial version of a Code
> of Conduct for the RIOT community [1]. I invite you to discuss this with
> us, as this effects the whole community.
>
> Kind Regards,
> Martine Lenders
>
> [1] https://github.com/RIOT-OS/RIOT/pull/8116
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] 6lowpan Host with SLAAC, minimum ram

2017-12-04 Thread Martine Lenders
A... after five seconds of thinking I think I know what you mean: You
can't pick-and-choose shell commands. Yes this would be nice (and I was
thinking about something similar). Let me open an issue were we can discuss
further on that.

Cheers,
Martine

2017-12-04 15:31 GMT+01:00 Martine Lenders <m...@martine-lenders.eu>:

> Hi,
>
>
>
> 2017-12-04 15:14 GMT+01:00 Arndt, Josua <jar...@ias.rwth-aachen.de>:
>
>> Yes it is but then all shells are disabled, not only that which I don’t
>> need.
>>
>
> The shell should still be enabled. Just the commands pulled in by the
> modules should be disabled.
>
> Cheers,
> Martine
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] 6lowpan Host with SLAAC, minimum ram

2017-12-04 Thread Martine Lenders
Hi,



2017-12-04 15:14 GMT+01:00 Arndt, Josua :

> Yes it is but then all shells are disabled, not only that which I don’t
> need.
>

The shell should still be enabled. Just the commands pulled in by the
modules should be disabled.

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


Re: [riot-devel] 6lowpan Host with SLAAC, minimum ram

2017-12-04 Thread Martine Lenders
Hi,

This sounds awesome!

2017-12-04 15:05 GMT+01:00 Arndt, Josua :
> If there is demand for separately enabled shells I could do a PR, but
this needs to be also well  documented and I’m not quite sure which is the
best way.

Maybe I've missed something, but this is already possible by just
deactivating the `shell_commands` module.

Cheers,
Martine

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


[riot-devel] Test

2017-11-30 Thread Martine Lenders
Dan Petry was reporting, that none of his mails got through to devel, so
this is a test if there is a problem with this mailing list.

Please ignore this message, if it comes through ;-)

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


Re: [riot-devel] Notification: Hack'n'ACK @ Tue Nov 28, 2017 5pm - 10pm (RIOT Events)

2017-11-28 Thread Martine Lenders
Hi,
we are now set-up in Berlin for this month's Hack'n'ACK. If you like to
join via PlaceCam [1] feel free to do so at

*http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-
<http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc->*

RIOTers with access to the PlaceCam account: remember to remove your
PlaceCam config (located at `.local/share/daviko GmbH/PlaceCam/PlaceCam.ini`
on Linux) before starting PlaceCam, if you are logged in, so we can have an
uninterrupted conference call.

Cheers,
Martine

[1] 
*https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation#videoconferencing
<https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation#videoconferencing>*

2017-11-27 16:59 GMT+01:00 Google Calendar <calendar-notificat...@google.com
>:

> more details »
> <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNzExMjhUMTYwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn>
> Hack'n'ACK
>
> *When*
> Tue Nov 28, 2017 5pm – 10pm Berlin
>
> *Where*
> FU Berlin; HAW Hamburg (map
> <https://maps.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>)
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> 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.
>
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Plans for switching over to a new network infrastructure in GNRC

2017-11-28 Thread Martine Lenders
Hi,

yep, there is still some major optimization work required. But the feature
set provided in #7925 is a little bit larger than the previous NDP
implementation was (namely: the UNREACHABLE state as proposed in RFC 7048
is now fully working) + many places that made the old implementation
smaller, were just plain wrong assumptions that were major quality defects
in the old implementation. What is weird though is, that the 6LN
configuration got so much bigger... I would have expected it to be way
smaller :-/. (Also MSP430 [not listed] is unexpectedly large, but I blame
that on the old GCC doing some bad optimization work).

Cheers,
Martine

2017-11-28 15:21 GMT+01:00 Koen Zandberg <k...@bergzand.net>:

> Hi,
>
> As #7925 was merged yesterday, there is now a nightly build with the
> gnrc_netif code merged. From this I present you the build size differences
> <https://riot-graphs.snt.utwente.nl/dashboard/db/full-grid-diff-boards-vertical?orgId=1=1511743027554=1511869511369=examples%2Fdefault=examples%2Fgcoap=examples%2Fgnrc_border_router=examples%2Fgnrc_minimal=examples%2Fgnrc_networking=tests%2Fgnrc_udp=arduino-mega2560=cc2538dk=native=nucleo-f401=pic32-wifire=samr21-xpro=text>
> between today (with gnrc_netif) and yesterday (before the merge). Absolute
> numbers on a single application on a single board can be found by pressing
> the relevant diff. Selection of the tests, boards and metric (bss, data and
> text) is at the top of the page.
>
> Some remarks: These are the diffs between the previous and the current
> build size, not absolute numbers. Furthermore, this is a comparison between
> nightlies, not from merge to merge, so all merges from yesterday are
> included in this diff.
>
> Cheers,
> Koen
>
> On 11/01/2017 04:26 PM, Martine Lenders wrote:
>
> Hi,
>
> FYI there is a re-integration PR now: https://github.com/RIOT-
> OS/RIOT/pull/7925
>
> Cheers,
> Martine
>
> 2017-10-27 17:56 GMT+02:00 Martine Lenders <m.lend...@fu-berlin.de>:
>
>> Hi all,
>>
>> after the release is before the release, so let's use the drive to
>> continue the good work.
>>
>> Some of you might have noticed, that we are currently working on a big
>> switch-over for GNRC-internal APIs, so if you are not involved in any
>> direct GNRC programming or need access to the network interfaces this won't
>> most likely only affect you a little bit (the calls how to get an interface
>> ID will change -- actually simplify ;-)) to not at all.
>>
>> This is quite a massive step, since basically most of the files that are
>> doing operations on, or related to network interfaces (i.e. IPv6, 6LoWPAN,
>> MAC and routing protocols) need to be touched. In addition we decided to
>> integrate this network interface layer directly with the new, shiny and
>> fixed neighbor discovery which saves us a lot of integration work into old
>> stuff, but doesn't make things easier. Some of that work is already done
>> and in master, but most of it will take some time to adapt.
>>
>> This is why we (the RIOT maintainers) decided to go a slightly different
>> route than usual: we made a feature branch where all the integration work
>> (and testing) for the new components will happen [1] and made a 1-2 week
>> plan to get this branch re-merged into master as fast as possible. In that
>> time this feature branch exist merging new changes to GNRC into master is
>> highly discouraged to not risk merge conflicts in the
>> gnrc_netif2_integration/master branch. We will notify you again when this
>> embargo is lifted.
>>
>> So what changes after all this is done (I call the new interface API
>> gnrc_netif2 here, but in the final result it will be called just
>> gnrc_netif):
>>
>> * Network interfaces:
>> - Simplification of GNRC's network interface architecture: currently
>> there are 4 APIs (gnrc_netdev, gnrc_netif, gnrc_ipv6_netif, and
>> gnrc_sixlowpan_netif) that represent network interfaces in some kind or
>> form. This makes things complicated if you need e.g. in NDP information
>> that is both device dependent (e.g. link-layer address) and IPv6 dependent
>> (e.g. IPv6 address). This is why gnrc_netif2 merges all these APIs into one
>> single API.
>> - Tighter integration into GNRC's principles: For most device related
>> options interfaces worked like any other GNRC module and used NETAPI, but
>> when it came to other stuff, like IPv6 addresses or 6LoWPAN configuration,
>> other APIs were used. With gnrc_netif2 all options can be set via NETAPI.
>> - Better thread synchronization: apart from the the fact that
>> GNRC-externally the options are now set over NETOPT (i.e. 

Re: [riot-devel] RIOT developers monthly meeting

2017-11-28 Thread Martine Lenders
Hi,

as hinted yesterday, I usually need to go around 5:30pm. So I was wondering
if we can move the meeting to 4pm.

Cheers,
Martine

2017-11-27 16:33 GMT+01:00 Francisco Javier Acosta Padilla <
francisco.aco...@inria.fr>:

>
> RIOT developers monthly meeting
> Scheduled: 27 Nov 2017 17:00 to 18:00
> Location: https://zoom.us/j/235153205
> Invitees: devel@riot-os.org, Francisco Javier Acosta Padilla
> Hi there,
>
> Francisco Acosta is inviting you to a scheduled Zoom meeting.
>
> Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/235153205
>
> Or iPhone one-tap :
> US: +16699006833 <(669)%20900-6833>,,235153205#  or +16465588656
> <(646)%20558-8656>,,235153205#
> Or Telephone:
> Dial(for higher quality, dial a number based on your current location):
> US: +1 669 900 6833 <(669)%20900-6833>  or +1 646 558 8656
> <(646)%20558-8656>
> Meeting ID: 235 153 205
> International numbers available: https://zoom.us/zoomconference?m=
> 3QuTkS0wteDtL_3pyOjFM0KBPZ_220mB
>
>
> --
> Francisco Javier Acosta Padilla
> Research Engineer at INRIA Saclay
> INFINE Team
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Updates to the build system - modules definition

2017-11-24 Thread Martine Lenders
Hi Daniel,

2017-11-24 16:47 GMT+01:00 Daniel Petry :

> […]
>
> 1) Move build information concerning a particular module into that
> module's Makefile
> 2) Make the module makefiles able to be written with purely declarative
> language
> 3) Retain backwards compatibility with the current build system


 I don't think it is possible this way and I don't think that's what Gaëtan
meant. Makefiles demand to be in make's language, so you can't just make up
your own declarative language in them. You could however use some
declaritive language files like json or yaml and generate Makefiles from
them (or let make parse them).

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


Re: [riot-devel] Updates to the build system - modules definition

2017-11-24 Thread Martine Lenders
Hi Gaëtan,

I think most of us are happy about any more structural approach to the
build system, and me personally would prefer if we can stick to GNU
standard tools. So in my opinion: go ahead. Maybe - as discussed offline -
also start drafting some GitHub issues, outlining the drawbacks you found
in more detail.

Kind Regards,
Martine

2017-11-23 15:24 GMT+01:00 Gaëtan Harter :

> Dear RIOT developers,
>
> I would like to introduce some packaging concepts around RIOT.
> To consider modules like well defined distribution packages and not only
> source files added to an application firmware. This would allow software
> architecture/configuration informations to be parseable by external tools
> without reading source code and without an application context.
>
> My need is allowing a graphical interface to describe, configure
> applications with possibly external modules and generate the Makefile.
>
> I want to start a task force on this in two weeks after some preliminary
> discussions on the concepts.
> Current state
>
> Some of these module information is already present but not in a easy to
> get way so it does not fit my need.
>
> To highlight some of the problems:
>
>- it is scattered in different centralized files
>   - Makes it hard to add external modules
>   - Needs different files to get one module metadata
>- some is defined in a Turing complete language
>   - Hard to parse
>   - only available in a compilation context
>- some information/configuration only in source files
>
> Implementation
>
> I am thinking about adding declaratively defined information/metadata on
> modules distributed to each module directory. This could be achieved by
> changing to a new build system with these features already included.
> However, integration into the current build system would be preferred in
> order to be able
> to incrementally integrate, test and document new changes.
> Roadmap
>
>- Initial feedback period of two weeks
>- Define and break down intermediate tasks
>- Iteration cycles on each sub task and integration
>
> Further steps
>
> I would like to gather feedback on the concept here, and find interested
> people to start working on it, for reviewing, advices, giving their
> constraints and implementing if you have time.
>
> I will give a two weeks time limit for the initial review until I start
> working onthis.
>
> Thank you in advance.
> Cheers,
> Gaëtan
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] RIOT Code of Conduct

2017-11-24 Thread Martine Lenders
Hi *,

as some of you might have noticed, I proposed an initial version of a Code
of Conduct for the RIOT community [1]. I invite you to discuss this with
us, as this effects the whole community.

Kind Regards,
Martine Lenders

[1] https://github.com/RIOT-OS/RIOT/pull/8116
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Updated invitation: Monthly RIOT developer meeting @ Monthly from 5pm to 6pm on the last Monday (RIOT Events)

2017-11-10 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20161031T17
DTEND;TZID=Europe/Berlin:20161031T18
RRULE:FREQ=MONTHLY;BYDAY=-1MO
DTSTAMP:20171110T154212Z
UID:6qi0htkdij3t9d7n8hkufug...@google.com
CREATED:20171110T142417Z
DESCRIPTION:-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the descriptio
 n.\n\nView your event at https://www.google.com/calendar/event?action=VIEW;
 eid=NnFpMGh0a2RpajN0OWQ3bjhoa3VmdWdiMTEgazNxbDhzZXR2N2w0OG9mbm9sMHRmdXU2dHN
 AZw.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~::~:~::-
LAST-MODIFIED:20171110T154212Z
LOCATION:Online
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Monthly RIOT developer meeting
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] New event: Monthly RIOT developer meeting @ Monthly from 5pm to 10pm on the last Monday (RIOT Events)

2017-11-10 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20161031T17
DTEND;TZID=Europe/Berlin:20161031T22
RRULE:FREQ=MONTHLY;BYDAY=-1MO
DTSTAMP:20171110T142418Z
UID:6qi0htkdij3t9d7n8hkufug...@google.com
CREATED:20171110T142417Z
DESCRIPTION:-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the descriptio
 n.\n\nView your event at https://www.google.com/calendar/event?action=VIEW;
 eid=NnFpMGh0a2RpajN0OWQ3bjhoa3VmdWdiMTEgazNxbDhzZXR2N2w0OG9mbm9sMHRmdXU2dHN
 AZw.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~::~:~::-
LAST-MODIFIED:20171110T142417Z
LOCATION:Online
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Monthly RIOT developer meeting
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Notification: Hack'n'ACK @ Tue Nov 7, 2017 5pm - 10pm (RIOT Events)

2017-11-07 Thread Martine Lenders
Hi,
we are now set-up in Berlin for this month's Hack'n'ACK. If you like to
join via PlaceCam [1] feel free to do so at

*http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-
<http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc->*

RIOTers with access to the PlaceCam account: remember to remove your
PlaceCam config (located at `.local/share/daviko GmbH/PlaceCam/PlaceCam.ini`
on Linux) before starting PlaceCam, if you are logged in, so we can have an
uninterrupted conference call.

Cheers,
Martine

[1] 
*https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation#videoconferencing
<https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation#videoconferencing>*

2017-11-06 17:00 GMT+01:00 Google Calendar <calendar-notificat...@google.com
>:

> more details »
> <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNzEwMzFUMTYwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn>
> Hack'n'ACK
>
> *When*
> Tue Nov 7, 2017 5pm – 10pm Berlin
>
> *Where*
> FU Berlin; HAW Hamburg (map
> <https://maps.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>)
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> 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.
>
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] RIOT assembly at 34C3

2017-11-04 Thread Martine Lenders
Hi,

I'm going to 34C3 [1] this year. Anyone interested forming a RIOT assembly
[2] there this year?

Cheers,
Martine

[1] https://www.ccc.de/en/updates/2017/34C3-in-leipzig
[2] https://events.ccc.de/2017/11/04/people-34c3/
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] [riot-maintainer] Monthly meetings for organisation purposes

2017-11-04 Thread Martine Lenders
Hi Paco,

I'm in as well.

Cheers,
Martine

2017-11-04 1:03 GMT+01:00 Thomas Eichinger <tho...@riot-os.org>:

> Hi Paco,
>
> Thanks for the initiative!
>
> I will try to tune in.
>
> Without wanting to start a tools discussion, I had very good experiences
> with larger groups using zoom.us.
>
> Best, Thomas
>
> On Nov 3, 2017, at 4:29 PM, Francisco Javier Acosta Padilla <
> francisco.aco...@inria.fr> wrote:
>
> Hi again!
>
> A kind reminder to let us now who’s willing to attend the meeting on
> Monday, November 6th at 17:00 CET (UTC +1).
>
> I don’t have an agenda yet but if we can establish it before it would
> speed up the meeting. So far I propose:
>
> 1. Sort the most urgent bugs-issues by priority
> 2. Assign (more/new) people to the bugs-issues
> 3. Mark the related issues/PRs to be solved as “in progress”
>
> The goal is to have the selected issues solved before the next meeting, if
> it happens before, be free to assign new ones and move them to the “in
> progress” column.
>
> Please don’t hesitate to propose your ideas for the topics of the meeting!
>
> Cheers!
>
> --
> Francisco Javier Acosta Padilla
> Research Engineer at INRIA Saclay
> INFINE Team
>
> On 1 November 2017 at 12:25:51, Martine Lenders (m...@martine-lenders.eu)
> wrote:
>
> Hi Cenk,
>
> 2017-11-01 11:05 GMT+01:00 Cenk Gündoğan <list-r...@cgundogan.de>:
>
>> > > On 17-10-31 18:03:01, Francisco Javier Acosta Padilla wrote:
>> > > […]
>> > > > P.S: @Martine, can you set up the next Hack meeting? Thanks
>> > >
>> >
>> > Anything different to do than the usual ad-hoc placecam set-up?
>> >
>>
>> Jup, provide a working mic for the FU's PlaceCam laptop this time (:
>>
>
> We had... the problem was that the machine we ran placecam on was so slow
> and old that ALSA wasn't able to stream that audio including video ^^
> (that's definitely a problem we need to solve until next week).
>
> Cheers,
> Martine
> ___
> Maintainer mailing list
> maintai...@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/maintainer
>
> ___
> Maintainer mailing list
> maintai...@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/maintainer
>
>
> ___
> Maintainer mailing list
> maintai...@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/maintainer
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Plans for switching over to a new network infrastructure in GNRC

2017-11-01 Thread Martine Lenders
Hi,

FYI there is a re-integration PR now:
https://github.com/RIOT-OS/RIOT/pull/7925

Cheers,
Martine

2017-10-27 17:56 GMT+02:00 Martine Lenders <m.lend...@fu-berlin.de>:

> Hi all,
>
> after the release is before the release, so let's use the drive to
> continue the good work.
>
> Some of you might have noticed, that we are currently working on a big
> switch-over for GNRC-internal APIs, so if you are not involved in any
> direct GNRC programming or need access to the network interfaces this won't
> most likely only affect you a little bit (the calls how to get an interface
> ID will change -- actually simplify ;-)) to not at all.
>
> This is quite a massive step, since basically most of the files that are
> doing operations on, or related to network interfaces (i.e. IPv6, 6LoWPAN,
> MAC and routing protocols) need to be touched. In addition we decided to
> integrate this network interface layer directly with the new, shiny and
> fixed neighbor discovery which saves us a lot of integration work into old
> stuff, but doesn't make things easier. Some of that work is already done
> and in master, but most of it will take some time to adapt.
>
> This is why we (the RIOT maintainers) decided to go a slightly different
> route than usual: we made a feature branch where all the integration work
> (and testing) for the new components will happen [1] and made a 1-2 week
> plan to get this branch re-merged into master as fast as possible. In that
> time this feature branch exist merging new changes to GNRC into master is
> highly discouraged to not risk merge conflicts in the
> gnrc_netif2_integration/master branch. We will notify you again when this
> embargo is lifted.
>
> So what changes after all this is done (I call the new interface API
> gnrc_netif2 here, but in the final result it will be called just
> gnrc_netif):
>
> * Network interfaces:
> - Simplification of GNRC's network interface architecture: currently
> there are 4 APIs (gnrc_netdev, gnrc_netif, gnrc_ipv6_netif, and
> gnrc_sixlowpan_netif) that represent network interfaces in some kind or
> form. This makes things complicated if you need e.g. in NDP information
> that is both device dependent (e.g. link-layer address) and IPv6 dependent
> (e.g. IPv6 address). This is why gnrc_netif2 merges all these APIs into one
> single API.
> - Tighter integration into GNRC's principles: For most device related
> options interfaces worked like any other GNRC module and used NETAPI, but
> when it came to other stuff, like IPv6 addresses or 6LoWPAN configuration,
> other APIs were used. With gnrc_netif2 all options can be set via NETAPI.
> - Better thread synchronization: apart from the the fact that
> GNRC-externally the options are now set over NETOPT (i.e. in the thread
> context of the interface) we also use recursive mutexes GNRC-internally now
> to better synchronize the access to the interface. In the previous
> implementation normal mutexes were used (requiring some dangerous unlocking
> in the middle of an operation) or no mutexes were used at all.
> - Easier to extend: If you want to provide a new MAC protocol to GNRC
> you don't have to copy all the thread-handler stuff anymore. Just implement
> the operations provided in `gnrc_netif2_ops_t` and let gnrc_netif2 do the
> rest ;-).
> * new neighbor discovery:
> - In comparison to the old neighbor discovery the new was designed
> more thoughtfully so it easier to maintain.
> - Most issues with the old neighbor discovery were fixed (because with
> the new design we actually were able to pinpoint issues within minutes, not
> within days as with the old NDP)
> - For the end-user the shell commands will change slightly:
> manipulations of the neighbor cache and FIB now are done using the `nib`
> command instead of a wide variety of commands.
>
> I hope that's all.
>
> If you have further questions, don't be afraid to ask.
>
> Cheers,
> Martine
>
> [1] https://github.com/RIOT-OS/RIOT/tree/gnrc_netif2_integration/master
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] [riot-maintainer] Monthly meetings for organisation purposes

2017-11-01 Thread Martine Lenders
Hi Cenk,

2017-11-01 11:05 GMT+01:00 Cenk Gündoğan :

> > > On 17-10-31 18:03:01, Francisco Javier Acosta Padilla wrote:
> > > […]
> > > > P.S: @Martine, can you set up the next Hack meeting? Thanks
> > >
> >
> > Anything different to do than the usual ad-hoc placecam set-up?
> >
>
> Jup, provide a working mic for the FU's PlaceCam laptop this time (:
>

We had... the problem was that the machine we ran placecam on was so slow
and old that ALSA wasn't able to stream that audio including video ^^
(that's definitely a problem we need to solve until next week).

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


Re: [riot-devel] [riot-maintainer] Monthly meetings for organisation purposes

2017-11-01 Thread Martine Lenders
Hi,

2017-11-01 8:52 GMT+01:00 Cenk Gündoğan :

> On 17-10-31 18:03:01, Francisco Javier Acosta Padilla wrote:
> […]
> > P.S: @Martine, can you set up the next Hack meeting? Thanks
>

Anything different to do than the usual ad-hoc placecam set-up?

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


[riot-devel] Plans for switching over to a new network infrastructure in GNRC

2017-10-27 Thread Martine Lenders
Hi all,

after the release is before the release, so let's use the drive to continue
the good work.

Some of you might have noticed, that we are currently working on a big
switch-over for GNRC-internal APIs, so if you are not involved in any
direct GNRC programming or need access to the network interfaces this won't
most likely only affect you a little bit (the calls how to get an interface
ID will change -- actually simplify ;-)) to not at all.

This is quite a massive step, since basically most of the files that are
doing operations on, or related to network interfaces (i.e. IPv6, 6LoWPAN,
MAC and routing protocols) need to be touched. In addition we decided to
integrate this network interface layer directly with the new, shiny and
fixed neighbor discovery which saves us a lot of integration work into old
stuff, but doesn't make things easier. Some of that work is already done
and in master, but most of it will take some time to adapt.

This is why we (the RIOT maintainers) decided to go a slightly different
route than usual: we made a feature branch where all the integration work
(and testing) for the new components will happen [1] and made a 1-2 week
plan to get this branch re-merged into master as fast as possible. In that
time this feature branch exist merging new changes to GNRC into master is
highly discouraged to not risk merge conflicts in the
gnrc_netif2_integration/master branch. We will notify you again when this
embargo is lifted.

So what changes after all this is done (I call the new interface API
gnrc_netif2 here, but in the final result it will be called just
gnrc_netif):

* Network interfaces:
- Simplification of GNRC's network interface architecture: currently
there are 4 APIs (gnrc_netdev, gnrc_netif, gnrc_ipv6_netif, and
gnrc_sixlowpan_netif) that represent network interfaces in some kind or
form. This makes things complicated if you need e.g. in NDP information
that is both device dependent (e.g. link-layer address) and IPv6 dependent
(e.g. IPv6 address). This is why gnrc_netif2 merges all these APIs into one
single API.
- Tighter integration into GNRC's principles: For most device related
options interfaces worked like any other GNRC module and used NETAPI, but
when it came to other stuff, like IPv6 addresses or 6LoWPAN configuration,
other APIs were used. With gnrc_netif2 all options can be set via NETAPI.
- Better thread synchronization: apart from the the fact that
GNRC-externally the options are now set over NETOPT (i.e. in the thread
context of the interface) we also use recursive mutexes GNRC-internally now
to better synchronize the access to the interface. In the previous
implementation normal mutexes were used (requiring some dangerous unlocking
in the middle of an operation) or no mutexes were used at all.
- Easier to extend: If you want to provide a new MAC protocol to GNRC
you don't have to copy all the thread-handler stuff anymore. Just implement
the operations provided in `gnrc_netif2_ops_t` and let gnrc_netif2 do the
rest ;-).
* new neighbor discovery:
- In comparison to the old neighbor discovery the new was designed more
thoughtfully so it easier to maintain.
- Most issues with the old neighbor discovery were fixed (because with
the new design we actually were able to pinpoint issues within minutes, not
within days as with the old NDP)
- For the end-user the shell commands will change slightly:
manipulations of the neighbor cache and FIB now are done using the `nib`
command instead of a wide variety of commands.

I hope that's all.

If you have further questions, don't be afraid to ask.

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/tree/gnrc_netif2_integration/master
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Updated invitation: Hack'n'ACK @ Tue Nov 7, 2017 5pm - 10pm (RIOT Events)

2017-10-27 Thread Martine Lenders
FYI: Oct 31st is a Holiday in most of Germany, that is why we decided to
move it by one week.

Am 27.10.2017 2:53 nachm. schrieb "Martine Lenders" <authmille...@gmail.com
>:

> *This event has been changed.*
> more details »
> <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNzEwMzFUMTYwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn>
> Hack'n'ACK
>
> *When*
> *Changed: *Tue Nov 7, 2017 5pm – 10pm Berlin
>
> *Where*
> FU Berlin; HAW Hamburg (map
> <https://maps.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>)
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> 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 updated invitations 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.
>
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Release 2017.10

2017-10-27 Thread Martine Lenders
Yay, congratz everyone 

Am 27.10.2017 12:38 nachm. schrieb "Hauke Petersen" <
hauke.peter...@fu-berlin.de>:

> Dear RIOTers,
>
> we are happy to announce the 13th official release of RIOT:
>
> --- * RIOT 2017.10 * ---
>
> This release provides fixes, code cleanup and improved documentation,
> as well as enhancements.
>
> Most notable, this release is bringing RIOT a step closer to supporting
> over-the-air-updates by containing initial support for MCUBoot.
> Furthermore, it adds support for some new platforms (e.g. arduino-mkzero,
> nucleos, and frdm-k22f), drivers (e.g. my9221, apa102, ds1307), and of course
> a large number of bug fixes (e.g. `make buildtest` now working properly,
> various fixes to `xtimer`).
>
> About 230 pull requests with about 442 commits have been merged since
> the last release and about 13 issues have been solved. 45 people
> contributed with code in 56 days. 1395 files have been touched with
> 211720 insertions and 65729 deletions.
>
> You can download the RIOT release from Github by cloning the repository
> [1] or by downloading the tarball [2], and look up the release notes for
> further details [3].
>
> Again, a big thank you to all the people who helped getting this release
> on its way and who constantly work on making RIOT a better OS.
>
> Keep on RIOTing and cheers,
> Hauke
>
> [1] https://github.com/RIOT-OS/RIOT/releases/tag/2017.10
> [2] https://github.com/RIOT-OS/RIOT/archive/2017.10.tar.gz
> [3] https://github.com/RIOT-OS/RIOT/blob/2017.10-branch/release-notes.txt
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Update to the coding conventions regarding names of standardized constants and variables

2017-10-13 Thread Martine Lenders
Dear all,

FYI: I amended the coding convention with a statement about names in
standardization documents (e.g. RFCs) [1]. It's a no-brainer: They should
be used at least in Doxygen to allow for easy reference when cross-checking
(or review) the implementation of the standard.

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions#naming
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Ethernet communication initialization.

2017-10-12 Thread Martine Lenders
Hi Subhasis,

2017-10-12 11:36 GMT+02:00 subhasis :
>
> Please clarify how enc28j60 driver starts to communicate with connected
> device. Specifically how the MAC address of connected device (Linux PC) is
> known to the mote. I am using OpenBase with cc2358.
>

As far as I know this is not something Ethernet usually does. If you are
just debugging: get it by hand, if you are using it in production ARP/NDP
in IP traffic should do the trick.

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


Re: [riot-devel] Graphing build sizes

2017-10-11 Thread Martine Lenders
Hi Koen,

Wow, +1!

Cheers,
Martine

2017-10-11 16:59 GMT+02:00 Koen Zandberg :

> Hello,
>
> One of the issues from the CI discussion at the RIOT summit was the
> tracking and graphing of the nightly build sizes. After some
> instructions from Kaspar for getting the JSON files I got something
> working here:
>
> https://riot-graphs.snt.utwente.nl/dashboard/db/demonstrator?orgId=1
>
> For now I want to keep it up to date by running my script as a cron
> every night approximately after the nightly build. The source code of
> the script that parses and pushes the values to the database can be
> found at my github [1].
>
> The dashboard is now a simple Grafana templated dashboard where a test
> and a board can be selected. I'd like to expand this by creating a
> dashboard for every test or for every board. The most difficult thing
> for now is to present the huge amount of data in a clear and concise
> way. Input on this and the overview in general is most welcome.
>
> Koen
>
> [1]: https://github.com/bergzand/RIOT-graphs
>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support

2017-09-23 Thread Martine Lenders
Hi,

this will be discussed tomorrow at the T2TRG meeting preceeding the RIOT
summit [1]. Will anyone of you who discussed this be there? The premise is
that 6LoWPAN was designed to run on even on a minimized, non-compliant IEEE
802.15.4, so the question is: other than PAN bootstrapping and MAC: is this
really required for a minimal network set-up? (Answer in the session,
rather than in this thread are preferred, but I'll try to carry any posts
here into the f2f discussion ;-)).

Best,
Martine

[1] https://github.com/t2trg/2017-09-berlin#agenda

2017-09-21 19:11 GMT+02:00 Thomas Eichinger :

> Hi Joakim,
>
> That was what I pretty much meant before I'm sorry for not expressing
> this clear enough.
>
> Seems we reached common ground here.
>
> Best,
> Thomas
>
>
> On 20 Sep 2017, at 13:51 PDT(-0700), Joakim Nohlgård wrote:
>
> Hi again,
>> Perhaps it would make sense to split it in two? One low level part
>> which manages the duty cycling and wake scheduling, while the PAN
>> management part (I think it is called MAC services in the 802.15.4
>> standard) would run as a higher layer on top of it.
>>
>> /Joakim
>>
>> On Wed, Sep 20, 2017 at 10:37 PM, Thomas Eichinger 
>> wrote:
>>
>>> Hi Joakim,
>>>
>>> Thanks for sharing your point of view.
>>>
>>> Personally I think it complicates MAC protocol implementations when they
>>> somehow have to accommodate 802.15.4 functionality and deal with e.g.
>>> starting and maintaining the PAN and I'd expect we will have to use more
>>> #ifdefs.
>>>
>>> In my opinion runtime functionality as described in 6.3 and following of
>>> the standard also doesn't need to run with the same priority as the
>>> actual
>>> MAC protocol.
>>>
>>> Your approach would however benefit upper layers I think as the interface
>>> wouldn't have to change.
>>>
>>> In the end I'm fine with whatever works and covers our requirements.
>>>
>>> Best, Thomas
>>>
>>>
>>> On 20 Sep 2017, at 1:11 PDT(-0700), Joakim Nohlgård wrote:
>>>
>>> Hi,
 I have recently been digging around the gnrc_netdev code as well. I
 think that adding support for other frame types and logic for sending
 these frames will definitely become a mess if the 802.15.4 code is not
 decoupled from the netdev code. Especially if someone would like to
 add advanced features like 802.15.4e TSCH, which requires version 2
 framing and a number of special MAC header fields. I don't think the
 802.15.4 layer needs to be in its own thread though, it should be
 enough to separate the framing functionality from the send/recv code
 and let the MAC layer handle it internally, and keep the 802.15.4
 layer in the same thread as the netdev driver, like gnrc_netdev does
 today.

 /Joakim

 On Wed, Sep 20, 2017 at 12:16 AM, Thomas Eichinger 
 wrote:

>
> Hi Oleg!
>
> On 19 Sep 2017, at 13:24 PDT(-0700), Oleg Hahm wrote:
>
> On Sun, Sep 17, 2017 at 02:37:39PM -0700, Thomas Eichinger wrote:
>>
>> A while ago I worked on adding support for MAC commands and procedures
>>> the
>>> standard describes like channel scanning and automatic association
>>> of a
>>> device with a coordinator.
>>> Personally I think those are nifty features to provide, the reality
>>> check
>>> the last two days showed though that it'd need some non-trivial
>>> refactoring
>>> of the existing 15.4 code to not end up in #ifdef hell.
>>>
>>
>>
>>
>>
>> Can you elaborate a little bit on this part? I would assume that being
>> compatible with other 802.15.4 implementations requires run-time
>> flexibility,
>> i.e., react properly to optional features implemented by other
>> 802.15.4
>> devices. Or were you proposing to have a minimal
>> non-standard-compliant
>> version _and_ standard-compliant version intermingled, sharing commmon
>> code
>> through preprocessor directives?
>>
>
>
>
> Admittedly the "#ifdef hell" was a bit polemic and I didn't intend to
> propose
> offering a non-standard-compliant version. ;)
>
> Right now RIOT is very much streamlined to send and receive 802.15.4
> data
> and
> ACK frames. The nontrivial refactoring I referred to would have to
> break
> this.
>
> On the receiving side I see the possibility to introduce an other
> nettype
> like
> GNRC_NETTYPE_802154 set by the corresponding frame type and the actual
> runtime
> logic would basically be in parallel of sixlowpan threads,
> hierarchically.
> (changing channels and hardware addresses, actively/passively scanning
> for
> coordinators...)
> That'd be at least my approach.
>
> On the sending side, however, the 15.4 header currently gets crafted in
> the
> netdev code and set to data frames. We'd have to take that out and let
> the

Re: [riot-devel] gnrc: MAC layer selection

2017-09-20 Thread Martine Lenders
Hi Joakim, Hi Shuguo,

First of all: We know of this problem and I try to come up with a solution
for this for a long time, so thanks for picking this up. A step into that
direction (but not the final solution) was the refactoring of GNRC's
interface layer (aka gnrc_netif2, see [1], should also simplify
implementing new MAC-layers a lot ;-)).

2017-09-20 10:38 GMT+02:00 Shuguo Zhuo :

> Hi, Joakim,
>
> This is a very good topic which also confuses me (with also my GoMacH MAC
> implementation queued up in pipe).
>
> > One possible solution is to add a function pointer member to the
> > `at86rf2xx_params_t` (and similar parameter structs for the other
> > netdev drivers) for initializing the MAC layer, and let the user
> > select the MAC layer there.
>
> This sounds like a good solution to me.
> Waiting for responses from more experienced RIOT developers. ;-)
>

I see some problems with this for several reasons:

a) This seems too device-specific for me. Can we maybe find a looser
coupling. First thing coming to mind is a (void *,
MAC_init_function)-tuple, where `void *` is an arbitrary params struct
(this solution isn't perfect either because it requires some searching).
b) Device configuration. That's a problem with our config in general. Say
you have several devices the same type on a board (e.g. two at86rf233). If
you want to change the config (i.e. switch MAC layer) for one device of
that type you need to reconfigure *all* devices of that type, since they
are in a static array. That sucks.
c) We need to ensure that this solution isn't GNRC-specific. lwIP has a
similar mechanism (different init functions for different MAC layers), but
there abstraction only starts at the interface layer, so a user (or in our
case our auto-init system) needs to know which device they want to use for
which MAC layer (sounds familiar?)
d) Function pointers. While I personally have no problem with function
pointers and quite happily use them to achieve better modularity (see [1]
;-)), I know there are community members that don't think using too many
function pointers is a good idea and make the code more complicated.

Best Regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/7370

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


[riot-devel] Updated invitation: Hack'n'ACK @ Tue Oct 10, 2017 5pm - 10pm (RIOT Events)

2017-09-15 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20171010T17
DTEND;TZID=Europe/Berlin:20171010T22
DTSTAMP:20170915T124510Z
UID:lbk4mfucqdomcf7c8o9cg4cmsg_r20160329t150...@google.com
RECURRENCE-ID;TZID=Europe/Berlin:20170926T17
CREATED:20150319T120715Z
DESCRIPTION:-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the descriptio
 n.\n\nView your event at https://www.google.com/calendar/event?action=VIEW;
 eid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNzA5MjZUMTUwMDAwWiBrM3FsOHNldHY
 3bDQ4b2Zub2wwdGZ1dTZ0c0Bn.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20170915T124510Z
LOCATION:FU Berlin\; HAW Hamburg
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Hack'n'ACK
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] native target, adc and encx24j600

2017-09-08 Thread Martine Lenders
Hi Temmu,

actually, there is no `periph_adc` implementation on native. But if you
don't care about the return value, a simple mock-up should be easily
ported. Just adapt the `periph_conf.h` of native accordingly and add the
implementation to `cpu/native/periph/adc.c`. For the encxj600 problem: just
use netdev_tap instead. It's also a (virtual) Ethernet device and can
communicate with other native instances and the host system via TAP.

Cheers,
Martine

2017-09-08 11:54 GMT+02:00 temmi...@gmail.com :

> Hi
>
> I have a small application that uses gcoap as server, which I'd like to
> debug the network traffic with BOARD=native. Currently it fails to compile
> because of periph/adc and likely will fail also because of encxj600.
>
> How to modify the program so that it compiles to BOARD=native and
> BOARD=nucleo-f401 using proper hardware on the nucleo-f401 and something
> fake on native? I'm not worried about what the native-adc reads.
>
>  - t
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] 6lowpan is not answering address ff02::2

2017-09-04 Thread Martine Lenders
Hi,

can you try with the new neighbor discovery? [1]

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/7479

2017-09-04 20:09 GMT+02:00 Baptiste Clenet :

> Hi,
>
> I've flashed gnrc_networking on two samr21-xpro. I've noticed that
> they do not answer to router solicitation because "packet destination
> is not this host" when source address is ff02::2 (gnrc_ipv6.c)[1].
> On native, there is no problem.
> By going deeper, I saw that the address ff02::2 is not added to the
> interface because samr21-xpro uses sixlowpan (compare to native), the
> function in question is [2]
>
> So basically, when the first samr21-xpro send a router solicitation,
> nobody answers. Shouldn't the second samr21-xpro answer? What do you
> think?
>
>
> [1] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/
> network_layer/ipv6/gnrc_ipv6.c#L905
> [2] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/
> network_layer/ipv6/netif/gnrc_ipv6_netif.c#L268
> --
> Baptiste
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] gnrc_border_router in native

2017-08-24 Thread Martine Lenders
Hi,

2017-08-24 19:08 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:

> My goal is to simulate in native a setup with a border router and a
> node (so without any hardware board)
>

Then try socket_zep. It simulates IEEE 802.15.4 networks for native.


> No, what I want is to run gnrc_border_router in native and instead of
> communicating with a serial port, I want to use tap0 (or something
> else).
> When we do make term, we open a connection between a node and linux
> and we can send command. Why can't I use the connection to make ethos
> communicate with gnrc_border_router?
>

ethos (Ethernet over Serial) requires a serial port, which is not provided
in the default config of native. You need something like socket_zep (for
the non-ethernet interface), to have the normal 6LoWPAN configuration for
the border router. Native usually uses netdev_tap in master, which is
Ethernet-based.


>
> Is it clearer?
>
> Cheers,
>
> 2017-08-24 16:56 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
> > Hi,
> > I assume you want to use it with the xbee (otherwise it does make little
> > sense, since this is the only non-Ethernet device we support for native,
> > AFAIK)? If so, please don't use `ethos` as the second interface, but just
> > `netdev_tap` (which is pulled in by default). If you want to be
> experimental
> > you try to use socket_zep instead of xbee with native [1].
> >
> > Cheers,
> > Martine
> >
> > [1] https://github.com/RIOT-OS/RIOT/pull/6121
> >
> > 2017-08-24 14:42 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
> >>
> >> Hi,
> >> I try to compile and run gnrc_border_router in native so I can have this
> >> setup:
> >> - LINUX
> >> - tap0: gnrc_border_router
> >> - tap1: gnrc_networking
> >> - tapbr0 linking tap0 and tap1
> >>
> >> Then instead of using ping6 fe80:%tap1, I could use ping6
> >> 2001:db8:.
> >> Ouput:
> >> RIOT/examples/gnrc_border_router$ make BOARD=native term
> >> make -C ethos
> >> make[2]: rien à faire pour « all ».
> >> make -C uhcpd
> >> make[2]: rien à faire pour « all ».
> >> sudo sh RIOT/dist/tools/ethos/start_network.sh tap0 tap0 tap0
> >> 2001:db8::/64
> >> net.ipv6.conf.tap0.forwarding = 1
> >> net.ipv6.conf.tap0.accept_ra = 0
> >> Error: ??? prefix is expected rather than "tap0".
> >> Cleaning up...
> >> RIOT/dist/tools/ethos/start_network.sh: 23: kill: Usage: kill [-s
> >> sigspec | -signum | -sigspec] [pid | job]... or
> >> kill -l [exitstatus]
> >> RIOT/examples/gnrc_border_router/../../Makefile.include:380 : la
> >> recette pour la cible « term » a échouée
> >> make: *** [term] Erreur 1
> >>
> >> First thing: A third tap0 appears I don't know how. If I replace :
> >> TERMFLAGS ?= $(PORT) $(TAP) $(IPV6_PREFIX)
> >> By
> >> TERMFLAGS ?= $(TAP) $(IPV6_PREFIX)
> >>
> >> Output:
> >> RIOT/examples/gnrc_border_router$ make BOARD=native term
> >> make -C ethos
> >> make[2]: rien à faire pour « all ».
> >> make -C uhcpd
> >> make[2]: rien à faire pour « all ».
> >> sudo sh RIOT/dist/tools/ethos/start_network.sh tap0 tap0 2001:db8::/64
> >> net.ipv6.conf.tap0.forwarding = 1
> >> net.ipv6.conf.tap0.accept_ra = 0
> >> Error opening serial device tap0
> >> Error opening serial device tap0
> >> Cleaning up...
> >> RIOT/examples/gnrc_border_router/../../Makefile.include:380 : la
> >> recette pour la cible « term » a échouée
> >> make: *** [term] Erreur 1
> >>
> >> Of course, tap0 is not serial port so how to make border_router work in
> >> native?
> >>
> >> Cheers,
> >>
> >> --
> >> Baptiste
> >> ___
> >> devel mailing list
> >> devel@riot-os.org
> >> https://lists.riot-os.org/mailman/listinfo/devel
> >
> >
> >
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
> >
>
>
>
> --
> Baptiste
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] gnrc_border_router in native

2017-08-24 Thread Martine Lenders
Hi,
I assume you want to use it with the xbee (otherwise it does make little
sense, since this is the only non-Ethernet device we support for native,
AFAIK)? If so, please don't use `ethos` as the second interface, but just
`netdev_tap` (which is pulled in by default). If you want to be
experimental you try to use socket_zep instead of xbee with native [1].

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/6121

2017-08-24 14:42 GMT+02:00 Baptiste Clenet :

> Hi,
> I try to compile and run gnrc_border_router in native so I can have this
> setup:
> - LINUX
> - tap0: gnrc_border_router
> - tap1: gnrc_networking
> - tapbr0 linking tap0 and tap1
>
> Then instead of using ping6 fe80:%tap1, I could use ping6
> 2001:db8:.
> Ouput:
> RIOT/examples/gnrc_border_router$ make BOARD=native term
> make -C ethos
> make[2]: rien à faire pour « all ».
> make -C uhcpd
> make[2]: rien à faire pour « all ».
> sudo sh RIOT/dist/tools/ethos/start_network.sh tap0 tap0 tap0
> 2001:db8::/64
> net.ipv6.conf.tap0.forwarding = 1
> net.ipv6.conf.tap0.accept_ra = 0
> Error: ??? prefix is expected rather than "tap0".
> Cleaning up...
> RIOT/dist/tools/ethos/start_network.sh: 23: kill: Usage: kill [-s
> sigspec | -signum | -sigspec] [pid | job]... or
> kill -l [exitstatus]
> RIOT/examples/gnrc_border_router/../../Makefile.include:380 : la
> recette pour la cible « term » a échouée
> make: *** [term] Erreur 1
>
> First thing: A third tap0 appears I don't know how. If I replace :
> TERMFLAGS ?= $(PORT) $(TAP) $(IPV6_PREFIX)
> By
> TERMFLAGS ?= $(TAP) $(IPV6_PREFIX)
>
> Output:
> RIOT/examples/gnrc_border_router$ make BOARD=native term
> make -C ethos
> make[2]: rien à faire pour « all ».
> make -C uhcpd
> make[2]: rien à faire pour « all ».
> sudo sh RIOT/dist/tools/ethos/start_network.sh tap0 tap0 2001:db8::/64
> net.ipv6.conf.tap0.forwarding = 1
> net.ipv6.conf.tap0.accept_ra = 0
> Error opening serial device tap0
> Error opening serial device tap0
> Cleaning up...
> RIOT/examples/gnrc_border_router/../../Makefile.include:380 : la
> recette pour la cible « term » a échouée
> make: *** [term] Erreur 1
>
> Of course, tap0 is not serial port so how to make border_router work in
> native?
>
> Cheers,
>
> --
> Baptiste
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] IPv4 support

2017-08-18 Thread Martine Lenders
Hi Oleg,

2017-08-18 15:37 GMT+02:00 Oleg Hahm :

> Dear Ameya!
>
> On Fri, Aug 18, 2017 at 06:38:31PM +0530, Ameya Joshi wrote:
> > Does the latest version of RIOT support IPv4?
>
> RIOT supports the lwip network stack which supports IPv4. However, AFAIK
> there
> is no IPv4 support for application interface "sock". Martine, correct me if
> I'm wrong.
>

You are wrong ;-). Compile with `lwip_ipv4` and `lwip_sock_udp` or
`lwip_sock_tcp` to use UDP over IPv4 or TCP over IPv4, respectively.
However, this might only work for Ethernet-based L2 protocols. IPv4 over
IEEE 802.15.4 is not specified and I'm not sure if it would work with lwIP.

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


Re: [riot-devel] where to put bootloader?

2017-08-09 Thread Martine Lenders
Hi,

gut feeling says `dist/tools/bootloader` (maybe something more unique than
just bootloader?), since it isn't really part of the system and not really
an example, but a quite specific application. Then again, for the same
reasons I could argue to put it in the root folder, that IMHO should be
kept small, however.

Cheers,
Martine

2017-08-09 13:29 GMT+02:00 Kaspar Schleiser :

> Hi everyone,
>
> PR #7457 will introduce a bootloader application.
>
> The question came up where to put it within the source tree?
> Currently the PR puts it in the root folder (./bootloader).
>
> Do we want that? Is there a better place?
>
> Options:
> examples/bootloader
> dist/tools/bootloader
> ...
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Help needed for porting to stm32l4

2017-07-04 Thread Martine Lenders
Hi Nazmul,
have you seen the Porting Guide [1]? It should provide you with all
information you need.

Best Regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/wiki/Porting-Guide

2017-07-05 6:40 GMT+02:00 Nazmul Alam :

> Hi Rioters,
> I want to port RIOT to stm32L4discovery device, the cpu is corex_m0 and I
> think RIOT has implementation for cortex_m0 cpu.
>
> Any suggestion from where I can start?
>
> Thanks in advance.
>
> --
> with best regards,
>Nazmul Alam Shovon
>
>
> *শুভেচ্ছান্তে,   নাজমুল আলম শোভন*
>
> blog : https://yourdigitaleffects.wordpress.com/
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] 2017.07 feature freeze

2017-06-30 Thread Martine Lenders
Hi,
I took it upon me to make the 2017.10 tag a proper annotated tag using `git
tag -a` (`git describe` on current master no returns `2017.10-devel`). The
last real annotated tag was 2017.04-devel, so for the last two releases our
master counted commits from 2017.01 ;-).

Cheers,
Martine

2017-06-30 22:20 GMT+02:00 Alexandre Abadie :

> Dear RIOT'ers,
>
> I've just created the 2017.07 branch and tagged the first release
> candidate [1], which means we're now in feature freeze.
>
> Final 2017.07 release is still planned for the 14th of July.
>
> Theres an issue for tracking the testing progress at [2]. Any help is
> highly appreciated!
>
> Best,
>
> Alex
>
> [1] https://github.com/RIOT-OS/RIOT/tree/2017.07-RC1
> [2] https://github.com/RIOT-OS/Release-Specs/issues/44
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Minimal MCU clock speed for using it as a border-router.

2017-06-12 Thread Martine Lenders
Hi Neo,

regarding clock speed I'm not aware of any restrictions on the
`gnrc_border_router` example (though there are some on space, which most
STM32 MCUs should fulfill). It might get slower and depending on the
traffic it might get overwhelmed, but I think no one ever made any
experiments for that specifically.

Best regards,
Martine

2017-06-12 12:42 GMT+02:00 Neo :

> Dear RIOT-developers,
>
> up to now I have worked with a beaglebone as a 6LoWPAN border router.
>
> I want now to change to a microcontroller based system (STM32 family).
>
> Now my question - what is the minimum clock speed of such a controller to
> be able to work as a border-router?
>
> Thanks a lot!
>
> Best regards,
>
> Neo
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Support for cc3200

2017-05-19 Thread Martine Lenders
Hi Markus,
I don't know about the library (usually try not to include vendor library,
due to licensing issues on the one hand side and since they aren't in many
cases the most optimal solutions size-wise, on the other), but it is
basically up to you which API you would use as a wrapper. sock is our
high-level API networking, so you basically just have to implement the API
around the device driver. However, for sock there is already a wrapper
around NETAPI. So if you choose NETAPI you would not need to implement it.
NETAPI is the internal inter-modular API of our network stack, so it is a
little bit more complicated to implement, but it would basically allow for
dual-stack operation if you do so. On the matter of where to place the
latter: You would need to make it a handler for GNRC_NETTYPE_UDP or
GNRC_NETTYPE_TCP, respectively.

Cheers,
Martine

2017-05-19 16:14 GMT+02:00 Härtinger Markus <markus.haertin...@xws.de>:

> Thanks for your help!
>
>
>
> Yes the CC3200 includes a full IPv4 network stack.
>
> So I will try to implement GNRC's NETAPI or sock API at the moment I am
> not sure where to place these, to connect, the existing simple link library
> (cc3200) to the riot network stack.
>
>
>
> Best Regards
>
>
>
> Markus
>
>
>
> *Von:* devel [mailto:devel-boun...@riot-os.org] *Im Auftrag von *Martine
> Lenders
> *Gesendet:* Freitag, 19. Mai 2017 09:11
> *An:* RIOT OS kernel developers
> *Betreff:* Re: [riot-devel] Support for cc3200
>
>
>
> Hi,
>
>
>
> 2017-05-19 8:00 GMT+02:00 Härtinger Markus <markus.haertin...@xws.de>:
>
> Hi
>
> We are currently developing an WIFI support in RIOT-OS for the CPU cc3200.
>
> Our implementation is based on the code of Attilio Donà and the vendor
> libraries of Texas Instruments.
>
>
>
> Great! Thanks for picking that up.
>
>
>
>
>
> After the first hardware support for this CPU currently we try to
> implement the WLAN support.
>
> For this goal we have some questions:
>
> -  Is there already an implementation for any WLAN  IEEE-802.11
> CPU in RIOT-OS
>
> AFAIK no.
>
> -  Is there an IPv4 support or only IPv6
>
> Currently only IPv6 is supported natively (though we support IPv4 via the
> lwIP pkg). But we don't say no if we get IPv4 support for GNRC ;-).
>
> -  Is it correct that it is only necessary to wirte the
> cc3200_netdev.c-File.
>
> The CC3200 delivers a full embedded network stack right? If so, I would
> rather suggest to either implement against GNRC's NETAPI [1] or the sock
> API [2], rather than netdev. Though it is the CC3200 network device,
> porting it to the netdev API might lead to problems that API rather thought
> to be used for link-layer networking.
>
>
>
> Kind Regards,
>
> Martine
>
>
>
> [1] http://doc.riot-os.org/group__net__gnrc__netapi.html
>
> [2] http://doc.riot-os.org/group__net__sock.html
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Support for cc3200

2017-05-19 Thread Martine Lenders
Hi,

2017-05-19 8:00 GMT+02:00 Härtinger Markus :

> Hi
>
> We are currently developing an WIFI support in RIOT-OS for the CPU cc3200.
>
> Our implementation is based on the code of Attilio Donà and the vendor
> libraries of Texas Instruments.
>

Great! Thanks for picking that up.


>
>
> After the first hardware support for this CPU currently we try to
> implement the WLAN support.
>
> For this goal we have some questions:
>
> -  Is there already an implementation for any WLAN  IEEE-802.11
> CPU in RIOT-OS
>
AFAIK no.

> -  Is there an IPv4 support or only IPv6
>
Currently only IPv6 is supported natively (though we support IPv4 via the
lwIP pkg). But we don't say no if we get IPv4 support for GNRC ;-).

> -  Is it correct that it is only necessary to wirte the
> cc3200_netdev.c-File.
>
The CC3200 delivers a full embedded network stack right? If so, I would
rather suggest to either implement against GNRC's NETAPI [1] or the sock
API [2], rather than netdev. Though it is the CC3200 network device,
porting it to the netdev API might lead to problems that API rather thought
to be used for link-layer networking.

Kind Regards,
Martine

[1] http://doc.riot-os.org/group__net__gnrc__netapi.html
[2] http://doc.riot-os.org/group__net__sock.html
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Ladies That FOSS 2.0

2017-05-15 Thread Martine Lenders
Hi,
sadly this month's Ladies That FOSS (the one tomorrow) was canceled, but
let's wait and see what next month will bring.

Kind Regards,
Martine

2017-05-15 11:47 GMT+02:00 Martine Lenders <m.lend...@fu-berlin.de>:

> Hi,
> For those of you who don't know, last October we participated at the
> "Ladies that FOSS" Hackathon intended to bring women into Free and Open
> Source Software projects. This was rather successful as we got an
> implementation of the SNTP protocol out of it. For the last few month we
> weren't able to participate due to scheduling conflicts, but I'd like to
> revive this relationship.
>
> The next meetup [1] will be tomorrow 18:00 (despite the event page
> claiming to be on May 17th) at Wikimedia Deutschland in Berlin. This time I
> won't be able to attend again, but if you want to just ask me and I give
> you Charlie's contact data. The next I'm planning to attend is on June 21st
> 18:00 [2] and I would be happy about any fellow contributor to RIOT that is
> in Berlin at this time and would like to join.
>
> Kind Regards,
> Martine
>
> PS: you do not need to identify as female to join as a mentor. As long as
> you stick to the Code of Conduct [3], anyone is welcome to join.
>
> [1] https://www.meetup.com/de-DE/LadiesthatFoss/events/239394439/
> [2] https://www.meetup.com/de-DE/LadiesthatFoss/events/hmpfvmywjbcc/
> [3] https://www.wikimedia.de/wiki/Ladies_that_FOSS/Code_of_Conduct
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


  1   2   3   4   >