text:
Automated cherry pick of #6306: fix: openstack 安全组规则同步

Cherry pick of #6306 on release/3.2.
#6306: fix: openstack 安全组规则同步

Codecov Report

Merging #6310 into release/3.2 will increase coverage by 0.01%.
The diff coverage is 7.63%.

@@               Coverage Diff               @@
##           release/3.2    #6310      +/-   ##
===============================================
+ Coverage         7.04%    7.05%   +0.01%
===============================================
  Files              646      649       +3
  Lines           110882   111210     +328
===============================================
+ Hits              7813     7850      +37
- Misses          102467   102752     +285
- Partials           602      608       +6

Flag
Coverage Δ

#aFlag
7.05% <7.63%> (+0.01%)
:arrow_up:

Impacted Files
Coverage Δ

pkg/baremetal/manager.go
0.50% <0.00%> (+<0.01%)
:arrow_up:

pkg/baremetal/tasks/bm_register.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/db_dispatcher.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/domainresource.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/infraresource.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/project.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/sharablevirtual.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/virtualresource.go
0.00% <0.00%> (ø)

pkg/cloudprovider/cloudprovider.go
1.53% <0.00%> (-0.11%)
:arrow_down:

pkg/compute/guestdrivers/managedvirtual.go
0.00% <0.00%> (ø)

... and 34 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 79f9d69...535e9a1. Read the comment docs.

authors: codecov-io ioito


text:
Automated cherry pick of #10808: fix(region): convert eip with same project with vm

Cherry pick of #10808 on release/3.7.
#10808: fix(region): convert eip with same project with vm

Codecov Report

Merging #10809 (c79495d) into release/3.7 (0ff3997) will decrease coverage by 0.40%.
The diff coverage is 1.15%.

@@               Coverage Diff               @@
##           release/3.7   #10809      +/-   ##
===============================================
- Coverage         5.98%    5.58%   -0.41%
===============================================
  Files              848      518     -330
  Lines           131795    90237   -41558
===============================================
- Hits              7887     5036    -2851
+ Misses          123206    84801   -38405
+ Partials           702      400     -302

Flag
Coverage Δ

aFlag
5.58% <1.15%> (-0.41%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/apis/const.go
0.00% <0.00%> (ø)

pkg/apis/input.go
0.00% <ø> (ø)

pkg/apis/list.go
0.00% <ø> (ø)

pkg/appsrv/appsrv.go
44.32% <0.00%> (-4.35%)
:arrow_down:

pkg/baremetal/tasks/stop.go
0.00% <0.00%> (ø)

pkg/cloudcommon/notifyclient/events.go
0.00% <ø> (ø)

pkg/cloudcommon/notifyclient/notify.go
0.72% <0.00%> (-0.45%)
:arrow_down:

pkg/cloudcommon/notifyclient/notify_internal.go
0.00% <0.00%> (ø)

pkg/cloudcommon/validators/validators.go
62.39% <0.00%> (-0.69%)
:arrow_down:

pkg/cloudcommon/notifyclient/template.go
7.04% <7.04%> (ø)

... and 453 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7c12d40...c79495d. Read the comment docs.

source: gharchive/pull-request

authors: codecov-commenter ioito

repo: yunionio/yunioncloud

license_type: permissive

license_source: github-api


text:
Bike Kitchen theme

Related to our discussion at #1259 , how could we make a pre-defined Bike Kitchen theme? Consider the following a draft that will be updated in the following days, when I get more feedback from users... These are the elements that could be changed in my opinion:

rename pickups to activities
replace the food basket icon for a bike one like fa-bicycle or another neutral one
replace the feedback icon for... what? fa-check-square, fa-reply, fa-thumbs-up fa-book?
leave the feedback feature with the comment field alone, taking away the amount of food saved
change the background image to a bike-fixing related one. Maybe the one I used at my first mockup (in my repo)?

What still needs to be adapted:

the automatically sent out emails in the backend
possibly other things in the backend

@brnsolikyl check it out here: https://dev.karrot.world/#/group/24

Backend: true, I had forgotten about it!
Damn, you two were mega productive this week! :smile:
Cool to see the changes (even though the background I chose is much uglier than what I remembered)
I noticed yesterday that I could not give feedback some minutes after I did the pickup, it lead me to a page saying "all done" or something similar. Now I tried it again and it worked. Have you been working on it meanwhile? I'll try to reproduce the problem...

Background is easy to change! Maybe it's good for the first release, and then somebody creates a better one hopefully ;)

I noticed yesterday that I could not give feedback some minutes after I did the pickup, it lead me to a page saying "all done" or something similar. Now I tried it again and it worked. Have you been working on it meanwhile? I'll try to reproduce the problem...

Pickups have a default duration of 30 minutes, I think feedback can only be given afterwards.

Need to spend some time with the backend to find a nice solution for emails, push notifications and error messages. Currently I don't have an elegant solution in mind.

Another detail: Take away "weight" from "Both comment and weight cannot be blank" when entering blank feedback.

This is a backend error message, we need a different approach to handle them. Maybe it's a good opportunity to move all error messages into the frontend and address them via identifiers…? (just thinking out loud)

@brnsolikyl did you get more feedback regarding non-fitting emails or error messages for the bike kitchen theme? I wonder there's still something that should be done in the next time...

Nothing about the e-mails but I'll investigate a bit more. I haven't asked for feedback in a while and I think nobody there would contact me spontaneously to give me one. hehe
Definitely no big issues here...

Thanks, then I think it's ok to close this for now. Feel free to re-open if something comes up!

source: gharchive/issue

authors: brnsolikyl djahnie tiltec

repo: yunity/karrot-frontend

license: mit

license_source: bigquery


text:
Add attachment content-type handling and appropriate attachment rendering

Implement content-type specific rendering of the HipChat message for the addAttachmentToCard event.
If the attachment content-type is an image it is render using  tag, otherwise it is render as url.

Thanks @MariyaNizovtsova - am closing this now to keep it out of the inbox.

authors: MariyaNizovtsova hugorodgerbrown

repo: yunojuno/django-test


text:
Discovery: explore alternatives to Docker Desktop

The usage of Docker Desktop in large corporates can be limited due to Docker's updated terms and conditions.
The following are some alternatives that should be tested:

Podman Desktop
Rancher Desktop
Lima + containerd - see example
Colima

The ideal would be to make tomodo interoperable, regardless of the available container runtime.  If interoperability can't be achieved, the user could proactively choose to configure tomodo with their preferred container runtime.

For Podman: Interoperability would be difficult (i.e., controlling Podman containers with the Docker SDK).  This is mainly a product of the difference between how Podman and Docker machines manage volumes.
For this purpose, it would be much cleaner to use the Podman SDK for Python.

repo: yuviherziger/tomodo

license: MIT


text:
Log line text is incorrect for disconnect peer

This should say "disconnect":
https://github.com/yzernik/squeaknode/blob/ebbbf00999c497e739bde9737207fd4518d61023/squeaknode/admin/squeak_admin_server_handler.py#L755

https://github.com/yzernik/squeaknode/pull/1153

repo: yzernik/squeaknode


text:
Discovered problems in unitPrice.js

Problem 1:
For if the quantity of the item is not in digits, for example, "1/2" or "0.5", the js file cannot get the correct result yet.
This may be solved by updating regular expression later?
Problem 2:
There may be cases that the price/unit is already been provided, but this is not considered/distuiguish by the js file yet.
Notice that the format is "$[digits]/[unit]".
This can be solved by adding an if statement before applying regular expression.
Problem 3:
The style of inserted tag (span) does not apply CSS changes.
The reason is not yet found.
Somebody is yelling outside right now :)

Problem 1 update:
Decimal number such as 0.5 can be handled by updating Regular Expression.
Thanks to yZhu.

Problem 2 update:
Provided price/unit is solved by re-constructing logic.

Problems solved

bug fixed


text:
Integrate with Secure Network Analytics via REST API

Instead of just creating g host_groups.xml file, integrate directly with SNA via the API to modify the host groups.

Completed

repo: yzxbmlf/netorganizer


text:
Restore setOverwinter function

This function is required by z-nomp's node-stratum-pool in order to
allow both forks that have overwinter as well as forks that don't.

yay! merge!

authors: egyptianbman nettts

repo: z-nomp/bitcoinjs-lib


text:
Select2 need to have empty option (Select2需要有空选项)

Select2 need to have empty option so it select empty option as default value...
Select2需要有空选项，因此选择空选项为默认值… ^^

谢谢

authors: z-song zho

repo: z-song/laravel-admin


text:
Problem with setting up [Latest version]

Configure project :
Found AccessTransformer: hydrogen_at.cfg
Version string '1.5-beta_2' does not match SemVer specification
You should try SemVer : http://semver.org/

Task :decompileMc FAILED

FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':decompileMc'.

GC overhead limit exceeded

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/4.9/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 40s
5 actionable tasks: 4 executed, 1 up-to-date

unbuilt version is unstable download the stable and built version at https://github.com/zPeanut/Hydrogen/releases/tag/1.5

try adding org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=4096m -XX:+HeapDumpOnOutOfMemoryError to your gradle.properties file

also i accidentally forgot to update the gradle build file in 1.5, is fixed in 1.6 however!

try adding org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=4096m -XX:+HeapDumpOnOutOfMemoryError to your gradle.properties file

Where do i find the gradle.properties file?, and why does it says Version string '1.5-beta_2' does not match SemVer specification

if you set it up with the 1.6 version the semver specification should be met, also gradle.properties is in the directory you cloned the repo in

actually let me add a gradle.properties file to the repo

try using the current 1.7-dev repo now, i added the options to the properties. to your semver specifications: thats not an error, its basically forge telling you to refer to semantic versioning which "1.5-beta_2" does not follow. this is fixed in the latest release but its usually just a warning which you would normally ignore

i guess i can close this now, reopen if you have any further problems

authors: ProfKambing SMS221 zPeanut

repo: zPeanut/Hydrogen


text:
可以发布下版本吗？

当前最新版本为 3.5.37，但是releases里依旧是3.5.33，我想构建webjars，无法构建最新版，可以发布一下3.5.37releases吗？

非常抱歉，这是我的疏忽，现在已经添加上了！！

我觉得我真的很懒，这么方便，居然一直没有去维护 npm 的代码库；刚才已经上传到 npm 了，以后这个地址就是我自己来维护啦！！
https://www.npmjs.com/package/@ztree/ztree_v3

哈哈

我觉得我真的很懒，这么方便，居然一直没有去维护 npm 的代码库；刚才已经上传到 npm 了，以后这个地址就是我自己来维护啦！！
npmjs.com/package/@ztree/ztree_v3

嗯，你直接发了3.5.37 吗？低版本可以也写个脚本都发一下。不过npm只能发更高的版本。。。

为何还要发布低版本？ 这个我真的不想发了 @jasonHzq

你好，我们项目有人用了 ztree，很不错的组件。但是用的是低版本（3.5.26）。由于之前的研发直接copy了源码，既不符合规范，也难以进行构建优化。现在我想用 npm 包，但是你直接发布了高版本。虽然我可以 copy 你的代码发布我想要的版本，但是我也不想像另一位同学那样，让其它 ztree 用户感到混乱。

git+https://github.com/zTree/zTree_v3/tree/v3.5.27
那你应该可以使用 git 地址 进行处理。
另外，我看了一下发布日志，并没有进行什么不兼容之前版本的改动，你应该可是直接升级到最新版的 zTree 代码，建议你大胆的尝试一下

