Broken tests on multiple challenges in the Information Security with HelmetJS

Describe your problem and how to reproduce it:
Multiple challenge tests fail for no obvious reasons related to the challenge -

Mitigate the Risk of Clickjacking with helmet.frameguard()
Prevent IE from Opening Untrusted HTML with helmet.ieNoOpen()
Disable DNS Prefetching with helmet.dnsPrefetchControl()

Add a Link to the page with the problem:
https://glitch.com/edit/#!/busy-rambunctious-tern
this server fails the tests for reasons beyond my understanding.
I tried to replicate the server on a different service and tweak the tests and I still don't understand the cause.
<EMAIL_ADDRESS>Tell us about your browser and operating system:

Browser Name:
Google Chrome
Browser Version:
Version 83.0.4103.116 (Official Build) (64-bit)
Operating System:
Windows 10 Enterprise

If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box):

I can confirm this is an issue. It appears the likely cause is helmetjs renaming their middleware.
These are the new name:
frameguard -> xFrameOptionsMiddleware
ienoopen -> xDownloadOptionsMiddleware
dnsPrefetchControl -> xDnsPrefetchControlMiddleware
I cannot confirm anything wrong with the CSP tests.

Some of the function names changed
https://github.com/helmetjs/helmet/blob/master/index.ts#L136
module aliases tests
https://github.com/helmetjs/helmet/blob/master/test/index.test.ts#L16
Shouldn't we get this fixed sooner rather than later? Unless someone jumps on this fairly quickly I'd suggest removing the first timers only label.
Side note: The way the tests are done (_router.stack) seems like it would be pretty error/breakage-prone.

@lasjorg You are right, it would be best to get it fixed sooner. I just expected someone to jump on it, as it is quick and easy.
The tests are done in a way that keeps us on our toes, regarding changes.

Is it okay if I raised a PR to fix this? or is someone else on it? I haven't really dug through the fcc code base so I'm not sure where the tests live but now that I know the root cause it seems simple enough.

@obsessedyouth , No one has mentioned to be working on it. Here is where the tests live: https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/09-information-security/information-security-with-helmetjs

Just to confirm, an old version of HelmetJS we specified in the project's package.json was not failing these tests?  If the old version was not failing, then why are we having to rewrite the tests?

@RandellDawson The starter boilerplate does not have helmetjs in the package.json, the first challenge is to add it.
Not so sure locking the boilerplate to a specific version is the right choice, although it is certainly an option.

Also just as an aside. If we want to keep backward compatibility with projects made before this change we have to check for both the old and new function names. Not sure what the consensus on this is?

If we must, I would suggest checking for both old and new, as lasjorg mentioned. Originally, I assumed backwards compatibility was not a problem, because this is related to the lesson content, and not projects. So, all a user currently on them has to do, is update the version of Helmetjs in their package.json.

I'm just calling the finished version of the code a camper would end up with from this section of challenges a "project". I know it isn't really a project.
Sure it is easy to fix, but you have to know what the problem is and to update the dependencies.
I guess there isn't any expectation that the code used to pass the challenges will be accessible or remain valid. Once you have passed all the challenges you can delete the code and still have a valid passing section of challenges. So it doesn't matter much (from a validation point of view) if the code doesn't pass at a later date. But from a camper's point of view, it may be confusing why code that was passing now doesn't.

In order to pass the test i had to go back to version: 2.3.0

Hi @lasjorg @Sky020 @RandellDawson can you guys please reach a consensus about what will be done regarding this issue? It seems it is starting to affect more campers. I think my PR addresses this and backward compatibility is extremely unlikely since I doubt anyone would try to attempt a lesson with an older version of a project using helmet.js

I think my PR addresses this and backward compatibility is extremely unlikely since I doubt anyone would try to attempt a lesson with an older version of a project using helmet.js.

@obsessedyouth Fixing the current issue is definitely a lot more important than any backward compatibility considerations. I think it might be fine to break old "projects".
I doubt that there are many people that will go back and re-run the tests on their old code. However, it is possible that some campers may have started doing the challenges and then moved on to something else, or took a break, and when they return back their starter code will be broken.
I just wanted to point out that updating the tests would break any older starter code. But like I said backward compatibility issues are not as important as fixing the current one.

@moT01 @ojeytonwilliams Any thoughts on this issue?

How about rewriting the lesson that installs the package to make users install the specific version we were using when the lessons were written? This will keep everything compatible and save us from running into this issue again if something else in the package changes. I don't like teaching older versions of things, but it may be a good way to make sure things keep working - I think that would work anyway.

@moT01 That is a good point.  Many companies purposely do not upgrade a package, to avoid breaking existing code.

Well, this was an unexpected outcome but I'm happy this will get addressed either way.

Yep, I agree with Tom.
The packages should definitely get pinned to specific versions and get updated when a contributor intends to move to new versions.  Ideally they should be updated to the latest stable builds, but it's important that the process is controlled.

I honestly think the real problem here is how we are testing for the middleware.

Depending on the internals of Express, especially internals declared using underscore (_router.stack) is surely bound to cause issues.

Looking at internal function names of middleware and not the publicly exposed middleware methods. The HelmetJS middleware method names have not changed (that would be a major breaking change). Only the internal function name assigned to the middleware properties has changed (i.e. aliasing).

Ideally, we should able to check for the middleware by looking at publicly exposed APIs and not depend on the internal function names. I'm just not sure how you would normally test/check for properly mounted middleware. I'm guessing most just check the functionality and look to see if the middleware is performing as expected and not check for the mounting itself.
I'd still expect there to be some way to perform testing for properly mounted middleware without having to do what we are doing.

@RandellDawson @ojeytonwilliams @moT01
So what is the plan here? Should we update the challenge description to ask the camper to install a specific version or do we just abandon backward compatibility and go with the PR from obsessedyouth?

I think there was pretty good support for rewriting the lesson to use a specific version of helmet - If the current tests all pass with 3.21.3, like @lasjorg mentioned - we could probably go with that one. It has the dual benefit of backwards compatibility and stopping this issue from coming up again if/when helmet changes something else. So I would say to pin helmet to that version if it works. I believe this would only required a small change to the instructions of the first lesson in that section, and probably add a test for it as well - and probably add the version to the boilerplate as well.

The instructions of the tests does not say you should use v3.21.3 on all the tests, only on the first test. It does say you should clone the repo for each and every test though. So it's a bit misleading, should one use v3.21.3 or the latest? What about express, which version?
As for right now, the tests for hidePoweredBy isn't working as they should even with v3.21.3 https://forum.freecodecamp.org/t/test-failing-with-correct-implementation/466530

It does say you should clone the repo for each and every test though.

Where does it say that? As far as I can tell it just gives you a reminder of the starting project used.

should one use v3.21.3 or the latest? What about express, which version?

You have to keep things as-is for the next challenge, whatever came before the current challenge has to stay (unless it is explicitly said otherwise).

Where does it say that? As far as I can tell it just gives you a reminder of the starting project used.
Sorry, it's my bad reading skills as usual, it says the following "As a reminder, this project is being built upon the following starter project on Replit, or cloned from GitHub.".

You have to keep things as-is for the next challenge, whatever came before the current challenge has to stay (unless it is explicitly said otherwise).
I never saw this instruction anywhere, and also, for the challenges, I always had to start by removing what I added.

I never saw this instruction anywhere, and also, for the challenges, I always had to start by removing what I added.

There are plenty of sections in the curriculum where challenges build upon previous challenges. Sometimes challenges depend on code from previous challenges, sometimes not.
One challenge might ask you to add a Version field in package.json and then the next challenge might ask you to add some npm package. In this instance, the current challenge does not depend on the previous challenge. But this also doesn't mean you should or need to remove the Version field from package.json just because the current challenge doesn't depend on it or test for it.
Another challenge might ask you to serve an HTML page and then the next challenge might ask you to serve a CSS file. Here the latter is dependent on the code from the previous challenge and you can not remove it.

Ooh and using app.use(helmet()) should already be configuring everything needed for the test according to the documentation

Yes, but the opposite is not true. If all you need is one or two of the middleware functions there is no reason to bring in the kitchen sink.

Sometimes challenges depend on code from previous challenges, sometimes not.

I wish this would be more clear

Yes, but the opposite is not true. If all you need is one or two of the middleware functions there is no reason to bring in the kitchen sink.

Perhaps this should be be clarified in the tests, because the test says to enable the filter, calling helmet.use()  does that. so by definition the challenge should be completed. As it is right now, I consider it to be a bug, but maybe that's just me because I like instructions to be clear.

I wish this would be more clear

I think it is pretty clear if a previous challenge has set up something the next challenge would need. As I said, you shouldn't need to remove anything you did in a previous challenge unless it is explicitly said so.

Perhaps this should be be clarified in the tests, because the test says to enable the filter, calling helmet.use() does that. so by definition the challenge should be completed. As it is right now, I consider it to be a bug, but maybe that's just me because I like instructions to be clear.

