Tabbing flow on login form is email to forgot password then password field

Core Library
MSAL.js v2 (@azure/msal-browser)
Core Library Version
1.3.0
Wrapper Library
MSAL Node Extensions (@azure/msal-node-extensions)
Wrapper Library Version
none
Description
I am running Azure B2C login in an electron app. On the login window when you are in username/email field, navigating using the tab button on the keyboard will take you to forgot password link. So the flow is

email > forgot password >  password > sign button

Should be

email> password > sign button > forgot password

MSAL Configuration
No response
Relevant Code Snippets
No response
Identity Provider
Azure B2C Basic Policy
Source
External (Customer)

@amrit-moomie MSAL is not responsible for the login UI. This is a question for the B2C service, you can file a ticket with them by following these directions


Fix counting_iterator with unsigned types

:+1:  It fixes the problem for me.
I'm also wandering, shouldn't we somewhere cast value to the value_type of the result buffer iterator? Also
Without it
    bc::iota(vector.begin(), vector.end(), bc::float_(-4), queue);
    CHECK_RANGE_EQUAL(bc::float_, 4, vector, (-4, -3, -2, -1));

works, but
    bc::iota(vector.begin(), vector.end(), -4, queue);
    CHECK_RANGE_EQUAL(bc::float_, 4, vector, (-4, -3, -2, -1));

does not work like one would assume.
Full code:
BOOST_AUTO_TEST_CASE(iota_float)
{
    bc::vector<bc::float_> vector(4, context);
    bc::iota(vector.begin(), vector.end(), bc::float_(-4), queue); // this works
    CHECK_RANGE_EQUAL(bc::float_, 4, vector, (-4, -3, -2, -1));

    bc::iota(vector.begin(), vector.end(), 1, queue); // this works
    CHECK_RANGE_EQUAL(bc::float_, 4, vector, (1, 2, 3, 4));

    bc::iota(vector.begin(), vector.end(), -4, queue); // this does not work
    CHECK_RANGE_EQUAL(bc::float_, 4, vector, (-4, -3, -2, -1));
}

Result:
Mismatch in a position 0: 4.29497e+09 != -4
Mismatch in a position 1: 4.29497e+09 != -3
Mismatch in a position 2: 4.29497e+09 != -2
Mismatch in a position 3: 4.29497e+09 != -1


fix(sessions): don't throw if withTransaction() callback rejects with a null reason

Description
See: Automattic/mongoose#8637 . The issue is that if you do session.withTransaction(() => Promise.reject()), you get a TypeError: Cannot read property 'code' of undefined error.
Re: #2252, just against 3.5 branch so it can land in 3.5.6.
What changed?
One liner checking for null
Are there any files to ignore?
Nope

@vkarpov15 , any chance you could throw a test together for this one? I'm making the JIRA ticket now

Made NODE-2515 to track this

@mbroadst I added a test, comments welcome :point_up:

thanks @vkarpov15 ! It will be included in the next patch release


tflint: 0.43.0 -> 0.44.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/terraform-linters/tflint/releases.
meta.description for tflint is: "Terraform linter focused on possible errors, best practices, and so on"
meta.homepage for tflint is: "https://github.com/terraform-linters/tflint"
meta.changelog for tflint is: "https://github.com/terraform-linters/tflint/raw/v0.44.1/CHANGELOG.md"
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.44.1 with grep in /nix/store/g8vrpmbab9iwgvmkz051jx47zxp5jyh9-tflint-0.44.1
found 0.44.1 in filename of file in /nix/store/g8vrpmbab9iwgvmkz051jx47zxp5jyh9-tflint-0.44.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
tflint

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/g8vrpmbab9iwgvmkz051jx47zxp5jyh9-tflint-0.44.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A tflint https://github.com/r-ryantm/nixpkgs/archive/51b1d853951e21200ec6ed5d7dd969cbaf25c0bc.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/g8vrpmbab9iwgvmkz051jx47zxp5jyh9-tflint-0.44.1
ls -la /nix/store/g8vrpmbab9iwgvmkz051jx47zxp5jyh9-tflint-0.44.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

tflint

Maintainer pings
cc @marsam for testing.

Result of nixpkgs-review pr 208560 run on x86_64-linux 1

1 package built:

tflint


Set Default "Ends On" Date for Task Assignments

When creating a task from an issue and assigning it to someone, it's important to establish a reasonable timeframe for task completion. To streamline this process and ensure clarity, we propose setting a default "Ends On" date for task assignments.
Proposed Solution

Default Date Calculation: When a task is assigned to someone, automatically calculate and set the "Ends On" date as two days from the time of assignment. This default date should appear in the task details.
User Modification: Users should have the flexibility to adjust the "Ends On" date as needed to accommodate specific timelines or requirements.

Benefits

Efficiency: This default date saves time for Super user and reduces the need for manual date entry.
Clarity: Clear due dates improve task management and communication.
Consistency: Establishing a standard default date ensures uniformity across tasks.

Priority
Medium
This enhancement will help streamline task assignment and improve clarity in task management. Your feedback and suggestions are welcome to refine this feature.
Hints:
file to modify: src/components/issues/ActionForm.tsx
Expected form (screenshot taken on 29th September 2023)

Can I please take up this task, I am planning to complete this task by ETA 2nd october.

I would like to work on this task. Could you please assign me this ?
ETA by 20 October


Assertion in reduce_index_spaces when computing index space intersections over a pending partition

I'm getting an assertion in reduce_index_spaces when using create_index_space_intersection on a pending partition.
Here is the backtrace:
(lldb) bt

thread #5: tid = 0x68f5a, 0x00007fff9acab286 libsystem_kernel.dylib__pthread_kill + 10, stop reason = signal SIGABRT   frame #0: 0x00007fff9acab286 libsystem_kernel.dylib__pthread_kill + 10
frame #1: 0x00007fff98ff89f9 libsystem_pthread.dylibpthread_kill + 90   frame #2: 0x00007fff9909e9b3 libsystem_c.dylibabort + 129
frame #3: 0x00007fff99066a99 libsystem_c.dylib`__assert_rtn + 321

frame #4: 0x000000010b3ddf9d pennantRealm::IndexSpace::reduce_index_spaces(op=ISO_INTERSECT, spaces=0x000000012c4f4f30, result=0x000000012c4f4ea0, mutable_results=false, parent=(id =<PHONE_NUMBER>), wait_on=(id = 0, gen = 0)) + 77 at idx_impl.cc:208 frame #5: 0x000000010afba361 pennantLegionRuntime::HighLevel::RegionTreeForest::compute_pending_space(this=0x00007f9993406d60, target=, handles=0x00007f999379f890, is_union=false) + 2001 at region_tree.cc:824
frame #6: 0x000000010ad1696f pennantLegionRuntime::HighLevel::PendingPartitionOp::ComputePendingSpace::perform(this=0x00007f999379f870, forest=0x00007f9993406d60) + 207 at legion_ops.h:1552 frame #7: 0x000000010ace094a pennantLegionRuntime::HighLevel::PendingPartitionOp::trigger_execution(this=0x00007f999379f760) + 58 at legion_ops.cc:7995
frame #8: 0x000000010b185ab4 pennantLegionRuntime::HighLevel::Runtime::high_level_runtime_task(args=0x00007f999350d1d0, arglen=20, p=(id =<PHONE_NUMBER>)) + 1060 at runtime.cc:15895 frame #9: 0x000000010b3798f0 pennantRealm::Task::execute_on_processor(this=0x00007f999350c240, p=(id =<PHONE_NUMBER>)) + 336 at tasks.cc:80
frame #10: 0x000000010b37dd09 pennantRealm::UserThreadTaskScheduler::execute_task(this=0x00007f9993600cb0, task=0x00007f999350c240) + 41 at tasks.cc:884 frame #11: 0x000000010b37b580 pennantRealm::ThreadedTaskScheduler::scheduler_loop(this=0x00007f9993600cb0) + 1840 at tasks.cc:448
frame #12: 0x000000010b380c8e pennant`void Realm::Thread::thread_entry_wrapper<Realm::ThreadedTaskScheduler, &(obj=0x00007f9993600cb0))>(void*) + 94 at threads.inl:127

Note this is on master, as of e4a626f9c0ab43b2104dfc11f959759ca97144ea

That would be this assert here https://github.com/StanfordLegion/legion/blob/master/runtime/realm/idx_impl.cc#L207-L208, which is telling you that you should be setting SHARED_LOWLEVEL=1 because the dependent partitioning stuff isn't implemented yet in Realm.  :)

Closing this, as the dependent partitioning work is going on anyway.


Game crashing when trying to install packs in game

Describe the bug
A clear and concise description of what the bug is.
The game crashes whenever I try to download song packs in game.
To Reproduce
Steps to reproduce the behavior:

Open up the game (version 0.70.3 if that helps)
click on pack downloader
Click download on any pack that isn't installed

Expected behavior
A clear and concise description of what you expected to happen.
I just want to download song packs in game.
Screenshots
not needed
Desktop (please complete the following information):