git+zTree/zTree_v3.git#v3.5.27
那你应该可以使用 git 地址 进行处理。
另外，我看了一下发布日志，并没有进行什么不兼容之前版本的改动，你应该可是直接升级到最新版的 zTree 代码，建议你大胆的尝试一下

哈哈，一个大项目，不敢造次。我用git地址吧。

authors: jasonHzq leshalv zTree


text:
Label doesn't inherit textAlignment

If the label has a text alignment set, it doesn't inherit (like it does for font) the text alignment, so the tapping rects may be off if it's not left-aligned.

This does not occur if you set an NSParagraphStyleAttributeName in the attributedText like so:
NSMutableParagraphStyle *style = [[NSMutableParagraphStyle alloc] init];
style.alignment = NSTextAlignmentCenter;
options.baseAttributes = @{ NSParagraphStyleAttributeName: style };

However, the label should handle the -[UILabel textAlignment] being changed from left.

repo: zacwest/ZSWTappableLabel


text:
Third Api Discovery - Stretch Goal

This api will be the map function to display country of origin for an art piece.

From further research I have come to find that Google Maps - Static Map api may be the right solution to show a dropped pin  in the country of origin with the rest of the world in view.

repo: zaczacariah/Artitude


text:
Performance of a model with single backbone

Hi,
Thank you for sharing this great work!
I have a simple question about the performance with single backbone.
What is the mAP@0.25 and mAP@0.5 on both ScanNet and SUN RGB-D when the model use single backbone?
Regards,

That's a great question! With ScanNet, we have tried with on BB. You should get around 66 mAP@0.25 from scratch.
For SUN RGB-D, we have not tried. You are welcome to try it with yourself.
With the pretrained model from here, we used a backbone model which is about 3x larger than the original one, we are able to achieve around 69 mAP@0.25 for ScanNet and 63 mAP@0.25 for SUN RGBD.

@zaiweizhang
Thank you for your kind reply!

Hi,
Thank you for sharing this great work!
I have a simple question about the performance with single backbone.
What is the mAP@0.25 and mAP@0.5 on both ScanNet and SUN RGB-D when the model use single backbone?
Regards,

Hi, i have the same question as you. So i want to know have you test the single backbone. And share the result. Thank you very much!

@chrockey
hi, I have the same question as you. So did you test the single backbone. If so, can you share the result. Thank you very much!

@zaiweizhang Thank you for your reply. I still have some questions. In your paper, you give the mAP 60.1% on SUNRGBD. which scale does it use?  And what do you think about the args--use_color,  should we set use or not use.

That's using four BB without pretraining from the method described here. You should not set the --use_color, it does not give performance gain and sometimes give worse results.

authors: chrockey xuntan97 zaiweizhang


text:
Review-SRS-Team30: Conflicting open issue and assumption

Open issue states to decide on a data transfer protocol such as wifi, bluetooth or ethernet
Assumption states that no wireless data transfer will occur for data privacy
Might be a good idea to clarify this in the document

P.S No permission to add label to issues

@CSchank


text:
Update .zappr.yaml

aruha-508

👍

👍

authors: lmontrieux zrobgar

repo: zalando-incubator/bubuku


text:
Removed obsolete docs folder

There was almost no content in these files which confuses or at least demotivates new devs starting to work on this project during onboarding. Some information about authentication (possibly outdated as well) has been moved temporarily into the README.md, which is also going to be updated soon in a separate PR.

This change is

+1 for removing the old docs

👍

@mtrenkmann, you need to send it using Authentication: Bearer <TOKEN> header.

Ok, I will add this piece of info to my README.md cleanup PR later ...

Cool

authors: mtrenkmann netme

repo: zalando-incubator/pazuzu-registry


text:
Use Zalando PostgreSQL database conventions

fullstop. currently does not follow our database conventions (as all our STUPS microservices do), check e.g. https://github.com/zalando-stups/pierone/blob/master/resources/db/migration/V1__Basic_schema.sql

For simplicity with Spring Boot + Hibernate, we agreed on keeping the "standard" naming scheme.

repo: zalando-stups/fullstop


text:
#391 filter by version

fixes #391

Current coverage is 46.60%

Merging #398 into master will not affect coverage as of 5e15ae3

@@            master   #398   diff @@
=====================================
  Files          127    127
  Stmts         2942   2942
  Branches       242    242
  Methods          0      0
=====================================
  Hit           1371   1371
  Partial         61     61
  Missed        1510   1510

Review entire Coverage Diff as of 5e15ae3

Powered by Codecov. Updated on successful CI builds.

:+1:

authors: Gregsen codecov-io mrandi


text:
access to custom vendor extension properties

Hello, is there any way to access custom vendor extension properties, or else the swagger doc for the current operation (or even whole swagger doc) ?
eg:
paths:
  /foo/{id}:
    get:
      x-foo: bar
      operationId: api.get_foo
      parameters:
      - in: path
        name: id
      responses:
        200:
          description: OK

def get_foo(id):
   x_foo = something.get("x-foo")
   assert x_foo == "bar"

The API object is your friend, see answer on #444

Great, thanks for the hint. have managed to make it work with @before_request and flask.g to store/retrieve the during the operation.

repo: zalando/connexion


text:
Problem exceptions

Fixes #366 .
Changes proposed in this pull request:

Adds in a base problem exception class which allows better customisation of responses
Demonstration of use for oAuth 2 Decorator

Coverage remained the same at 100.0% when pulling 17c69e30d4f0c3c93fb063357f94e7be70e3bed4 on wilsonge:problem_exceptions into 80dd8ea10655e9a661c451568e9bbca071a5577f on zalando:master.

@wilsonge Thank you for the PR. It is a good start!
I think it would be a good idea to use subclasses of ProblemException throughout Connexion code with custom templates following ideas from the RFC https://tools.ietf.org/html/rfc7807 as I mentioned at #368. But it might be food for a new PR. 😉

I would convert decorator by decorator. It also makes things easier to revert if there's a problem with one of the implementations :) I think if this is accepted I'll move onto the ParamValidation as that's probably the next most interesting one to tackle

Coverage remained the same at 100.0% when pulling fcf81d2611b488b85794f84625d09942c5ae1e34 on wilsonge:problem_exceptions into 80dd8ea10655e9a661c451568e9bbca071a5577f on zalando:master.

Coverage remained the same at 100.0% when pulling 437386d9e950b792956402980ed3e7f84feef808 on wilsonge:problem_exceptions into 80dd8ea10655e9a661c451568e9bbca071a5577f on zalando:master.

Coverage remained the same at 100.0% when pulling 1f04b919c504935067b9773bd1ca388cde6be738 on wilsonge:problem_exceptions into 80dd8ea10655e9a661c451568e9bbca071a5577f on zalando:master.

Coverage remained the same at 100.0% when pulling 928c800aadf9adb3d10d033d0e83b3fa795f75c3 on wilsonge:problem_exceptions into 80dd8ea10655e9a661c451568e9bbca071a5577f on zalando:master.

OK I think this is ready for review again :)

Coverage remained the same at 100.0% when pulling 7a6d8edb61994cb3fa81364f6c7f3ad99293356b on wilsonge:problem_exceptions into 80dd8ea10655e9a661c451568e9bbca071a5577f on zalando:master.

@wilsonge Could you please remove this import:
connexion/app.py:8:1: F401 'connexion.exceptions.ProblemException' imported but unused

Done :)

Coverage remained the same at 100.0% when pulling b7b6c253ae90e183f8a8e25971e72162da6d3834 on wilsonge:problem_exceptions into 80dd8ea10655e9a661c451568e9bbca071a5577f on zalando:master.

👍

@wilsonge Thank you for working on this! 😃

Thank you for all the feedback  🙇

authors: coveralls rafaelcaricio wilsonge


text:
Project Headache

Please don't merge yet. Let's merge this branch until all related refactoring is done and tested.

Coverage increased (+0.2%) to 92.643% when pulling b77b6ce4e832cee0ae6cc8d5b353d478270fd776 on headache into cf2ae7b08fbb6155d2c14d304f1c7d6dcbefc0fc on master.

@gbordyugov you can still review it in the history of merge pull request, but I am afraid its too big to review anyways. Maybe checkout the code directly is easier.
I am gonna merge it now, without releasing. So we can still discuss when you're back.

authors: coveralls shansfolder

repo: zalando/expan


text:
Add javax activation as a dependency to logbook-servlet

Potential fix for issue #423

Thanks for your contribution! :tada:
I released this as 1.13.0 to central just now.

authors: acet whiskeysierra

repo: zalando/logbook


text:
Provide a fix for the module importer, deprecated find_module in Python 3.12

Description
Deprecated find_module in Python 3.12, triggered when executing pre or post build scripts.
This PR fixes the issue
Ref: #1291, #1292

Superseded by #1320

repo: zappa/Zappa


text:
call to exit() in desock.c::accept()

When trying to use redis with desock I ran into an issue where redis would exit right after it receives any input in STDIN, using gdb I found out that this is due to the exit(0) call in desock.c::accept(). Now, when I comment out line 216 and 217 everything works as expected.
I see that this was added with this commit, any reason why redis behaves this way?

I think it's to handle the following case:
while (1)
{
    int fd = accept();
    int pid = fork();
    if (pid) { close(fd); wait(pid); }
    else { handle_request(fd); }
}

If we desock the program, we probably want to only handle one request (at least, this has been my use-case so far), hence the exit on the second accept.
I'm all for having that controlled by an environment variable, though!

That use case makes a lot of sense. However, I imagine a lot of people (myself included) are using this on servers that offload the request to a thread pool or use nonblocking I/O to accept a large number of concurrent connections. I'm using desock on nginx, and it exits before the first request can be serviced.
Should this be the default behavior? Wouldn't it be better to have an optional env var to enable this on applications that only service one request at a time?

My commit dd96c133f6651380e6204f01c70d36d51af7e73a moves the exit call from accept to close/shutdown, so this should fix the issue.

authors: hillu reberhardt7 suyashmahar zardus

repo: zardus/preeny


text:
Question: How does the field 'validator' function works?

If you can put an example it will be highly appreciated.
I looked at the source code and test it but no luck!

I got it to work like this :
Creating a FormGroup with the field query :
this.form = this.fb.group({
    query: [{ condition: 'or', rules: [] }],
});

Using the query builder like this in my template :
<query-builder formControlName="query" [config]='this.config' (change)="onChange($event)">
(...)
</query-builder>

Using this config :
config: QueryBuilderConfig = {
    fields: {
        Status: {
            name: 'Status', type: 'number', validator: (r, p) => {
                if (r.value > 4)
                    return "Value cannot be greater than 4";
            }
        },
    },
};

Updating the validator with the onchange event :
onChange($event) {
    Object.keys(this.form.controls).forEach(k => {
        this.form.controls[k].updateValueAndValidity();
    });
}

Then when you submit your form, just check if it's valid :
if (this.form.valid) {
// ...
}

repo: zebzhao/Angular-QueryBuilder


text:
Erlang support

Check for existing issues

[X] Completed

Language
Erlang
Tree Sitter parser link
https://github.com/WhatsApp/tree-sitter-erlang
Language server link
https://github.com/erlang-ls/erlang_ls
Misc notes
No response

+1 this would be great

There's also whatsapp/erlang-language-platform that might make it easier to integrate into testing.

authors: codeadict eproxus samgaw