You are specifically asked to enable the middleware by using helmet.hidePoweredBy(). The behavior of something might be the same without the implementation details being exactly the same.
The test checks the return of this endpoint /_api/app-info (e.g. https://replName.replUsername.repl.co/_api/app-info).
This is what using app.use(helmet()) returns:
{
  headers: {
    'x-dns-prefetch-control': 'off',
    'x-frame-options': 'SAMEORIGIN',
    'strict-transport-security': 'max-age=15552000; includeSubDomains',
    'x-download-options': 'noopen',
    'x-content-type-options': 'nosniff',
    'x-xss-protection': '1; mode=block',
  },
  appStack: ['helmet'],
}

This is what using app.use(helmet.hidePoweredBy()) returns:
{
  headers: {},
  appStack: ['hidePoweredBy'],
}

The test is looking at appStack.
assert.include(data.appStack, 'hidePoweredBy');
You can look in the starting boilerplate code, inside server.js on line 33 is how it is getting the appStack value (although reading the code is a bit of a pain and likely not very illuminating).

As I said, you shouldn't need to remove anything you did in a previous challenge unless it is explicitly said so.
You shouldn't keep the "precious work" either unless it explicitly says to. Because  you're moving from one challenge to a new one. Nothing says they are connected to one another other than it being started from the same "template-repo".
Things like "assumption" should never be a part of a challenge, the instructions should be very clear. Like right now I'm working on the Anonymous message board, the instructions here also appears to be incomplete to me.
Sure the instructions says
Build a full stack JavaScript app that is functionally similar to this: https://anonymous-message-board.freecodecamp.rocks/.
Normally in a message board it's like a forum. But if you try this link, you'll see it behaves in an unnatural way, it doesn't have the expected behavior. Create a thread, what do you expect to happen? Well for me, I expect to see the thread. But instead, I appear to be presented with all of the previously-created threads? makes no sense at all to me imo.

You are specifically asked to enable the middleware by using helmet.hidePoweredBy().
This isn't really true, because the instructions says the following: "You will add any security features to server.js". Which means as long as I've added my security features to server.js it should be good enough. Although, since the instruction doesn't specify which features, any features should suffice.

I thank you though for taking your time to explain and discus this with me, I appreciate that. I just tend to have problems when the instructions are based on guess-work, I like my instructions clearly defined so there's no room for misunderstandings. Except at work of course, but that's different, because then I can just ask the product owner how they want it.

I had the same problem, I managed to fix it with the following configuration in package.json:
"dependencies": {
    "express": "^4.14.0",
    "helmet": "2"
}

This will work but you change the version of the helmet on other task
"dependencies": {
"express": "^4.14.0",
"helmet": "2"
}

xFrameOptionsMiddleware

@digenaldo this was a huge help! Thank you all for sharing your insights.


Grocery_CRUD in view

Hi.
I am having issues with position of CRUD in view.
Is there a way to set CRUD inside  like this
>

>

Server settings

>

>
> Put crud here ?
>
>
>

>

To use Grocery CRUD within your custom view (instead of /application/modules/admin/views/crud.php), you can simply skip the Admin_Controller's render_crud() function and pass the CRUD object like:
$crud = $this->generate_crud('users');
$this->mViewData['crud'] = $crud;   // or use $this->mCrud
$this->render('my_view');

But then you will miss some functions from render_crud(), like you will need to add stylesheets / scripts to page manually - for reference please have a look on the render_crud() function from Admin_Controller.php


Don't parse test for const field in mutable struct in Julia 1.6

I tried to test const fields in mutable structs in version 1.6 (which could be supported), but Julia 1.6 fails to parse const name::String as it expects an assignment, even after putting it behind a @static block.
        @static VERSION ≥ v"1.8.0" && @testset "const field in mutable (julia ^1.8)" begin
            @dynamic mutable struct ConstPerson
                const name::String
            end

            p = ConstPerson("Frank", age=50)
            @test isdynamictype(ConstPerson)
            @test isdynamic(p)
            @test p.age == 50
        end

For now, I just stopped testing 1.6, bumping it to 1.8 instead, but that means that we should either drop support for 1.6, or find a way to test it.
or we just... don't test it... but at the same time I want that sweet sweet 100% coverage.

Actually no wait I'll just put it in a separate file and include it, such that it doesn't even get parsed unless the condition is met.


Eid 887: Schedule Metadata Aggregation on DW app

Creating a managed dropwizard job that schedules the aggregation.
The schedule delay is defined in config, and there is an acceptance test for ensuring that the aggregation scheduler is managed by DW.
NB A ScheduledExecutorService is used instead of Timer to allow future blocking when we wish to introduce a manual trigger.

I have offline comments, please don't merge yet.


formatting script inside custom block went wrong

Before Formatting

After Formatting

Sorry about this major bug! I've pushed a fix for this issue but please let me know if you're still running into any issues 👍

@mblode You fix it so fast. I found other issues and I would new issue later. Thank you for your contribution. The extension is so useful for me. :0


help

Hello Victor,
I implemented your control but there is something not rigth.
I can´t select multiple elements. I putt the option IsMultiple with true and left it blank, but nothing still select only one record...and the name i get its with that format...

Hey!
I believe your problem is in the main attribute id. It should be axx_tipodeobjetivoid, you put axx_tipodeobjetivoId, (Uppercase I in the Id)
Let me know if that solves the problem.
The final objective of the JSON is to have the ID and the Name to show, both of them, so it seems the problem you are having is coming from there


Remote install : Error 3005:UnauthorizedOperation

I have followed the instructions but Remote install failed.
Camera is Cam v2 running <IP_ADDRESS> firmware
Host is Linux Mint from virtualmachine.

WyzeHacks isn't going to work with that firmware version.
Unfortunately, they've blocked this particular route, because that version validates the SSL of the firmware url. For a brief window of time, it would accept a port 80 OTA firmware update which allowed for DNS spoofing to serve arbitrary firmwares.
Try https://github.com/gtxaspec/wz_mini_hacks
which uses a different method (special filename on SD card) to load a hack.

I was just reading up on the DNS spoof method, which is unfortunate and somewhat difficult to deal with..
I've tried the wyzehack SD card flash method as well, which seems to have opened telnet atleast, but its not generating any NFS mounts.
I shall take a look at the wz mini hack, thank you.

Went to take a look at wz mini hack, but that just lets you mount through a script, and I have no idea how any of that is supposed to work. I need a more casual hack, like Wyzehack (was).


Extra tab in one submitter

from mock submissions

This is the case of this expression file:
Long-read RGASP/Submissions/Vollmers_submitter_id/Mandalorion_Isoforms/quantifiedIsoforms.txt

format now validated


error: The image architecture is incompatible with the target server

Few days ago, I created a container from an Ubuntu Wily (amd64) image and put some database stuff into it.
Then I wanted to test out pulling that container to another host, so I used the lxc publish command. This is what I get:
>>> lxc publish mexico:bdr/daemon
Container published with fingerprint: 7a08030fc64ab63342e6c67381c35492b8fcfc25625550c592bbb220379d3120
>>> lxc image list
+-------+--------------+--------+---------------------+---------+----------+------------------------------+
| ALIAS | FINGERPRINT  | PUBLIC |     DESCRIPTION     |  ARCH   |   SIZE   |         UPLOAD DATE          |
+-------+--------------+--------+---------------------+---------+----------+------------------------------+
|       | 7a08030fc64a | no     |                     | unknown | 575.27MB | Nov 20, 2015 at 9:22pm (CET) |
|       | a47e09905490 | no     | Ubuntu wily (amd64) | x86_64  | 73.34MB  | Nov 11, 2015 at 9:57am (CET) |
+-------+--------------+--------+---------------------+---------+----------+------------------------------+
>>> lxc launch 7a08030fc64a bdr
error: The image architecture is incompatible with the target server

Somehow, the architecture info of the container has been lost in the process. What's wrong here?

Are both LXDs running the same version?

Yes, both running 0.22.

Managed to reproduce this, not much we can fix after the fact, but I think i plugged all the needed holes to not have this happen when starting from a scratch using a clean image.


Add tota11y

https://github.com/Khan/tota11y

Depends on the result of https://github.com/blittle/bower-installer/issues/126


drivers: sensor: Convert fxos8700 Kconfigs to dts properties

This lays some groundwork for supporting multiple instances of the fxos8700 driver with different properties on each instance. We convert pulse detection, range, and power mode options from Kconfigs to optional device tree properties.
I'm not sure yet how to convert FXOS8700_DRDY_INT1, FXOS8700_PULSE_INT1, and FXOS8700_MOTION_INT1. We probably need to add support for using both INT1 and INT2 simultaneously (i.e., data ready interrupt on INT1 and pulse interrupt on INT2).
I also need to figure out how to handle the different modes (accelerometer-only, magnetometer-only, and hybrid accel+mag).
Would like to get some feedback to see if folks agree with this direction before I continue further.

We convert pulse detection, range, and power mode options from Kconfigs to optional device tree properties.

Looks good, except that someone might want to change it at runtime, but that was not possible even with Kconfig.

I'm not sure yet how to convert FXOS8700_DRDY_INT1, FXOS8700_PULSE_INT1, and FXOS8700_MOTION_INT1. We probably need to add support for using both INT1 and INT2 simultaneously (i.e., data ready interrupt on INT1 and pulse interrupt on INT2).

I would leave it as it is for now.

@gmarull @jfischer-phytec-iot please have another look. I rebased to the latest master, moved default values from the driver to the dts bindings, and converted the driver to use DT_INST_FOREACH_STATUS_OKAY.

@jfischer-phytec-iot ping


feat: Add trim method to all input

Purpose of the pull request

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

Codecov Report

Merging #10984 (b29864b) into dev (05308cc) will increase coverage by 0.03%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev   #10984      +/-   ##
============================================
+ Coverage     40.31%   40.34%   +0.03%
- Complexity     4858     4866       +8
============================================
  Files           943      943
  Lines         37015    37027      +12
  Branches       4061     4061
============================================
+ Hits          14921    14938      +17
+ Misses        20594    20588       -6
- Partials       1500     1501       +1

Impacted Files
Coverage Δ

...duler/plugin/task/zeppelin/ZeppelinParameters.java
81.25% <0.00%> (-3.37%)
:arrow_down:

...inscheduler/plugin/task/zeppelin/ZeppelinTask.java
48.05% <0.00%> (-0.64%)
:arrow_down:

...che/dolphinscheduler/api/python/PythonGateway.java
21.64% <0.00%> (ø)

.../dolphinscheduler/plugin/task/datax/DataxTask.java
0.00% <0.00%> (ø)

...r/plugin/task/sqoop/parameter/SqoopParameters.java
54.66% <0.00%> (+1.33%)
:arrow_up:

...nscheduler/api/service/impl/TenantServiceImpl.java
69.91% <0.00%> (+6.19%)
:arrow_up:

...inscheduler/api/service/impl/QueueServiceImpl.java
75.29% <0.00%> (+8.23%)
: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 05308cc...b29864b. Read the comment docs.


SSCS-10493-Alert-On-Hearing-Event-Failure Initial Setup

JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/SSCS-10493
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[X] No

Old Azure Solution has now been changed and updated so PR closed


Update CloudFront functions to the latest package version

We 're using CloudFront functions to rewrite all URI requests from /latest/* to the latest package version uploaded in the S3 bucket.
F.x.:
/poseidon/latest/ -> /poseidon/1.0.0-beta.1/

With this PR, a new feature is introduced that automates the update of CloudFront functions to point to the new package versions upon release.
Changes:

A new step was added to the workflow that triggers a script
An aux script was created that compares the latest version in the CloudFront function against the deployed package version. If the versions differ, it updates and publishes the function that now includes the latest package version.

Thanks @ntampakas!
What happens when we manually upload the artifacts from the tags and the tag is not the latest? This may not be necessary in the future actually, but that was another idea we've discussed right?

Thanks @ntampakas!
What happens when we manually upload the artifacts from the tags and the tag is not the latest? This may not be necessary in the future actually, but that was another idea we've discussed right?

TBH i don' t remember this, but If you upload any kind of artifacts without using the GH Actions workflow, the functions will not be affected and will point to the latest version according to the last workflow execution; if that requires specific operations to be performed on any AWS resources, it should be done manually.
Is there a scenario where artifacts are uploaded to S3 using AWS console/SDK?

@ntampakas

Is there a scenario where artifacts are uploaded to S3 using AWS console/SDK?

I don't think so, I meant through Github workflows. I remember you showed us a drop-down menu where you can manually trigger the workflow for a specific tag.

@ntampakas

Is there a scenario where artifacts are uploaded to S3 using AWS console/SDK?

I don't think so, I meant through Github workflows. I remember you showed us a drop-down menu where you can manually trigger the workflow for a specific tag.

I see now.. you are talking about having a workflow dispatch event to manually trigger the workflow.
Yeah sure, that could be an enhancement. Would you like me to create a new issue for this feature?

@sripwoud

Would you like me to create a new issue for this feature?

Do we really need it in your opinion?

@sripwoud

Would you like me to create a new issue for this feature?

Do we really need it in your opinion?

Well... it really depends on whether you want to upload all these artifacts for each specific tag automatically to S3, and how frequently, or if you just want to upload a bunch of them. If it' s the second case, or you think there is no added value, we can skip this feature.
Additionally, the implementation might be challenging because the older tags do not have the GitHub Actions workflow/scripts that upload the artifacts to the S3 bucket. We should find a way, which is not straightforward, to check out the tag in question during the workflow execution.

@sripwoud

Would you like me to create a new issue for this feature?

Do we really need it in your opinion?

I don't think we really need.
The best feature is "merge and forget" ^^. Everything deployed on merge without having to think about it


refactor(transformer/object-rest-spread): avoid multiple symbol lookups

IdentifierReference::is_global_reference and MaybeBoundIdentifier::from_identifier_reference both look up the symbol for the identifier. Do this lookup only once, rather than twice.

#7420  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Merge activity

Nov 22, 11:58 PM EST: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.


Update community-hub-release-parent POM to 1.3.1

For folks using the community-hub-release-parent POM, an update is required because we recently moved from Nexus to Artifactory (learn more here). Please make sure you are using version 1.3.1 to avoid failed deployments.

Hello potential future maintainer! You will need to double check the latest version of the GitHub release Action as well.


Mandate Elf_Rela over Elf_Rel?

Elf_Rel is legacy, a pain, and not always well-supported. As far as I know, all implementations use solely Elf_Rela for RISC-V; can/should we mandate only Elf_Rela be used?

Fuchsia is pursuing with REL on architectures which normally use RELA.
There is only one benefit: size. However, since Fuchsia uses -z separate-loadable-segments which overaligns PT_LOAD segments, they don't really get size benefit by switching to REL....
I was a bit reluctant but still added ld.lld -z rel for them. https://reviews.llvm.org/D80496
That said, REL still has size benefits for non--z separate-loadable-segments (most) users.
For dynamic relocation types, if we take out R_*_RELATIVE (which has a more compact RELR), all the other addends almost always have zero addend.
REL input is quite a pain for a linker. REL output is much better in terms of code complexity. @arichardson


Body request gzip behaviour inconsistent between ios and android

Environment
React Native Environment Info:
    System:
      OS: macOS 10.14.2
      CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
      Memory: 72.56 MB / 16.00 GB
      Shell: 5.3 - /bin/zsh
    Binaries:
      Node: 10.13.0 - ~/.nvm/versions/node/v10.13.0/bin/node
      Yarn: 1.12.3 - ~/.yarn/bin/yarn
      npm: 6.4.1 - ~/.nvm/versions/node/v10.13.0/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
      Android SDK:
        API Levels: 24, 26, 27, 28
        Build Tools: 27.0.3, 28.0.3
        System Images: android-28 | Google Play Intel x86 Atom
    IDEs:
      Android Studio: 3.2 AI-181.55<IP_ADDRESS>56338
      Xcode: 10.1/10B61 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.5.1 => 16.5.1
      react-native: ^0.57.0 => 0.57.7
    npmGlobalPackages:
      react-native-cli: 2.0.1
      @qompium/react-native-fibricheck-sdk: 0.3.3

Description
When trying to gzip a request body (before a POST request), this behaviour is inconsistent across iOS and Android.
iOS: Manually gzip the body (in my case using pako) and add the Content-Encoding: gzip header.
Android:  Add the Content-encoding: gzip header and the underlying okHttp client (Android's built-in http client?) will do the gzipping for you it seems.
*When react-native-debugger is open, manually gzipping the body is required too, but I guess this is because the requests go through Chrome's http client and not the device's http client?
Reproducible Demo
await axios({
        data: body,
        transformRequest: axios.defaults.transformRequest.concat((body, headers) => {
          if (typeof body === 'string' && body.length > 1024) {
            headers['Content-Encoding'] = 'gzip';
            return Platform.switch({
              ios: pako.gzip(body), // manually gzip
              android: body, // okHttp will do the rest if the header is set
            });
          }
        }),
        method: 'POST',
        url: '...',
});

Is the answer for this to add support for content-encoding: 'gzip' to iOS, so that it's consistent?

@robinclaes would you be able to send a Pull Request to align this behavior?


Regenerator deprecation

The regenerator/runtime module is deprecated; please import regenerator-runtime/runtime instead.

Fixed in https://github.com/NewSpring/Apollos/tree/the-final-rebase


go install downloads package but does not install

Sorry if this is the wrong place or format, I'm new to this and new to github,
OS: Ubuntu 20.04.1
Go version: Go 1.18
I'm having an issue where sudo apt install gobuster works, and after installation I can use it, but it's version 2.0.1, and I'm unsure how to update it to the current 3.x version so I used sudo apt remove gobuster and started over.
Installing via the recommended method of
go install github.com/OJ/gobuster/v3@latest
It downloads the files and I can find them in
~/go/bin
where gobuster.exe resides, and in
<EMAIL_ADDRESS>However, I'm unable to use the gobuster command, it just says
Command 'gobuster' not found, but can be installed with:

sudo apt install gobuster

And I've already added the gopath.

Issue fixed partially: For some reason despite my ~/.bashrc being configured with the gopath downloads were not being put in usr/local/go, but instead went to /home/go/
Temporary solution was to sudo mv all the files within the pkg and bin folders into their respective folders of the same name in usr/local/go.


Small typo in INSTALL.md for installing cctbx

I followed the installation guide in
https://github.com/keitaroyam/yamtbx/blob/master/INSTALL.md
and it worked well, until I typed this line in the script
[yolee@log02 yamtbx]$ ./build/bin/libtbx.configure --enable-openmp-if-possible=True yamtbx
Usage: libtbx.configure [options] module_name[=redirection_path] ...

env_config.py: error: no such option: --enable-openmp-if-possible

So I looked up ./build/bin/libtbx.configure  and it showed that the correct option is --enable_openmp_if_possible  with underscores.
[yolee@log02 yamtbx]$ ./build/bin/libtbx.configure --help
Usage: libtbx.configure [options] module_name[=redirection_path] ...

Options:
  -h, --help            show this help message and exit
  --only                disable previously configured modules
  --exclude=EXCLUDE     Modules to leave out from configuration
  --build_boost_python_extensions=True|False
                        build Boost.Python extension modules (default: True)
  --enable_openmp_if_possible=True|False
                        use OpenMP if available and known to work (default:
                        False)
  --enable_boost_threads=ENABLE_BOOST_THREADS
                        make Boost.Threads available
  --enable_cuda         Use optimized CUDA routines for certain calculations.
                        Requires at least one NVIDIA GPU with compute
                        capability of 2.0 or higher, and CUDA Toolkit 4.0 or
                        higher (default: False)
  --use_conda           Use conda as the source for Python and dependencies
                        (default: False)
  --opt_resources=True|False
                        use opt_resources if available (default: False)
  --precompile_headers  Precompile headers, especially Boost Python ones
                        (default: don't)
  --clear_scons_memory  remove scons build signatures and config cache
  --no_bin_python       do not create <build directory>/bin/python even in a
                        development environment
  --enable_cxx11        use C++11 standard
  --skip_phenix_dispatchers
                        Skip all dispatchers with 'phenix' in the title

[yolee@log02 yamtbx]$ ./build/bin/libtbx.configure --enable_openmp_if_possible=True yamtbx

With --enable_openmp_if_possible all finished successfully.

Thank you for pointing this out. This is probably due to a change in cctbx.


rubygems_url attribute not working

Cookbook version
8.1.8
Chef-client version
12.19.36
Platform Details
RHEL6.8 and RHEL7.3
Scenario:
Gem update while upgrading chef package from 12.19.36 to 13.1.31.
Steps to Reproduce:
Created a wrapper cookbook with chef_client_updater. Changed the following attributes:
default['chef_client_updater']['version'] = '13.1.31'
default['chef_client_updater']['download_url_override'] = 'http://xyz123.com/chef-13.1.31-1.el6.x86_64.rpm'
default['chef_client_updater']['checksum'] = '31d3c8d09a884a10f93d58c9ead636cfb19b12c9ea6c8de1bb661918347c164d'
The above cookbook updates mixlib gems during the upgrade. As we have a air-gapped environment, we have set a ruby gem mirror. And set the following attribute in chef-client cookbook.
default['chef_client']['config']['rubygems_url'] = 'http://xyz.com/'
Though the client.rb is already updated with rubygems_url, it still tries to connect to http://rubygems.org
Expected Result:
rubygems_url in client.rb config should take into effect during the chef-client run but it is not.
Actual Result:
Mixlib::ShellOut::ShellCommandFailed: chef_client_updater[update chef-client] (chef_client_updater::default line 20) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /opt/chef/embedded/bin/gem update --system --no-rdoc --no-ri ----
STDOUT:
STDERR: ERROR:  While executing gem ... (Gem::RemoteFetcher::UnknownHostError)
no such name (https://rubygems.org/specs.4.8.gz)
---- End output of /opt/chef/embedded/bin/gem update --system --no-rdoc --no-ri ----

I don't think the problem is with the chef-client cookbook here. Which recipes are you including? Based on the output you have included it looks like the chef_client_updater is what is erroring. When I created a wrapper cookbook, I got a failure at trying to install (it didn't try to go to rubygems.org). I don't know whether chef_client_updater will honor the rubygems_url configuration. It's just using https://github.com/chef/mixlib-install. Can you verify your run_list/recipe contents? Thanks.
My wrapper recipe looked like:

node.default['chef_client_updater']['version'] = '13.1.31'
node.default['chef_client_updater']['download_url_override'] = 'http://xyz123.com/chef-13.1.31-1.el6.x86_64.rpm'
node.default['chef_client_updater']['checksum'] = '31d3c8d09a884a10f93d58c9ead636cfb19b12c9ea6c8de1bb661918347c164d'
node.default['chef_client']['config']['rubygems_url'] = 'http://xyz.com/'
include_recipe 'chef-client::config'
include_recipe 'chef-client'
chef_client_updater 'Install latest Chef' do
post_install_action 'kill'
end

Runlist has chef-client wrapper and chef-client-updater wrapper.
As per the details provided by Jeremy in the below link, rubygems_url should install the gems from the specified internal url. But in my case, it is trying to go to rubygems.org (external) and as we have a air-gapped environment, it is failing.
https://github.com/jeremymv2/chef-intranet-scaffolding#installing-additional-gems-via-chef-gem_package-resource-from-alternate-sources

What's in your chef-client wrapper?

Default recipe with the following recipes:
include_recipe 'chef-client::config'
include_recipe 'chef-client::default'
Attributes:
default['chef_client']['interval']    = '1800'
default['chef_client']['log_dir']     = '/var/log/chef'
default['chef_client']['log_perm'] = '640'
default['chef_client']['config']['chef_server_url'] = 'https://xyz123.com/organizations/abc'
default['chef_client']['config']['rubygems_url'] = 'http://internalrubygems.com/'

@sputturao The issue here is with Chef Client 12. The rubygems_url functionality was enhanced with Chef Client 13.  It's been working for me once I updated these clients to Chef Client 13.  See the release notes: https://discourse.chef.io/t/chef-client-13-released/10735

@sputturao Please check ^ and confirm.
Thanks!

Yeah this was never a cookbook bug, if the config is rendering properly this cookbook is working, if the behavior is still broken that is on chef-client.


two choices for entering network namespaces

The binary, deployed on the root network, will have to enter the different network namespaces on the node so that it can check DNS service availability.
To go about doing this, first, we'll have to extract the container id
containerID := pod.Status.ContainerStatuses[0].ContainerID

and then the process id
pid = "$(docker inspect -f '{{.State.Pid}}' "container_id")"

After this, there are two choices:

ns package from Container Networking:
This package has a method Do() that takes a netns object and then executes functions in that namespace.
A netns object can be obtained from the command ns.GetNS(path) where path could be constructed using the pid we
obtained earlier.
path = "/proc/$pid/ns/net"

nsenter :
This can also be used to execute operations inside a namespace using the command
nsenter -t "container-pid" -n "command"

I'm not using ip netns exec as I had initially planned as the steps above are better in that they don't require the symlink hack (Step 2).

My opinion
I think the ns package option is better since it is implemented in code and the existence of netns objects makes the usage easier and intuitive.
Question
Should I use nsenter instead? I'm not sure I totally understand its implementation but I think it sets the current network namespace to the one specified and then executes the commands, something the ns package does in code.

ns sounds better.

@wjayesh As we are approaching the ending phase of CommunityBridge Program, we will need to have a final project report. Can you send a report through email, ideally in 1-2 pages?

@yongtang I'll prepare one as soon as possible. Is there a fixed template that I need to follow?

@wjayesh A normal report capture the deliverable or results would be good enough.

I have created a draft report at this link. Please let me know if it's apt. Thanks!


Adding multi-platform support for linux/amd64 and linux/arm64

Still needs testing as I'm sure I've left something out.
Resolves #81

I think this is working, but I don't have a good way of testing the arm images. I've tried building images on a few different configurations as well. I'm using Rancher Desktop on a 2018 Intel based mac, podman on a 2021 m1 mac, and Docker Desktop on WSL under windows. The only issue I'm having is with the images produced by podman. It doesn't have arm64 and amd64 manifests in the image.
# built under WSL with Docker Desktop on Windows 11
❯ docker buildx imagetools inspect us.icr.io/icm-docker-images/varnish-operator:wsl-support
Name:      us.icr.io/icm-docker-images/varnish-operator:wsl-support
MediaType: application/vnd.docker.distribution.manifest.list.v2+json
Digest:    sha256:555238d753bee3066abdf52e76927ea28294b3ad0cd35ad61b54c6e2df7bc4d4

Manifests:
  Name:      us.icr.io/icm-docker-images/varnish-operator:wsl-support@sha256:38de421069d3899c00ca9e04026dedc017596a36d83fd6c2e117543da735fa67
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/amd64

  Name:      us.icr.io/icm-docker-images/varnish-operator:wsl-support@sha256:105e783c9c3200ce16e63e66cfaf2ec9969af36f3553b8fdb8eca28a767c452b
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/arm64

# built on x86 mac w/Rancher Desktop as Docker Desktop replacement
❯ docker buildx imagetools inspect us.icr.io/icm-docker-images/varnish-operator:arm-support
Name:      us.icr.io/icm-docker-images/varnish-operator:arm-support
MediaType: application/vnd.docker.distribution.manifest.list.v2+json
Digest:    sha256:bd39b9d54fa6ccb46cb57bbc2e9c7368cc67eef182a8fc2c87bc15196d2ec9c0

Manifests:
  Name:      us.icr.io/icm-docker-images/varnish-operator:arm-support@sha256:3174538fe2ca304f658ae11d2057739ae7880d4235da4368c52ed25db69e1870
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/arm64

  Name:      us.icr.io/icm-docker-images/varnish-operator:arm-support@sha256:91713a00743b47c194580494a25fefcfd80937b9cc6b385e85e3e49c8304b08a
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/amd64

# built on m1 mac with podman
❯ docker buildx imagetools inspect us.icr.io/icm-docker-images/varnish-operator:m1-arm
Name:      us.icr.io/icm-docker-images/varnish-operator:m1-arm
MediaType: application/vnd.oci.image.manifest.v1+json
Digest:    sha256:3ac3ff69aee695fe6a516e676b32aabcf3d393bdcf8a2300fb99306d1bbb69fa

I think the only way I will know if the build works under GHA is to merge/tag it. I'm also having issues on the m1 mac with the e2e-tests. The create script is failing to load the images onto the kind cluster's nodes. This happens with the other images as well, so it's not just an issue with the podman produced images. The e2e-tests work fine under WSL and my old mac.
TLDR: more testing is needed at this point to determine what's going on with the m1 mac and podman.

e2e-tests failure:
+ kind load docker-image -n e2e-tests ibmcom/varnish-operator:local
using podman due to KIND_EXPERIMENTAL_PROVIDER
enabling experimental podman provider
Image: "ibmcom/varnish-operator:local" with ID "01310181d02334a075005a93719350b78e3b80bbf9557b4ef386423a6f0f3cff" not yet present on node "e2e-tests-control-plane", loading...
+ kind load docker-image -n e2e-tests ibmcom/varnish:local
using podman due to KIND_EXPERIMENTAL_PROVIDER
enabling experimental podman provider
Image: "ibmcom/varnish:local" with ID "09c78f243e69900cccf78c18e11eccccf987df349a08ee06eb0c3915f222225d" not yet present on node "e2e-tests-control-plane", loading...
ERROR: failed to load image: command "podman exec --privileged -i e2e-tests-control-plane ctr --namespace=k8s.io images import --digests --snapshotter=overlayfs -" failed with error: exit status 1
Command Output: ctr: image might be filtered out
make: *** [e2e-tests] Error 1


refactors init params across encoders

Hi @Morgan-Sell
My request was a bit more complicated than expected, thanks to you picking up that not all encoders share the 3 parameters in question.
So, I refactored the master class and added a child class to expand the params, and then refactored all encoders.
Please have a look at these changes and merge if you are happy with them :)

Looks good to me! Ahhhh, yes, I forgot to include super() to inherit the parent class's attributes.


[OpenACC-OpenMP] Incorrect results while offloading the code to GPUs after migration but gives correct results on CPU

I tried migrating the openACC code Cholesky_Decomp using the https://github.com/intel/intel-application-migration-tool-for-openacc-to-openmp.]
The code migrated successfully but the results are incorrect.
 So i guess the issue lies within the migrated openmp pragmas.
Could someone please confirm if there is an issue with the openacc-openmp migration tool ?

Hello @vidyalathabadde
please, note that the translator cannot perfectly translate from OpenACC to OpenMP. There are several limitations, so we consider the translated a suggestion that needs supervision, at least up to now.
That said -- can you provide further details as which version of the translator and compiler are you using?
I will take a look into it, given the fact that the code is rather simple. Please, give me the requested details and I'll come back to you.
Best,

Thanks for the help @hservatg .
icx --version : 2024.2.0
Coming to translator version i cannot tell it exactly.. is there a way to check it?

For the translator version -- what does  "git log --pretty=format:"%h" | head -1" give you?

It seems that the issue comes from the translation of this OpenACC statement
#pragma acc data create(a) copyin(sm) copyout(a[0:N][0:N])
which is translated into
#pragma omp target data map(to:sm) map(from:a[0:N][0:N]) map(alloc:a)
Interestingly, if one removes map(alloc:a), it seems to provide the correct results.
Not sure if this is a compiler or an OpenMP-spec related issue. Need to investigate this.

Thanks @hservatg for getting back. As the fortran compiler is throwing errors, is there anything to change from the translator tool side?

@vidyalathabadde -- after scrutinizing the OpenMP spec with some of my colleagues, it seems that the Fortran compiler is wrong. It seems legit that the same variable appears in more than one map() clause.
That said -- it seems that the problem lies around the mix of map(alloc:a) and map(from:a[0:N][0:N]) clauses in the target data map. Let me investigate that further.

Hi @hservatg ,
Any update on the issue?

Hello @vidyalathabadde -- I was on vacation.
I'm afraid that this particular issue needs manual fixing as of now. The OpenACC > OpenMP tool could check for the same variable (a) appears in an alloc and from but in this particular case the additional range in one of them makes it impossible to match because the tool does not know the actual sizing of the referenced variable. I think I could raise a warning in the summary, though.
Sorry about that.

>>I think I could raise a warning in the summary, though.
Hi @hservatg, Thanks for considering the issue. when do you plan to include this?

@vidyalathabadde  -- I have extended the tool to raise warnings whenever this issue is detected.  For instance, in the example you shared, it shows:
* Line 96 contains the following statement
#pragma acc data create(a) copyin(sm) copyout(a[0:N][0:N])
that has been as been translated into:
#pragma omp target data map(to:sm) map(from:a[0:N][0:N]) map(alloc:a)
* WARNING(s)! Please review the translation.
  1. Potential mapping overlap between map(alloc:a) and map(from:a). Try to unify to avoid potential data mapping issues, for instance map(from:a).

But as said, this is not a programming error. I've already created an internal compiler ticket to get this fixed in the compilers.


Be careful about where we change braces in closures

And some general refactoring of closure code.
Fixes #863
r? @marcusklaas

addressed the dodgy change

I guess I too have become a little accustomed to the new style in the past 15 minutes :-P
r+ when travis gives the green light


UI footer

Hi,
I would like to add the trademark in the middle which is currently on to the left side of website which is a must to be viewed and also the Questions part would like to add on the last part.
@07sumit1002 and @sanjay-kv pl. do assign me the task

sorry i cant assign issue on someone else repo, i can only help you manage the labels. tag the admin to get assign,.

@sanjay-kv can you pl. tag the admin, @07sumit1002 can you assign me the task

@RitikaMaha its only 9hrs, you raised this issue, give some time, maybe a day or 2 and foucs on other 199 repos. whoever assigns issue faster stick and contribute in that repo. thanks


Reorg for converters gelu (FX Converter Refactor [13/N]) <Target: converter_reorg_proto>

This PR needs to target converter_reorg_proto

Closing in favor of https://github.com/pytorch/TensorRT/pull/2070


Add the option to disable IPX function

Summary
Add the option to disable IPX function using DISABLE_IPX env var.
To be honest I would disable IPX by default and give the option to enable it via an env var (Having this enabled by default put Netlify customer at risk of XSS), but this PR does the opposite since it would be a breaking change.

https://github.com/netlify/next-runtime/issues/1605


Dot . will be duplicated if suggestions are allowed for words beginning with a dot . in RMarkdown R code chunks

Describe the bug
For example, if I want to enter the option .groups for the function dplyr::summarise(), and I select the suggested candidate on a .Rmd file, I will get ..groups, which has a duplicated dot.
In .R file (works fine)

In .Rmd file

To Reproduce
See the videos above.
setting.json
"editor.tabCompletion": "on"

Environment (please complete the following information):

OS: Windows + Remote Ubuntu (Docker Container)
VSCode Version: 1.63.2
R Version: 4.1.2
vscode-R version: 2.3.5

I wonder if this is related to #821, which is also has strange extra characters appearing autocompletions in Rmd files.

Thank you for pointing this out.
This seems to be a duplicate of #821.


Abug which Result in Crashing of Application

The whole Application is working fine there is a bug creating problem.

please assign this issue to me.

Best of luck @tanvi2508 Keep Contributing...


iOS app crashing throwing error: libc++abi: terminating with uncaught exception of type NSException Message from debugger: Terminated due to signal 6

When I was running from Xcode iOS app crashed and when I running app with react native command It successfully run but There is one issue
My unity view is not loaded only white screen showing

It seems something is wrong with your setup. Does the included example app work for you?


App is exited on back button pressed

I am using on android 13. when bottom navigation back button is pressed, then app is exited. please solve.

sorry for late answer please could you please add image or video ?
@rinkuanuragkumar


Release Notes Doesn't Retain Scroll Position

Issue Type: Bug
When reading the release notes, it often lists new settings features.  A user will often discover these features as they scrolled down through the release notes.
The user then might open the settings tab to adjust for the new options. When the user clicks back to the Release Notes tab, the scroll position is lost and the user is back to the top of the release notes.
See this video: https://watch.cloudflarestream.com/081964d7237d045663c43445fa51c1cb
VS Code version: Code 1.53.0 (8490d3dde47c57ba65ec40dd192d014fd2113496, 2021-02-03T16:01:04.046Z)
OS version: Darwin x64 19.6.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz (8 x 3100)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
7, 3, 3

Memory (System)
16.00GB (0.03GB free)

Process Argv
-psn_0_30276830 --crash-reporter-id e6bed93b-dfae-4b13-a937-b05d7455ce20

Screen Reader
no

VM
0%

Extensions (18)

Extension
Author (truncated)
Version

jelly-language-support
Act
0.9.0

vscode-icalendar
af4
1.0.1

vscode-tailwindcss
bra
0.5.8

vscode-expo
byC
0.1.2

cacher-vscode
Cac
1.1.1

vscode-eslint
dba
2.1.14

gitlens
eam
11.2.1

prettier-vscode
esb
5.9.1

easy-snippet
inu
0.6.2

python
ms-
2021.1.502429796

jupyter
ms-
2020.12.414227025

vscode-typescript-tslint-plugin
ms-
1.3.3

polacode
pnp
0.3.4

prisma
Pri
2.16.0

synthwave-vscode
Rob
0.1.8

html5-boilerplate
sid
1.1.1

rewrap
stk
1.13.0

highlight-matching-tag
vin
0.10.0

(3 theme extensions excluded)

/duplicate of #115791
Problem has existed in previous versions too.


install fails on debian 8

# apt-get install nodejs npm mongodb graphicsmagick
...
# npm install -g pump.io
npm WARN deprecated<EMAIL_ADDRESS>Jade has been renamed to pug, please install the latest version of pug instead of jade
The authenticity of host 'github.com (<IP_ADDRESS>)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
-\e you sure you want to continue connecting (yes/no)? -
npm ERR! git clone git@github.com:github:e14n/connect-auth Cloning into bare repository '/root/.npm/_git-remotes/git-github-com-github-e14n-connect-auth-b91d704e'...
npm ERR! git clone git@github.com:github:e14n/connect-auth Warning: Permanently added 'github.com,<IP_ADDRESS>' (RSA) to the list of known hosts.
npm ERR! git clone git@github.com:github:e14n/connect-auth Permission denied (publickey).
npm ERR! git clone git@github.com:github:e14n/connect-auth fatal: Could not read from remote repository.
npm ERR! git clone git@github.com:github:e14n/connect-auth
npm ERR! git clone git@github.com:github:e14n/connect-auth Please make sure you have the correct access rights
npm ERR! git clone git@github.com:github:e14n/connect-auth and the repository exists.
npm ERR! notarget No compatible version found: connect-auth@'github:e14n/connect-auth'
npm ERR! notarget Valid install targets:
npm ERR! notarget ["0.0.1","0.0.2","0.0.3","0.1.0","0.1.1","0.1.2","0.1.3","0.2.0","0.2.1","0.2.2","0.2.3","0.3.0","0.3.1","0.3.2","0.4.0","0.4.1","0.5.0","0.4.2","0.4.3","0.5.1","0.5.2","0.5.3","0.5.4","0.6.0","0.6.1"]
npm ERR! notarget
npm ERR! notarget This is most likely not a problem with npm itself.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

npm ERR! System Linux 4.9.7-x86_64-linode80
npm ERR! command "/usr/bin/nodejs" "/usr/bin/npm" "install" "-g" "pump.io"
npm ERR! cwd /usr/share/doc/npm
npm ERR! node -v v0.10.29
npm ERR! npm -v 1.4.21
npm ERR! code ETARGET
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     /usr/share/doc/npm/npm-debug.log
npm ERR! not ok code 0

exit code 1

Looks to me like
git@github.com:github:e14n/connect-auth

in the log should be
https://github.com/e14n/connect-auth

I can clone the latter, not the former.


Jsonapi work towards v1.0 spec.

First off, I'm still getting the hang of representable / roar's internals & your coding style, so suggestions and better / cleaner ways to do things very much appreciated :). Please consider this PR 'in progress' and a request for feedback.
Onward:
I've been working on the JSONAPI implementation, trying to get it to more accurately match the v1 spec, and I've made some progress. Specifically, basic "attributes" and "relationships" support is more or less done. I removed the "links" method, as I don't think it really fits with JSONAPI any more, but correct me if I'm wrong. I wasn't entirely sure what semantics it was trying to fulfil there.
The included / compound concept still needs a lot of work... according to the spec it's supposed to be a single level array (not object) at the top level of the document, and for an object to be there it must be listed as a relationship on something else (either the main document or one of it's embedded relationships) It also must have a type/id pair, like everything else. With the current API expressed by the tests (just passing a block) I don't think this is really doable. I've been wondering if it wouldn't be better to handle this with an option on has_one and has_many (e.g. has_one :album, include: true) which would add the related objects to the 'included' array, and do away with the compound keyword altogether?