OS: windows 10
Version 2004 - 64bit

Additional context
not needed

Not enough information
lacking permissions?
what pack? any?
unreproducable
possibly a duplicate
#229 #762


Make the website responsive for mobile phone 🐱🏍

Assign me @SauravMukherjee44

I have added some changes regarding this issue.
Do check it out :)

Hey @SauravMukherjee44
Can I work on this issue?
will optimize it for mobile view

@rahulaarora Yeah sure !

@SauravMukherjee44
made pr
do check
Rahulaarora/issue35 #114

@rahulaarora Site is not opening after merging. I had reverted your PR. Try to create a pr and add hosted link so that I can rev

okay

@SauravMukherjee44 now the site code is breaking due to other pr's merged in btw!


A lot of changes

PTAL @nicolasgarnier

It seems that browser tests without an attached HTML file fail. I'm investigating...

Was just missing the default HTML file template (and using the Dart template code instead). All good now :D


[stable/spark] Fix a typo in Configuration section

Fix the typo in spark operation configuration section.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Title of the PR starts with chart name (e.g. [stable/chart])

@MQasimSarfraz
Would you mind to bump the chart to latest version please? Thank you.

/lgtm
/approve


Update storage_context while building index

Hi,
Updated storage_context in index = GPTVectorStoreIndex.from_documents(documents, storage_context=storage_context).
Thank you.

Amazing, thanks for the contribution!


[Question] Is it possible to share translations yml files from react web?

Hi.
I was curious if anyone imported a yml file and set the translations to this. I am trying to reuse a yml file from a web react app for use in react native app. Anyone have done this and can provide some info to accomplish this?
Thanks.

Hi.
You can use a YML parser and output in a formatted JSON file.

Hi @zoontek
That's a good solution. I also realized this about an hour ago after talking with another developer. My only concern is the performance of the parser and I hope it doesn't bottleneck the configuration.
Hopes this helps anyone else in the same position.


RE: Using BBB w/ Grove Cape v2 on Debian Stretch...

Hello,
I am trying to use this software I found for grovegprs.js. I installed mraa with npm since I have node on my BBB. I am using a Grove Cape for that specific board (Grove Cape v2).
Is anyone working with Debian, the BBB, and the Grove Cape v2?
Seth
P.S. I need a bit of guidance right now with this software. I keep getting an error message: cannot find module 'jsupm_grovegprs'.

Hi Seth, you'll also need to install jsupm_grovegprs with npm to be able to run the samples in this repository. There are also some known issues with some of the UPM packages on npm, but I don't recall if grovegprs is on that list. See this section for further reference.


Crash handling

We have to handle the crashes and recover the system gently.
This may be done in several ways:

Use some bash daemon utilities.
Handle the exceptions in python.
Both.

First bash daemon in https://github.com/niclabs/ratadns-filters/commit/4d186ee828c06337a24629f22450bdddd87ba9f1

Add handling python exceptions in https://github.com/niclabs/ratadns-filters/commit/936e824cd37cd626ba7eefca0c606e55e1cc4325

Systemd daemon first version created. We don't need this right now, maybe in the future. To use the rata we just need a howto... Closing...


Model interfaces with shared cabling

Environment

Python version: any
Nautobot version: future

Proposed Functionality

Add modelling for multiple interfaces which share a single physical cable - such as QSFP+ going to a breakout cable or panel.
Add modelling for cables with different numbers of connectors at each end (i.e. MPO one end, 4 x LC pair the other), and a way to create new cables / pinouts to describe different cable types (MPO-MPO A/B/C polarity, MPO-4xLC etc.)

Use Case
PSM4(PLR4) optics have an MPO/MTP connector, and are recognised by the device a 4 separate physical interfaces (and can be 10/25/100g per interface).
There are 2 ways these are used:

MPO breakout cable, which has an MPO connector on one end, and 4 x LC pairs on the other.
MPO breakout panel, usually a cassette which fits in a panel, and has 4 x LC pairs on the front, and 1 x MPO on the back. An MPO cable is connected from the panel to the QSFP+ in the equipment.

Multimode QSFP+ optics can be used with a breakout MPO cable as in the same way.
Currently, we have to model the 4 physical interfaces as SFP+ 10G, and connect cables directly to them - and cannot model the existence of either a breakout cable, or a breakout panel.
Some users achieve this by creating front/back connections in the device with the QSFP+ optic installed - however this is very cumbersome and does not accurately represent reality.
Database Changes
I'm not sure - proposing this so we can discuss the requirements, then address how to achieve this in the DB.
I think fibre modelling should be changed, to model individual strands rather than pairs - trying to build this feature without this is possible, but means that there needs to be code for all the different options - better do model fibre strands so users can define cables / etc. themselves.
I expect cables would need to be modelled differently to allow different numbers of connectors.
External Dependencies
I expect no external dependency changes.

Thanks @nward for the request. We'll give this a good review and follow up.


Set new options only if their values are different from the old ones