repo: zed-industries/community


text:
ruff-lsp

Check for existing issues

[X] Completed

Describe the feature
Is ruff-lsp supported for python in zed. If supported, can I find out an example of the settings?
If not supported, are there plans to add ruff-lsp support?
If applicable, add mockups / screenshots to help present your vision of the feature
No response

It is not supported at the moment, but we are currently working on adding in language server extensibility, so someone could make a package for this after that feature lands.

authors: JosephTLyons stalexsm


text:
When Module is active, scenes can't be saved

When the module is enabled, it's not possible to change or create a new scene, since the "save" button loses its function. You can click it once, nothing will happen. after that there's nothing you can do except close the window and deactivate the module to start anew.

I got the same problem with FoundryVTT 11.315 and DnD5e 3.1.2
There is the following console error:
 invalid form control with name='' is not focusable. <input type="number" class="range-editor" value="999" min="0.1" max="3" step="0.1">

If you change to the Pin Fixer Tab inside the Configure Scene dialog, the default value of Zoom Ceiling is set to 999. You have to set a value between 0.1 and 3 to be able to save the scene settings.

authors: marcstraube zarazandra


text:
RPM Dependencies missing

[x] I am on the latest Hyper.app version
[x] I have searched the issues of this repo and believe that this is not a duplicate

OS version and name: Fedora Rawhide
Hyper.app version: <1.1.3>
Link of a Gist with the contents of your .hyper.js: Not Applicable
Relevant information from devtools (CMD+ALT+I on Mac OS, CTRL+SHIFT+I elsewhere): Not Applicable
The issue is reproducible in vanilla Hyper.app: Yes

Issue
The hyper rpm file has a missing dependency. Hyper looks for NPM on startup however it is not listed as a requirement under your RPM spec. Adding that dependency to the specfile should flag package managers to install npm along with hyper.

Hey there, please try again with the new Hyper v2 release and open a new issue if the problem stills exists. Thank you!

authors: Stanzilla grturner

repo: zeit/hyper


text:
next seems to break text-size-adjust css property

[x] I believe that this is not a duplicate.

