OpenShift Deployment Wizard - refactoring list

This is a list of problems I've found in #7620 , which are not huge enough to block the PR but still need fixing...
UI:

1A - Use existing VMs from an existing provider - opening the dropdown with the inspector open causes the options to pop up, not down, and these are then hidden by the step indicator, when there's too many
footer - the Cancel button has nonsencial left and right padding, causing it to look weird when the other 2 buttons don't
1B - Private SSH key - that miq-clear-input-button is styled wrong and such hacks are not really necessary, because bootstrap input-group-addon would work just fine
1B - Edit Roles & Remove Roles - it's not immediately clear when these will be enabled, could use a  title specifying that you have to check one in the list first
1B - Edit Roles - the Submit button in the role dropdown looks misleading - Add or Save might make slightly more sense
1B - there is no indication why I can't click Next (turns out at least one server needs to be a Master, apparently, but how does the user know?)
3B - Progress  - there is nothing telling you the server was ..created, or any indicator whether the wizard was actually sucessful or not

JS:

miqHttpInject should only be called once per module, that is, when it's created, not whenever a controller is added there
getAuthenticationType does not return translated strings

HTML/HAML:

multiple missing translations in deploy-provider-details-no-provider.html.haml - Master, Node, Storage, Load Balancer... Master & Masters, Node & Nodes, ...
bad formatting causes hard to read code..

%div{"miq-wizard-substep" => "", "next-enabled" => "!inventoryChanged", "next-tooltip" => "navTooltip",
"ok-to-nav-away" => "!inventoryChanged", "on-show" => "onShow", "prev-enabled" => "!inventoryChanged",
"prev-tooltip" => "navTooltip", "step-id" => "review-summary", "step-priority" => "0", "step-title" => _("Summary"), "wz-disabled" => "false"}

could be
%div{"miq-wizard-substep" => "",
     "next-enabled" => "!inventoryChanged",
     "next-tooltip" => "navTooltip",
     "ok-to-nav-away" => "!inventoryChanged",
     "on-show" => "onShow",
     "prev-enabled" => "!inventoryChanged",
     "prev-tooltip" => "navTooltip",
     "step-id" => "review-summary",
     "step-priority" => "0",
     "step-title" => _("Summary"),
     "wz-disabled" => "false"}

(or even better with the arrows aligned)

overall there seems to be a lot of repetition - Master and Node being used in 5 different places for example (not saying it has to be one, just saying it will be a pain to find all of them when you need to add a new kind of thing)

CSS:

.btn[disabled] { pointer-events: none; } is wrong, this does not stop the user from activating the button, but does stop hover events, right click, etc.

@miq-bot move_issue ManageIQ/manageiq-ui-classic


Adds test for IPv6 evasion atomic fragment

This is one of the pcaps from #172 with a modified rule to make it pass (with suricata PR) cc @norg

LGTM

Merged, thanks!


Support compressed URL source

This is a basic implementation of handling compressed text files as URL sources, see https://github.com/gbif/ipt/issues/1632. In case of a URL source with file extension zip, the first file within the archive will be extracted and treated as a text file.

Thanks Pieter. I'll have a look

Got lots of conflicts with SourceAction, it was dramatically changed recently. Anyway, this changes now in the master branch

@mike-podolskiy90 I'm happy to update my PR next time.


What player modifications make a difference to the seed results?

Is it possible to crack the seed by disabling everything but dungeons? I have tried this and it outputs about 7 structure seeds and then what do I do with them. Im a bit confused on how and what the mod needs to gather a correct seed. For instance, does the biome setting matter if players modify the blocks? What about the shipwrecks? If I break a wood plank in a shipwreck and enable shipwrecks in the settings will I not get a seed? Im wondering if you could give more explanation on what player changes make a difference to the seed cracking results. Since 99% of the time the mod is used to find seeds on servers that will always be player modified in some ways.

Yes, it is possible to find the seed using just dungeons. I've tested this using only the dungeon finder on a 1.15.2 paper/spigot server. When the cracker outputs the several potential (dungeon?) seeds, you need additional information to calculate which one is correct.
In my experience (and I'm not sure if this is or isn't necessary), going to another dimension, End or Nether, fetches the hashed seed and quickly calculates and outputs the world seed of you've already done the dungeon cracking part.

Did you disable everything but dungeons?

I've tested this using only the dungeon finder on a 1.15.2 paper/spigot server.
Yes.