This patch makes it possible to use react-codemirror with codemirror's lint plugin, which otherwise doesn't work (see #89 and #53). It does this by only re-setting options on the codemirror instance when the values differ from those already set. I added a set of basic "deep equal" tools to ensure that this works correctly.

Branch works well, and allows lint plugin to function. I recommend a merge of this PR.

Any idea when this v0.4.0 be published on npm?

Waiting for this to go out. Can we get an estimate when this will be merged and released?

@JedWatson can you merge this?

Thanks for the fix @attaboy!
I've made similar changes directly because of conflicts, and introduced lodash.isequal rather than inlining the deep comparison methods to keep the source focused.


Wrong SCSS syntax coloring

Hello
I have discovered a wrong SCSS syntax coloring. Please see the picture below. & sign should be blue in &:visited (1) and color property should be cyan (2).

VSCode Version: 1.18.1
OS Version: Windows 10 Home (OS Build 15063.726)

Steps to Reproduce:

Create a new .scss file
Enter a text like

.link-class {
    &:link,
    &:visited {
        color: red;
        font-size: 2rem;
    }
}

Reproduces without extensions: Yes
Thanks

duplicate of #38001, fixed in 1.19


fix: def-env is deprecated and will be removed in 0.88.

Yeah you're right!

https://github.com/nushell/nushell/pull/10715
https://github.com/nushell/nushell/pull/10999

Thanks for the PR!


HDFS-16406. ReadsFromLocalClient counts short-circuit reads

Description of PR

ReadsFromLocalClient counts short-circuit reads

How was this patch tested?

UT

For code changes:

[x] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 59s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
36m 48s

trunk passed

+1 :green_heart:
compile
1m 27s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
1m 19s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 59s

trunk passed

+1 :green_heart:
mvnsite
1m 28s

trunk passed

+1 :green_heart:
javadoc
1m  2s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 28s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
3m 23s

trunk passed

+1 :green_heart:
shadedclient
25m 12s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 18s

the patch passed

+1 :green_heart:
compile
1m 24s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
1m 24s

the patch passed

+1 :green_heart:
compile
1m 13s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
1m 13s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 53s
/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs-project/hadoop-hdfs: The patch generated 1 new + 45 unchanged - 0 fixed = 46 total (was 45)

+1 :green_heart:
mvnsite
1m 19s

the patch passed

+1 :green_heart:
javadoc
0m 53s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 26s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
3m 24s

the patch passed

+1 :green_heart:
shadedclient
25m 35s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
361m 13s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 38s

The patch does not generate ASF License warnings.

470m 25s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.blockmanagement.TestBlockTokenWithDFSStriped

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3847/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3847

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux c7b4c1553f91 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 51ec6608fd52251640d131c355f00c77dda977dd

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3847/1/testReport/

Max. process+thread count
1895 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3847/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 59s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
36m 48s

trunk passed

+1 :green_heart:
compile
1m 27s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
1m 19s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 59s

trunk passed

+1 :green_heart:
mvnsite
1m 28s

trunk passed

+1 :green_heart:
javadoc
1m  2s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 28s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
3m 23s

trunk passed

+1 :green_heart:
shadedclient
25m 12s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 18s

the patch passed

+1 :green_heart:
compile
1m 24s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
1m 24s

the patch passed

+1 :green_heart:
compile
1m 13s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
1m 13s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 53s
/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs-project/hadoop-hdfs: The patch generated 1 new + 45 unchanged - 0 fixed = 46 total (was 45)

+1 :green_heart:
mvnsite
1m 19s

the patch passed

+1 :green_heart:
javadoc
0m 53s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 26s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
3m 24s

the patch passed

+1 :green_heart:
shadedclient
25m 35s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
361m 13s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 38s

The patch does not generate ASF License warnings.

470m 25s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.blockmanagement.TestBlockTokenWithDFSStriped

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3847/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3847

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux c7b4c1553f91 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 51ec6608fd52251640d131c355f00c77dda977dd

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3847/1/testReport/

Max. process+thread count
1895 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3847/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

@secfree Thanks for your contribution. It looks good to me.
Can you check the failed test cases?

@ferhui thanks for your review. The failed test case is the one you recorded HDFS-16169. And I have raised a PR for it: https://github.com/apache/hadoop/pull/3850

@secfree can you check the checkstyle?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 40s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
32m 38s

trunk passed

+1 :green_heart:
compile
1m 26s

trunk passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
compile
1m 20s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
1m  1s

trunk passed

+1 :green_heart:
mvnsite
1m 32s

trunk passed

+1 :green_heart:
javadoc
1m  2s

trunk passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
1m 33s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
3m 15s

trunk passed

+1 :green_heart:
shadedclient
22m 34s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 18s

the patch passed

+1 :green_heart:
compile
1m 19s

the patch passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javac
1m 19s

the patch passed

+1 :green_heart:
compile
1m 13s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 13s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 51s

the patch passed

+1 :green_heart:
mvnsite
1m 20s

the patch passed

+1 :green_heart:
javadoc
0m 52s

the patch passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
1m 25s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
3m 15s

the patch passed

+1 :green_heart:
shadedclient
22m  4s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
230m  6s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 45s

The patch does not generate ASF License warnings.

329m 25s

Reason
Tests

Failed junit tests
hadoop.hdfs.TestRollingUpgrade

hadoop.hdfs.server.blockmanagement.TestBlockTokenWithDFSStriped

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3847/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3847

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 0afaed5e8363 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 40109acd47ceebc7f730e4370a21281590676013

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3847/7/testReport/

Max. process+thread count
3143 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3847/7/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 54s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
31m 18s

trunk passed

+1 :green_heart:
compile
1m 28s

trunk passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
compile
1m 22s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
1m  1s

trunk passed

+1 :green_heart:
mvnsite
1m 30s

trunk passed

+1 :green_heart:
javadoc
1m  4s

trunk passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
1m 34s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
3m 15s

trunk passed

+1 :green_heart:
shadedclient
22m 27s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 17s

the patch passed

+1 :green_heart:
compile
1m 20s

the patch passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javac
1m 20s

the patch passed

+1 :green_heart:
compile
1m 14s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 14s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 53s

the patch passed

+1 :green_heart:
mvnsite
1m 19s

the patch passed

+1 :green_heart:
javadoc
0m 52s

the patch passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
1m 24s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
3m 15s

the patch passed

+1 :green_heart:
shadedclient
22m 21s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
241m 48s

hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 46s

The patch does not generate ASF License warnings.

340m  5s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3847/8/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3847

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 896b11986a08 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 85d116cd5d867fb75a7e99b50c83f7a85bbcfc66

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3847/8/testReport/

Max. process+thread count
3373 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3847/8/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

@aajisaka Thanks for your review! Do you have other comments, I plan to merge this.

@secfree Thanks for your contribution. @aajisaka Thanks for your review! Merged


flighttask reactivate before taekoff

Since the state estimation can significantly change from  the disarmed-state to idle-state, I added a re-activation method for  flighttask. This method will be called until the vehicle state changes  from idle to smooth-takeoff state.

Has this been flight tested? Particularly takeoff in manual modes (stabilize, altitude, position).

Has this been flight tested? Particularly takeoff in manual modes (stabilize, altitude, position).

yes, but on our drone. by the way, with the current way of arming (throttle down), you will not see a difference. However, if you have a different way of arming, then the drone can takeoff automatically.
@PX4/testflights can you please test manual takeoff?

couple flights on the Pixracer (V4)
https://logs.px4.io/plot_app?log=e4693168-3b81-49c3-bd02-123a3f09e827
https://logs.px4.io/plot_app?log=b802d80e-4c90-4b6f-8f9b-85337979a438
slightly smoother take-off in position mode than with current master in the second flight


Please tag versions

Hi, I'm a maintainer for the Homebrew package manager. We maintain an idnits package but we don't have a way of checking for new versions at the moment. We used to check the tarball link on the previous website but the idnits page started redirecting to https://www6.ietf.org/tools/idnits/ around 2021-11 and the current website is only an online checker (no tarball link or version information).
I happened upon this repository and it seems like something we could migrate to in the future (now that it's no longer just a mirror) but we can't use it until there are version tags. Could you please create a tag for 2.17.00 (preferably pointing to the original commit, bfda9518d5b4e8a682f2e6f34a449c2d3ea745390)? Similarly, would you be willing to commit to tagging new versions as they're released? This would make it easy for us to download a snapshot of a given version and allow us to programmatically check the tags for new versions.
Somewhat related, are there any plans for releasing a new version? I see there are some new commits after 2.17.00 but the version in the idnits file remains the same.
Thanks!

We're not expecting this to be updated much at all in the future. The expectation is that it will be eclipsed by a different implementation. But hopefully these two tags/releases are helpful.


docs: tweaks to tutorial based on user feedback

Addressing user feedback and this issue.

@kimwnasptd it should be good to go now. If you can pls approve and merge.

Thanks for picking this up @afgambin!


fix: resolve tilda paths and validate datadir config

Running the command bacalhau --repo=~/some/path <command> results in a config with a DataDir value of ~/some/path rather than an expanded path, e.g. /home/$USER/some/path. We must handle tilda paths gracefully by expanding them to an absolute path before accepting them as configuration.
Further, we must either dis-allow relative paths, or expand them to absolute paths, before accepting them as configuration. In this PR we have chosen the latter. This is because the DataDir field is used as the root path for our hard-coded config paths, and said path must be absolute when provided to docker as a volume mount point, else we get errors like: https://github.com/bacalhau-project/bacalhau/issues/4506
This PR adds path expansion when DataDir is a tilda path, and validation to enforces DataDir be an absolute path before accepting it as configuration.
Below are some examples of valid, and invalid paths - enforced via unit tests:
Valid
DataDir:  "/absolute/path",
DataDir:  "~/absolute/path",
DataDir:  "~",
DataDir:  "~/",
DataDir:  "~/.",
DataDir:  "/path/with/special/char$",
DataDir:  "/path/with space",
DataDir:  "/absolute/path/",
DataDir:  "~/~/path",
DataDir:  "~/path/with space",
DataDir:  "/very/long/path/" + strings.Repeat("a", 255),
DataDir:  "/path/~to/file",
DataDir:  "~/path/~to/file",
DataDir:  "/path/with?invalid",

Invalid
DataDir: "",
DataDir: "not/absolute/path",
DataDir: "./not/absolute/path",
DataDir: "~not/absolute/path",

closes #4484

Also I am not sure what the problem the PR is trying to solve. I see you are linking an issue, but that issue also doesn't have a description on why data dir with ~ is a problem

Sorry, I should have provided a more verbose description in the issue - at a high level we need to expand ~ paths to be absolute/valid paths before using them for filesystem operations in bacalhau.

I am missing the purpose of expanding ~

As an example, ~/something isn't a valid path: ~ is a convenience provided by a shell, not a universally valid path component. So, without expansion, ~/something is just a string that won't lead to the intended directory unless the we explicitly handle it, and we don't currently.
More generally this PR is:

Handling ~ paths by expanding them from, say, ~/some/path to /home/$USER/some/path
Validating the DataDir path is an absolute path - specifying the exact path on the file system.

I believe most of our users do as we keep saying ~/.bacalahu is the default repo

Yes, this is the intention, the goal is for this to work as expected, right now it doesn't.
https://github.com/bacalhau-project/bacalhau/issues/4457 was actually caused by this issue, for example try this:
Terminal 1
bacalhau --repo=~/bacalhau serve --node-type=compute,requester
Terminal 2
bacalhau docker run -i https://gist.githubusercontent.com/js-ts/ec6a58c9e0991ed27dce5ca11198a88c/raw/fe16cb212661a30c46309da60fdd055ba4648bc5/fake_logs.log  ubuntu cat /inputs/fake_logs.log
Observe this is the error returned:
Job successfully submitted. Job ID: j-0195016a-2b62-4763-a86b-654da0ad6283
Checking job status... (Enter Ctrl+C to exit at any time, your job will continue running):

 TIME                 EXEC. ID    TOPIC              EVENT
 Sep 20 15:18:48.189  e-6f0519b4  Running Execution  creating container: Error response from daemon: invalid moun
                                                     t config for type "bind": invalid mount path: '~/bacalhau/co
                                                     mpute/executions/j-0195016a-2b62-4763-a86b-654da0ad6283/e-6f
                                                     0519b4-c77f-445c-95fb-717585781d15/2114722141/fake_logs.log'
                                                      mount path must be absolute
 Sep 20 15:18:48.402  e-872ea25a  Running Execution  creating container: Error response from daemon: invalid moun
                                                     t config for type "bind": invalid mount path: '~/bacalhau/co
                                                     mpute/executions/j-0195016a-2b62-4763-a86b-654da0ad6283/e-87
                                                     2ea25a-8b91-4b57-9f4f-04f886f3fdd0/4278892486/fake_logs.log'
                                                      mount path must be absolute
 Sep 20 15:18:48.420              Scheduling         not enough nodes to run job. requested: 1, available: 1, sui
                                                     table: 0.
                                                     • Node n-ae099dd0: job already executed on this node more th
                                                     an once

Since ~/bacalhau was never expanded before being persisted to the config, methods that rely on it, like ComputeDir() end up returning an invalid (~) path - resulting in this error from docker.

few examples that should work, but aren't:
→ bacalhau  serve --orchestrator --compute --data-dir=./here
failed to setup config: path must be absolute (start with '/')
DataDir ("./here") must be an absolute path

→ bacalhau  serve --orchestrator --compute --data-dir here
failed to setup config: path must be absolute (start with '/')
DataDir ("here") must be an absolute path

# this works, which maybe it shouldn't
→ bacalhau config set --config config.yaml datadir ./here
10:46:06.327 | INF ../ProtocolLabs/workspace/bacalhau/cmd/cli/config/set.go:94 > Writing config to /Users/walid/bacalhau-versions/config.yaml

# but trying to fix it fail
→ bacalhau config set --config config.yaml datadir $(PWD)/here
failed to setup config: path must be absolute (start with '/')
DataDir ("./here") must be an absolute path

First, please do more through manual testing from your end and document them in the PR's description
Second, you need to differentiate between setting the data-dir from config file and from cli flags as it makes sense if users define relative paths as cli flags, but I'll that to product to decide @aronchick
Lastly, since we are validating when unmarshalling the config, then we need to also validate before persisting config changes using config set. Otherwise we will corrupt the config file and only manual intervention will be required to fix it. I might even say you should only validate after writing when using config set and shouldn't validate before

Right now this PR enforces the DataDir path be absolute, or tilda paths, so it's understandable that: --data-dir=./here and --data-dir here don't work as they are not absolute. The command with datadir $(PWD)/here should work - least it works for me:
$ bacalhau config set datadir $(pwd)/here
07:25:50.478 | INF pkg/repo/fs.go:91 > Initializing repo at /home/frrist/.bacalhau
07:25:50.479 | INF cmd/cli/config/set.go:94 > Writing config to /home/frrist/.bacalhau/config.yaml

$ cat ~/.bacalhau/config.yaml
datadir: /home/frrist/workspace/src/github.com/bacalhau-project/bacalhau/here

First, please do more through manual testing from your end and document them in the PR's description

The tests are fairly thorough: https://github.com/bacalhau-project/bacalhau/pull/4485/files#diff-29cea1b5b831c8655c7155f43e2367cec73e66d1e338f8b3c7877a2f339b8811R19 is there a specific case you have in mind that is not covered here? Or it this comment more related to the nature of absolute vs relative paths?

Second, the error message path must be absolute (start with '/') might be specific to unix and won't play nicely with windows

Good point, I'll modify this instead say:
failed to setup config: path must be absolute DataDir ("./here") must be an absolute path since windows and unix path separators are different. (but note there is validation in this PR for both OS types)

Third, you need to differentiate between setting the data-dir from config file and from cli flags as it makes sense if users define relative paths as cli flags, but I'll that to product to decide aronchick

For the case when paths are passed via flags, I can modify this PR such that it attempts to expand them to absolute paths before accepting them as config. If they cannot be expanded then we should fail and not accept them as configuration.

Lastly, since we are validating when unmarshalling the config, then we need to also validate before persisting config changes using config set

Ooo yeah, good catch - will add validation to set before persisting the values to the file.

The tests are fairly thorough:

You don't think unit tests for the config are enough, right? We keep finding issues with each config change, so obviously we can do better. As I mentioned several times before, try to break the feature, think of edge cases, and document the scenarios you ran. I am more than happy with manual tests for now, and we can migrate those to bashtub after launch.

failed to setup config: path must be absolute DataDir ("./here") must be an absolute path

The message still has duplication

For the case when paths are passed via flags, I can modify this PR such that it attempts to expand them to absolute paths before accepting them as config. If they cannot be expanded then we should fail and not accept them as configuration.

Yeah that sounds right

@wdbaruni can you review this, please? Needed for 1.5.0

i don't understand this. We are now allowing relative paths even in config files where the original goal was to no longer support relative paths, and expand them only if provided in cli flags as you mentioned below

For the case when paths are passed via flags, I can modify this PR such that it attempts to expand them to absolute paths before accepting them as config. If they cannot be expanded then we should fail and not accept them as configuration.

relative paths in config files result in unpredictable behaviour as the data-dir will depend on where you are running the binary from and not where the config file is. The reason it makes sense to support them in cli flags is because the user will provide a path relative to where they are running the binary and that make sense.
Here is an exmaple of unpredictable behavour:
→ pwd
/Users/walid/bacalhau-versions

→ touch config.yaml

→ bacalhau --config config.yaml config set datadir ./bacalhau

# note the data dir /Users/walid/bacalhau-versions/bacalhau
Walid-MacBook-5: ~/bacalhau-versions
→ bacalhau serve --orchestrator  --config config.yaml
23:54:07.727 | INF ../ProtocolLabs/workspace/bacalhau/cmd/cli/serve/serve.go:102 > Config loaded from: [/Users/walid/bacalhau-versions/config.yaml], and with data-dir /Users/walid/bacalhau-versions/bacalhau

→ cd ..

# note the data dir is now /Users/walid/bacalhau
Walid-MacBook-5: ~
→ bacalhau serve --orchestrator --config bacalhau-versions/config.yaml
23:55:08.08 | INF ProtocolLabs/workspace/bacalhau/cmd/cli/serve/serve.go:102 > Config loaded from: [/Users/walid/bacalhau-versions/config.yaml], and with data-dir /Users/walid/bacalhau

I see 56e7fd507cc14f4aece7a875a6ea7acfe89ab9f2. It seems we needed to add a couple things:

Validate the datadir of each config file loaded by the config package, if any file contains an invalid data dir, fail.
Ensure the datadir path provided to config set is expanded and valid. If its not valid, fail
Prevent users from editing the datadir of the config file within their bacalhau repo via config set to avoid confusion.

Here is the new behavior from your commands above with this change:
> pwd
/home/frrist/parent/child

> touch config.yaml

> bacalhau --config config.yaml config set datadir ./bacalhau
16:29:31.975 | INF cmd/cli/config/set.go:122 > Writing config to /home/frrist/parent/child/config.yaml

> cat config.yaml
datadir: /home/frrist/parent/child/bacalhau

> bacalhau serve --orchestrator  --config config.yaml
16:29:57.526 | INF cmd/cli/serve/serve.go:102 > Config loaded from: [/home/frrist/parent/child/config.yaml], and with data-dir /home/frrist/parent/child/bacalhau
16:29:57.526 | INF pkg/repo/fs.go:94 > Initializing repo at /home/frrist/parent/child/bacalhau

> cd ..

> bacalhau serve --orchestrator --config child/config.yaml
16:30:15.967 | INF cmd/cli/serve/serve.go:102 > Config loaded from: [/home/frrist/parent/child/config.yaml], and with data-dir /home/frrist/parent/child/bacalhau

Additionally, removing the foot gun of modifying the data dir path of the config in the default repo location:
> bacalhau config set datadir somepath
16:32:19.456 | INF pkg/repo/fs.go:94 > Initializing repo at /home/frrist/.bacalhau

Error: modifying the config key "datadir" within the bacalhau repo config "/home/frrist/.bacalhau/config.yaml" is not permitted.
Hint:  You are free to do so manually, but advised against it.

Ensure paths provided to config set are expanded:
> touch config.yaml

> bacalhau config set --config=config.yaml datadir ./this_will_expand_in_file
16:33:34.743 | INF cmd/cli/config/set.go:122 > Writing config to /home/frrist/config.yaml

> cat config.yaml
datadir: /home/frrist/this_will_expand_in_file

Ensure config files cannot be loaded with invalid paths already present:
> echo 'datadir: ./bad/path' > config.yaml

> bacalhau serve --config=config.yaml

Error: failed to setup config: config file "/home/frrist/config.yaml" with value "./bad/path" invalid. datadir must be an absolute path

Works with several config files:
> echo 'datadir: /home/frrist/good' > config.yaml

> echo 'datadir: home/frrist/bad' > override.yaml

> bacalhau serve --config=config.yaml --config=override.yaml
Error: failed to setup config: config file "/home/frrist/parent/override.yaml" with value "home/frrist/bad" invalid. datadir must be an absolute path

> bacalhau serve --config=override.yaml --config=config.yaml
Error: failed to setup config: config file "/home/frrist/parent/override.yaml" with value "home/frrist/bad" invalid. datadir must be an absolute path

> bacalhau serve --config=config.yaml
16:36:35.823 | INF cmd/cli/serve/serve.go:102 > Config loaded from: [/home/frrist/parent/config.yaml], and with data-dir /home/frrist/good
16:36:35.823 | INF pkg/repo/fs.go:94 > Initializing repo at /home/frrist/good

> bacalhau serve --config=override.yaml

Error: failed to setup config: config file "/home/frrist/parent/override.yaml" with value "home/frrist/bad" invalid. datadir must be an absolute path

The --config flags still accept relative paths, and expand them:
> bacalhau serve --config=datadir=relative/path
16:38:48.631 | INF cmd/cli/serve/serve.go:102 > Config loaded from: [], and with data-dir /home/frrist/parent/relative/path
16:38:48.631 | INF pkg/repo/fs.go:94 > Initializing repo at /home/frrist/parent/relative/path

Testing done

Unit tests
Manual scenarios as show below

Default
# defaults
→ bacalhau serve --orchestrator --compute
12:16:00.093 | INF  > Config loaded from: [], and with data-dir /Users/walid/.bacalhau

Env Var
# env var: tila path
Walid-MacBook-5: ~
→ export BACALHAU_DIR="~/.bacalhau2"

Walid-MacBook-5: ~
→ bacalhau serve --orchestrator --compute
12:16:30.991 | INF  > Config loaded from: [], and with data-dir /Users/walid/.bacalhau2

# env var: relative path
Walid-MacBook-5: ~
→ export BACALHAU_DIR=".bacalhau"

Walid-MacBook-5: ~
→ bacalhau serve --orchestrator --compute

Error: data dir path ".bacalhau" is not an absolute path
Hint:  Use an absolute path for the data directory

Walid-MacBook-5: ~
→ bacalhau serve --orchestrator --compute

Walid-MacBook-5: ~
→ export BACALHAU_DIR="bacalhau"

Walid-MacBook-5: ~
→ bacalhau serve --orchestrator --compute

Error: data dir path "bacalhau" is not an absolute path
Hint:  Use an absolute path for the data directory

Walid-MacBook-5: ~
→ export BACALHAU_DIR="./bacalhau"

Walid-MacBook-5: ~
→ bacalhau serve --orchestrator --compute

Error: data dir path "./bacalhau" is not an absolute path
Hint:  Use an absolute path for the data directory

Cli Flag
Walid-MacBook-5: ~/bacalhau-versions/test
→ bacalhau serve --orchestrator --compute --data-dir .
12:22:49.32 | INF  > Config loaded from: [], and with data-dir /Users/walid/bacalhau-versions/test

→ bacalhau serve --orchestrator --compute --data-dir dir
12:23:14.236 | INF  > Config loaded from: [], and with data-dir /Users/walid/bacalhau-versions/test/dir

→ bacalhau serve --orchestrator --compute --data-dir ./dir
12:23:19.186 | INF  > Config loaded from: [], and with data-dir /Users/walid/bacalhau-versions/test/dir

→ bacalhau serve --orchestrator --compute --data-dir ~/bacalhau-versions/test/dir
12:23:33.105 | INF  > Config loaded from: [], and with data-dir /Users/walid/bacalhau-versions/test/dir

→ bacalhau serve --orchestrator --compute --data-dir ~/bacalhau-versions/test/dir2
12:23:37.277 | INF  > Config loaded from: [], and with data-dir /Users/walid/bacalhau-versions/test/dir2

→ bacalhau serve --orchestrator --compute --data-dir /Users/walid/bacalhau-versions/test

12:24:38.836 | INF  > Config loaded from: [], and with data-dir /Users/walid/bacalhau-versions/test

Config Value
→ bacalhau serve --orchestrator --compute -c datadir=.

12:25:28.673 | INF  > Config loaded from: [], and with data-dir /Users/walid/bacalhau-versions/test

→ bacalhau serve --orchestrator --compute -c datadir=dir

12:25:38.466 | INF  > Config loaded from: [], and with data-dir /Users/walid/bacalhau-versions/test/dir

→ bacalhau serve --orchestrator --compute -c datadir=./dir

12:26:03.447 | INF  > Config loaded from: [], and with data-dir /Users/walid/bacalhau-versions/test/dir

→ bacalhau serve --orchestrator --compute -c datadir=~/bacalhau-versions/test/dir

12:32:49.703 | INF  > Config loaded from: [], and with data-dir /Users/walid/bacalhau-versions/test/dir

→ bacalhau serve --orchestrator --compute -c datadir=/Users/walid/bacalhau-versions/test

12:27:32.918 | INF  > Config loaded from: [], and with data-dir /Users/walid/bacalhau-versions/test

Config File
→ bacalhau serve --orchestrator --compute -c config.yaml

Error: data dir path "." is not an absolute path
Hint:  Use an absolute path for the data directory

Walid-MacBook-5: ~/bacalhau-versions/test
→ bacalhau serve --orchestrator --compute -c config.yaml

Error: data dir path "dir" is not an absolute path
Hint:  Use an absolute path for the data directory

Walid-MacBook-5: ~/bacalhau-versions/test
→ bacalhau serve --orchestrator --compute -c config.yaml

Error: data dir path "./dir" is not an absolute path
Hint:  Use an absolute path for the data directory

→ bacalhau serve --orchestrator --compute -c config.yaml
12:39:52.24 | INF  > Config loaded from: [/Users/walid/bacalhau-versions/test/config.yaml], and with data-dir /Users/walid/bacalhau-versions/test/dir

→ bacalhau serve --orchestrator --compute -c config.yaml
12:40:12.412 | INF  > Config loaded from: [/Users/walid/bacalhau-versions/test/config.yaml], and with data-dir /Users/walid/bacalhau-versions/test/dir2

→ bacalhau serve --orchestrator --compute -c config.yaml
12:40:22.19 | INF  > Config loaded from: [/Users/walid/bacalhau-versions/test/config.yaml], and with data-dir /Users/walid/bacalhau-versions/test

Config Set
Walid-MacBook-5: ~/bacalhau-versions/test
→  bacalhau --config config.yaml config set datadir .
DEPRECATED: use key=value instead of space-separated key value
Writing config to /Users/walid/bacalhau-versions/test/config.yaml

Walid-MacBook-5: ~/bacalhau-versions/test
→ cat config.yaml
datadir: /Users/walid/bacalhau-versions/test

Walid-MacBook-5: ~/bacalhau-versions/test
→ bacalhau --config config.yaml config set datadir ~/.bacalhau
DEPRECATED: use key=value instead of space-separated key value
Writing config to /Users/walid/bacalhau-versions/test/config.yaml

Walid-MacBook-5: ~/bacalhau-versions/test
→ cat config.yaml
datadir: /Users/walid/.bacalhau

Walid-MacBook-5: ~/bacalhau-versions/test
→ bacalhau --config config.yaml config set datadir=/Users/walid/bacalhau-versions
Writing config to /Users/walid/bacalhau-versions/test/config.yaml

Walid-MacBook-5: ~/bacalhau-versions/test
→ cat config.yaml
datadir: /Users/walid/bacalhau-versions

Walid-MacBook-5: ~/bacalhau-versions/test
→ bacalhau --config config.yaml config set datadir=
Writing config to /Users/walid/bacalhau-versions/test/config.yaml

Walid-MacBook-5: ~/bacalhau-versions/test
→ cat config.yaml
datadir: /Users/walid/bacalhau-versions/test

Walid-MacBook-5: ~/bacalhau-versions/test
→ bacalhau --config config.yaml config set datadir=""
Writing config to /Users/walid/bacalhau-versions/test/config.yaml

Walid-MacBook-5: ~/bacalhau-versions/test
→ cat config.yaml
datadir: /Users/walid/bacalhau-versions/test


Tutorial needed

Howdy!
Some of us are new to mobile development and don't have much experience with bluetooth overall. I was wondering if it was possible to add a tutorial section with perhaps a tile or another bluetooth device that shows how to connect and retrieve/read real data from it.
I have a medical bluetooth device and I can connect and read the services/characteristics without a problem, the issue is that I'm not sure how to decode the data it makes available via the characteristics. I keep getting base64 for the value property which after decoding doesn't make much sense to me:
Encoded: AZyDslz++CcAGA8AAMA=
Decoded: '
Any help is much appreciated! I've looked online for tutorials but haven't found one that I was able to get working on my end.

Hello :)
Characteristic UUID defines its type. If your UUID is of the following form: XXXXXXXX-0000-1000-8000-00805F9B34FB, that means it's probably defined and available on Bluetooth site.
Otherwise, you have to find the specification for your characteristic describing how it should be read.

@Cierpliwy I'm getting UUID's that are definitely different from XXXXXXXX-0000-1000-8000-00805F9B34FB
When you say I have to find the specifications, you mean I have to get the specs for the device from the manufacturer correct?

Yes, that's right.


forward push-state requests to index.html

We are experiencing this issue:
https://stackoverflow.com/questions/31415052/angular-2-0-router-not-working-on-reloading-the-browser
It has to do with push-state. It looks like our http-server is getting requests to /foo or /bar, but we need those requests to be mapped to index.html.
Is there a way to map all routes in index.html?
with the live-server package, it apparently looks like this:

using live-server: https://www.npmjs.com/package/live-server
$ live-server --entry-file=index.html

My guess is that proxy option can do what we want? something like this:
-P or --proxy Proxies all requests which can't be resolved locally to the given url. e.g.: -P http://someurl.com
so:
http-server . --proxy index.html

Requiring JavaScript to resolve server-focused URLs is an anti-pattern (however popular). Be sure all non-hash fragment URLs have their own server-side representation or use hash URLs.
If you need that feature, I'd stick with live-server as http-server is focused on HTTP serving. Thanks!


Unable to add custom dashboard

Describe the bug
I'm following this tutorial but unable to add my custom dashboard
Installed libraries and their versions

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
To Reproduce

Create new dashboard component:

import React from 'react'
import { Box } from 'admin-bro'

const Dashboard = (props) => {
  return (
    <Box>My custom dashboard</Box>
  )
}

export default Dashboard

Update dashboard options:

  ...
    dashboard: {
      handler: async (request, response, data) => {
        console.log('Dashboard Handler')
        return {}
      },
      component: AdminBro.bundle('./components/dashboard.jsx')
    }
  ...

After updated the options, I still see the default dashboard and get this error in the console:

2020-05-13 17:42:26 - info GET /admin/frontend/assets/components.bundle.js 500 41.991 ms - 922

Error: Runtime helpers are not enabled. Either exclude the transform-runtime Babel plugin or pass the `runtimeHelpers: true` option. See https://github.com/rollup/rollup-plugin-babel#configuring-babel for more information

Nvm, I found the issue
There was a conflict with the @babel/plugin-transform-runtime plugin. I have disable the plugin and everything is working now


Replacing dev center manager code files with package reference

This pull request will complete migration of Hardware dashboard API handling code to a common shared library. Code files have been packed in their own repository located here: https://github.com/microsoft/devices-hardware-dev-center-manager

Nice work, D!  Lemme know if you need an actual review, othewise I'll assume Mssr. Fu will review/approve.  Happy Holidays and thanks for improving things by leveraging componentization, etc. 🎉👍😁

Sorry 'bout that PR closure!  My intention was to comment without creating a "blocking comment"... not to close the PR (just "close"/resolve the comment while making it so it didn't block. 😁)