Expected Behavior
The text-size-adjust property is part of many css reset (including normalize, check out the first selector https://necolas.github.io/normalize.css/7.0.0/normalize.css). its goal is to prevent browsers from inflating or deflating text in weird ways when the site is viewed on mobile.
This is how it should behave: https://media.giphy.com/media/3oKIPz6jOMmO3tQkqk/giphy.gif
Current Behavior
And this is how it behaves when used with next.js https://media.giphy.com/media/l4FGBK6OrUm10Xd5e/giphy.gif
Steps to Reproduce (for bugs)

Setup a new next.js project
add normalize (just paste it in a style tag)
add some text (full page length for best results)
use chrome dev tools responsive tool.

Your Environment

next 3.0.1-beta.9
node 8.1.3
ubuntu 64
chrome 60.0

May be that's because we are rendering the app inside a div.
Anyway, we don't ship any CSS with Next.js.

(sorry for the close, wrong button on mobile phone)
I know we don't ship any css with next, what bothers me is that this css rule works with the official cra and nwb, it's only in next that the problem exist.
I'm going to investigate this, the issue is to keep track of the bug publicly

@quentin-sommer weird, sounds like something no related to Next.js.
Could you deploy your example with now to explore the same project?

Do you have <meta name="viewport" content="width=device-width, initial-scale=1"> in the head?

^ you nailed it @stevebluck

Nice 😄

authors: arunoda elrumordelaluz quentin-sommer stevebluck timneutkens


text:
React attempted to reuse markup in a container but the checksum was invalid

I have this error while trying to use Next with redux and redux saga.
We use it exactly the same way as the example 'with-redux-saga', and we dispatch an action that triggers a saga in the getInitialProps function:
static async getInitialProps ({ query, store, isServer }) {
    store.dispatch(ProductsActions.getCategories())
}

When I query the page, it is rendered with the categories displayed, then they disappear and this error is printed in the console...
It all works good when I get the categories through an async await and return them in the props.
More specifically the error reads:
(client)  data-reactid="26">

<li style="flex-grow:

So if I guess correctly the client expects an empty ul meaning NO categories and the server renders the list of categories
Versions:

nextjs: 3.2.2
next-redux-saga: 1.0.1
next-redux-wrapper: 1.3.4
react: 15.6.1
react-redux: 5.0.6
redux: 3.7.2
redux-sagas: 0.15.6

Is the store in the client the same of the server ? if that's the case you should use a store per request in the server and a single store in the client instead. And if you're using a different store for the client then the dispatch doesn't work as it's going to happen only server side

authors: Goluis tomexa


text:
Rename unstable GSP field

As discussed this renames the revalidate GSP field to unstable_revalidate while it's still experimental

Stats from current PR

Default Server Mode

General Overall increase ⚠

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

buildDuration
10.4s
10.6s
⚠ +217ms

nodeModulesSize
47.7 MB
47.7 MB
⚠ +1.1 kB

Client Bundles (main, webpack, commons)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.js gzip
6.25 kB
6.25 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5272.js gzip
10.2 kB
10.2 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
56.3 kB
56.3 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.module.js gzip
4.78 kB
4.78 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.75 kB
6.75 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
51.4 kB
51.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.js gzip
1.24 kB
1.24 kB
✓

_error.js gzip
3.15 kB
3.15 kB
✓

hooks.js gzip
664 B
664 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.03 kB
2.03 kB
✓

routerDirect.js gzip
279 B
279 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
7.86 kB
7.86 kB
✓

Client Pages Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.module.js gzip
594 B
594 B
✓

_error.module.js gzip
2.08 kB
2.08 kB
✓

hooks.module.js gzip
370 B
370 B
✓

index.module.js gzip
212 B
212 B
✓

link.module.js gzip
1.48 kB
1.48 kB
✓

routerDirect..dule.js gzip
271 B
271 B
✓

withRouter.m..dule.js gzip
270 B
270 B
✓

Overall change
5.28 kB
5.28 kB
✓

Client Build Manifests

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Rendered Page Sizes

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

index.html gzip
917 B
917 B
✓

link.html gzip
926 B
926 B
✓

withRouter.html gzip
915 B
915 B
✓

Overall change
2.76 kB
2.76 kB
✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

buildDuration
11.1s
10.9s
-179ms

nodeModulesSize
47.7 MB
47.7 MB
⚠ +1.1 kB

Client Bundles (main, webpack, commons)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.js gzip
6.25 kB
6.25 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5272.js gzip
10.2 kB
10.2 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
56.3 kB
56.3 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.module.js gzip
4.78 kB
4.78 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.75 kB
6.75 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
51.4 kB
51.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.js gzip
1.24 kB
1.24 kB
✓

_error.js gzip
3.15 kB
3.15 kB
✓

hooks.js gzip
664 B
664 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.03 kB
2.03 kB
✓

routerDirect.js gzip
279 B
279 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
7.86 kB
7.86 kB
✓

Client Pages Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.module.js gzip
594 B
594 B
✓

_error.module.js gzip
2.08 kB
2.08 kB
✓

hooks.module.js gzip
370 B
370 B
✓

index.module.js gzip
212 B
212 B
✓

link.module.js gzip
1.48 kB
1.48 kB
✓

routerDirect..dule.js gzip
271 B
271 B
✓

withRouter.m..dule.js gzip
270 B
270 B
✓

Overall change
5.28 kB
5.28 kB
✓

Client Build Manifests

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Serverless bundles Overall increase ⚠

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_error.js gzip
232 kB
233 kB
⚠ +109 B

404.html gzip
1.32 kB
1.32 kB
✓

hooks.html gzip
956 B
956 B
✓

index.js gzip
232 kB
233 kB
⚠ +362 B

link.js gzip
243 kB
243 kB
-56 B

routerDirect.js gzip
241 kB
241 kB
⚠ +159 B

withRouter.js gzip
241 kB
241 kB
⚠ +142 B

Overall change
1.19 MB
1.19 MB
⚠ +716 B

Stats from current PR

Default Server Mode

General Overall increase ⚠

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

buildDuration
10.3s
10.1s
-205ms

nodeModulesSize
47.7 MB
47.7 MB
⚠ +1.43 kB

Client Bundles (main, webpack, commons)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.js gzip
6.25 kB
6.25 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5272.js gzip
10.2 kB
10.2 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
56.3 kB
56.3 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.module.js gzip
4.78 kB
4.78 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.75 kB
6.75 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
51.4 kB
51.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.js gzip
1.24 kB
1.24 kB
✓

_error.js gzip
3.15 kB
3.15 kB
✓

hooks.js gzip
664 B
664 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.03 kB
2.03 kB
✓

routerDirect.js gzip
279 B
279 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
7.86 kB
7.86 kB
✓

Client Pages Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.module.js gzip
594 B
594 B
✓

_error.module.js gzip
2.08 kB
2.08 kB
✓

hooks.module.js gzip
370 B
370 B
✓

index.module.js gzip
212 B
212 B
✓

link.module.js gzip
1.48 kB
1.48 kB
✓

routerDirect..dule.js gzip
271 B
271 B
✓

withRouter.m..dule.js gzip
270 B
270 B
✓

Overall change
5.28 kB
5.28 kB
✓

Client Build Manifests

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Rendered Page Sizes

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

index.html gzip
917 B
917 B
✓

link.html gzip
926 B
926 B
✓

withRouter.html gzip
915 B
915 B
✓

Overall change
2.76 kB
2.76 kB
✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

buildDuration
10.9s
11.3s
⚠ +422ms

nodeModulesSize
47.7 MB
47.7 MB
⚠ +1.43 kB

Client Bundles (main, webpack, commons)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.js gzip
6.25 kB
6.25 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5272.js gzip
10.2 kB
10.2 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
56.3 kB
56.3 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.module.js gzip
4.78 kB
4.78 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.75 kB
6.75 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
51.4 kB
51.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.js gzip
1.24 kB
1.24 kB
✓

_error.js gzip
3.15 kB
3.15 kB
✓

hooks.js gzip
664 B
664 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.03 kB
2.03 kB
✓

routerDirect.js gzip
279 B
279 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
7.86 kB
7.86 kB
✓

Client Pages Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.module.js gzip
594 B
594 B
✓

_error.module.js gzip
2.08 kB
2.08 kB
✓

hooks.module.js gzip
370 B
370 B
✓

index.module.js gzip
212 B
212 B
✓

link.module.js gzip
1.48 kB
1.48 kB
✓

routerDirect..dule.js gzip
271 B
271 B
✓

withRouter.m..dule.js gzip
270 B
270 B
✓

Overall change
5.28 kB
5.28 kB
✓

Client Build Manifests

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Serverless bundles Overall increase ⚠

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_error.js gzip
233 kB
233 kB
⚠ +14 B

404.html gzip
1.32 kB
1.32 kB
✓

hooks.html gzip
956 B
956 B
✓

index.js gzip
233 kB
233 kB
⚠ +161 B

link.js gzip
243 kB
243 kB
⚠ +295 B

routerDirect.js gzip
241 kB
241 kB
⚠ +174 B

withRouter.js gzip
241 kB
241 kB
⚠ +59 B

Overall change
1.19 MB
1.19 MB
⚠ +703 B

Stats from current PR

Default Server Mode

General Overall increase ⚠

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

buildDuration
9.7s
9.8s
⚠ +83ms

nodeModulesSize
47.7 MB
47.7 MB
⚠ +1.32 kB

Client Bundles (main, webpack, commons)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.js gzip
6.25 kB
6.25 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5272.js gzip
10.2 kB
10.2 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
56.3 kB
56.3 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.module.js gzip
4.78 kB
4.78 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.75 kB
6.75 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
51.4 kB
51.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.js gzip
1.24 kB
1.24 kB
✓

_error.js gzip
3.15 kB
3.15 kB
✓

hooks.js gzip
664 B
664 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.03 kB
2.03 kB
✓

routerDirect.js gzip
279 B
279 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
7.86 kB
7.86 kB
✓

Client Pages Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.module.js gzip
594 B
594 B
✓

_error.module.js gzip
2.08 kB
2.08 kB
✓

hooks.module.js gzip
370 B
370 B
✓

index.module.js gzip
212 B
212 B
✓

link.module.js gzip
1.48 kB
1.48 kB
✓

routerDirect..dule.js gzip
271 B
271 B
✓

withRouter.m..dule.js gzip
270 B
270 B
✓

Overall change
5.28 kB
5.28 kB
✓

Client Build Manifests

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Rendered Page Sizes

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

index.html gzip
917 B
917 B
✓

link.html gzip
926 B
926 B
✓

withRouter.html gzip
915 B
915 B
✓

Overall change
2.76 kB
2.76 kB
✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

buildDuration
10.2s
10s
-148ms

nodeModulesSize
47.7 MB
47.7 MB
⚠ +1.32 kB

Client Bundles (main, webpack, commons)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.js gzip
6.25 kB
6.25 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5272.js gzip
10.2 kB
10.2 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
56.3 kB
56.3 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.module.js gzip
4.78 kB
4.78 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.75 kB
6.75 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
51.4 kB
51.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.js gzip
1.24 kB
1.24 kB
✓

_error.js gzip
3.15 kB
3.15 kB
✓

hooks.js gzip
664 B
664 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.03 kB
2.03 kB
✓

routerDirect.js gzip
279 B
279 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
7.86 kB
7.86 kB
✓

Client Pages Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.module.js gzip
594 B
594 B
✓

_error.module.js gzip
2.08 kB
2.08 kB
✓

hooks.module.js gzip
370 B
370 B
✓

index.module.js gzip
212 B
212 B
✓

link.module.js gzip
1.48 kB
1.48 kB
✓

routerDirect..dule.js gzip
271 B
271 B
✓

withRouter.m..dule.js gzip
270 B
270 B
✓

Overall change
5.28 kB
5.28 kB
✓

Client Build Manifests

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Serverless bundles Overall increase ⚠

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_error.js gzip
233 kB
232 kB
-172 B

404.html gzip
1.32 kB
1.32 kB
✓

hooks.html gzip
956 B
956 B
✓

index.js gzip
233 kB
233 kB
⚠ +231 B

link.js gzip
243 kB
243 kB
⚠ +192 B

routerDirect.js gzip
240 kB
241 kB
⚠ +545 B

withRouter.js gzip
241 kB
241 kB
⚠ +170 B

Overall change
1.19 MB
1.19 MB
⚠ +966 B

Stats from current PR

Default Server Mode

General Overall increase ⚠

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

buildDuration
9.8s
10s
⚠ +263ms

nodeModulesSize
47.7 MB
47.7 MB
⚠ +1.32 kB

Client Bundles (main, webpack, commons)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.js gzip
6.25 kB
6.25 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5272.js gzip
10.2 kB
10.2 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
56.3 kB
56.3 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.module.js gzip
4.78 kB
4.78 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.75 kB
6.75 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
51.4 kB
51.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.js gzip
1.24 kB
1.24 kB
✓

_error.js gzip
3.15 kB
3.15 kB
✓

hooks.js gzip
664 B
664 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.03 kB
2.03 kB
✓

routerDirect.js gzip
279 B
279 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
7.86 kB
7.86 kB
✓

Client Pages Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.module.js gzip
594 B
594 B
✓

_error.module.js gzip
2.08 kB
2.08 kB
✓

hooks.module.js gzip
370 B
370 B
✓

index.module.js gzip
212 B
212 B
✓

link.module.js gzip
1.48 kB
1.48 kB
✓

routerDirect..dule.js gzip
271 B
271 B
✓

withRouter.m..dule.js gzip
270 B
270 B
✓

Overall change
5.28 kB
5.28 kB
✓

Client Build Manifests

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Rendered Page Sizes

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

index.html gzip
917 B
917 B
✓

link.html gzip
926 B
926 B
✓

withRouter.html gzip
915 B
915 B
✓

Overall change
2.76 kB
2.76 kB
✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

buildDuration
10.4s
10.4s
-39ms

nodeModulesSize
47.7 MB
47.7 MB
⚠ +1.32 kB

Client Bundles (main, webpack, commons)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.js gzip
6.25 kB
6.25 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

de003c3a9d30..5272.js gzip
10.2 kB
10.2 kB
✓

framework.HASH.js gzip
39.1 kB
39.1 kB
✓

Overall change
56.3 kB
56.3 kB
✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

main-HASH.module.js gzip
4.78 kB
4.78 kB
✓

webpack-HASH..dule.js gzip
746 B
746 B
✓

de003c3a9d30..dule.js gzip
6.75 kB
6.75 kB
✓

framework.HA..dule.js gzip
39.1 kB
39.1 kB
✓

Overall change
51.4 kB
51.4 kB
✓

Legacy Client Bundles (polyfills)

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

polyfills-HASH.js gzip
26.3 kB
26.3 kB
✓

Overall change
26.3 kB
26.3 kB
✓

Client Pages

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.js gzip
1.24 kB
1.24 kB
✓

_error.js gzip
3.15 kB
3.15 kB
✓

hooks.js gzip
664 B
664 B
✓

index.js gzip
222 B
222 B
✓

link.js gzip
2.03 kB
2.03 kB
✓

routerDirect.js gzip
279 B
279 B
✓

withRouter.js gzip
278 B
278 B
✓

Overall change
7.86 kB
7.86 kB
✓

Client Pages Modern

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_app.module.js gzip
594 B
594 B
✓

_error.module.js gzip
2.08 kB
2.08 kB
✓

hooks.module.js gzip
370 B
370 B
✓

index.module.js gzip
212 B
212 B
✓

link.module.js gzip
1.48 kB
1.48 kB
✓

routerDirect..dule.js gzip
271 B
271 B
✓

withRouter.m..dule.js gzip
270 B
270 B
✓

Overall change
5.28 kB
5.28 kB
✓

Client Build Manifests

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_buildManifest.js gzip
61 B
61 B
✓

_buildManife..dule.js gzip
61 B
61 B
✓

Overall change
122 B
122 B
✓

Serverless bundles Overall increase ⚠

zeit/next.js canary
ijjk/next.js add/NEXT-160
Change

_error.js gzip
232 kB
232 kB
-69 B

404.html gzip
1.32 kB
1.32 kB
✓

hooks.html gzip
956 B
956 B
✓

index.js gzip
232 kB
233 kB
⚠ +659 B

link.js gzip
243 kB
243 kB
⚠ +258 B

routerDirect.js gzip
240 kB
241 kB
⚠ +493 B

withRouter.js gzip
241 kB
241 kB
⚠ +1 B

Overall change
1.19 MB
1.19 MB
⚠ +1.34 kB


text:
'yarn add json2csv' installs 3.9.1

Include the command or code you used.

yarn add json2csv

or

yarn add json2csv@3.9.0 -E

Include your output/error.
Yarn installed package.json in node_modules
{
  "name": "json2csv",
  "preferGlobal": "true",
  "version": "3.9.1",
  "description": "Convert JSON to CSV",
  "keywords": [
    "json",
    "to",
    "csv",
    "export",
    "convert",
    "parse"
  ],
  "author": {
    "name": "Mirco Zeiss",
    "email": "mirco.zeiss@gmail.com",
    "twitter": "zeMirco"
  },
  "license": "MIT",
  "bin": {
    "json2csv": "./bin/json2csv.js"
  },
  "main": "./lib/json2csv.js",
  "repository": {
    "type": "git",
    "url": "https://github.com/zemirco/json2csv"
  },
  "scripts": {
    "build": "webpack",
    "test": "node test | tap-spec",
    "test-coverage": "istanbul cover test/index.js --report lcovonly | tap-spec",
    "deploy:docs": "docpress b && git-update-ghpages zemirco/json2csv _docpress",
    "prepublish": "in-publish && npm run before:publish || not-in-publish",
    "before:publish": "npm test && npm run build && npm run deploy:docs && npm run release",
    "release": "standard-version"
  },
  "dependencies": {
    "cli-table": "^0.3.1",
    "commander": "^2.8.1",
    "debug": "^2.2.0",
    "flat": "^2.0.0",
    "lodash.flatten": "^4.4.0",
    "lodash.get": "^4.4.0",
    "lodash.set": "^4.3.0",
    "lodash.uniq": "^4.5.0",
    "lodash.clonedeep": "^4.5.0",
    "path-is-absolute": "^1.0.0"
  },
  "devDependencies": {
    "async": "^2.0.1",
    "docpress": "^0.7.0",
    "eslint": "^3.3.1",
    "git-update-ghpages": "^1.3.0",
    "in-publish": "^2.0.0",
    "istanbul": "^0.4.3",
    "standard-version": "^4.0.0",
    "tap-spec": "^4.1.0",
    "tape": "^4.0.0",
    "webpack": "^1.13.1"
  }
}

NPM installed package.json in node_modules
{
  "_args": [
    [
      {
        "raw": "json2csv@3.9.0",
        "scope": null,
        "escapedName": "json2csv",
        "name": "json2csv",
        "rawSpec": "3.9.0",
        "spec": "3.9.0",
        "type": "version"
      },
      "/Users/Seth/Sandbox/blackbird"
    ]
  ],
  "_from": "json2csv@3.9.0",
  "_id": "json2csv@3.9.0",
  "_inCache": true,
  "_location": "/json2csv",
  "_nodeVersion": "6.9.4",
  "_npmOperationalInternal": {
    "host": "s3://npm-registry-packages",
    "tmp": "tmp/json2csv-3.9.0.tgz_1499777296364_0.43090387410484254"
  },
  "_npmUser": {
    "name": "knownasilya",
    "email": "ilya@burstcreations.com"
  },
  "_npmVersion": "4.6.1",
  "_phantomChildren": {},
  "_requested": {
    "raw": "json2csv@3.9.0",
    "scope": null,
    "escapedName": "json2csv",
    "name": "json2csv",
    "rawSpec": "3.9.0",
    "spec": "3.9.0",
    "type": "version"
  },
  "_requiredBy": [
    "#USER",
    "/"
  ],
  "_resolved": "https://registry.npmjs.org/json2csv/-/json2csv-3.9.0.tgz",
  "_shasum": "4cd460f31b47817e1732268e21082fc37b1483da",
  "_shrinkwrap": null,
  "_spec": "json2csv@3.9.0",
  "_where": "/Users/Seth/Sandbox/blackbird",
  "author": {
    "name": "Mirco Zeiss",
    "email": "mirco.zeiss@gmail.com"
  },
  "bin": {
    "json2csv": "./bin/json2csv.js"
  },
  "bugs": {
    "url": "https://github.com/zemirco/json2csv/issues"
  },
  "dependencies": {
    "cli-table": "^0.3.1",
    "commander": "^2.8.1",
    "debug": "^2.2.0",
    "flat": "^2.0.0",
    "lodash.clonedeep": "^4.5.0",
    "lodash.flatten": "^4.4.0",
    "lodash.get": "^4.4.0",
    "lodash.set": "^4.3.0",
    "lodash.uniq": "^4.5.0",
    "path-is-absolute": "^1.0.0"
  },
  "description": "Convert JSON to CSV",
  "devDependencies": {
    "async": "^2.0.1",
    "docpress": "^0.7.0",
    "eslint": "^3.3.1",
    "git-update-ghpages": "^1.3.0",
    "in-publish": "^2.0.0",
    "istanbul": "^0.4.3",
    "standard-version": "^4.0.0",
    "tap-spec": "^4.1.0",
    "tape": "^4.0.0",
    "webpack": "^1.13.1"
  },
  "directories": {},
  "dist": {
    "shasum": "4cd460f31b47817e1732268e21082fc37b1483da",
    "tarball": "https://registry.npmjs.org/json2csv/-/json2csv-3.9.0.tgz"
  },
  "gitHead": "cff9da79ef5a77deaf736555b59ad82b73a1dbbe",
  "homepage": "https://github.com/zemirco/json2csv#readme",
  "keywords": [
    "json",
    "to",
    "csv",
    "export",
    "convert",
    "parse"
  ],
  "license": "MIT",
  "main": "./lib/json2csv.js",
  "maintainers": [
    {
      "name": "azhang",
      "email": "azhang@bottlenose.com"
    },
    {
      "name": "knownasilya",
      "email": "ilya@burstcreations.com"
    },
    {
      "name": "zemirco",
      "email": "mirco.zeiss@gmail.com"
    }
  ],
  "name": "json2csv",
  "optionalDependencies": {},
  "preferGlobal": "true",
  "readme": "ERROR: No README data found!",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/zemirco/json2csv.git"
  },
  "scripts": {
    "before:publish": "npm test && npm run build && npm run deploy:docs && npm run release",
    "build": "webpack",
    "deploy:docs": "docpress b && git-update-ghpages zemirco/json2csv _docpress",
    "prepublish": "in-publish && npm run before:publish || not-in-publish",
    "release": "standard-version",
    "test": "node test | tap-spec",
    "test-coverage": "istanbul cover test/index.js --report lcovonly | tap-spec"
  },
  "version": "3.9.0"
}