It works thanks. Its not as easy as it looks. Since clearing all seed data also clears the worlds hashed seed and resets categories to default so what you have to do to get it back is go to another dimension in the world. Nether works best. Heres what I did:
log on to server hub.
Switch to the survival server.
Go to nether dimension through vanilla means.
Clear seed data in nether.
Set everything to false through categories.
Enable dungeons through types.
Go back to overworld.
You should see a get hashed seed notification in chat.
Gather a few dungeons. (32+ bits)
You should now see a hashed decorators seeds notification.
It then works its magic and lists the seed in chat.

Glad to hear it worked for you. I opted to set the other finders off by default (with only the dungeon finder on) in the profile before compiling. This means you don't have to worry about clearing data if you know some of the other decorators are incorrect/modified.

For instance, does the biome setting matter if players modify the blocks? What about the shipwrecks? If I break a wood plank in a shipwreck and enable shipwrecks in the settings will I not get a seed? Im wondering if you could give more explanation on what player changes make a difference to the seed cracking results. Since 99% of the time the mod is used to find seeds on servers that will always be player modified in some ways.

It's a bit complicated but it should NEVER throw false positives. Breaking a piece of wood in a shipwreck probably won't affect it since the structure can still be uniquely identified. It depends on which wood block though. Overall, each structure has it's own restrictions and I tried really hard to make sure bad data never gets collected.

Thanks, the dungeon cracker works well but I havent had any luck with end decorator cracking.

End decorator cracking?

Using the end pillars and end gateways to complete the seed

I don't understand what you're referring to. The end features work the same as everything else.

If youre cracking without dungeon finder, you need the end dimension with gateways and pillars to find the seed right? What im saying is the non dungeon cracking never worked for me and I suspect its because my servers end dimension is wrong in some way. I think some of the end gateways are off by one block or something.


x/review: pickup URL specific http.cookieFile from the git config

git-codereview does not pick up an URL-specific cookieFile, like: http.{URL}.cookieFile. Looks like this in the config file:
[http "https://go.googlesource.com"]
        cookiefile = ~/.gitcookies-googlesource