Thanks so much for your work, the master branch should have an almost working version now!


host to service network not working after reboot/join after upgrade from v3.26.3 to v3.27.3 (v3.28.0) ebpf dataplane/vxlan/no kube-proxy/dsr

host to service network not working after reboot/join after upgrade from v3.26.3 to v3.27.3 ebpfdataplane/vxlan/no kube-proxy/dsr
killing calico-node pod immediately fixing the problem
Expected Behavior
host to service network working well after node reboot/join
Current Behavior
host to kube service network not working after reboot/join node unless you kill calico-node pod
it start working after it
Possible Solution
kill calico-node pod on restarted or joined node
kubectl delete pod -n calico-system calico-node-xxxxx

Steps to Reproduce (for bugs)

reboot node
try to connect from the rebooted host to any kube service (kube-dns like example)

nslookup example.com {kube-dns svc ip}

fail

Context
Any pods with a host network would fail to start after rebooting/joining node
Cluster network works fine
Your Environment

Calico version: v3.27.3 v3.28.0
Helm chart: projectcalico/tigera-operator:v3.28.0

  - chart: projectcalico/tigera-operator
    version: v3.28.0
    name: calico
    namespace: tigera-operator
    values:
      - installation:
          calicoNetwork:
            linuxDataplane: BPF
            mtu: 8950
            bgp: Disabled
            ipPools:
              - cidr: <IP_ADDRESS>/14
                blockSize: 20
                encapsulation: VXLAN