Sounds like a big in yarn..

I posted the issue to Yarn https://github.com/yarnpkg/yarn/issues/3935 and they pointed out that the package in Yarn actually references 3.9.1 in the published package.json.
I'm not sure how Yarn got that, whether it was a bug in them grabbing the NPM package, or with this package being published to Yarn having that reference.
I'd like to help resolve if I can, though I'm not sure what I can do, other raise the issue as I have done here and with Yarn.

Looks like something happened in the prepublish script, and npm didn't catch it as a bug. I published an actual 3.9.1.

authors: knownasilya smcguinness


text:
Bug: Additional connection pool is made when primary DB has no slave

When the DB is configured without a slave in particular environment the connection name for non-sharded DB should be resolved as "primary" but not Rails.env.
The condition in this return doesn't cover the use case when slave is not configured for the environment:
https://github.com/zendesk/active_record_shards/blob/master/lib/active_record_shards/shard_selection.rb#L54

Fixed by #185.

authors: bogdan bquorning


text:
Instrument create_time from last message in batch

Why?
My team at GitHub uses racecar version 1.0.1 and by extension ruby-kafka. We're interested in the potential of racecar 2 that uses the rdkafka-ruby client but we heavily rely on the consumer.offset_lag metric for monitoring our stream processors.
It doesn't look like that metric is going to be straightforward to implement in racecar 2 but I'm wondering if we could instead switch to the consumer.time_lag metric instead? Unfortunately that metric isn't published in the process_batch.consumer payload in racecar 1.0.1 or racecar 2.0.0-beta.
How?
This PR updates the process_batch.consumer payload to include a last_create_time metric which comes from the last message in the batch.
We could use a fork of ruby-kafka with these changes to accomplish our goal with racecar 1.0.1 in the short term but I thought others may benefit as well so I'm opening this PR.
I'm also hoping to open a PR against racecar 2 to add the same metric to the process_batch payload so we can easily transition from racecar 1.0.1 with ruby-kafka to racecar 2.0.0 with rdkafka-ruby.
Thank you for your consideration.

The failing specs should all pass once #810 ships and I update this PR to include it.

Can you rebase on master?

Thanks!

authors: dasch jonmagic

repo: zendesk/ruby-kafka


text:
Added Swoole config, if installed

This PR adds the support of Swoole overwriting some service configurations of zend-expressive.
The configuration is injected via Zend\Expressive\Swoole\ConfigProvider if zend-expressive-swoole is installed.
This PR allows to execute Swoole without any change on public/index.php. We can just run the follows:
php public/index.php

To execute an Expressive application with Swoole.

@xtreamwayz you right, I fixed it. I didn't test without zend-expressive-swoole installed, thanks!

To fix the Travis build you can append this to phpstan.installer.neon:
parameters:
    ignoreErrors:
        - '#Class Zend\\Expressive\\Swoole\\ConfigProvider not found#'

@xtreamwayz thanks!

authors: ezimuel xtreamwayz

repo: zendframework/zend-expressive-skeleton


text:
New coding standard

Usage of the newly introduced zendframework/zend-coding-standard for CS checks.

Merged to develop for release with 2.6.0 via #37.

authors: Koopzington weierophinney


text:
Simplify example for zend.session.manager

The current example is very complex:
http://zf2.readthedocs.org/en/latest/modules/zend.session.manager.html#initializing-the-session-manager
IMO the SessionManagerFactory provided by ZF2 would take care of most of this boilerplate.
An example of how I approach configuring the SessionManager in my projects: https://github.com/ZF-Commons/ZfcUser/issues/274#issuecomment-69925345.  In that example, we could pass configuration options (eg: validator list) to the SessionManager factory via the session_manager config key.

SessionManagerFactory is indeed easier to use, however there is a problem with adding validators via config at this moment: https://github.com/zendframework/zf2/pull/7128

The Issue seems to be fixed, so the example could be simplified now

authors: Martin-P adamlundrigan xelax90


text:
bugfix - object mapper upgrade

Fix minor changes from Object-Mapper.

Fix #10
Fix #11

:+1: There are no linter violations.

repo: zendobk/RealmMapper


text:
Error when including optional relation when a polymorphic relation is present

Description and expected behavior
Hello, running into an error when trying to include a model in a findMany that is optional. I will layout the simplest setup I can that reproduced the error for me:
schema.zmodel:
generator client {
    provider = "prisma-client-js"
}

datasource db {
    provider = "postgresql"
    url      = env("DATABASE_URL")
}

model User {
    @@auth
    id    String @id
    edits Edit[]
    @@allow('all', true)
}

model Entity {

    id    String @id @default(cuid())
    name  String
    edits Edit[]

    type  String
    @@delegate(type)

    @@allow('all', true)
}

model Person extends Entity {
}

model Edit {
    id       String  @id @default(cuid())

    authorId String?
    author   User?   @relation(fields: [authorId], references: [id], onDelete: Cascade, onUpdate: NoAction)

    entityId String
    entity   Entity  @relation(fields: [entityId], references: [id], onDelete: Cascade, onUpdate: NoAction)

    @@allow('all', true)
}

As you can see the authorId (and relation User) is optional. When attempting to make a query that includes this model I run into the following error:
TypeError: Object.entries requires that input parameter not be null or undefined

Here is some test code with the above the will throw the error:
import { enhance } from "@zenstackhq/runtime";
import { db } from "~/server/db";

const zen = enhance(db);

await zen.edit.deleteMany({});
await zen.person.deleteMany({});
await zen.user.deleteMany({});

const person = await zen.person.create({
	data: {
		name: "test",
	},
});

await zen.edit.create({
	data: {
		entityId: person.id,
	},
});

// THROWS ERROR HERE
const all = await zen.edit.findMany({
	include: {
		author: true,
	},
});

Oddly enough this does not happen if the model does not have a relation on it that is polymorphic, so if I remove the Entity relation from Edit or replace it with a regular (non-polymorphic) model, then the error doesnt happen!
It will also not happen if the author is specified when the row is created but that might be less surprising.
Thanks!
Environment (please complete the following information):

ZenStack version: 2.1.2
Prisma version: 5.13
Database type: postgres

Additional context
Add any other context about the problem here.

Thank you for the detailed repro steps @kwerdna19 ! I'll look into it and make a fix soon.

Fixed in v2.2.0

repo: zenstackhq/zenstack


text:
DatatableModel implemented class cannot extend CI_model

If I extend CI_model and implement DatatableModel all the methods that are not directly linked with datatableModel don't work.
In short, loading page goes in escape with a 500 error.
If i take out the implements clause the page suddenly works. Why is that?

My guess is that you don't have all of the methods from the DatatableModel implemented.  You have to provide a default implementation even if you are not using the method.
At a minimum, the only method that cannot return a NULL is fromTableStr().  This is what a very basic implementation would look like
    class store_dt extends CI_Model implements DatatableModel{

		/**
		 * @ return
		 * 		Expressions / Columns to append to the select created by the Datatable library
		 */
		public function appendToSelectStr() {
				return NULL;
		}

		public function fromTableStr() {
			return 'MyTable';
		}

	    /**
	     * @return
	     *     Associative array of joins.  Return NULL or empty array  when not joining
	     */
	    public function joinArray(){
	    	return NULL;
	    }

    /**
     *
     *@return
     *  Static where clause to be appended to all search queries.  Return NULL or empty array
     * when not filtering by additional criteria
     */
    	public function whereClauseArray(){
    		return NULL;
    	}
   }

Let me know if that solves the problem.

Have not heard back in over 2 weeks and this was not a bug.

Actually We fixed the problem. The interface was not being loaded for some strange reason. That is, if you use both extend CI_Model and implements Datablae, for some strange reason, the datable inteface will not be loaded. If you put the following code befora declaring:
get_instance()->load->iface('Datatable');

Then in MY_Loader you need to implement iface:
   public function iface($name){
       require_once APPPATH.'libraries/'.$name.'.php';
   }

Then bothe the extends and the implements will finally works.
Cheers,
Salvo and Giovanni

Hi Salvo and Giovanni,
Thank you for getting back.  I would like to look into this further, but I have not seen this same issue occur.  Are yoy using HMVC?

Yes we are, Our controllers extend a MY_Core controller which then extends teh CI_CONTROLLER, but our models extend directly CI_Model. The problems lies in the fact that this model has to extend  CI_Model and implemente Datatable. Now, some controllers use the regular methods, while other controllers access the same model through the Datatable interface. By extending the interface, the regular methods that have nothing do with the datatable methods do not work anymore. It is very strange indeed.

Here is an example code:

get_instance()->load->iface('Datatable');

class Gara_model extends CI_Model implements DatatableModel {

    public function elimina_gara($id_gara) {
       ....
    }

    public function elimina_elabora_gara($id) {
        ...
    }

    public function getGareElaborabili() {
	....
    }

//*******************************************************************************************************

    public function appendToSelectStr() {
        return array(
			...
        );
    }

    public function fromTableStr() {
        return 'elabora_gara e';
    }

    public function joinArray() {
        return array(
			....
			);
    }

    public function whereClauseArray() {

        return null;
    }