A GitHub newb

Thanks Charlie! All feedback is welcomed. Not much code to review here per se. Mostly lives over in the other project now.
And the 'Close and comment' button is new to me also. Wasn't there last time I used GitHub :confused:

Thanks Charlie! All feedback is welcomed. Not much code to review here per se. Mostly lives over in the other project now.
And the 'Close and comment' button is new to me also. Wasn't there last time I used GitHub :confused:


Serial port fixes.

Changes default Pi serial port to /dev/serial0.  ttyAMA0 is the Blueooth UART on a
a Pi with WLAN/BT.   serial0 is the UART on pins GPIO14/GPIO15 on all Pi's under
standard configurations.
Tries all the ports in the default list.
(Sorry for the PR noise; my gerrit habits are strong.)

I'll send a clean PR.


Allow Users to Refresh their API Token

Add a button on the User Profile page that generates a new API token for the user.

Works well once I realised that API access is now a tab on its own ;)

hah. sorry about that :)

Confirming that I am able to regenerate a new API token.


Enable circle ci for this project

Or give me rights in dazed-sheep to do it.

Ok, I'll setup circle ci as soon as I can

done, thanks


Page 370 Bank Account Card - OnBeforOnOpenPage, OnAfterSetCountrySpecificControls, & OnAfterAfterGetCurrentRecord - Event Request