kind: ConfigMap
apiVersion: v1
metadata:
  name: kubernetes-services-endpoint
  namespace: tigera-operator
data:
  KUBERNETES_SERVICE_HOST: "<IP_ADDRESS>"
  KUBERNETES_SERVICE_PORT: "6443"

apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  annotations:
    operator.tigera.io/bpfEnabled: "true"
  creationTimestamp: "2023-11-09T09:16:01Z"
  generation: 1
  name: default
  namespace: calico-system
  resourceVersion: "65934135"
  uid: 5d0de475-8603-4e7b-9282-baecc231e48e
spec:
  bpfEnabled: true
  bpfExternalServiceMode: DSR
  bpfLogLevel: ""
  floatingIPs: Disabled
  healthPort: 9099
  logSeverityScreen: Info
  reportingInterval: 0s
  vxlanMTU: 8950
  vxlanVNI: 4096

# /etc/NetworkManager/conf.d/calico.conf
[keyfile]
unmanaged-devices=interface-name:cali*;interface-name:bpf*.cali*;interface-name:tunl*;interface-name:vxlan.calico;interface-name:vxlan-v6.calico;interface-name:wireguard.cali;interface-name:wg-v6.cali

apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
certificateKey: ""
skipPhases:
  - addon/kube-proxy
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
  serviceSubnet: "<IP_ADDRESS>/16"
  podSubnet: "<IP_ADDRESS>/14"
  dnsDomain: "l8s.local"