	/*I also implemented this for personal use*/
    public function likeClauseArray() {
        $params = array(
          ....
        );

        return $params;
    }

}

All the methods above the asterics will not work if the interface is not loaded.

Hi... you said...
Then in MY_Loader you need to implement iface:
public function iface($name){
require_once APPPATH.'libraries/'.$name.'.php';
}
Where in this MY_Loader....?
Im a beginer to Codeigniter.
so please help?

repo: zepernick/Codeigniter-DataTables


text:
display config values when hovering over luya version

When hovering over the luya version in the admin module we should display informations:

YII_DEBUG
YII_ENV
errorHandler: $transferException
$config id
timezone
registered components
registered assets

add styles to debug toolbar, like useronline.

https://github.com/zephir/luya/commit/6215cf5081ef9832bcaa42d4b627dc871cb161eb

authors: hwernze nadar

repo: zephir/luya


text:
cmake: add config option to enable reference device

Add the config option to enable Thread Certification reference device support.

Codecov Report

Merging #14 into zephyr will decrease coverage by 52.73%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           zephyr      #14       +/-   ##
===========================================
- Coverage   74.02%   21.28%   -52.74%
===========================================
  Files         368      283       -85
  Lines       49793    33515    -16278
===========================================
- Hits        36859     7135    -29724
- Misses      12934    26380    +13446

Impacted Files
Coverage Δ

src/cli/cli_coap.hpp
0.00% <0.00%> (-100.00%)
:arrow_down:

src/ncp/ncp_base.hpp
0.00% <0.00%> (-100.00%)
:arrow_down:

src/core/net/dhcp6.hpp
0.00% <0.00%> (-100.00%)
:arrow_down:

src/cli/cli_console.cpp
0.00% <0.00%> (-100.00%)
:arrow_down:

src/core/common/new.hpp
0.00% <0.00%> (-100.00%)
:arrow_down:

src/core/net/ip6_mpl.hpp
0.00% <0.00%> (-100.00%)
:arrow_down:

src/core/utils/flash.hpp
0.00% <0.00%> (-100.00%)
:arrow_down:

include/openthread/coap.h
0.00% <0.00%> (-100.00%)
:arrow_down:

src/core/common/crc16.cpp
0.00% <0.00%> (-100.00%)
:arrow_down:

src/core/common/crc16.hpp
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 318 more

Also, feel free to --signoff your commits :)

@edmont you will need to create a PR in the main zephyr repo so we can run zephyr's CI there. Please follow the instructions in:
https://docs.zephyrproject.org/latest/guides/modules.html#changes-to-existing-modules

authors: carlescufi codecov-commenter edmont rlubos

repo: zephyrproject-rtos/openthread


text:
OpenThread upmerge July 5th

Regular upmerge to bring in recent infinite loop fix and the support for DNS service subtypes.

Looks good, but could you please move changes in zephyr/CMakeLists.txt to a separate commit? It helps to keep track of the local changes in the repository.

Sure, I thought we don't want to have commits which are not "self-sufficient" and require fixes from subsequent changes, but I can split the change if it's better.

Looks good, but could you please move changes in zephyr/CMakeLists.txt to a separate commit? It helps to keep track of the local changes in the repository.

Sure, I thought we don't want to have commits which are not "self-sufficient" and require fixes from subsequent changes, but I can split the change if it's better.

We don't use intermediate revisions in Zephyr, so it shouldn't affect bisectability.

We don't use intermediate revisions in Zephyr, so it shouldn't affect bisectability.

Done.

authors: Damian-Nordic rlubos


text:
logging: Where's my function name??

With new logger, I get:
[00:00:19.606,640] <err> net_tcp: context->tcp == NULL
[00:00:19.612,784] <err> net_tcp: context->tcp == NULL
[00:00:19.615,296] <err> net_tcp: context->tcp == NULL
[00:00:19.618,140] <err> net_tcp: context->tcp == NULL

What's this? How to get use of this? I need the function name where it happens, like was there with the old logger. (It was there, right, or am I hallucinating? All in all, with the old logger, it was clear (ahem) what happens where, and the new logger really leads to that question - what's this?)

NET_DBG() will add function name. There was no function name for error log prints with old logging.

We need this also for Bluetooth (see the duplicate issue I opened by mistake). Currently #10264 is mapping the Bluetooth logging macros as follows:
#define BT_DBG(fmt, ...) LOG_DBG("%s: " fmt, __func__, ##__VA_ARGS__)
#define BT_ERR(fmt, ...) LOG_ERR("%s: " fmt, __func__, ##__VA_ARGS__)
#define BT_WARN(fmt, ...) LOG_WRN("%s: " fmt, __func__, ##__VA_ARGS__)
#define BT_INFO(fmt, ...) LOG_INF(fmt, ##__VA_ARGS__)

I'd like to completely remove the Bluetooth-specific macros and replace them with corresponding LOG_* ones however as long as the function name support is not there this would change the behavior.

authors: jhedberg jukkar pfalcon

repo: zephyrproject-rtos/zephyr


text:
settings: NVS back-end

NVS was designed as ultra simple FS which is supposed to store configuration values very effectively.
It will be nice to have back-end for it - it can be used instead of fcb back-end. I expect similar complexity, but much  better performance as NVS is traversable in both direction and It is able to take care about entry overriding by the implementation.

@nvlsianpu, implementing a nvs backend for the settings module is not straight forward. It is mainly limited by the fact that settings supposes that data is stored in the backend as a line consisting of "name"=value. This is of course not good for flash usage as each name is stored in flash again when only the value is changing.
Removing this supposition requires quite some work. To allow for easy extension of the settings module I am proposing the following changes:
a. Change the api for set: value_ctx becomes a structure like:
value_ctx {
   size_t len;
   size_t (*read)(char *data, size_t len, void *arg);
   void *arg;
}

In the set routine value_ctx.len and value_ctx.read(&data, len, arg) can be used and arg contains information that is needed by the backend.
b. The save routine checks for duplicate data in the backend
c. The delete routine should also delete all items that have a name starting with the deleted entry name.

I will no longer work on trying to add a nvs backend for the settings subsystem, so for me this can be closed.

This is the early bird of NVS backed By @kapi-no  : https://github.com/kapi-no/zephyr/commits/settings_nvs_backend

authors: Laczen nvlsianpu


text:
LTS 1.14.0: sanitycheck: Cannot identify OOT boards and shields

Describe the bug
sanitycheck cannot find OOT boards and OOT shields, even if --board_root is explicitly defined.
Everything is tested on 1.14.0 with https://github.com/zephyrproject-rtos/zephyr/commit/d4163bc17ec4c2779b2e53a6d14cca3986d65d1d cherry-picked from v1.14-branch.
The project is a west-T2 star topology.
The main project is the manifest and has zephyr and other projects as 3rd-parties.
To Reproduce
At first I tried:
BOARD_ROOT="${MY_PRJ_ROOT}/zephyr/boards"
"${ZEPHYR_BASE}"/scripts/sanitycheck --board-root "${BOARD_ROOT}" --testcase-root "${MY_PRJ_ROOT}" --tag build --build-only --platform my_oot_board --verbose --inline-logs --outdir /tmp/sanity

It failed, reporting that my_oot_board is not supported, spitting out the list of zephyr in-tree boards.
I investigated the generated CMakeCache.txt file, finding out about the BOARD_DIR variable, so my second trial was:
BOARD_ROOT="${MY_PRJ_ROOT}/zephyr/boards"
"${ZEPHYR_BASE}"/scripts/sanitycheck --board-root "${BOARD_ROOT}" --testcase-root "${MY_PRJ_ROOT}" --tag build --build-only --platform my_oot_board --verbose --inline-logs --outdir /tmp/sanity -x=BOARD_DIR=${BOARD_ROOT}/arm/my_oot_board

This time, the my_oot_board is recognized, but the shield needed by the apps cannot be found.
I have inserted some debugging messages in zephyr/cmake/app/boilerplate.cmake and I've seen that althought the OOT boards/shields directory is listed by sanitycheck, the contents are omitted.
Expected behavior
Since OOT boards and shields are supported, sanitycheck should also be adapted to this kind of structures.
Impact
Blockage, since we do not have a working testing environment. Delay, if we choose to move OOT boards and shields in-tree again.
Environment (please complete the following information):

GNU/Linux
Zephyr SDK

Additional context
Something else I tried was to move only the OOT shield in-tree, but with no success because of how the corresponding cmake process keeps the shield list.

@SebastianBoe FYI

I've encountered this issue now as well

Hi, I believe sanitycheck is not translating it's received
--board-root argument to a CMake argument as it should have been
doing. This should be fixed, but first, as a workaround, could
you try instead of doing,
BOARD_ROOT="${MY_PRJ_ROOT}/zephyr/boards"
"${ZEPHYR_BASE}"/scripts/sanitycheck --board-root "${BOARD_ROOT}" --testcase-root "${MY_PRJ_ROOT}" --tag build --build-only --platform my_oot_board --verbose --inline-logs --outdir /tmp/sanity -x=BOARD_DIR=${BOARD_ROOT}/arm/my_oot_board

do
"${ZEPHYR_BASE}"/scripts/sanitycheck --board-root "${BOARD_ROOT}" --testcase-root "${MY_PRJ_ROOT}" --tag build --build-only --platform my_oot_board --verbose --inline-logs --outdir /tmp/sanity -x=BOARD_ROOT=${BOARD_ROOT}
I believe this will work because AFAIK BOARD_ROOT is
unfortunately not read as an environment variable. Also,
specifying BOARD_DIR should be unnecessary when BOARD_ROOT is set
appropriately.

@SebastianBoe Thanks for the input. Currently I don't have time to test it, but will do as soon as possible.

BOARD_ROOT needs to point to a directory that has a board directory structure similar to what we have in master, i.e. /boards///...
--board-root of sanitycheck should point to <oot-root/boards>
I think this is where things are failing. Please confirm.

no response after 2 months

authors: SebastianBoe gon1332 ioannisg nashif nwsetec


text:
posix clock: unexpected value for CLOCK_REALTIME when used with newlib

When compiling with newlib and posix clock enabled, and so using sys/time.h,
call to clock_settime will failed due to CLOCK_REALTIME having differente values
(0 in posix/clock.c file, 1 in main.c)
CONFIG_NEWLIB_LIBC=y
CONFIG_POSIX_CLOCK=y

#include <zephyr.h>
#include <sys/time.h>
/* using posix/time.h (as in posix/clock.c), instead of sys/time.h will print
 * a different value for CLOCK_REALTIME
 */

void main(void) {
    printk("CLOCK_REALTIME: %ld\n", CLOCK_REALTIME);
}

I'm unable to reproduce this using what you provided as prj.conf and src/main.c in samples/hello_world on nrf52840_pca10056.  The build succeeds and I get:
Hello World! nrf52840_pca10056 1
***** Booting Zephyr OS build zephyr-v2.0.0-1547-gda5a595f248f *****
CLOCK_REALTIME: 1

Are you using some other platform?  native_posix for example, where it does fail as you describe?
I think that would be an unsupported configuration (Zephyr's POSIX implementation surely can't co-exist with a host POSIX implementation) but defer to @pfalcon.

i'm using nrf52840_mdk. Did you get 1 also using (posix/time.h):
#include <zephyr.h>
#include <posix/time.h>
void main(void) {
printk("CLOCK_REALTIME: %ld\n", CLOCK_REALTIME);
}