trigger OnOpenPage()
var
    Contact: Record Contact;
begin
    OnBeforOnOpenPage();                // New event
    ContactActionVisible := Contact.ReadPermission;
    SetNoFieldVisible;
end;

local procedure SetCountrySpecificControls()
begin
    "Client No.Enable" := "Export Format" = "Export Format"::CA;
    "Client NameEnable" := "Export Format" = "Export Format"::CA;
    "Input QualifierEnable" := "Export Format" = "Export Format"::CA;
    OnAfterSetCountrySpecificControls();
end;

local procedure ExportFormatOnAfterValidate()
begin
    SetCountrySpecificControls;
end;

local procedure AfterGetCurrentRecord()
begin
    xRec := Rec;
    SetCountrySpecificControls;
    OnAfterAfterGetCurrentRecord();
end;

=================
[IntegrationEvent(true, false)]
local procedure OnBeforOnOpenPage();
begin
end;
[IntegrationEvent(true, false)]
local procedure OnAfterSetCountrySpecificControls()
begin
end;

[IntegrationEvent(true, false)]
local procedure OnAfterAfterGetCurrentRecord()
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Implement Ray for distributed task execution

Overview
Introduces Ray framework for distributed task execution and multiprocessing support in Datamimic. This change moves us from single-process execution to a distributed model where:

Parent process handles model parsing and orchestration
Ray workers handle parallel data generation and processing
Improved resource utilization across multiple cores

Key Features

New GenerateWorker class using Ray for distributed execution
Parent/worker process separation for better resource management
Automatic scaling across available CPU cores
Proper context isolation between workers
Efficient cleanup of resources

Technical Implementation

Ray workers handle chunks of data generation tasks
Parent process manages task distribution and result aggregation
Context copying ensures proper isolation between workers
Resource cleanup in finally blocks
Error propagation from workers to parent process

Architecture
Parent Process

Parse models
Initialize Ray
Distribute tasks to workers
Aggregate results

Ray Workers (@ray.remote)

Handle data generation
Process data chunks
Manage database connections
Clean up resources

Notes
This is our first implementation using Ray for distributed processing. The architecture separates concerns between parent orchestration and worker execution while maintaining our existing model parsing and validation.

@dangsg a first draft of what we discussed , you can have a look ... all unittest and nearly all integration test are already working successfully


Publish 8.7-20240309014325+0000

Publish 8.7-20240309014325+0000

@bot-gradle test and merge

The merge queue build has started. Click here to see all failures if any.


Use new /sync API

Split out from #1.
PTO currently uses the old fashioned initialSync API. oob.systems does not yet use this version of synapse so this can be delayed for a bit.

It should probably be calling /sync rather than /initialSync and /events - /sync is much simpler (albeit slghtly less performant on synapse currently)

@tdfischer: please yell if the /sync response sucks.  In general we've found it to be way easier to work with (by unifying /initialSync and /events, and adding support for stuff like /filters).  Removing roomIDs from the response was actually my request to avoid redundant roomIDs appearing in both the key to the event and the event itself.


20-50% performance increase

We were profiling our application last night with ruby-prof to find out where we could improve the speed of our api calls and found two things in jsonapi resources I think would be an easy fix to increase performance. On simpler api calls the performance was less noticeable, but in our more complex calls the performance was up to 50% faster. I wanted to put the ideas in here and see if you could think of any issues with these ideas, and if not we could create a pull request or you could if you had a better idea in mind how to facilitate these changes.
At a low level, mosts of the costs were surrounding ActiveSupport::Inflector for string names manipulation and finding class objects from strings.
The first easier fix would be to cache two methods that were called frequently and made up 25% of the performance issues in our bigger api call. I monkey patched it to test it, but these changes could be configured better to take into account cache_classes in the config and use rails cache. Only caching if we are looking for performance in staging / production.
class Resource

    class << self

      alias_method :resource_for_old, :resource_for

      def resource_for(type)
        @resources ||= {}
        @resources[type] ||= resource_for_old(type)
      end

    end
  end

  class Formatter

    class << self

      alias_method :formatter_for_old, :formatter_for

      def formatter_for(format)
        @formatters ||= {}
        @formatters[format] ||= formatter_for_old(format)
      end

    end
  end

The second fix was around link generation. To test that it was faster I monkey patched these four link builder methods and returned nil.
relationships_self_link, relationships_related_link, query_link, self_link
Obviously thats not a real solution, but I wanted to test what the profiler saw. Eliminating the link generation also improved performance by 25%. Knowing that area was a performance issue, I feel that  based on the parameters, a caching mechanism could created that generates the link patterns based on the parameters and then the only thing that is changed in subsequent calls is replacing the variables for the resource ids.
For example the first time the method is called, a pattern could be generated like:
https://example.com/api/v1/post/{{id}}/comments

Then on following calls the only thing to replace would be the {{id}} field and the more expensive costs of generating that initial link text could be overcome. Not all links will work for this process, but I believe most will. I need to dig deeper into the link builder generating, but those are my initial thoughts.
Some example images from the performance changes.
Our original api call

Our api after performance optimization (same calls)

This issue could be closed. 😸


[CORE-2227] Allocate a main context in pachctl main

And plumb through to PachctlCmd and command execution.

I am not sure this makes things better without a refactoring to remove mainCtx from the command builders and a changeover from mainCtx to cmd.Context. People still won't know which to use for new RPCs.

It may not make things better, but it doesn’t make them worse, right? Before this PR, main called PachctlCmd, which allocated a pctx background context, which passed it to command-handler-creators, and some command handlers closed over that context and others didn’t, and then the selected command handler was called with a new context.Context; after this PR, main allocates a pctx background context, passes it to PachctlCmd, which passes it to command-handler-creators, and some command handlers close over that context and other don’t, and then the selected command handler is called with that same initial pctx background context.