controllerManager:
  extraArgs:
    "node-cidr-mask-size": "20"
    "allocate-node-cidrs": "false"
apiServer:
  certSANs:
    - "<IP_ADDRESS>"
    - "<IP_ADDRESS>"
    - "k8clust-lon01.l8s.space"
clusterName: "k8clust-lon01"
controlPlaneEndpoint: "k8clust-lon01.l8s.space:6443"
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
maxPods: 4000
cgroupDriver: systemd
serverTLSBootstrap: true

Orchestrator version:
kubernetes 1.29.5
Operating System and version:

# uname -r
5.14.0-452.el9.x86_64
# cat /etc/os-release
NAME="CentOS Stream"
VERSION="9"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="9"
PLATFORM_ID="platform:el9"
PRETTY_NAME="CentOS Stream 9"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:centos:centos:9"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://issues.redhat.com/"
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_SUPPORT_PRODUCT_VERSION="CentOS Stream"

calico-node log after new node join
calico-node install-cni log after new node join
calico-node log after killling pod
ccalico-node install-cni log after killling pod

killing calico-node pod immediately fixing the problem

What changes after killing the pod. Could you share your routing table before/after?

Did you have ctlb disabled before upgrade?

Did you have ctlb disabled before upgrade?

Nope
Can you provide additional parameters which I need to set up?
I think it is something with
bpfConnectTimeLoadBalancingEnabled
bpfConnectTimeLoadBalancing
bpfHostNetworkedNATWithoutCTLB
It's all not set up currently