Sorry, I didn't read what you wrote here closely enough.
Yes, I see the values are different.  I suspect the best approach here would be to work #18892 so Zephyr only provides values that are not defined by a standard header provided by the toolchain.  That would need to be scheduled based on POSIX subsystem needs.

This appears to be fixed by e5b462b0103e741683b5cdc89a6f87e70840c430 which was hidden inside #19114 and was merged earlier today.  Please re-open if it still doesn't work.

This appears to be fixed by e5b462b which was hidden inside #19114 and was merged earlier today.

More specifically, I ack and confirm this issue. It's one of many conflicts related to Zephyr's POSIX subsystem, which get tracked and persistently fixed since the beginning of this year following the approach "POSIX subsys and libc should cooperate, not compete, and newlib should be used as a pattern/convention for libc interfacing (i.e. e.g. minlibc should behave/be structured as newlibc)".
I've seen this particular issue before, but it was forgotten/lost while looking into other issue. It sufaced again while performing refactoring of https://github.com/zephyrproject-rtos/zephyr/pull/19114 based on its code review. Indeed, I would hope that the patch included there would fix the issue. I'm at a conference now though, so maybe be slow with confirming that the change also fixes this issue, so would appreciate independent verification. Thanks.

It's working for me, thanks

authors: pabigot pfalcon sdalu


text:
Bluetooth: Mesh: scan_start fails with synchronous bt_enable

The Bluetooth Mesh fails in the bt_le_scan_start call in adv.c because of NRPA, but only if the Bluetooth subsystem is initialized without a ready callback.
This happens because the scan_start call uses the hci_core BT_ADV_ENABLED flag to check whether the advertiser is in progress, while the controller uses the ull_adv state:
When initializing the mesh subsystem, the adv thread is started. It calls bt_le_adv_start, which calls set_le_adv_enable_legacy. The HCI command is processed by the controller, which sets the adv structure in ull_adv.c. Then, the HCI command response is enqueued in hci_core.c, and the adv thread goes to sleep. Next, settings are loaded, which starts the mesh subsystem and the scanner. When calling bt_le_scan_start from adv.c's bt_mesh_scan_enable, hci_core.c checks whether the advertiser is running, using its local BT_ADV_ENABLED flag. This flag won't be set until the adv_enable HCI command response is processed. hci_core decides that the advertiser isn't running, and sets the NRPA, which fails, because in the controller, the advertiser is already started.
I'm not sure why this works if bt_enable is called with a callback, but I assume it's a thread priority thing. It also works if I enable CONFIG_BT_DEBUG_HCI_CORE, which suggests it's a yield or race condition issue.
Bisecting the issue, it appears first in 915c510a0a, which looks like it is changing some scheduling aspects of the controller.
To Reproduce
Change the mesh sample to call bt_ready from main after the call to bt_enable, instead of as a callback:
void main(void)
{
	int err;

	printk("Initializing...\n");

	/* Initialize the Bluetooth Subsystem */
	err = bt_enable(NULL);
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
		return;
	}

	bt_ready(0);
}

Then, provision and power cycle the device. It should immediately trigger the bug:
Console log
*** Booting Zephyr OS build v2.3.0-rc1-245-g451e559a22a4  ***
Initializing...
Bluetooth initialized
[00:00:00.008,819] <inf> fs_nvs: 2 Sectors of 4096 bytes
[00:00:00.Mesh initialized
008,819] <inf> fs_nvs: alloc wra: 0, f20
[00:00:00.008,819] <inf> fs_nvs: data wra: 0, 12c
[00:00:00.010,131] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:00.257,507] <wrn> bt_hci_core: opcode 0x2005 status 0x0c
[00:00:00.257,507] <err> bt_mesh_adv: starting scan failed (err -5)

cc @jhedberg @carlescufi

Didn't @joerchan add the cmd_state_set stuff to hci_core.c precisely because of this kind of stuff, i.e. so that we can set various flags through the RX priority thread?

le_set_random_address failed, is the host trying to set the random address while having started the advertisement?
I will try to reproduce with hci core debug and check.

Is host calling hci_driver_send from multiple threads (controller's HCI interface is not designed to be reentrant)? and also, expects the controller to be blocking?

Yes, Mesh sends advertiser HCI commands from a separate thread, that's initialized like this: https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/mesh/adv.c#L298-L301

Host is initiating new HCI commands before previous command response is processed?

Yes, as a consequence of the separate thread.
Sounds like this is an issue hci_core should resolve then, for instance by mutexing the hci command/response handling when sent as a synchronous command. @joerchan

@trond-snekvik that's not completely accurate. The bt_hci_cmd_send() API doesn't send anything but only queues the command to bt_dev.cmd_tx_queue. That queue is in turn processed by a single thread, hci_tx_thread(). Furthermore, this sending uses the bt_dev.ncmd_sem to control the sending, which in turn is a binary semaphore mapped to the ncmd parameter of Command Complete & Command Status events, so there should never be two pending commands at the same time, at least not from the controller's perspective.

@jhedberg I see. The issue is still there though, since we're doing checks in the caller thread, which isn't subject to this semaphore. A bit odd that this started happening in a commit that only changed the controller, but I guess that just uncovered the already existing race condition.

@joerchan you are still working on this right?

Yes.
The linked controller change is causing the TX thread to be unscheduled during the processing of the adv enable command.
So the main thread becomes active, and can continue to start the scanner, while the Mesh adv thread and TX thread is blocked. Since the command complete for adv enable has not been delivered then the current executing command in the TX thread is the adv enable command, but the host state of the advertiser is that it is not active.
The reason why changing to async is simply because this will executive in a cooperative thread and will continue to start the scanner after marking the Mesh advertiser thread as ready.

Update to bug description:
After commit c69a27b78970f3426 the behavior that triggered the bug has changed, and to get it back adding CONFIG_SYSTEM_CLOCK_NO_WAIT=y is needed.
Also on current master (36128bde19) the bug can sometimes happen on the sample with asynchronous bt_enable as well.

authors: carlescufi cvinayak jhedberg joerchan trond-snekvik


text:
I2C on SAMC21 sends out stop condition incorrectly

Running an I2C master on a SAMC21 results in an incorrect end of the transaction. The last byte will be read and the master will send out correctly a NACK. But after this another 9 clocks follow with the stop condition after this. Actually the stop condition should come right after the NACK, without any additional clocks in between.
The issue is that the stop condition is triggered in the context of the thread, instead of during the interrupt:

Commands can only be issued when either the Client on Bus Interrupt flag (INTFLAG.SB) or Host on Bus Interrupt
flag (INTFLAG.MB) is '1'.

Source: https://ww1.microchip.com/downloads/aemDocuments/documents/MCU32/ProductDocuments/DataSheets/SAM-C20-C21-Family-Data-Sheet-DS60001479J.pdf (Page 587).
I was able to fix it in our local fork of zephyr with the following patch:
diff --git a/drivers/i2c/i2c_sam0.c b/drivers/i2c/i2c_sam0.c
index d557bb4..939c94d 100644
--- a/drivers/i2c/i2c_sam0.c
+++ b/drivers/i2c/i2c_sam0.c
@@ -154,6 +154,7 @@ static void i2c_sam0_isr(const struct device *dev)
 	if (status & SERCOM_I2CM_INTFLAG_MB) {
 		if (!data->msg.size) {
 			i2c->INTENCLR.reg = SERCOM_I2CM_INTENCLR_MASK;
+			i2c->CTRLB.bit.CMD = 3;
 			k_sem_give(&data->sem);
 			return;
 		}
@@ -169,6 +170,7 @@ static void i2c_sam0_isr(const struct device *dev)
 			 * require write synchronization.
 			 */
 			i2c->CTRLB.bit.ACKACT = 1;
+			i2c->CTRLB.bit.CMD = 3;
 		}

 		*data->msg.buffer = i2c->DATA.reg;
@@ -492,23 +494,6 @@ static int i2c_sam0_transfer(const struct device *dev, struct i2c_msg *msgs,
 			return -EIO;
 		}

-		/*
-		 * Only send a stop if after this message:
-		 *   - it is explicitly requested that we send a stop, or
-		 *   - we are not conducting a restart, with more messages to follow
-		 *
-		 * Note: nothing validates the flags, so default to a stop if a stop is
-		 * requested... do not let a restart request override it
-		 */
-		bool send_stop = (data->msgs->flags & I2C_MSG_STOP)
-			|| !((data->msgs->flags & I2C_MSG_RESTART) && (data->num_msgs > 1));
-
-		if (send_stop) {
-			while (!i2c->STATUS.bit.CLKHOLD) {
-			}
-			i2c->CTRLB.bit.CMD = 3;
-		}
-
 		data->num_msgs--;
 		data->msgs++;
 	}

But I assume this is not the whole story. First of all, the interrupt flags are actually already cleared at this point again, but within the context of the same interrupt routine just a few lines of code earlier on. So technically not 100% correct, but it works at least in my setup. Second, I am uncertain if all the flags (data->msgs->flags) are considered correctly this way.
It took a look at the current version of the driver (b27c5d73ef09278186dc8858dfbed2a33dff6031) and I strongly assume that the same bug is still there.

Hi @benediktibk ,
Thank you for sharing this with us. Please, open a PR with your fix so I can add more people to look at it.
It is important mention that there is no support for SAMC21 on current Zephyr but maybe the driver uses same IP and we may have same bug anyway. Maybe people from #50384 may help to check too.
@attie-argentum This maybe could be interesting to you look. Let me know if you could reproduce, if you have the time.

@benediktibk please correct me: I2C works now with master code, but not efficient.
You fix that sercom stops clock/transmission faster?
I read L21 / D21 / C21 datasheet and they mention the same thing.

Commands can only be issued when either the Client on Bus Interrupt flag (INTFLAG.SB) or Host on Bus Interrupt
flag (INTFLAG.MB) is '1'.

(I tested on my board i2c "master" code with one i2c sensor and it works)

@benediktibk - thanks for your patch, I've reviewed it and would like to also relocate the STOP on error - see #50933.
I've credited you in the commit message, but if you'd prefer to make the PR I'm more than happy to pass it to you.

I'm absolutely happy that you prepared the PR, I just wasn't yet able to find the time to prepare a test setup as a preparation for creating the PR. Thanks mate!

I have a same54p20a part and i can see this patch is merged, but i still seem to have an extra byte clocked at the end. Does anyone have a atsame54_xpro board that can confirm if this is fixed there?

@TomzBench - I don't think the SAM E54 is covered by the SAM0 drivers... have you checked for a similar issue in the relevant drivers? (e.g: i2c_sam_twi.c or i2c_sam_twihs.c)

@attie-argentum hello,
I added a discussion here: https://github.com/zephyrproject-rtos/zephyr/discussions/55170
It seems that the sam0 support is intentionally pretty minimal but im not sure if im following the driver correctly, maybe you can take a look

authors: TomzBench attie-argentum benediktibk benys nandojve


