18962: pkg/lwip: Force loglevel when using log module r=maribu a=yarrick
18999: Paho: Allow building for 8 and 16 bit platforms r=maribu a=OlegHahm
### Contribution description
Providing a patch to Paho upstream which uses fixed size integers (int32_t) instead of plain int whenever it is used to represent a size of an object.
This patch will allow to build the Paho package for platforms where an integer has a width of less than 32 bit.
This patch is also provided as a PR to the upstream version of Paho (https://github.com/eclipse/paho.mqtt.embedded-c/pull/238) but unfortunately the upstream seems to be unmaintained.
### Testing procedure
Build for a 8 or 16 bit platform that has enough memory for the example, e.g., https://api.riot-os.org/group__boards__atxmega-a1u-xpro.html:
BUILD_IN_DOCKER=1 BOARD=atxmega-a1u-xpro make clean all
Without this PR this build will fail, with the patches applied it will succeed.
### Issues/PRs references
This PR makes #18997 obsolete and thus reverts the change.
19034: boards/nucleo-l496zg: doc improvement r=maribu a=krzysztof-cabaj
### Contribution description
This PR adds to nucleo-l496zg documentation MCU table - similar to those, for example for, Nucleo F103RB, F302R8 or F446RE.
### Testing procedure
```
make doc
xdg-open doc/doxygen/html/group__boards__nucleo-l496zg.html
```
### Issues/PRs references
None
Co-authored-by: Erik Ekman <eekman@google.com>
Co-authored-by: Oleg Hahm <oleg@hobbykeller.org>
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
19026: riscv: Reduce reset trampoline code size by 2 bytes r=maribu a=jnohlgard
`addi` with 20 bit immediate does not have a compressed representation, so using `jalr` with immediate offset uncompressed is smaller than using `addi`+`c.jr`
Co-authored-by: Joakim Nohlgård <joakim@nohlgard.se>
19032: sys/analog_util/dac_util: fix truncation bug r=maribu a=Enoch247
### Contribution description
From the commit message:
> In `dac_util_map(...)` the expression `((value - min) * UINT16_MAX)` was cast to a 16 bit unsigned, then divided by `(max - min)`. This means that anytime `(value - min) != 0` the numerator was truncated prior to being divided and then returned.
>
> This patch modifies the expression so that the downcast to 16 bits is performed as the last operation.
### Testing procedure
Should be verifiable by simply analyzing the code.
### Issues/PRs references
none known
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
In `dac_util_map(...)` the expression `((value - min) * UINT16_MAX)` was
cast to a 16 bit unsigned, then divided by `(max - min)`. This means
that anytime `(value - min) != 0` the numerator was truncated prior to
being divided and then returned.
This patch modifies the expression so that the downcast to 16 bits is
performed as the last operation.
18803: dist/tools: Add compile_like_murdock r=benpicco a=MrKevinWeiss
### Contribution description
Helper script to pre-test murdock build conditions.
This is intended to compile like murdock giving control for only a subset of boards or applications. One can use this if only a limited change should be build tested. Defaults boards and apps are selected to be an early warning if something is wrong.
This should be used before triggering much larger murdock builds.
The following use cases are:
I made a change to something in the stm32 clocks... ./compile_like_murdock.py -c stm32
I changed a driver the DHT driver
./compile_like_murdock.py -a tests/driver_dht tests/saul
I changed a nucleo-f103rb board...
./compile_like_murdock.py -a tests/driver_dht tests/saul
### Testing procedure
View the help...
```
./dist/tools/compile_test/compile_like_murdock.py -h
```
Do a dry run of the cpu...
```
./dist/tools/compile_test/compile_like_murdock.py -c stm -d
```
Play with each of the args, try adding a module to hello-world to get a module mismatch.
### Issues/PRs references
<!--
Examples: Fixes#1234. See also #5678. Depends on PR #9876.
Please use keywords (e.g., fixes, resolve) with the links to the issues you
resolved, this way they will be automatically closed when your pull request
is merged. See https://help.github.com/articles/closing-issues-using-keywords/.
-->
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
19029: check-pr.yml: Fail when `State: waiting for CI update` is set r=miri64 a=miri64
<!--
The RIOT community cares a lot about code quality.
Therefore, before describing what your contribution is about, we would like
you to make sure that your modifications are compliant with the RIOT
coding conventions, see https://github.com/RIOT-OS/RIOT/blob/master/CODING_CONVENTIONS.md.
-->
### Contribution description
See https://github.com/RIOT-OS/RIOT/pull/18956#issuecomment-1342781762
<!--
Put here the description of your contribution:
- describe which part(s) of RIOT is (are) involved
- if it's a bug fix, describe the bug that it solves and how it is solved
- you can also give more information to reviewers about how to test your changes
-->
### Testing procedure
I've set the label in question, so the test should fail in the beginning.
<!--
Details steps to test your contribution:
- which test/example to compile for which board and is there a 'test' command
- how to know that it was not working/available in master
- the expected success test output
-->
### Issues/PRs references
See https://github.com/RIOT-OS/RIOT/pull/18956
<!--
Examples: Fixes#1234. See also #5678. Depends on PR #9876.
Please use keywords (e.g., fixes, resolve) with the links to the issues you
resolved, this way they will be automatically closed when your pull request
is merged. See https://help.github.com/articles/closing-issues-using-keywords/.
-->
Co-authored-by: Martine Lenders <m.lenders@fu-berlin.de>
Helper script to pre-test murdock build conditions.
This is intended to compile like murdock giving control for only a subset of
boards or applications. One can use this if only a limited change should be
build tested. Defaults boards and apps are selected to be an early warning
if something is wrong.
This should be used before triggering much larger murdock builds.
The following use cases are:
I made a change to something in the stm32 clocks...
./compile_like_murdock.py -c stm32
I changed a driver the DHT driver
./compile_like_murdock.py -a tests/driver_dht tests/saul
I changed a nucleo-f103rb board...
./compile_like_murdock.py -a tests/driver_dht tests/saul
19024: pkg/paho-mqtt: add support for DNS r=aabadie a=benpicco
<!--
The RIOT community cares a lot about code quality.
Therefore, before describing what your contribution is about, we would like
you to make sure that your modifications are compliant with the RIOT
coding conventions, see https://github.com/RIOT-OS/RIOT/blob/master/CODING_CONVENTIONS.md.
-->
### Contribution description
This is pretty straightforward, we only need to hook up `dns_query()`.
Since paho supports both IPv4 and IPv6 we use `AF_UNSPEC` in the query.
This can however give us a A record if we only have IPv6 enabled, so translate the request based on what IP address module is enabled in `dns_query()`.
### Testing procedure
connecting by name works
```
> con test.mosquitto.org 1883
mqtt_example: Connecting to MQTT Broker from test.mosquitto.org 1883
mqtt_example: Trying to connect to test.mosquitto.org , port: 1883
user: clientId: password:
mqtt_example: Connection successfully
```
connecting by IP still works
```
> con 2001:41d0:1:925e::1 1883
mqtt_example: Connecting to MQTT Broker from 2001:41d0:1:925e::1 1883
mqtt_example: Trying to connect to 2001:41d0:1:925e::1 , port: 1883
user: clientId: password:
mqtt_example: Connection successfully
```
<!--
Details steps to test your contribution:
- which test/example to compile for which board and is there a 'test' command
- how to know that it was not working/available in master
- the expected success test output
-->
### Issues/PRs references
<!--
Examples: Fixes#1234. See also #5678. Depends on PR #9876.
Please use keywords (e.g., fixes, resolve) with the links to the issues you
resolved, this way they will be automatically closed when your pull request
is merged. See https://help.github.com/articles/closing-issues-using-keywords/.
-->
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
18956: CI: implement quick build logic r=kaspar030 a=kaspar030
<!--
The RIOT community cares a lot about code quality.
Therefore, before describing what your contribution is about, we would like
you to make sure that your modifications are compliant with the RIOT
coding conventions, see https://github.com/RIOT-OS/RIOT/blob/master/CODING_CONVENTIONS.md.
-->
### Contribution description
This PR implements "quick builds" (subset builds).
The logic is as following (checkmark for what was tested):
- [x] if the "CI: full build" label is set, [result](https://ci.riot-os.org/details/15e489f7a3f346bdb49a84080329f3d6)
- [x] or NIGHTLY=1 [result](https://ci.riot-os.org/details/d741a174bbbc437eb1972e87688098fb)
- [x] or if building bors' ~~"trying"~~"staging" branch, do a full build. [result](https://ci.riot-os.org/details/692362fd0e594bdeb190ea99a6de2479)
- [x] otherwise, if BOARDS was supplied, build those: [result](https://ci-staging.riot-os.org/details/2034f3ed656c4b37b573732517334cfd) (ci-staging hard-sets BOARDS="samr21-xpro native")
- [x] otherwise, if can_fast_ci_build.py figured out boards that have changes, build those [result](https://ci.riot-os.org/details/ab92ec61cb7040b18d9789c05831eb86)
- [x] otherwise, only consider boards listed in QUICKBUILD_BOARDS [result](https://ci.riot-os.org/details/fca366441e0341d79af52200365d298d)
<!--
Put here the description of your contribution:
- describe which part(s) of RIOT is (are) involved
- if it's a bug fix, describe the bug that it solves and how it is solved
- you can also give more information to reviewers about how to test your changes
-->
TBD: actual list of QUICKBUILD_BOARDS
### Testing procedure
<!--
Details steps to test your contribution:
- which test/example to compile for which board and is there a 'test' command
- how to know that it was not working/available in master
- the expected success test output
-->
### Issues/PRs references
bors tracking issue: https://github.com/RIOT-OS/RIOT/issues/18911
<!--
Examples: Fixes#1234. See also #5678. Depends on PR #9876.
Please use keywords (e.g., fixes, resolve) with the links to the issues you
resolved, this way they will be automatically closed when your pull request
is merged. See https://help.github.com/articles/closing-issues-using-keywords/.
-->
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
`addi` with 20 bit immediate does not have a compressed representation,
so using `jalr` with immediate offset uncompressed is smaller than using
`addi`+`c.jr`
18910: CI: add bors.toml r=kaspar030 a=kaspar030
<!--
The RIOT community cares a lot about code quality.
Therefore, before describing what your contribution is about, we would like
you to make sure that your modifications are compliant with the RIOT
coding conventions, see https://github.com/RIOT-OS/RIOT/blob/master/CODING_CONVENTIONS.md.
-->
### Contribution description
This adds configuration for [bors](https://bors.tech).
This has been discussed in CI meetings. The intended workflow is:
1. regular PR commits get built by CI as usual, but doing a quick-build (building only a subset of all boards), unless "CI: full build" is set
2. once that passes and the PR is ACKed, instead of merging using the merge button, we use bors to merge by typing "bors merge".
3. bors takes the PR, pushes it to the "testing" branch
4. CI does a full build of "testing"
5. on success, bors merges testing into master
The main benefits are
1. a quickbuild / full build scheme ("regular" PR builds will be <5 minutes, but only fully built branches get merged into master)
2. bors does "rollups", meaning, if multiple PRs are to be "bors merged", bors merges them together, tests them together and merges them together. That's more efficient than doing this sequentially, and prevents semantic merge conflicts (e.g., PR a and b pass CI individually, but fail when both merged, breaking master).
Once fully implemented, using bors will be a workflow change (no more "pressing the green button", but typing "bors merge" instead). But we've been using bors for RIOT-OS/riotdocker for a long time now, the experience was good (as opposed to disruptive).
This PR just adds the necessary bors configuration, and once merged will allow using bors to merge PRs using "bors merge", but the previous workflow is still in place (manual merging can be done, and "regular" PR builds are still full builds).
<!--
Put here the description of your contribution:
- describe which part(s) of RIOT is (are) involved
- if it's a bug fix, describe the bug that it solves and how it is solved
- you can also give more information to reviewers about how to test your changes
-->
### Testing procedure
<!--
Details steps to test your contribution:
- which test/example to compile for which board and is there a 'test' command
- how to know that it was not working/available in master
- the expected success test output
-->
### Issues/PRs references
bors tracking issue: #18911
<!--
Examples: Fixes#1234. See also #5678. Depends on PR #9876.
Please use keywords (e.g., fixes, resolve) with the links to the issues you
resolved, this way they will be automatically closed when your pull request
is merged. See https://help.github.com/articles/closing-issues-using-keywords/.
-->
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