killing calico-node pod immediately fixing the problem

What changes after killing the pod. Could you share your routing table before/after?

Routes almost did not change
I am checkins via dns resolviong against kube-dns service and it is there after reboot (when it is not working) and after killing pod (when it is working).
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali

killing calico-node pod immediately fixing the problem

What changes after killing the pod. Could you share your routing table before/after?

Routes almost did not change I am checkins via dns resolviong against kube-dns service and it is there after reboot (when it is not working) and after killing pod (when it is working).
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali

That route is correct. Since iirc 3.27 we route traffic from host to UDP service via that device by default.

I wonder is some routes caching is in play. Could you dump ip route show cached ?

I wonder is some routes caching is in play. Could you dump ip route show cached ?
ip route show cached
it is empty before and after killing the pod

BTW
Apparently, I have a problem with only services pinned in the route table
And apparently, they are all UDP services (dns services)
There are no tcp services in the route table and they are working fine (tested kube api service via cservice api and nginx ingress)

Just to confirm, do you see the same problem from host-networked pods/processes or from regular pods as well?
I tried to reproduce the issue, I created a cluster in gcp with kubeadm and installed calico 3.26.4 and upgraded to 3.28 and my DNS did worked just fine.
Would you be able to tcpdump whether your traffic is reaching the service, what kind of packets are exiting from bpfout.cali on your test node?
If your cluster is not a production cluster we could dig deeper with enabling bpf logging to get some more useful logs. Ideally we could sync at calico users slack.

Just to confirm, do you see the same problem from host-networked pods/processes or from regular pods as well?

Regular pods don't have a problem. They work fine.
So only  host-networked pods/processes have problem

Would you be able to tcpdump whether your traffic is reaching the service, what kind of packets are exiting from bpfout.cali on your test node?

bpfout.cali.pcap.gz
I tested with
nslookup openebs-api-rest.openebs.svc.l8s.local. <IP_ADDRESS>

That doesn't seem to be a problem :arrow_up: Do you see packets returning to the client in both cases? <IP_ADDRESS> is a local pod or remote?
you could also enable :arrow_down:  in default felixconfiguration and provide bpf logs from the node using bpftool prog tracelog > log.txt for the case when it does not work. That should give us good insight.
bpfLogLevel: Debug
bpfLogFilters:
  - all: host <IP_ADDRESS> and udp port 53

<IP_ADDRESS> is a local pod or remote?

it's a service IP
pods behind that IP are remote
BTW hostNetwoork -> pod IP has no issue

bpfLogLevel: Debug
bpfLogFilters:

all: host <IP_ADDRESS> and udp port 53

that does not work
this changes have been accepted by API
  bpfLogLevel: Debug
  bpfLogFilters:
    all: host <IP_ADDRESS> and udp port 53

however bpfLogFilters property disappeared from object
so anyway here is a log probably not filtered
bpflog.txt.gz

BTW I found a repeated error in the tigera operator
probably not related to this issue
{"level":"error","ts":"2024-06-12T08:07:07Z","logger":"controller_ippool","msg":"Cannot update an IP pool not owned by the operator","Request.Namespace":"","Request.Name":"periodic-5m0s-reconcile-event","reason":"ResourceValidationError","stacktrace":"github.com/tigera/operator/pkg/controller/status.(*statusManager).SetDegraded\n\t/go/src/github.com/tigera/operator/pkg/controller/status/status.go:356\ngithub.com/tigera/operator/pkg/controller/ippool.(*Reconciler).Reconcile\n\t/go/src/github.com/tigera/operator/pkg/controller/ippool/pool_controller.go:291\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.3/pkg/internal/controller/controller.go:118\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.3/pkg/internal/controller/controller.go:314\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.3/pkg/internal/controller/controller.go:265\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.15.3/pkg/internal/controller/controller.go:226"}

Thanks for the logs, helpful. It seems like the packets from bpfout.cali do not make it to any other device. Perhaps worth verifying with tcpdump. They seem to be eaten by the host network stack. They either have a wrong csum (unlikely that would not get fixed by  calico-node restarting) or they get dropped by RPF (could you check the value in /proc/sys/net/ipv4/conf/bpfout.cali/rp_filter) which could be strict and then fixed after the restart. Or it gets dropped by iptables. I will give it some more try to reproduce it.

Before pod killing (after node restart when we have the problem)
cat /proc/sys/net/ipv4/conf/bpfout.cali/rp_filter
1

route
route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
<IP_ADDRESS>         <IP_ADDRESS>      <IP_ADDRESS>         UG    100    0        0 eth0
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>    <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>    <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>    <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>    <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>    <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 *
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS> UH    0      0        0 califee8cfb24e3
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS> UH    0      0        0 calie89ffdb4633
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS> UH    0      0        0 cali193e57c628e
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS> UH    0      0        0 calid31be247766
<IP_ADDRESS>    <IP_ADDRESS>    <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>    <IP_ADDRESS>    <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS> UH    0      0        0 bpfin.cali
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>   U     100    0        0 eth0

iptables
iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* cali:zkuE8qdwsVpH6Kd2 */ /* Accept packets from flows that pre-date BPF. */ mark match 0x5000000/0x5000000 ctstate RELATED,ESTABLISHED
DROP       all  --  anywhere             anywhere             /* cali:XQL0mC-L6wldZdgN */ /* Drop packets from unknown flows. */ mark match 0x5000000/0x5000000
ACCEPT     all  --  anywhere             anywhere             /* cali:pbFdTFCLcV-MVLSS */ mark match 0x1000000/0x1000000
DROP       all  --  anywhere             anywhere             /* cali:u_TyW7ph8QsYnThE */ mark match ! 0x1000000/0x1000000
KUBE-FIREWALL  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* cali:umcmOn0WnTNOKJrp */ /* Pre-approved by BPF programs. */ mark match 0x3000000/0x3000000
DROP       all  --  anywhere             anywhere             /* cali:NnQ109Z-tVFkJGc1 */ /* From workload without BPF seen mark */ mark match ! 0x1000000/0x1000000
MARK       all  --  anywhere             anywhere             /* cali:YmI_zfAgHIHbINEV */ /* Mark pre-established flows. */ ctstate RELATED,ESTABLISHED MARK or 0x8000000
cali-to-wl-dispatch  all  --  anywhere             anywhere             /* cali:-EFgmtwMJVO64q9s */ /* To workload, check workload is known. */
ACCEPT     all  --  anywhere             anywhere             /* cali:wP1i1sEU71uRzM5d */ /* To workload, mark has already been verified. */
ACCEPT     all  --  anywhere             anywhere             /* cali:3t5V_2xe4DFVlHBq */ /* From  */ /* bpfout.cali */ /*  device, mark verified, accept. */

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
MARK       all  --  anywhere             anywhere             /* cali:CD7jZCSqPP_KjGsd */ /* Mark pre-established flows. */ ctstate RELATED,ESTABLISHED MARK or 0x8000000
KUBE-FIREWALL  all  --  anywhere             anywhere

Chain KUBE-FIREWALL (2 references)
target     prot opt source               destination
DROP       all  -- !<IP_ADDRESS>/8          <IP_ADDRESS>/8          /* block incoming localnet connections */ ! ctstate RELATED,ESTABLISHED,DNAT

Chain KUBE-KUBELET-CANARY (0 references)
target     prot opt source               destination