text:
fix MISRA-C rule 20.9 (#ifdef instead of #if)

MISRA-C states that If an attempt is made to use a macro identifier in a preprocessor directive, and that identifier has not been defined, then the preprocessor will assume that it has a value of zero and this could not be what was expected.

@andrewboie is just a style problem ? I can change them to use ifdef but makes sense keep the second comparison (CONFIG_ != 0).

Absolutely we don't want this for kconfig variables.  Those have a standard form and are always testable with #ifdef by design.
Some of the other stuff is more squishy.  I'm pretty sure all those xtensa HAL symbols, in fact, are always defined to either 0 or 1 specifically.  But even then it sounds like MISRA would be fine with that as  there's no ambiguity about what to do for an undefined symbol, right?

Absolutely we don't want this for kconfig variables. Those have a standard form and are always testable with #ifdef by design.

agree.
This looks really bad for something we use in mass.

Absolutely we don't want this for kconfig variables. Those have a standard form and are always testable with #ifdef by design.

agree.
This looks really bad for something we use in mass.

the problem is if we do #if X and X is not defined violates a MISRA-C rule. Changing #if to #ifdef changes the semantic, e.g:
#define CONFIG_A 0

#if CONFIG_A
/* code no compiled */
#endif

#ifdef CONFIG_A
/* code compiled */
#endif

So, what I'm proposing is:
#ifdef CONFIG_A && CONFIG_A != 0

Yeah, but the point is that kconfig also has defined semantics, and it doesn't do that.  A false kconfig value produces an undefined symbol.  That's it's documented API.  And hell, we even control the code generator.

I guess to state things differently: where does this end?  I mean, a naive interpretation of this would would seem to require that every preprocessor variable be first checked with defined() before it is used.  Which is... insane, right?  And even MISRA doesn't require that, as I'm understanding the rule.  It just wants us to assume "undefined means zero".  Which... is exactly what almost all the usage being changed here was doing in the first place.

I guess to state things differently: where does this end? I mean, a naive interpretation of this would would seem to require that every preprocessor variable be first checked with defined() before it is used. Which is... insane, right? And even MISRA doesn't require that, as I'm understanding the rule. It just wants us to assume "undefined means zero". Which... is exactly what almost all the usage being changed here was doing in the first place.

you are right, i just added the second test to keep the same semantic in the code (with the if).
I don't have problem changing it to use ifdef, this is completely safe for the Kconfig ones, but there others that may need special treatment. As I did it automatically I was conservative with the change.

Codecov Report

Merging #12341 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #12341   +/-   ##
=======================================
  Coverage   48.32%   48.32%
=======================================
  Files         294      294
  Lines       44189    44189
  Branches    10600    10600
=======================================
  Hits        21354    21354
  Misses      18569    18569
  Partials     4266     4266

Impacted Files
Coverage Δ

kernel/include/kernel_structs.h
100% <ø> (ø)
:arrow_up:

include/net/net_pkt.h
85.14% <ø> (ø)
:arrow_up:

kernel/sched.c
92.83% <ø> (ø)
:arrow_up:

kernel/init.c
72.13% <ø> (ø)
:arrow_up:

include/logging/log_core.h
100% <ø> (ø)
:arrow_up:

include/misc/util.h
50% <ø> (ø)
:arrow_up:

arch/posix/core/posix_core.c
91.91% <ø> (ø)
:arrow_up:

include/shell/shell_history.h
0% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 330cbfa...095f787. Read the comment docs.

stale, closing. Reopen when there are updates...

authors: andyross ceolin codecov-io nashif


text:
sanitycheck: Fix incorrect QEMUHandler status reporting.

The current QEMUHandler implementation in sanitycheck does not check
for the process exit code and reports "PASS" even when either the QEMU
executable cannot be launched or exited immediately due to an error
(e.g. unsupported machine type, missing file, ...).
This commit adds QEMU process exit code check and error reporting when
the exit code is a non-zero value.
Signed-off-by: Stephanos Ioannidis root@stephanos.io

I'm not very familiar with this part of the code but I see a mismatch between the commit message and the code change: the commit message says "add error checking..." but doesn't mention the most visible change: moving code from one class to a completely different one. Explaining the reason for this distant move might help with the review?
PS: I did look at the actual commit message and not just at the description Duplicated & Diverged by github.

Explaining the reason for this distant move might help with the review?

I moved the code under if instance.handler.type_str == "qemu": to inside QEMUHandler.handle in order to align with what other handlers are doing (note that if instance.handler.type_str is qemu, the instance.handler must be QEMUHandler).
https://github.com/zephyrproject-rtos/zephyr/blob/0297756342fb60e6a64813aac046f4d241cbd369/scripts/sanitycheck#L1937-L1938
For example, the handle method of both BinaryHandler and DeviceHandler execute the "runner", wait for it to finish and set the result; there is no reason for QEMUHandler to be an exception.
handle method implementation for BinaryHandler:
https://github.com/zephyrproject-rtos/zephyr/blob/0297756342fb60e6a64813aac046f4d241cbd369/scripts/sanitycheck#L559-L635
Note that subprocess.Popen, proc.wait(), self.set_state(...) and self.instance.reason = are all inside the handle method.

Thanks, looks like some of explanation above belong to the commit message(s)
https://wiki.openstack.org/wiki/GitCommitMessages#Structural_split_of_changes

Thanks, looks like some of explanation above belong to the commit message(s)

I will split the exit code check and the move into two separate commits (the move was actually an afterthought).

authors: marc-hb stephanosio


text:
driver: ieee802154: rf2xx: implement setting tx power

Signed-off-by: Markus Becker markus.becker@tridonic.com

I am currently fixing the checkpatch warnings.

sorry @nandojve confused the PRs, no need to review this one right now.

sorry @nandojve confused the PRs, no need to review this one right now.

I

Sorry, close/open, did a mistake!

sorry @nandojve confused the PRs, no need to review this one right now.

If you don't want review you can switch back to draft.
Anyway, this is an enhanced and probably only can be merged for 2.4.

rebased on master post 2.3 release.

@jukkar @tbursztyka would you be able to review?

@jukkar @tbursztyka anything holding this back from merging?

Since this is approved now. Who could merge it?

authors: markus-becker-tridonic-com nandojve


text:
refactor devicetree binding support for JESD216 devices

JESD216 specifies serial flash discoverable parameters used by various flash memory devices.  Historically the only Zephyr driver for these devices was the one that became SPI_NOR.  Subsequently Nordic introduced a QSPI driver that required some of the parameters, but not others.  This introduced a split so the shared properties could be described once and used in multiple driver-specific bindings.
Now there are additional QSPI drivers being proposed for different SOCs, including #30864 and #31034.  #30864 includes a commit to further split the shared properties by eliminating ones that aren't supported by a driver.
I'd like to see that split discussed and merged separately so that all QSPI rework in progress (including Nordic) can use it.  Hence this PR, which is much the same as the one from @erwango in #30864 but adds documentation explaining what goes in which layer, and takes steps towards removing a legacy property.

CI failure is #31044, not related to this PR.

Rebased now that CI build failure has been fixed (#31044).

Rebased now that CI build failure has been fixed (#31044).

@galak any input?

@galak any input?

Could we please get this merged so #30864 and #31034 can take advanrage of it?  @galak waiting on you?

Could we please get this merged so #30864 and #31034 can take advanrage of it?  @galak waiting on you?

LGTM, only query on marking has-be32k as deprecated in the binding.

Wasn't thinking about that, added it now.

LGTM, only query on marking has-be32k as deprecated in the binding.

Wasn't thinking about that, added it now.

authors: MaureenHelm pabigot


text:
x86: allow specifying extra memory mappings at build time

This allows passing extra command line arguments to the gen_mmu.py script to generate extra memory mappings. This is useful for static mappings and/or device MMIO access during very early boot.

This includes https://github.com/zephyrproject-rtos/zephyr/pull/33193. Will rebase once that is merged.


text:
More changes to make it buildable on GCC 11

See individual commits for information.

This is on top of #35852. This new PR is to avoid adding new changes to that PR after approval.

Got most of tests/kernel for qemu_x86 and qemu_x86_64 built with orphan section warning disabled due to bunch of .eh_frame_hdr in libgcc.a. One test failed to build due to _GLOBAL_OFFSET_TABLE_ being placed into .got.plt and GCC 11 on Fedora doesn't like. This PR should get most of the common errors out of the way, and we can deal with build error and warnings (and about the orphan sections) once we have Zephyr SDK built on top of GCC 11.

The build process reports timeout, would you want to re-build it again?

Not sure why buildkite always times out.

authors: dcpleung enjiamai


text:
Update BAP to build for new ISO API

Update the BAP implementation to build and run on the new ISO API.

May be we need add “Bluetooth Audio” label ?

May be we need add “Bluetooth Audio” label ?

We actually have that label, but it is only applied for the subsys/bluetooth/audio (where the upstreamed LE audio stuff is placed), and this is placed in subsys/bluetooth/host/audio. I guess we could/should add temporary codeowners and label commits for this branch. @asbjornsabo thoughts?

May be we need add “Bluetooth Audio” label ?

We actually have that label, but it is only applied for the subsys/bluetooth/audio (where the upstreamed LE audio stuff is placed), and this is placed in subsys/bluetooth/host/audio. I guess we could/should add temporary codeowners and label commits for this branch. @asbjornsabo thoughts?

We have removed the CODEOWNERS for this branch, to avoid noise.  I think that still applies (especially as we will still do rebases).
I usually add labels like the "audio" one by hand, it is not much of a hassle.

authors: LingaoM Thalley asbjornsabo


text:
Bluetooth: Controller: DTM: Fix timer rollover

It changes the behaviour of while loop in lll_test.c in isr_tx() . When bug happens and t<s is quite big it can hapen that while loop will take a long time. This leads to setting up start of a radio timer before current timer value. This then leads to invocation of a timer after rollout and this will lead to very large delay in sending packet.
Fixes #42534.
Signed-off-by: Piotr Parfeniuk piotr.parfeniuk@magitech.pl

@piotrParf ping, can you take a look at the review comments please?

Why do i got .github/labeler.yml Error: HttpError ?

@KAGA164 could you please comment on this proposed change?

@KAGA164 could you please comment on this proposed change?

@carlescufi I will check timings with Anritsu

@piotrParf  Please rebase and align your PR due to changes made by #42300. I included CTE time in the transmit time calculation.

The DTM Tx interval is incorrect with this fix because it doesn't follow the calculation from Core v5.3 Vol 6 Part F 4.1.6 where interval should follow basically pattern n*625us. I did a test on 1Mb PHY with payload length 37 bytes and I measured the 908us interval when it shall be 625us.

As I do not have proper tools for this what is your suggestion ?

@piotrParf I made PR with my proposal how to handle Tx timings in the DTM, Could you test it and give me a feedback ? https://github.com/zephyrproject-rtos/zephyr/pull/44735

@piotrParf I made PR with my proposal how to handle Tx timings in the DTM, Could you test it and give me a feedback ? #44735

For me it is many changes to 2.7.0 but it looks like it works when loaded with this controller to network core.

authors: KAGA164 carlescufi piotrParf


text:
Add module and toolchain-bundled Picolibc synchronisation policy

This series adds the policy for keeping the Picolibc module and the toolchain-bundled Picolibc in sync.
Related to https://github.com/zephyrproject-rtos/sdk-ng/pull/673
Part of https://github.com/zephyrproject-rtos/zephyr/issues/49922

@cfriedt @galak @nashif Can you please take a look at this?


text:
logging: Add option to select/imply immediate mode

It's not possible to use choice entries for imply/select. Added LOG_DEFAULT_IMMEDIATE option which can be used with select/imply to set immadiate mode. Same approach was taken as for minimal mode where LOG_DEFAULT_MINIMAL can be used.
Added help entry for LOG_DEFAULT_MINIMAL.
Fixes #67378.

@nordic-krch do you plan to return to this PR?

authors: MaureenHelm nordic-krch