Also now this blocks other pachctl work until we decide what state we want to leave this in, where before the PR, we just did things in an unusual but consistent way.

Does this block any work? I believe that it is a strict improvement and doesn’t leave anything more broken than it was before. But … finding out that one’s PR will break something one had no idea about is definitely a key reason for PRs☺


Update .env.sample

Closes #386

Add FEATURE_FLAG_NESTED_DECODING (default value: true)
Add REDIS_URL (default value: redis://<IP_ADDRESS>:6379)
Remove ROCKET_DATABASES

Open Questions:
Is ROCKET_LOG_LEVEL read by Rocket itself? I did not include it here in these changes.

Yes, it is part of the variables that rocket consumes. It used to be ROCKET_LOG but the name go deprecated.
I would prefer to include, we would otherwise get this warning every time we start the service.

I approve the PR just not to block you, but like said in the other comment, please include ROCKET_LEVEL_LOG as well as part of the changes :) I think also the values got changed, what we have on staging is ROCKET_LEVEL_LOG=normal

I will update in the context of this PR! 👍

Converted to Draft until issue with deployment is fixed


Rewrite with links to sim examples

@jheidegger thoughts?

Reviewed and agree with all the changes!

um.. this is not the sim overhaul branch.. 🤦 #2


Start implementation of BuildXL VFS cas process.

Start implementation of BuildXL VFS cas process. Currently just proxies to a backing content server. Next step is to actually add virtualization.

using System;

nit: license?

Refers to: Public/Src/Cache/ContentStore/Vfs/VirtualizedContentSession.cs:1 in f5984ad. [](commit_id = f5984ad2ddf75e72f549718dcfff1d7d7d8e660a, deletion_comment = False)

Just to understand the current state: it seems that this is just an infra to glue pieces together, there is no actual logic there yet. Right?

Right.

In reply to: 489699591 [](ancestors = 489699591)


update third party protos and related scripts.

Description
This does the following:

Updates the scripts used to check and download the third party protos.
Moves the proofs.proto into a new confio directory (it was the only proto file not in a directory).
Updates the third party proto files.
Updates the swagger files.

closes: #1017

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

Not sure why the actions won't run on this thing. Gonna cancel this one and re-open it anew.


Fix open issue commands

Fixes open issue open issues commands

Nice ones!
Clearly this project is missing unit tests.. hard to do without mocking an azure devops backend though.


puma/sinatra/multi-process/middleware & paths

I'm using puma with sinatra and puma clustered mode.  I added a
use PrometheusExporter::Middleware

And I am seeing
# HELP ruby_http_requests A counter of HTTP requests made
# TYPE ruby_http_requests counter
ruby_http_requests{path="/discover/product/123"} 2
ruby_http_requests{path="/discover/product/456"} 1

However, I don't want my metrics to record every product number, I want it to
record it like:
ruby_http_requests{path="/discover/product/:id"}

Is this possible?  How do I modify the path
The client_ruby library which I switched away from has a way to do this.

Yeah path is ultra weak, this is why our default rails middleware tries to send action and controller name per:
https://github.com/discourse/prometheus_exporter/blob/master/lib/prometheus_exporter/middleware.rb#L42-L49
Do you have a access to action/controller name in env in Sinatra?

yes, I have access to them, not sure what to do about it though?

A PR to improve our middleware is the way to go:
route = nil
if params
action = params["action"]
controller = params["controller"]
else
route = env["sinatra.route"]
end


[Draft] Fetch cluster info from Metadata server

[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[ ] Does not have any changes that may affect Istio users.

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

/test all

@elfinhe: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test release-notes_istio_release-1.7

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@elfinhe: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test release-notes_istio_release-1.7

lint_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test lint_istio_release-1.7

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@elfinhe: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test release-notes_istio_release-1.7

lint_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test lint_istio_release-1.7

gencheck_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test gencheck_istio_release-1.7

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@elfinhe: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test release-notes_istio_release-1.7

lint_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test lint_istio_release-1.7

gencheck_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test gencheck_istio_release-1.7

unit-tests_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test unit-tests_istio_release-1.7

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test all

@elfinhe: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test lint_istio_release-1.7

gencheck_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test gencheck_istio_release-1.7

unit-tests_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test unit-tests_istio_release-1.7

release-notes_istio_release-1.7
fdff3910cb5023f2a45430a12a03087a5d94012b
link
/test release-notes_istio_release-1.7

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@elfinhe: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test gencheck_istio_release-1.7

unit-tests_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test unit-tests_istio_release-1.7

release-notes_istio_release-1.7
fdff3910cb5023f2a45430a12a03087a5d94012b
link
/test release-notes_istio_release-1.7

lint_istio_release-1.7
fdff3910cb5023f2a45430a12a03087a5d94012b
link
/test lint_istio_release-1.7

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test all

@elfinhe: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test gencheck_istio_release-1.7

unit-tests_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test unit-tests_istio_release-1.7

lint_istio_release-1.7
911c5aaa78ed309d0b7f0f4b9ebe24fa8baee29c
link
/test lint_istio_release-1.7

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@elfinhe: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

unit-tests_istio_release-1.7
595263fee99d0616af6186780bc70a26e9729989
link
/test unit-tests_istio_release-1.7

lint_istio_release-1.7
911c5aaa78ed309d0b7f0f4b9ebe24fa8baee29c
link
/test lint_istio_release-1.7

gencheck_istio_release-1.7
911c5aaa78ed309d0b7f0f4b9ebe24fa8baee29c
link
/test gencheck_istio_release-1.7

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@elfinhe: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio_release-1.7
911c5aaa78ed309d0b7f0f4b9ebe24fa8baee29c
link
/test lint_istio_release-1.7

gencheck_istio_release-1.7
911c5aaa78ed309d0b7f0f4b9ebe24fa8baee29c
link
/test gencheck_istio_release-1.7

unit-tests_istio_release-1.7
911c5aaa78ed309d0b7f0f4b9ebe24fa8baee29c
link
/test unit-tests_istio_release-1.7

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Replaced by https://github.com/istio/istio/pull/26671


Add version and private keys to helper package.json files

I am using yarn workspaces to manage dependencies of helpers.
Without a version parameter, yarn install ignores the dependencies of this package.json when using workspaces.
https://yarnpkg.com/lang/en/docs/workspaces/
Additionally, add private property to avoid accidentally publishing this package.

Definitely no harm here - thanks!


Add --config=rbe_lite_linux in .bazelrc

Both --config=rbe_cpu_linux and --config=rbe_linux_py3 expand to --config=rbe_linux which includes link opts for avx instructions. However that won't compile Tensorflow Lite.
This PR adds --config=rbe_lite_linux which reuses most of existing flags for building Tensorflow Lite with RBE.
Context: b/195294181

Added document for the option rbe_lite_linux.


Stage directions with multiple values in @type may not be rendered properly

Peter C points out that this kind of stage direction:
emdSel_M.html#emdSel_M_s5
is not rendered as it should be in italics. This is probably because it has multiple values in @type (which is probably not good from a TEI point of view either).

Added a fix for this in rev 9977. If it's now working, close the ticket.

I can't tell if it's fixed! The whole site is looking weird and there's a stylesheet message at the top. Screenshot below.

Fixed now, and the stage direction is correctly rendered in italics.


Fix misdetected cycle caused by finalizer task dependency on finalized task

Fixes #21000

@bot-gradle test ACC

OK, I've already triggered the following builds for you:

AllConfigCacheTestsPullRequestFeedback build

Superseded by #21076


Linting?

I saw that the angular repo is using TSLINT for linting.
We have clang, but clang is not a linter. Stuff like semicolons are not being processed by clang.
To add this, I would need, yet again, reestructure the tooling so linting can be run on the build, travis...
WDYT?

+1 for linting. But we need to re-shuffle our build first. IMO the current split of tasks between package.json and gulpfile doesn't make things clear / easy to evolve.

I totally agree Pawel. Wes suggested dropping gulp and go fully webpack, which I totally agree. The problem is that I didn't see how to properly run clang via CLI (so I can do a npm script with that).
What do you think? Try to move more to package.json or move more to gulpfile?
Both have their good and bad parts.

Wes suggested dropping gulp and go fully webpack, which I totally agree

I think that we need to have a conversation here :-) I'm fine with using webpack to prepare dist bundles, but I'm not sure it is the right fit for the entire build.

What do you think? Try to move more to package.json or move more to gulpfile?

My vote would go for gulp (probably starting with gulp 4 if we can)

Oh, let me research the gulp 4 thing.
We need that conversation for sure. cough slack cough.

I'm not hugely opinionated on the tooling, so I'm fine with keeping it mostly gulp.
I'm a big fan of linting though.

With tooling in place, I will do this soon
El 9/11/2015 17:27, "Wesley Cho"<EMAIL_ADDRESS>escribió:

I'm not hugely opinionated on the tooling, so I'm fine with keeping it
mostly gulp.
I'm a big fan of linting though.
—
Reply to this email directly or view it on GitHub
https://github.com/ng-bootstrap/core/issues/63#issuecomment-155114166.

Fixed by 8013e7bf1419d3cea98ea949378e701f9a17bff6


Fixed userids being sent out for password reset having wrong bit tag. Wa...

Per Django changlog documentation for 1.6 here.

Additionally, I left this bit alone. I don't know if it's applicable.
"In addition, if you have any custom password reset URLs, you will need to update them by replacing uidb36 with uidb64 and the dash that follows that pattern with a slash. Also add _- to the list of characters that may match the uidb64 pattern."


CLOUDSTACK-8843: Fixed issue in default iptables rules on shared network VR

On basic zone share network VR default iptables rules are not applied correctly. Due to this ssh to VR got failed.
In shared network the VR type is 'dhcpsrvr' not router. So corrected it in the ''del_standard' method to select the correct type.
Testing:

VR is deployed correctly.
Tested restart, stop, start VR.
New VM deployment is success.
ssh to VR from the host is successful.
iptables rules on the VR came up correctly.
below is the output from the VR:
iptables -L INPUT -nv
Chain INPUT (policy DROP 16 packets, 1056 bytes)
pkts bytes target     prot opt in     out     source               destination
0     0 ACCEPT     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>
0     0 ACCEPT     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>
104  9800 ACCEPT     all  --  eth0   *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            state RELATED,ESTABLISHED
281 36500 ACCEPT     all  --  eth1   *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            state RELATED,ESTABLISHED
0     0 ACCEPT     all  --  eth2   *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            state RELATED,ESTABLISHED
6   504 ACCEPT     icmp --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0
0     0 ACCEPT     all  --  lo     *       <IP_ADDRESS>/0            <IP_ADDRESS>/0
2   656 ACCEPT     udp  --  eth0   *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            udp dpt:67
13   780 ACCEPT     tcp  --  eth1   *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            tcp dpt:3922 state NEW,ESTABLISHED
0     0 ACCEPT     tcp  --  eth0   *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            tcp dpt:80 state NEW
0     0 ACCEPT     tcp  --  eth0   *       <IP_ADDRESS>/23       <IP_ADDRESS>/0            state NEW tcp dpt:8080

Thanks, @jayapalu
I will try to take some time today to test your PR.
Cheers,
Wilder

@jayapalu
Which integration tests did you execute?
Cheers,
Wilder

@wilderrodrigues
I have tested the changes on my local against the VR. It is specific to shared network and the fix is also specific to shared network VR. I think it will not impact the other type of VRs.
But I have not run the integration tests on it. Let me try  running test cases on it.

Ran XS Basic/EIP BVTs and passrate is at 97% - couple of tests failed due to unrelated bug/issue.

All Failed Tests
integration.smoke.test_vm_snapshots.TestSnapshots.test_01_test_vm_volume_snapshot
All Passed Tests
integration.smoke.test_affinity_groups 2 min 22 sec 0  0  1  1
integration.smoke.test_deploy_vgpu_enabled_vm 4 ms 0  1  0  1
integration.smoke.test_deploy_vm_iso 5 min 53 sec 0  0  1  1
integration.smoke.test_deploy_vm_root_resize 19 sec 0  0  3  3
integration.smoke.test_deploy_vm_with_userdata 36 sec 0  0  2  2
integration.smoke.test_deploy_vms_with_varied_deploymentplanners 1 min 7 sec 0  0  3  3
integration.smoke.test_disk_offerings 0.49 sec 0  0  5  5
integration.smoke.test_global_settings 0.36 sec 0  0  1  1
integration.smoke.test_iso 2 min 47 sec 0  1  6  7
integration.smoke.test_multipleips_per_nic 53 sec 0  0  1  1
integration.smoke.test_over_provisioning 0.14 sec 0  0  1  1
integration.smoke.test_portable_publicip 6.6 sec 0  0  1  1
integration.smoke.test_primary_storage 1 min 55 sec 0  0  2  2
integration.smoke.test_regions 73 ms 0  0  1  1
integration.smoke.test_reset_vm_on_reboot 20 sec 0  0  1  1
integration.smoke.test_routers 0.1 sec 0  1 +1 0 -1 1
integration.smoke.test_scale_vm 5.3 sec 0  0  1  1
integration.smoke.test_secondary_storage 0.67 sec 0  0  2  2
integration.smoke.test_service_offerings 0.28 sec 0  0  3  3
integration.smoke.test_ssvm 25 min 0  6 +6 4 -6 10
integration.smoke.test_templates 1 min 40 sec 0  1  6  7
integration.smoke.test_vm_life_cycle 6 min 49 sec 0  0  10  10
integration.smoke.test_vm_snapshots 1 min 22 sec 1  0  0  1
integration.smoke.test_volumes 15 min 0 -1 0  9 +1 9

@wilderrodrigues  Can you please review and give LGTM

LGTM
integration.smoke.test_vm_life_cycle test case validates ssh access to Vm as part of test_10_attachAndDetach_iso test
Would be better test_deploy_vm test in test_vm_life_cycle also validates that Vm is accessible via SSH.


Fix charset issues

Sting.getBytes() is dangerous.
It uses the OS platform encoding, which may be a strange charset.
This should hopefully also fix #16

Hello Erlend !
Thank you for the interest to the library.
I can explicitly specify UTF_8 charset to avoid this.
Base64 is done by scodec library.
To address #16 text should be split by 76 chars and I am working on it.


Windows 32Bit 0.7.1h (Lastest Version) .ndll Error

Describe your bug here.
I Dowland Windows32Bit.zip , ı open file and ı open Psych Engine ,

So i will translate to Engilish , ''Bozuk Görüntü'' is ''Distorted İmage'' , ''Hata'' is ''Error'' and lime.ndll is not working , How its possible? But 0.6.3h not have this error
Command Prompt/Terminal logs (if existing)
No response
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
No , I didnt edit anything

you need to compile the game yourself for 0.7

@JustAFnfPlayeer crowplexus doğru diyor kendi windowsunda buildlemelisin


Feature Request: Use password instead of id_rsa file

I want to be able to connect using a username and password, is this possible?

See this issue


give nan results when use pytorch version for some input

^^ Hello, I found fast_bss_eval (version 0.1.0) sometimes gives NaN results.
The test code:
import numpy as np
import torch
from mir_eval.separation import bss_eval_sources
import fast_bss_eval

x = np.load('debug.npz')
preds = torch.tensor(x['preds'])
target = torch.tensor(x['target'])
print(preds.shape, target.shape)

sdr, sir, sar, perm = fast_bss_eval.bss_eval_sources(target, preds)
print(sdr)

sdr, sir, sar, perm = fast_bss_eval.bss_eval_sources(target.numpy(), preds.numpy())
print(sdr)

sdr,_,_,_ = bss_eval_sources(target.numpy(), preds.numpy(), False)
print(sdr)

the results:
torch.Size([2, 64000]) torch.Size([2, 64000])
tensor([-2.6815,     nan])
[-2.6815615 44.575493 ]
[-2.68156071 44.58523729]

The data and the debug code are all zipped in the debug.zip

@quancs Thanks for reporting this. I will look into it.

One thing that could explain it is that mir_eval will use float64 and torch float32 by default. Your SIR is 44 dB, which is very high, so that the denominator may become zero with float32.

I have checked that this seems to be an issue with the torch (cpu) float32 sub-routines, probably solve I would say. Interestingly, the result is correct when running on gpu. Numpy with float32 algo gives the correct value.
Nevertheless, it is not desirable to get nan values in the output, so I have modified the code so that it returns inf instead in this case.
inf values are produced in case of extremely low or high sdr/sir/sar. To avoid getting such values, one can provide the clamp_db argument to bss_eval_sources which will saturate the output values to [-clamp_db, clamp_db].
Due to limited numerical precision, values over under -40 dB or above 40 dB may not be relevant. In that case, set clamp_db=True.
I have added a test file tests/test_issue_5.py based on your data and fixed this in PR #6 . I will release a new version as soon as CI is done.
$ python ./tests/test_issue_5.py
torch.Size([2, 64000]) torch.Size([2, 64000])

torch torch.float32
tensor([-2.6815,     inf]) torch.float32

torch torch.float64
tensor([-2.6816, 44.5852], dtype=torch.float64) torch.float64

torch/cuda torch.float32
tensor([-2.6816, 44.6203], device='cuda:0') torch.float32

torch/cuda torch.float64
tensor([-2.6816, 44.5852], device='cuda:0', dtype=torch.float64) torch.float64

numpy float32
[-2.6815615 44.575493 ] float32

numpy float64
[-2.68156071 44.58523729] float64

mir_eval float32
[-2.68156071 44.58523729] float64

mir_eval float64
[-2.68156071 44.58523729] float64

Fixed by #6