Chain cali-to-wl-dispatch (1 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* cali:cEwZ48PLVj36YM8T */
ACCEPT     all  --  anywhere             anywhere             /* cali:Geyg9JmnnDNPlLHX */
ACCEPT     all  --  anywhere             anywhere             /* cali:ICRLMI_1Qq8A0HWR */
ACCEPT     all  --  anywhere             anywhere             /* cali:bhG4cOJs_TnufY0G */
DROP       all  --  anywhere             anywhere             /* cali:k6ZOE-XDbClrqbFe */ /* Unknown interface */

After pod killing (when it is working well)
cat /proc/sys/net/ipv4/conf/bpfout.cali/rp_filter
0

route
route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
<IP_ADDRESS>         <IP_ADDRESS>      <IP_ADDRESS>         UG    100    0        0 eth0
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>    <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>    <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>    <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>    <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>    <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>  <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>   <IP_ADDRESS>     <IP_ADDRESS> UGH   0      0        0 bpfin.cali
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 *
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS> UH    0      0        0 califee8cfb24e3
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS> UH    0      0        0 calie89ffdb4633
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS> UH    0      0        0 cali193e57c628e
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS> UH    0      0        0 calid31be247766
<IP_ADDRESS>    <IP_ADDRESS>    <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>     <IP_ADDRESS>     <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>    <IP_ADDRESS>    <IP_ADDRESS>   UG    0      0        0 vxlan.calico
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS> UH    0      0        0 bpfin.cali
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>   U     100    0        0 eth0

iptables
iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* cali:zkuE8qdwsVpH6Kd2 */ /* Accept packets from flows that pre-date BPF. */ mark match 0x5000000/0x5000000 ctstate RELATED,ESTABLISHED
DROP       all  --  anywhere             anywhere             /* cali:XQL0mC-L6wldZdgN */ /* Drop packets from unknown flows. */ mark match 0x5000000/0x5000000
ACCEPT     all  --  anywhere             anywhere             /* cali:pbFdTFCLcV-MVLSS */ mark match 0x1000000/0x1000000
DROP       all  --  anywhere             anywhere             /* cali:u_TyW7ph8QsYnThE */ mark match ! 0x1000000/0x1000000
KUBE-FIREWALL  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* cali:umcmOn0WnTNOKJrp */ /* Pre-approved by BPF programs. */ mark match 0x3000000/0x3000000
DROP       all  --  anywhere             anywhere             /* cali:NnQ109Z-tVFkJGc1 */ /* From workload without BPF seen mark */ mark match ! 0x1000000/0x1000000
MARK       all  --  anywhere             anywhere             /* cali:YmI_zfAgHIHbINEV */ /* Mark pre-established flows. */ ctstate RELATED,ESTABLISHED MARK or 0x8000000
cali-to-wl-dispatch  all  --  anywhere             anywhere             /* cali:-EFgmtwMJVO64q9s */ /* To workload, check workload is known. */
ACCEPT     all  --  anywhere             anywhere             /* cali:wP1i1sEU71uRzM5d */ /* To workload, mark has already been verified. */
ACCEPT     all  --  anywhere             anywhere             /* cali:3t5V_2xe4DFVlHBq */ /* From  */ /* bpfout.cali */ /*  device, mark verified, accept. */

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
MARK       all  --  anywhere             anywhere             /* cali:CD7jZCSqPP_KjGsd */ /* Mark pre-established flows. */ ctstate RELATED,ESTABLISHED MARK or 0x8000000
KUBE-FIREWALL  all  --  anywhere             anywhere

Chain KUBE-FIREWALL (2 references)
target     prot opt source               destination
DROP       all  -- !<IP_ADDRESS>/8          <IP_ADDRESS>/8          /* block incoming localnet connections */ ! ctstate RELATED,ESTABLISHED,DNAT

Chain KUBE-KUBELET-CANARY (0 references)
target     prot opt source               destination

Chain cali-to-wl-dispatch (1 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* cali:cEwZ48PLVj36YM8T */
ACCEPT     all  --  anywhere             anywhere             /* cali:Geyg9JmnnDNPlLHX */
ACCEPT     all  --  anywhere             anywhere             /* cali:ICRLMI_1Qq8A0HWR */
ACCEPT     all  --  anywhere             anywhere             /* cali:bhG4cOJs_TnufY0G */
DROP       all  --  anywhere             anywhere             /* cali:k6ZOE-XDbClrqbFe */ /* Unknown interface */

cat /proc/sys/net/ipv4/conf/bpfout.cali/rp_filter -> 1
vs
cat /proc/sys/net/ipv4/conf/bpfout.cali/rp_filter -> 0

That is the problem. Something sets it to 1(strict) and when calico-node restarts, is sets it back to 0. The something is probably your systemd which applies configuration when a new device is added. Seems like the issue is present with systemd 245+ What is your linux distro (which I should have asked a while ago)?

What is your linux distro (which I should have asked a while ago)?

# uname -r
5.14.0-452.el9.x86_64
# cat /etc/os-release
NAME="CentOS Stream"
VERSION="9"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="9"
PLATFORM_ID="platform:el9"
PRETTY_NAME="CentOS Stream 9"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:centos:centos:9"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://issues.redhat.com/"
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_SUPPORT_PRODUCT_VERSION="CentOS Stream"

@a-sorokin-sdg do you still see the issue? Have you figured what is changing the rpf? Closing now, but feel free to reopen if you have any new info.

Yes, still have an the issue.
I have tried to catch who change it via audit without success.

Yes, still have an the issue.
I have tried to catch who change it via audit without success.

Haven't cought calico right on bpf.cali eth setting rp_filter
But cought it with pod eth rp_filter setting
2024-11-13 09:40:43.865 [ERROR][9990] felix/bpf_ep_mgr.go 3062: Failed to  set /proc/sys/net/ipv4/conf/calie2b07182c0a/rp_filter to 2 err=open /proc/sys/net/ipv4/conf/calie2b07182c0a/rp_filter: no such file or directory
2024-11-13 09:40:43.865 [WARNING][9990] felix/bpf_ep_mgr.go 1075: Failed to set rp_filter for calie2b07182c0a. error=open /proc/sys/net/ipv4/conf/calie2b07182c0a/rp_filter: no such file or directory


Fields name 'description' print/return whole object

Issue Description
[DELETE EVERYTHING ABOVE THIS LINE BEFORE SUBMITTING YOUR ISSUE]
Describe your issue in as much detail as possible.
Returning any class with a column named description in the object prints the whole object when querying the column description
Steps to reproduce
Please include a detailed list of steps that reproduce the issue. Include curl commands when applicable.

Created a TEST class in my Parse-Server with items idKey name description
Created an object in TEST class idKey=11111 : name = Testing Description Bug : description = This description should print when queried without printing whole object.
Added this query to an IBOutlet in my iOS app that request print of description field only:

		PFQuery *q1 = [PFQuery queryWithClassName:@"TEST"];
		[q1 whereKey:@"idKey" equalTo:@"11111"];
		[q1 findObjectsInBackgroundWithBlock:^(NSArray * _Nullable objects, NSError * _Nullable error) {

			NSLog(@"TEST DESCRIPTION BUG %@", [objects[0]valueForKeyPath:@"description"]);

		}];

Run the method

Expected Results
NSLog response:
TEST DESCRIPTION BUG This description should print when queried without printing whole object

Actual Outcome
NSLog response:
TEST DESCRIPTION BUG <TEST: 0x7b86b180, objectId: hG1KmlGzds, localId: (null)> {
    description = "This description should print when queried without printing whole object.";
    idKey = 11111;
    name = "Testing Description Bug";
}

When I change my NSLog print log to the name or idKey field I get the appropriate response:
		PFQuery *q1 = [PFQuery queryWithClassName:@"TEST"];
		[q1 whereKey:@"idKey" equalTo:@"11111"];
		[q1 findObjectsInBackgroundWithBlock:^(NSArray * _Nullable objects, NSError * _Nullable error) {

			NSLog(@"TEST DESCRIPTION BUG %@", [objects[0]valueForKeyPath:@"name"]);

		}];

Console Log:

TEST DESCRIPTION BUG Testing Description Bug

Environment Setup

Server

parse-server version 2.2.24
Operating System:  Ubuntu 16.04 LTE up to date
Hardware:
Localhost or remote server? Remote - own datacenter

Database

MongoDB version: 3.2.10
Storage engine:  NA
Hardware:
Localhost or remote server? Remote from Parse Server - own datacenter

Logs/Trace
You can turn on additional logging by configuring VERBOSE=1 in your environment.
[FILL THIS OUT]

This doesn't seem like a server-side issue. You may want to open this as an issue on the Parse iOS SDK itself.


Doubly-dependent record field

Hello
What is the best way to achieve this:
type t =
{
    a : bool;
    b : (if a then bool else unit);
    c : (if a then (if b then string else unit) else unit);
}

I know it's possible to just factor out the common if a then ... else ... into a separate record, like below, but can this factoring out be avoided with a nice, inline solution?
type aux =
{
    b : bool;
    c : (if b then stirng else unit);
}

type t =
{
    a : bool;
    bc : (if a then aux else unit);
}

In Coq this thing is simple, you can just do a double match:
Record t : Type :=
{
    a : bool;
    b : if a then bool else unit;
    c :
      match a, b with
          | true, true => string
          | _   , _    => unit
      end;
}.

Hi,
I think your first definition doesn't work because F* does not even try to unify the type of the condition passed to the if _ then _ else _ combinator with bool, it just expects "plain" bool.
You could just wrap your b into the identity function for instance (the code below works) so that F* actually try to unify the type of your field b with bool. id will more or less yield a proof obligation (if a then bool else unit) <: bool that is easily discharged by normalization/unfolding.
type t =
{
    a : bool;
    b : (if a then bool else unit);
    c : (if a then (if id b then string else unit) else unit);
}

An even more explicit version:

let dep (b:bool) (t: (_:unit{b} -> Type))
                 (f: (_:unit{~b} -> Type))
    = if b then t() else f()
let as_t #b #t #f (x:dep b t f{ b }) : t() = x
let as_f #b #t #f (x:dep b t f{ ~b }) : f() = x

type t =
{
    a : bool;
    b : dep a (fun _ -> bool) (fun _ -> unit);
    c : dep a (fun _ -> dep b (fun _ -> string) (fun _ -> unit))
              (fun _ -> unit)
}

But you make a good point. The version that you wrote originally with the match on the tuple could be made to work with some tweaks to type inference ... will try.


Test disabled question validator behaviour

Description
Test disabled question validator behaviour
Type of change

[ ] Refactor
[ ] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library
[x] Unit test

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (af0f066) 95.28% compared to head (a6c2259) 95.48%.
Report is 11 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #349      +/-   ##
==========================================
+ Coverage   95.28%   95.48%   +0.19%
==========================================
  Files          32       32
  Lines        1039     1040       +1
==========================================
+ Hits          990      993       +3
+ Misses         49       47       -2

Files
Coverage Δ

ols/app/models/models.py
100.00% <ø> (ø)

ols/src/cache/cache.py
100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

/approve
/lgtm


failed to insert new head to L2 execution engine

simple-taiko-node-taiko_client_driver-1          | ERROR[06-08|12:39:58.631] Block batch iterator callback error      error="failed to insert new head to L2 execution engine: missing trie node 49c392582ec938adb8a9823446d90cc0418e576e1a19d9f9fddc08961e016a05 (path ) <nil>"

When running simple-taiko-node and restarting it, it starts showing this error and prover doesn't work anymore. The only way to fix it is to delete volumes and start again.
Possible cause is docker forcefully stopping it after 10 seconds

Since for A3 network, when we build a pending block's anchor tx, we need to query the "L1signalRoot" by an eth_getProof RPC query (now we have ~300 L2 pending blocks in avg), but a Sepolia geth's full node will only store last 128 blocks' state trie, so if a user's Sepolia provider only provides "Sepolia full node endpoint" but not "Sepolia archived node enpoint", u will get this error (missing trie node). And the solution is using a archived Sepolia node's endpoint.

Closed by https://github.com/taikoxyz/taiko-mono/pull/13942

I'm using Alchemy, don't they use archive node?

How do I determine whether an RPC node is a full node or an archive node?


fixes Multiplication{F,ConstantSpace,T}

I thinnk this works. The default was adding entries of the matrix of
Multiplication values in the space of f, but from ConstantSpace we only
need the first column (Σ[F] is an operator of the same rank as F).
Not sure how the default Multiplication was interacting with the
Conversion operator from a ConstantSpace. This might be missing
something from either type promotion or array-valued spaces. The tests
passed though.
Closes #184.

There's about a 30% speed boost in solving SIEs! The first time is the GreensFun, the second time is the solve. On branch:
include("Scattering.jl")
elapsed time: 2.240551216 seconds (924034136 bytes allocated, 49.56% gc time)
elapsed time: 1.988550999 seconds (429795248 bytes allocated, 21.36% gc time)
The length of ∂u∂n is: 272

On master/development:
include("Scattering.jl")
elapsed time: 2.203041633 seconds (924187956 bytes allocated, 47.71% gc time)
elapsed time: 2.842617216 seconds (654735840 bytes allocated, 19.79% gc time)
The length of ∂u∂n is: 272

Coverage decreased (-5.62%) to 46.49% when pulling 176118f1f84fa9b9bc5c35bb4c28709929bcf383 on fix-Multiplication{F,ConstantSpace,T} into e7941cb3690faa5561431c374eb687c166621f32 on development.


Update docker-compose to follow current logic in Rancher

@Robbie1977 - What's the status of this?

Sorry not had time yet. Exported all the compose scripts from the pipeline2 stack so probably best to just refer to them rather than updating a separate reference that is just as proprietary. @hkir-dev is there anything missing from local interpretation? Would it be better to create a more generic version as a ref for future reuse?

I have updated the existing compose file to use in my local (https://github.com/VirtualFlyBrain/vfb-pipeline-config/blob/dev/docker-compose-local.yml). But I only used this to build containers (up --no-start). Because compose is starting containers in order but hot waiting services to  be "ready". May need to add some synchronization mechanism for runtime, but not sure how it may affect rancher.

Need to talk with devs at Allen to understand how we can deal with these issues on AWS.


Cleanup /opencl and speedup OpenCL tests

Summary
This PR:

cleans up remaining ifdefed STAN_OPENCL code outside the /opencl folder (both stan/ and test/)
cleans up Jenkinsfile OpenCL sections
moved matrix_cl ref_type tests to test/unit/opencl

Tests
/
Side Effects
/
Release notes
Replace this text with a short note on what will change if this pull request is merged in which case this will be included in the release notes.
Checklist

[x] Copyright holder: Rok Češnovar
The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
- Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
- Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

This all looks good, ping me when the confict is fixed and I can look it over again

Had to remove jumbo as it was slower than non-jumbo.

Ready for review/merge.


Client Allocation Request for: FileDrive

Client Allocation Questions
Core Information

Name: FileDrive
Website / Social Media: http://filedrive.io
DataCap Requested: 5TiB
Addresses to be Notarized: f3wgfwtrs5p6jrkwfl2mksqa2ivgbgdjjrhjbefy3n7qzvotc3y6sazmp5gfyj7um6jlgdvlbiepzawnc6wxtq

Hey @mydoto - thanks for your request. Can you kindly add more information / context here on:

yourself , e.g. include links to social media / news mentions etc
your history working on IPFS / Filecoin, e.g. notable contributions to the community, type of engagement shown over time etc
type and source of the data you (and by extension other Discover participants) are looking to store on Filecoin, e.g. public data vs private data etc
how you intend to store the data on Filecoin, e.g. redundancy, location / miner preferences, etc

Thanks

l  yourself , e.g. include links to social media / news mentions etc
FileDrive is a open source databank powered by IPFS/Filecoin, users can retrieve any data by filename or content hash.
Our team is composed of talents with years development experience. We have self-developed underlying codes, and technical architecture and solutions of distributed storage.
Team website: https://honghupro.com
Project website: http://filedrive.io
Github: https://github.com/mydoto
l  your history working on IPFS / Filecoin, e.g. notable contributions to the community, type of engagement shown over time etc
(1)     Participating in Slingshot Phase 2 with over 300 TiB data
(2)     Participated in Slingshot Phase 1 by Protocol Labs: totally earned 6,885FIL o
①    Storage Awards: 6,335FIL
②    Community Choice Awards: Personal User Storage(Thrid Place) 500FIL
③    Booster Award: 50FIL
(3)     Startup project: DriveUp
①    Cloud storage application based on IPFS
②    Self-developed by FileDrive team
l  type and source of the data you (and by extension other Discover participants) are looking to store on Filecoin, e.g. public data vs private data etc
Public data: open source data on the list of Filecoin slingshot curated datasets
l  how you intend to store the data on Filecoin, e.g. redundancy, location / miner preferences, etc
Redundancy: at least 3 copies
Location: intend to store data in different regions
Miner: have great reputation and contribution in Filecoin Community, or are willing to participate in the test of Fil-plus, and also consider to select miners from https://www.storage.codefi.network

Hey @mydoto - thanks for providing the additional information. Two more items:

Can you share more info on the individuals behind your team? The team page on your website doesn't list names. E.g. links to social profiles would be great, if you can
Would you be OK with posting here links to the deal transactions after receiving data cap?

Thanks

Hey @philippbanhardt - here are my answers.
Q1:
Feng Li: founder of FIleDrive
Linked: https://www.linkedin.com/in/felixlee20190908/?locale=zh_CN)
Q2:
We would like to post deal transactions here.
Thanks

Hey @mydoto thanks. Do you have any stronger profile information (can also be on Chinese websites) you can share on the individuals? I.e. the LinkedIn profile you had shared doesn't seem to be very active / have a meaningful social graph - however I appreciate that this may be because it is a Western site.

Hey @philippbanhardt .  Sorry for forgetting to share the Github profile to you. Since Li is a developer, he is really not so active on social media. Hope his Github profile can present more information about him.
Feng Li on Github: https://github.com/beeleelee

Hey @mydoto apologies for the long process, but are there any other profiles, web posts (can also be in Mandarin) that have a meaningful history (e.g. have been around for more than just a few months). Also pointers to any contributions to the broader Filecoin / crypto community would be helpful (e.g. a link to Slack discussions). Thanks!

Hey @philippbanhardt
I really understand the reason why you want more information more about both FileDrive and my team, so please don’t be apologize.
Please let me show you more thing about who we are and what we are doing right now.
About FileDrive
FileDrive team has been in Filecoin ecosystem from 2019, and conscientiously concentrate on development distributed storage solution. Our vision is to build a data transaction platform on Filecoin Network.
In 2019, we independently developed DriveUp, which is a cloud storage application based on IPFS. However, since multiple reasons we had no choice but shut down this program.
In September 2020, we participated in Slingshot Phase 1. Through hard work by all team members, finally we reached a great achievement.
SR2 Slingshot Competition Phase 1 by Protocol Labs: totally earned 6,885FIL reward
①    Storage Awards(Third Place): 6,335FIL
②    Community Choice Awards: Personal User Storage(Third Place) 500FIL
③    Booster Award: 50FIL
Now, FileDrive is ranked first in Slingshot Phase 2 with over 260 TiB data.
https://slingshot.filecoin.io/
At the same time, we have applied for Filecoin Frontier Accelerator, and became one of the top 39 teams for the final interview stage.
About data source
All of the data on FileDrive are useful and valid, and from public datasets, which are on the list of Filecoin Slingshot curated datasets.
Here are PR links:
https://github.com/filecoin-project/slingshot/pull/365/commits/7857b7626d00108974af85676a1c8b55d12307a1
https://github.com/filecoin-project/slingshot/pull/364/commits/c14d4cc0012196ed8dce6d0f78e0602cb351d2fc
About web post
Slack: @flytosky @Laura Ren
Laura and I are in Filecoin Project channels. Welcome to message us on Slack.
Most of our team members are developers, they do not have much web post about themselves and their history. If you need, I can send their CV to you in private.
Thanks

Request Approved
Your Datacap Allocation Request has been approved by the Notary
Message sent to Filecoin Network

bafy2bzacecfsdyxme44t6girfmvuz5grym57d6inlduqrn6zeihtamojjpbbq

Address

f3wgfwtrs5p6jrkwfl2mksqa2ivgbgdjjrhjbefy3n7qzvotc3y6sazmp5gfyj7um6jlgdvlbiepzawnc6wxtq

Datacap Allocated

5 TiB


Optimize peekSequence

https://github.com/fpco/store/pull/26 suggests something similar might be beneficial for peekSequence.  However this is a little tricky as right now we are relying on https://hackage.haskell.org/package/mono-traversable-0.10.2/docs/Data-Sequences.html#v:replicateM .  We need something like replicateM but that does folding.  Could use StateT, but will it optimize better?
Also, implement peekMap and peekSet in terms of it.

Looking into it further I found that your INLINE commit actually removed the need for the manual inlining. It's probably not necessary now. Worth taking a look at again.

Woohoo, that's great news!