git config does have a way to do that matching (--get-urlmatch which is nothing new), which also falls back to any non-URL-specific http.cookieFile.
The following works, but it is clearly not covered by the tests (but they do pass).
diff --git a/git-codereview/api.go b/git-codereview/api.go
index 8440cb5..a3375ea 100644
--- a/git-codereview/api.go
+++ b/git-codereview/api.go
@@ -145,7 +145,7 @@ func loadAuth() {

 	// First look in Git's http.cookiefile, which is where Gerrit
 	// now tells users to store this information.
-	if cookieFile, _ := trimErr(cmdOutputErr("git", "config", "--path", "http.cookiefile")); cookieFile != "" {
+	if cookieFile, _ := trimErr(cmdOutputErr("git", "config", "--path", "--get-urlmatch", "http.cookiefile", auth.url)); cookieFile != "" {
 		data, _ := ioutil.ReadFile(cookieFile)
 		maxMatch := -1
 		for _, line := range lines(string(data)) {

@josharian @kevinburke

Thanks. Want to send a fix?

I can submit the above patch on gerrit but i don't really have time now to rewrite/add tests to accomodate for it..


Tracking Issue for credential-process RFC 2730

Summary
RFC: https://github.com/rust-lang/rfcs/pull/2730
Implementation: #8934
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#credential-process
Issues: https://github.com/rust-lang/cargo/labels/Z-credential-process
This feature provides a configuration option to specify a process to fetch a token to authenticate with a registry.
Unresolved issues

[X] Is this approach useful enough?  Things like macos keychain don't protect against being executed to extract tokens (and I don't see a way to require a password, or force the process to be untrusted).  The lack of signatures also cause issues (each update of the toolchain will cause it to become untrusted again).

Making the built-in providers like cargo:macos-keychain part of the cargo binary improves security here, since only the Cargo binary is accessing the Keychain. If we get Cargo signed by Apple, then it would be further improved.

[X] Should the login API be changed? Providers that need to be interactive need to be able to read from stdin.

This is worked around by having the credential-provider re-open stdin from /dev/tty or $CONIN

[X] Should the storage key off the registry name? RFC 3139 discusses problems with this. RESOLVED: credential helpers are now keying off the index url via #10592.
[x] Should it be possible to pass additional arguments on the command line for cargo login that would be sent to the provider? E.g. cargo login -- --extra-arg-for-provider

Implemented in #12499

[X] Figure out the name for cargo:basic: cargo:token-from-stdout
[X] Remove cargo-1password as a built-in (add the fn main so it can be published separately).
[x] Create a new -Z flag for cargo:paseto.

[x] Publish cargo-credential-1password to crates.io

[x] Figure out MSRV support. rust-lang/cargo#12381 is proposing to set MSRV for all packages in the repo. I think it will be important that the credential provider libraries have a relatively relaxed requirement (like stable-2 or something). I think this will be important to figure out before stabilization. This may be complicated with CI costs, so I'm wondering if cargo-credential could grow a few independent tests on its own so we could test just the library with an older rust? https://github.com/rust-lang/cargo/pull/12623
[x] Testing of forwards-compatibility support. It is important that when a user installs a new credential provider that it does not necessarily cause older cargos to fail. There is a version field when we need to do breaking changes, but we need tests that are actually verifying that is working. https://github.com/rust-lang/cargo/pull/12622

[x] A test with some manually generated JSON with an invalid version file fed into a credential provider should provide the correct error message.
[x] A test with some manually generated JSON with the current V1 format that is fed into a credential provider, and validate that it behaves correctly. This will make sure that if any changes to the credential provider are made that are not compatible with the old format that the test will fail.

[x] Resolve rust-lang/cargo#12642
[ ] Stabilization PR - #12649
[ ] Publish cargo-credential v0.4 to crates.io
[ ] Publish cargo-credential-1password v0.4 to crates.io

About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Also see the discussion in https://internals.rust-lang.org/t/securing-cargo-publishing-credentials/14050

There's still a lot of unanswered questions in this tracking issue. But to make it clear basic functionality from the RFC is implemented and available for testing. The questions are all about comparatively small details.

I have posted a proposal to stabilize just the cargo logout portion at #11910.

#12334 has been merged which is a redesign of this feature. It should land in nightly within the next week.

@ehuss should this issue be closed, then?

@ehuss should this issue be closed, then?

I'm not sure I understand the question, why would this be closed? This is still tracking the credential-process feature. Its design has changed some, but it is still an unstable feature we are tracking.

@ehuss 🤦🏻 Sorry, I forgot that just because it's implemented doesn't mean it's stabilized.

All the checkboxes in the original issue post here have been checked off - can an updated checklist be made if this is not ready to be stabilized?

All the checkboxes in the original issue post here have been checked off - can an updated checklist be made if this is not ready to be stabilized?

I'm not sure which original issue you are referring to. Work is still actively being performed on this, mainly the amazing effort from @arlosi:
#12424
#12439
#12440
#12461
#12469
#12499
#12507
#12512
#12515
#12518
#12521
#12526
#12551
#12587
#12588
#12590
#12622
#12623
#12626
#12628
We are getting very close to being ready to stabilize. However, some of these changes haven't even made it to nightly, yet.

@Fishrock123 The checkbox list in the comment at the top of this thread are "unresolved issues", meaning design questions that needed to be answered. It is not a complete list of steps necessary to actually implement this feature.

I'm not sure which original issue you are referring to. Work is still actively being performed on this, mainly the amazing effort from @arlosi:
We are getting very close to being ready to stabilize. However, some of these changes haven't even made it to nightly, yet.

All but one of those are merged. I am asking if it would be possible to update a high-level checklist like the one at the top of this issue with at least some kind of bullet point of what is left to be done.

Checklist in this issue updated

Hi,
A question   if "--token" for cargo build not included, is it any way to pass token to Private artifactory such as jfrog that requires token for crate download ??
Regards,
Moji

is there any way to pass token to Private artifactory such as jfrog that requires token for crate download

Yes, that's covered by the registry-auth unstable feature tracked as https://github.com/rust-lang/cargo/issues/10474
I'll be posting a stabilization PR for both registry-auth and credential-process soon. Hang in there.

Stabilize registry-auth and credential-process
Users have been requesting a way to have authenticated private registries for some time, and the registry-auth feature has received significant testing, with multiple commercial and non-commercial offerings implementing the current unstable protocol.
The Cargo team has been reluctant to stabilize it as-is because it uses static plaintext tokens which are at greator risk of being leaked (accidentally or maliciously).
To improve the security situation, work continued on credential-process and asymmetric-token unstable features and the team agreed to only stabilize registry-auth if it was combined with one of these two approaches for improved security. credential-process allows the token to be stored securely by the operating system, or for people to build external credential providers that can generate short-lived tokens for registries. I believe the credential-process feature is ready to be stabilized, which also unblocks registry-auth.
Attempts to use an authenticated registry without a credential provider configured will encounter an error such as:
authenticated registries require a credential-provider to be configured
see https://doc.rust-lang.org/cargo/reference/registry-authentication.html for details

For contexts like CI where a more secure credential provider may not be available, the existing behavior of reading from config or the *_TOKEN environment variables can be enabled by selecting the cargo:token provider.
Stabilization summary (registry-auth)

The auth-required field in the registry index's config.json
Automatically retrying requests to config.json in sparse registries with authorization included on HTTP 401 errors.
Note: Attempting to use these features without a credential provider configured is an error.

Stabilization summary (credential-process):

The built-in credential providers: cargo:token, cargo:wincred, cargo:macos-keychain, cargo:libsecret, cargo:token-from-stdout <path> <args>
The credential provider v1 JSON protocol for external credential providers
The registry.global-credential-providers config value
The registries.<NAME>.credential-provider config value
The [credential-alias] config table

To review these changes in more detail, I recommend looking at the documentation changes in the draft stabilization PR rust-lang/cargo#12649.
@rfcbot fcp merge

Initially, I was concerned about allowing a plugin to be used multiple times with different configurations.  This mostly came up as a theoretical because I was thinking or process plugins for per-user cache where that might be of more interest.  Arlo pointed me to the fact that CLI flags can be used for this which I had forgotten about and overlooked it when I went back over the docs.

@rfcbot concern future-compatibility
Built-in providers start with cargo: but on non-Windows systems, a binary could be created with a name like that or on all platforms a credential alias could be named that.  Either approach means we have a potential compatibility hazard if we want to add more built-ins in the future.

We could reserve the cargo: namespace for credential providers, but I think we shouldn't.

It's unlikely that a user will accidentally set up a credential-provider with a cargo: prefix, so the risk of unintentional shadowing is low (significantly less than the current issue of subcommand shadowing).
If in the future Cargo adds a new built-in provider cargo:foo, it would be possible to make a polyfill provider available for older cargos that could be added via cargo install cargo-credential-foo and a credential-alias.[credential-alias]
'cargo:foo' = 'cargo-credential-foo'

OTOH there may be a reason I'm not currently thinking of why we need to reserve something that we know can't be user-defined, and the current proposal does not allow for that.

We also consider shadowing fine for built-in subcommands, aliases, and third-party subcommands though we provide warnings when it happens: https://github.com/rust-lang/cargo/blob/master/src/bin/cargo/cli.rs#L258
Maybe that is the route we should go with using that as our precedence.

@rfcbot resolve future-compatibility
See #12671

Will this be in the beta on October 5th and available in the stable channel on November 16th?

Stabilizing this without making cargo:token a default option (which would have respected the world as it functioned before 1.74) has broken all of our CI: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Cargo.201.2E74.20broke.20all.20our.20CI.20due.20to.20credentials-process


Performance and Fairness Metrics Results Questions

I try to get performance and fairness metrics results but have two questions:
In performance_metrics.py line 211:
self.result['perf_metric_values'][j] = (self.result['perf_metric_values'][j][-1],  2*np.std(self.result['perf_metric_values'][j]))
Q1: why we take the last item [-1] from the list ['perf_metric_values'][j] as the metric value? Shouldn't this be the mean value?
In fairness_metrics.py line 243:
self.result[i]["fair_metric_values"][j] = self.result[i]['fair_metric_values'][j][-1] + (2*np.std([a_tuple[0] for a_tuple in self.result[i]["fair_metric_values"][j]]),)
Q2: can you explain the results here? for each fairness metric, I have three values:
{'country_code': {'disparate_impact': (0.9899166435069041,
0.9313824419778002,
0.010717541771964288),....}
According to the document, I should get "a dictionary with keys as the fairness metric name and values as the metric value together with confidence interval".

Q1: [-1] refers to the 1st round of results. the target output is [metric_value, confidence_range]. confidence_range is derived by 50-round bootstrapping (1st run + 49 runs later)
Q2: (metric_value, privileged_metric_value, confidence_range). "privileged_metric_value" refers to corresponding performance value of privileged group in a fairness metric. e.g. in disparate_impact, DI = Pr(Y=1|D = unprivileged) / Pr(Y=1|D = privileged), privileged_metric_value is the denominator. it's useful for computing fairness metric threshold.


There is no available initial state for the content type

@javrasya This issue is somehow related to this one https://github.com/javrasya/django-river/issues/32
So basically after creating my model with the status = StateField(editable=False) and migrating on an existing DB, i noticed that i had to do a makemigrations/migrate again for it to create an automatic proceeding migration 0007_auto_20161014_1736.
Without this migrations, i would run into this error river.utils.exceptions.RiverException: There is no available initial state for the content type mymodel. With it everything worked fine.
Now i am trying to run a unit test for my rest api endpoint  were i have instance = ModelClass.workflow.create(**validated_data) to create a new object, but since i don't have that auto migration i am running into river.utils.exceptions.RiverException: There is no available initial state for the content type mymodel. I tried call_command('makemigrations', stdout=out) and call_command('migrate', stdout=out) from within the test but not luck.
Is there a better way to avoid this error all-together? Or a way for me to force that proceeding extra migration?
Thanks

This is happening because you probably didn't define your workflow scenarios yet. I mean, django-river tries to detect initial state in your workflow scenario according to one defined for your model content type and put this initial state into your model instances. This is done by django-river at two different time. Whenever you create a new instance from your model, and whenever you migrate your existing db(contains data) for django-river. You can check 0004_data_fix.py in django-river to see it for second one.
Before doing those, define your workflow scenario(you can use admin interfaces. This is described in video tutorial if you wanna look at)
I should have prepared a tutorial to migrate from existing DB, I see this is the lack of django-river.
If you need more help, let me know please.

@javrasya oh i see.. since i am running it as a test i probably forgot to create the State, Transition and Proceeding objects to go along my test. When i test it manually everything works because i already have them in my database. I will try that and let you know if it works. Thanks

@javrasya i still haven't figured it out. I tried recreating my admin workflow scenario in my test but still getting the river.utils.exceptions.RiverException: There is no available initial state for the content type qualification request.
basically in my test.py i have
        source_state = State.objects.create(slug='requested', label='requested')
        destination_state = State.objects.create(
            slug='accepted', label='accepted')

        transition = Transition.objects.create(
            source_state=source_state, destination_state=destination_state)

        content_type = ContentType.objects.get_for_model(QualificationRequest)

        proceeding_meta = ProceedingMeta.objects.create(
            content_type=content_type, transition=transition
        )

        out = StringIO()
        sys.stout = out
        call_command('makemigrations', stdout=out)
        print(out.getvalue())
        call_command('migrate', stdout=out)
        print(out.getvalue())
        call_command('showmigrations', stdout=out)
        print(out.getvalue())

        QualificationRequest.workflow.create(
            al_id='35140', name='test', phone='2'<EMAIL_ADDRESS>
What am i doing wrong??

I will try to create a case as same as yours and reproduce it and let you know

@javrasya yes the workaround works, thanks.


support default docker machine env variables

The new docker machine that replaces boot2docker has different defaults env settings.

Irrelevant now that we do not support local Docker runs...


feature/add-svelte-ui

feature/add-svelte-ui
This PR creates a Svelte version of the React UI package using the exact same style.css stylesheet.
It exposes the following components:

WalletMultiButton as entry-point of the ui implementation
WalletButton as wrapper button for the different variants
WalletConnectButton connects the selected wallet.
WalletModal modal component containing the wallets to be selected

Usage:
Insert the <WalletMultiButton in your Svelte application and that's all. The UI implementation pull the methods and store from the core
To complete the integration and following what is done in the React and Vue implementation, the next components are added:

<WalletProvider />
<ConnectionProvider />

To give support to this, we need to add this Svelte Store.

workSpace.ts

This last one file, is a Svelte Store where are saved the values from Connection that should be used/share among the components to make/sign transactions.
To show how this works, a repo is created as demo which is deployed in Netlify connected to the DevNet.
Package
Followed the SvelteKit packaging documentation
`npm run build` to package the app using SvelteKit

The output files will be in the package directory

@jordansexton Hi there!
This PR related to the UI is ready too.

We tested this package locally with npm link

@jpshankle thanks for looking at this. This PR is blocked until https://github.com/solana-labs/wallet-adapter/pull/173 is merged.
We'll have to make some more amends based on the outcome of that PR

@jordansexton and @jpshankle this is now ready to review.
Looking for some advice on how to handle https://github.com/solana-labs/wallet-adapter/pull/162/commits/477b385275728e901ecff35d735efcb31bbfbe1a
This UI package was tested in conjunction with the wallet-adapter-svelte package locally using symlinks.
This works both in SPA and SSR mode

Any progress on this?

Sveltekit/Svelte dev numbers are skyrocketing; can the Svelte NPM packages also be pushed up the list.

#285 has removed Angular from this monorepo to its own repo where it can be maintained. I think we should do the same with Svelte and Vue in order to improve the release process and cadence for packages that I can't effectively maintain as part of the core. This will also allow these external packages to have more idiomatic patterns, build systems, and documentation.
@cogoo we discussed this before, but do want to take the lead on this?

#285 has removed Angular from this monorepo to its own repo where it can be maintained. I think we should do the same with Svelte and Vue in order to improve the release process and cadence for packages that I can't effectively maintain as part of the core. This will also allow these external packages to have more idiomatic patterns, build systems, and documentation.
@cogoo we discussed this before, but do want to take the lead on this?

Work on this has already started in https://github.com/svelte-on-solana. Few things left to iron out before first alpha release. Soon™

Awesome! Whenever you think it's ready, please open a PR to remove it and add links to your repo's packages.
I'm excited to finally unblock Svelte users :)

Svelte support is going to become community maintained! Please subscribe to https://github.com/solana-labs/wallet-adapter/pull/298, which will be completed and merged when @cogoo and @silvestrevivo release Svelte packages.


firefox: fix cross compilation

Motivation for this change
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Please mention what you tested here.

before:
nix-repl> pkgsCross.riscv64.rustc.llvmPackages.stdenv.buildPlatform.config
"x86_64-unknown-linux-gnu"

nix-repl> pkgsCross.riscv64.rustc.llvmPackages.stdenv.hostPlatform.config
"x86_64-unknown-linux-gnu"

nix-repl> pkgsCross.riscv64.rustc.llvmPackages.stdenv.targetPlatform.config
"riscv64-unknown-linux-gnu"

after:
nix-repl> pkgsCross.riscv64.rustc.llvmPackages.stdenv.buildPlatform.config
"x86_64-unknown-linux-gnu"

nix-repl> pkgsCross.riscv64.rustc.llvmPackages.stdenv.hostPlatform.config
"riscv64-unknown-linux-gnu"

nix-repl> pkgsCross.riscv64.rustc.llvmPackages.stdenv.targetPlatform.config
"riscv64-unknown-linux-gnu"

It should have no effect on native builds, just testing cross builds.

Btw, this PR added it: https://github.com/NixOS/nixpkgs/pull/144219

rebuild: 0 is a nice indication, just found that lld fails to cross, fixing on my side.

builds are all green: https://hydra.nichi.co/eval/39, lto on riscv is expected to fail as it is not implemented by lld.

builds fine natively on my local machine, we should be good to go.

Dropped the riscv related patches as they no longer apply as of firefox 95, but build for other platforms should work.

What cross compilation target did you test? aarch64 does not seem to cross compile for me.

Also aarch64, just ran a build, and it was green: https://hydra.nichi.co/build/82010.

It might be good to list which PRs (if they're already open) are blocking this to work then. It's not that useful to merge this if more work is needed, but I guess it's debatable. At least it's hard to test if it doesn't work ootb.

We now depends on https://github.com/NixOS/nixpkgs/pull/148647 (staging), https://github.com/NixOS/nixpkgs/pull/148618 (WIP), and https://github.com/NickCao/nixpkgs/commit/851d3bbb1e7dbffe094c6b758a5447045146daa7

Switch to libvpx and test, I suspect it will be fine but it's hard to know. Looking at what other distros (e.g. Gentoo) do is also valuable.

Switch to libvpx and test, I suspect it will be fine but it's hard to know. Looking at what other distros (e.g. Gentoo) do is also valuable.

I've check that both Gentoo and Debian are using the latest libvpx for firefox. Do require additional testing on our side.

Switch to libvpx and test, I suspect it will be fine but it's hard to know. Looking at what other distros (e.g. Gentoo) do is also valuable.

I've check that both Gentoo and Debian are using the latest libvpx for firefox. Do require additional testing on our side.

Maybe just open a PR for this and I can build all firefox at some point.

The gtk3 patchset is merged, hopefully that'll be enough to get this working. Could you rebase this? Or do you want to wait until the gtk3 change hits master before investing more time in this (the build will be very long for sure for firefox, I'm guessing).

The spring cleanup changed quite a lot of things, it will take me some time to pick this up.

Cross builds fine with LTO for aarch64-linux.

If we want to get this in as it is, this needs to go to staging. Since the gtk3 change is only in staging anyway, maybe it makes most sense to just send this all to staging for now.
It's also possible to factor out the gfortran change and send the rest to master, but it'll only work after staging goes to master anyway.

I've changed the base branch to staging, and the gfortran commit can be dropped once https://github.com/NixOS/nixpkgs/pull/171466 is merged.

Ah, I know why it suddenly did that (show thousands of rebuilds), because gcc11 is a difference from how it was before for some platforms. Now master should be fine again :). Sorry for the churn.

Ah, I know why it suddenly did that (show thousands of rebuilds), because gcc11 is a difference from how it was before for some platforms. Now master should be fine again :). Sorry for the churn.

Without the gtk fix this would just be useless, going through staging is fine

Of course, forgot about that. Yes, that's fine.

I'm not really sure why I was requested to review as I haven't had anything to do with either of these packages.
That said, I'm still a while away from being able to effectively test firefox on riscv64, since right now a basic successful nixos-rebuild is what I'm aiming for.
I'll see if I can properly test this (and I guess X, some window manager, and networkmanager) once that's complete. Current hardware is pretty slow on riscv, unfortunately.

@Madouura simply running the resulting binary under qemu-user is enough, also I tried watching video with firefox on a hifive unmatched a while ago. it was playing fine despite a little laggy (or a lot, in today's standard). Anyway riscv support is not part of this pr as it requires additional patching.

Anyway riscv support is not part of this pr as it requires additional patching.

I'm doubly confused then haha.
Anyway, I'll go ahead and do just that then.

Anyway riscv support is not part of this pr as it requires additional patching.

I'm doubly confused then haha. Anyway, I'll go ahead and do just that then.

You can simply grab the patch from our Arch Linux friends: https://github.com/felixonmars/archriscv-packages/tree/master/firefox, disable LTO and get a working firefox out of the box.

Good to go?

Ah, it's sndio. Makes sense.
The change there is fine.
Gonna make sure x86_64 works and then do the same for aarch64 and approve if nothing is amiss.

x86_64 builds fine.
aarch64-multiplatform fails.
log.txt

The wrapper won't cross build due to issues with perl, try just firefox-unwrapped.


New node for calling SalesForce REST services

I have some custom APEX REST services that I need to call from Node-Red. It was pretty easy to clone the SOQL node as a starting point and do some very minor changes to create an APEX REST node ... but then as I looked through the nforce api ... it seems like it might be better to just make a generic REST node that can call any of the bits the API that aren't covered by the other nodes (APEX Rest, Invocable Actions, Metadata, etc.).
What do you think makes more sense? i.e. just have specific nodes to wrap the rarer cases like nforce.apexRest, or make a general node that can wrap nforce.getUrl .putUrl .postUrl & .deleteUrl ?
Either way I can provide a pull request for the new node.
Thanks!

@Stwissel any comments on this one? I have a current version of this that we are using for calling for just custom APEX REST services, but I easily switch it to be more generic.
Either way I can provide a pull request. Thanks!

A pull request will be very much welcome

@Stwissel ... Any preference between implementing it as a "apexrest" node or a generic SF Rest node (or both)?
We have an apexrest node done now and have been using to do thousands of calls against a few custom SF Apex Rest services.
Thanks!

Apex rest would use the Salesforce config Object. I like that
On Tue, 6 Nov 2018 at 22:47, Dustin Windibank<EMAIL_ADDRESS>wrote:

@Stwissel https://github.com/Stwissel ... Any preference between
implementing it as a "apexrest" node or a generic SF Rest node (or both)?
We have an apexrest node done now and have been using to do thousands of
calls against a few custom SF Apex Rest services.
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Stwissel/node-red-contrib-salesforce/issues/30#issuecomment-436277839,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhHVY4OiORpY1uiO6z5GLNYqIj6Ua7uks5usaD8gaJpZM4WCQc3
.

--
Mobile message, pegged on glass.
Best regards
Stephan H. Wissel
http://www.wissel.net/

We've been using this for a while now, so I need to finally create a Pull request. Should I do it against the main branch or will the Dev branch be released soon?
Thanks!

@dwindibank -> did you ever get to implement this?


Add docs around using CodeTogether for collaboration

[ ] Test out in code-server
[ ] Document how to use

Related:

https://github.com/cdr/code-server/issues/33#issuecomment-890184201

At duckly I made some changes yesterday and now we also support code-server.
This version is not released yet but I can send you a .vsix and would be glad to help out with this

Oh awesome! Sure, feel free to open a new issue "Add docs around using duckly for collaboration" with the vsix, then I can try, ask questions and when I understand, I'll submit a PR to add to our docs. How does that sound?

Sound awesome, will do!

oh whoops didn't realize this issue existed


OS X build adjustments

Hey Travis,
As I also work on OS X, I've made some minor adjustments:

for some reason, std::size_t and long were not properly handled by serialization
std::set empty brace init caused compilation errors

Build is now OK and all tests pass on:
OS X Yosemite 10.10.3 (14D105g)
with
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
P.S.: sorry for the unnecessary dummy changes in source files, my editor strips trailing spaces.
Hope you'll find this useful.
Best,
--
Rémy

Coverage remained the same at 96.03% when pulling 485e81a96054e2c23060a3f60d837a503c85c7bb on chybz:master into 94963694a6ce18ef74b5c7c454efe26d188743b8 on tgockel:master.

Coverage decreased (-0.04%) to 95.99% when pulling 7891b24b03417e35a34ed216313f54419c1291a2 on chybz:master into 94963694a6ce18ef74b5c7c454efe26d188743b8 on tgockel:master.


Memory leak during page navigation with ListViews

Find attached two demo projects, the "UIOnly" folder contains the example from this issue comment, ported to the latest project template.
Additionally, the "MVVM" folder contains an example that is similar to what I try to build in my application. I had to click back and force for a long time and some memory gets freed sometimes, but the app will crash eventually.

Hope that helps and thanks for looking into it.
PoC.zip
Originally posted by @marcpiechura in https://github.com/microsoft/CsWinRT/issues/413#issuecomment-1016580898

Hi, I created a project using the starter WinUI3 template provided by Visual Studio.
Here it is.
I also provided a gif demonstrating how every navigation adds a MB and it never stops nor gets collected.

This is on .NET 6.0.300, template used was navigation pane with a settings page, MSIX packaging, and MVVM structure.
This is also demonstrated via the newest WinUI 3 Gallery update from the Microsoft Store, clicking a new navigation tab adds several MB every time.

Hi, I created a project using the starter WinUI3 template provided by Visual Studio. Here it is. I also provided a gif demonstrating how every navigation adds a MB and it never stops nor gets collected.       This is on .NET 6.0.300, template used was navigation pane with a settings page, MSIX packaging, and MVVM structure. This is also demonstrated via the newest WinUI 3 Gallery update from the Microsoft Store, clicking a new navigation tab adds several MB every time.

has the same problem, operation similar to yours.(also appears when navigation stack is disabled)
repo: https://github.com/l619534951/NavMemLeak
I don't know whose problem it is, then I created issue in microsoft-ui-xaml https://github.com/microsoft/microsoft-ui-xaml/issues/7322

is there any workaround for this while we wait for the fix ? I am surprise this has not been fix yet as this affects everyone using this framework. Even WinUI 2 Galery has this issue. Come on.

We have migrated our UWP app to WinUI3/WinAppSdk and all our users are reporting a significant performance improvement, there are still memory leaks in navigation, but in our stress tests they do not appear as early as they did in UWP. This team is doing a good job but these remaining issues need to be addressed soon, the navigation memory leaks have been present on this platform since its early days.

For now I went ahead and implemented ContentControl navigation instead of Frame navigation. Manually disposing/getting rid of UserControl (instead of pages) seems to be doing the trick for now.

For now I went ahead and implemented ContentControl navigation instead of Frame navigation. Manually disposing/getting rid of UserControl (instead of pages) seems to be doing the trick for now.

Try Windows App SDK 1.2.0-preview2, It fixes many problems. (The memory leak of listview is fixed, but I haven't tested Frame)

@l619534951 I'm using it, it's not fixed.

It should be fixed in the latest WindowsAppSDK version. I tested navigating back & forth and it's indeed increasing the memory but for my app it stops at around 500 MB of RAM. As far as I know there is a cache limit until which no memory will be released, so probably that's why it's still increasing.

Yes it has been fixed. I believe WinAppSdk is heading in the right direction with the latest improvements in rendering. But scrolling still isn't as smooth as UWP, but I believe this will be fixed in a future release.
Well done to the team.

I have still this issue.
@christosk92 my application runs with 110mb memory usage, I have several charts and after doing some navigation and loading some charts it goes to 2gb and more.
Is this certain threshold you mentioned above may goes higher than this or I should be hopeful to see it stop growing somewhere ?

@christosk92 Which version resolved this problem?

@manodasanW I think this issue is not only related to ListView (maybe rename this issue?) and I also would argue it is not really fixed. Apps like Files or the WinUI Gallery still have issues with massive memory consumption.
Attached is a simple repro project: NavigationMemoryLeak.zip

@manodasanW any update?