iOS - Profile - The App crashes when saving the user's avatar

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.49-0
Reproducible in staging?: y
Reproducible in production?: n
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4410248
Issue reported by: Applause - Internal Team
Action Performed:

Open iOS App
Login with any account
Go to Account Settings
Tap to User Avatar
Select "Upload photo"
Select "Take photo" or "Choose from gallery"
Take/select photo and tap "Save"

Expected Result:
Photo was successfully saved as the user's avatar.
Actual Result:
App crashes after user taps on "Save" button
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[x] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/93399543/61bd385b-6315-414f-9dd9-c4b4b33951fd
View all open jobs on GitHub

We think that this bug might be related to #vip-vsb
@quinthar

@shubham1206agra Please attached
logs crash.docx

not able to reproduce on dev

this appears to be related to this crash, which was first caught on 1.4.47-10. So I'm not sure if it's a blocker (but it was my mistake not noticing this earlier this week, I had been looking only at Android crashes by mistake)

was able to reproduce on staging. I wonder if it has to be an HEIC?

need to test on a physical device...

I reproduced in iOS Simulator.
The crash happens only on release build. It's pretty bad that once reproduced following OP, crash happens on app launch until uninstall and reinstall the app.
After reverting https://github.com/Expensify/App/pull/36019, not able to reproduce.

I managed to debug more.
After reproducing crash on release build, switch to debug scheme and build, console error on app launch:

I wonder if this can be fixed by removing deprecated useWorkletCallback: https://github.com/software-mansion/react-native-reanimated/pull/5377/files#r1501883320

cool, was able to reproduce on a release build. Going to try nixing useWorkletCallback and see if that helps

I am very stuck on trying to fix this, mostly because it's very difficult to debug or even get logs in a release build, which seems to be the only place where this is reproducible.

https://github.com/Expensify/App/pull/36019 is already on production. Have we verified that this is not reproducible on prod?

Requested retest: https://expensify.slack.com/archives/C9YU7BX5M/p1709996985170449

Noodling about in https://github.com/Expensify/App/pull/38018, but confident that I'm any closer to a fix

Ok, this was reproduced in prod, so not a deploy blocker. But it's very bad, maybe a fire

Bug is reproduced in production too.
https://github.com/Expensify/App/assets/43996225/104d8279-d96d-4252-ac37-30ccb28e5f36

I confirmed that commenting out this line prevents the crash. This doesn't really tell us much, other than that the crash doesn't appear to be happening inside cropOrRotateImage, or manipulateAsync. It's still possible that the crash is caused by a problem there though, such as a file not being saved correctly.

some logs: https://staging.expensify.com/_devportal/tools/logSearch/#query=request_id:("861c7ee5cdbbef73-PDX")+AND+timestamp:[2024-03-09T15:38:30.081Z+TO+2024-03-09T17:38:30.081Z]&index=logs_expensify-027211

ok, so I confirmed that the crash happens after this point. I tried just removing the Onyx data from API.write(WRITE_COMMANDS.UPDATE_USER_AVATAR, parameters, {});, but the crash still happens in this case.

ok, commented out API.write() entirely and put Onyx.update(optimisticData) directly in PersonalDetails.updateAvatar and that worked. I'm seeing the new avatar image, which tells me the file is being saved locally.
So next up I need to figure out where the actual image upload code is and try to narrow down what's going wrong.

I found a random article which does this to upload a file:
const createFormData = (photo, body = {}) => {
  const data = new FormData();

  data.append('photo', {
    name: photo.fileName,
    type: photo.type,
    uri: Platform.OS === 'ios' ? photo.uri.replace('file://', '') : photo.uri,
  });

  Object.keys(body).forEach((key) => {
    data.append(key, body[key]);
  });

  return data;
};

note the Platform.OS === 'ios' ? photo.uri.replace('file://', '') : photo.uri - the uri we have definitely starts with file://...

Hey @roryabraham  hope this can help, I can see the JS log.

The crash happened right after you clicked Send button and after reseting the app (later), so I think it must be something with applying optimisticData.

ok, commented out API.write() entirely and put Onyx.update(optimisticData) directly in PersonalDetails.updateAvatar and that worked

I'm not sure. I think it's the file upload that's failing?

I tried adding a line here like result.uri = result.uri.replace('file://', '');, no dice 😞

I can confirm revert to use @oguzhnatly/react-native-image-manipulator will fix the issue. So the problem will be with expo-image-manipulator.

Going to proceed with a revert due to the severity of the bug. I'd like to CP the revert to staging so we can fix prod ASAP

reopening to verify the fix in 1.4.49-4

ok so as I said here, app still crashes on launch for the users who already triggered crash on avatar upload in previous build.
They should uninstall and reinstall to continue using the app.

yeah, that's unfortunate but I don't think there's anything we can do about it really ☹

well, maybe if we found a "restorative" fix to the crash rather than a "preventative" fix, but idk if we'll be able to do that since it seems to be a low-level crash in the native network request code, presumably caused by some bad url or something?

verified this is fixed after you uninstall and reinstall

Hey, I've investigated this issue today.

The reason behind it was that we were passing the base64=null param inside the file parameter when calling the API:
https://github.com/Expensify/App/blob/95a774e597bed9621733e48df1b61e8c77b0c590/src/libs/actions/PersonalDetails.ts#L385
The RCTNetworking networking library didn't like the base64 nullish value, and early returned causing the crash:
https://github.com/facebook/react-native/blob/a7fde7c885a3827c03b058a21023b18501e2a57a/packages/react-native/Libraries/Network/RCTNetworking.mm#L425-L428
Why did we pass the base64 value?
The expo-image-manipulator library by default sets the base64 option to false, meaning that we don't need to generate it. But the library instead of skipping this param, adds base64=null in this line:
https://github.com/expo/expo/blob/a05bfbc3a907177bca2dd8a2dd22073763daa895/packages/expo-image-manipulator/ios/ImageManipulatorModule.swift#L33
Commenting out this line fixes the problem.
So I come up with two solutions (without touching the library):

We can pass here base64: true option to generate the base64 (instead of passing null)
We can remove the base64 prop from the parameters when calling the API command:

const {base64, ...fileWithoutBase64} = file;
const parameters: UpdateUserAvatarParams = {file: fileWithoutBase64};

I will also contact with the internal expo maintainers at SWM, as they might want to fix it in the library.

I will prepare a PR with the fix tomorrow.
Thanks @roryabraham for the initial investigation, as it helped a lot!

sounds good @kosmydel and thanks for figuring that out. Glad my initial investigation was helpful! If we're not using the base64 encoding I imagine it's likely better not to generate it unnecessarily. So let's go with the 2nd solution to remove the base64 from the parameters when calling the API command.
Alternatively, maybe we can update expo-image-manipulator to remove base64: null from the response if no base64 encoding is created. That seems like the best solution if they're down for that

https://github.com/expo/expo/blob/a05bfbc3a907177bca2dd8a2dd22073763daa895/packages/expo-image-manipulator/ios/ImageManipulatorModule.swift#L33

Alternatively, maybe we can update expo-image-manipulator to remove base64: null from the response if no base64 encoding is created. That seems like the best solution if they're down for that

I've contacted an Expo maintainer, so I will keep you updated.
For now, I think to unblock the issue, I can prepare a PR with the 2nd solution.

sounds good @kosmydel and thanks for figuring that out. Glad my initial investigation was helpful! If we're not using the base64 encoding I imagine it's likely better not to generate it unnecessarily. So let's go with the 2nd solution to remove the base64 from the parameters when calling the API command.
Alternatively, maybe we can update expo-image-manipulator to remove base64: null from the response if no base64 encoding is created. That seems like the best solution if they're down for that

Quick update: After contacting Expo maintainers they told me, that this is expected, and consistent across other parameters. They will improve the types, so the base64 will also include the null type (currently it is string | undefined). So in that way, we would know, that base64 could be null, and we would be able to handle it appropriately.
For now, I've created a PR with 2nd solution.


Work in progress: Use W3C Profile vocabulary

Expand profile crate to formalize the elements of the profile using the W3C Profile vocabulary

See https://stain.github.io/ro-crate/1.2-DRAFT/profiles#profile-crate using type Profile, and use of hasArtifact to a ResourceDescriptor in https://stain.github.io/ro-crate/1.2-DRAFT/profiles#what-is-included-in-the-profile-crate
(Rendered together with #233 #232 #231 #230 #229)


Specify Cost Center?

Hi.
There seems to be no way to specify which Cost Center the subscription is to use.
Am I understanding the documentation correctly?
Thanks.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 371189c2-154f-2716-bbc0-8496a76c5ac9
Version Independent ID: bb5cd103-ff51-1753-f269-e2c1aa49a8c8
Content: Programmatically create Azure Enterprise subscriptions
Content Source: articles/azure-resource-manager/programmatically-create-subscription.md
Service: azure-resource-manager
GitHub Login: @jlian
Microsoft Alias: jlian

@MartinNr5,
Thanks for the feedback. We are actively investigating and will get back to you soon.

Hi @MartinNr5, right now it's not supported during the preview. You can specify it in the EA portal https://ea.azure.com/manage/subscription/accountowner for now, and we're looking into putting it behind API as well.

#please-close

I created an item on feedback.azure.com
https://feedback.azure.com/forums/281804-azure-resource-manager/suggestions/37336423-specify-costcenter-when-creating-subscription-from
please vote :-)


Make kodi overrideAttrs and withPackages composable

Description of changes
When using a kodi derivation modified with overrideAttrs and adding extensions to it with withPackages the changes were discarded and the original unmodified kodi derivation was wrapped together with the extensions.
Fix this by switching kodi to use the mkDerivation with finalAttrs pattern (described in #119942 and https://nixos.org/manual/nixpkgs/stable/#mkderivation-recursive-attributes).
Things done

For testing I've assebled a little flake
Test-Flake (expand)

{
  description = "test flake for nixpkgs kodi override";

  inputs = {
    nixpkgs.url = github:nixos/nixpkgs/release-22.11;
    flake-utils.url = "github:numtide/flake-utils";
    nix-flake-tests.url = "github:antifuchs/nix-flake-tests";
  };

  outputs = inputs@{ self, nixpkgs, flake-utils, nix-flake-tests }:
    flake-utils.lib.eachSystem [ "x86_64-linux" "aarch64-linux" ] (system:
      let
        pkgs = import nixpkgs
          {
            localSystem = "${system}";
            overlays = [
              (final: prev: {
                kodi = prev.kodi.overrideAttrs (o: {
                  pname = "test-kodi";
                });
              })
            ];
          };
      in
      {
        packages = {
          inherit (pkgs) kodi;
          kodi-with-addons = pkgs.kodi.withPackages (p: [ p.inputstreamhelper ]);
        };
        checks = {
          kodi = nix-flake-tests.lib.check {
            inherit pkgs;
            tests = {
              testNameStartsWithPName = rec {
                expected = "test-kodi-";
                expr = builtins.substring 0 (builtins.stringLength expected)
                  self.packages.${system}.kodi-with-addons.name;
              };
              testAddonGetsLinked = {
                expected = [ ]; # exact match of regex returns empty list
                expr = builtins.match ".*-kodi-inputstreamhelper-.*"
                  self.packages.${system}.kodi-with-addons.postBuild;
              };
            };
          };
        };
      }
    );
}

The resulting kodi-with-addons derivation includes both, the pname changed via overrideAttrs as well as the postBuild wrapping for the inputstream plugin added via withPackages.
Running it is possible, finds the plugin and doesn't have any signs of anything being wrong.

Built on  #platform(s)

[x] x86_64-linux
[ ] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.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.

@dwagenk thanks for contributing this. I'll try and get back to it as soon as I can, though I'm going to prioritize getting the new kodi release packaged first. Please be patient with us :bowing_man:

Linking kodi update PR for visibility: https://github.com/NixOS/nixpkgs/pull/201835

Proposed changes merged in #304097, thanks!

Oh, wow, thank you for updating and getting this merged! :tada:


change repo references to docstrap/docstrap

Also might be good to add pr's referencing the project externally.
Its not required since github auto-redirects, but it will reduce confusion.

done


Fix specified lru-cache version range

Introduced as a consequence of the renovate config I created:
cab3444fa06e7ecc0e1918807d9578869407d65b (from #169)
Issue raised by @SimenB here:
https://github.com/apollographql/apollo-utils/pull/169#discussion_r1030190816

Looks like the pin is a Node 12 issue (https://github.com/isaacs/node-lru-cache/pull/247#issuecomment-1204481394). Can we just remove it and see if upgrading works fine? (The comment suggests there might be other issues with the TS compatibility but we would presumably learn about that quickly.)
Then perhaps do a v1 backport of a similar commit?

🎉


Adding new param to getUrl() method to return alternative API endpoint

Adding new param to getUrl() method to return an alternative form of the URL that does not contain the REDCap version directory (e.g., https://example.com/redcap/redcap_vX.X.X/ExternalModules/?id=1&page=index&pid=33), in which setting $useApiEndpoint=true will return a version-less URL using the API end-point (e.g., https://example.com/redcap/api/?type=module&id=1&page=index&pid=33). Both links will work identically. Also, this alternate API URL works for non-PHP files too, such as CSS and JS. NOTE: This is mainly being added for when External Modules gets added inside the REDCap release in the future where it will be inside the REDCap version folder. This API endpoint will work in REDCap 7.6.8 and later.

It looks like this pull request has some conflicts with some recent changes.  Are you able to merge the latest version of the testing branch into this one and resolve those conflicts?
Do you have to deal with conflicts often?  If not, I typically use p4merge to do visual three-way merge for conflicts.  Let me know if you want to see it in action.

I deal with conflicts sometimes, but you probably know this codebase better than me. So go ahead and feel free to merge it however you see fit. Thanks!

@mmcev106 I had a chance to take a look at these and resolve them, so they're ready to merge when you're able.

Some changes were overwritten during a merge on this pull request.  I have cherry-picked the only non-merge commit in this branch (4a28181) into the testing branch (as commit e3797d2).  That means the changes in this branch are effectively merged, but I can closing this pull request without merging it.


go module: cannot find module providing package testing/mem

In a folder with some code that works when compiled inside $GOPATH:
$ go mod init oral
go: creating new go.mod: module oral
$ go get -u ./...
go: finding github.com/rs/rest-layer/resource/testing/mem latest
go: finding github.com/rs/rest-layer/rest latest
go: finding github.com/rs/rest-layer/schema latest
go: finding github.com/rs/rest-layer/resource latest
go: finding github.com/rs/rest-layer/resource/testing latest
go: finding golang.org/x/crypto/bcrypt latest
go: finding golang.org/x/crypto latest
build oral: cannot load github.com/rs/rest-layer/resource/testing/mem: cannot find module providing package github.com/rs/rest-layer/resource/testing/mem

Is there something to modify in github.com/rs/rest-layer/resource/testing/mem to make it go modules compatible?

Sorry that there has been no response.
I am not sure what causes the issue you are seeing. You can try to ensure you are depending on the master version of rest-layer.
$ go get -u  github.com/rs/rest-layer@master

I confirm that pointing to the master version solves the issue. Thank you!

As v0.2 has been released some time ago, I am closing this issue.


Flake8-pyproject doesn't work with flake8 6.1.0

flake8 version 6.1.0 was recently released on conda forge but unfortunately seems to be incompatible with flake8-pyproject version 1.2.3. With version 6.1.0 my configuration in my pyproject.toml are ignored. Downgrading to 6.0.0 resolves this issue.

I don't see that in the nightly tests. The first run with Flake8 6.1.0 (three days ago) as well as all subsequent runs passed, just like the last run with Flake8 6.0.0.
I also cannot reproduce that locally: with Python 3.11, Flake8 6.1.0, Flake8-pyproject 1.2.3, on Windows. Though everything is installed directly via Pip, not Conda.

Hi @john-hen,
Thanks for the quick reply. I went back and tested again and things seem to be okay with 6.1.0. Our CI jobs were failing and it was pointing in this direction...but clearly that was wrong! Sorry about that. I'm closing this issue.
Cheers,
-Ed


Fix RESET.png file not found issue.

$ python vis.py
Unable to load RESET.png Cannot locate resource : RESET.png

Thanks for fixing this issue!


Rename moveonly_builtin.swift -> move_builtin.swift.

This is testing the move builtin... not moveonly stuff.
NFC

@swift-ci smoke test and merge


Increase tail at once for push_multiple()

Tail should be increased atomically to be semantically same for link operation + sqpoll case.
We've found sqpoll_thread steal in the middle of linked ops which results in non in-order execution.

This was from my misunderstanding. The tail was a just cache.


appendTracks function causes the currently playing song to stop

Calling appendTracks will cause the current song to stop playing.  It looks like the newly added track is set as as the current song as well.
You can test this bug at https://demo.mstream.io/winamp by adding a song, playing it, and then adding another

@IrosTheBeggar This should be fixed in the referenced commit. Will you need a new npm release to be able to use the fixed code?

@IrosTheBeggar Sorry for the long delay, but we finally cut a new version https://github.com/captbaritone/webamp/blob/master/CHANGELOG.md#131-current


This is awesome so...thanks

Ok so I've made 3 skills already hosted in azure app service with this. Have to admit this is awesome, used it because I have a ton of stuff in azure and didn't really want to use aws lambda.
So thanks for making this....

Glad to hear, thanks for your note. At some point I'd like to also look at Azure Functions to make sure this library can also work with with equivalent of AWS Lambda in Azure.


⚠ Bofrost.at has degraded performance

In 237a363, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1281 ms

Resolved: Bofrost.at performance has improved in 2c5ea3e after 6 minutes.


Unable to start serve or cms tasks

On a freshly installed Lume with Shirhara theme I get an error when trying to start serve or cms tasks.
OS: MacOS v15.0.1
Deno: v2.0.0
Lume: v2.3.3
Steps to reproduce

> deno run -A https://lume.land/init.ts
> (install a theme)
> (_config.ts)
> (Shiraha)
> deno task cms or > deno task serve
Observe error in terminal

Error message for deno task cms
error: Uncaught (in worker "") (in promise) TypeError: Module not found<EMAIL_ADDRESS>    at https://deno.land/x/lume_theme_shiraha@v0.1.0-alpha.5/_cms.ts:1:21
  const mod = await import(toFileUrl(cmsConfig).href);
              ^
    at async build (https://deno.land/x/lume@v2.3.3/cli/cms_worker.ts:35:15)
error: Uncaught (in promise) Error: Unhandled error in child worker.
    at Worker.#pollControl (ext:runtime/11_workers.js:204:19)
    at eventLoopTick (ext:core/01_core.js:175:7)

Error message for deno task serve
error: Uncaught (in worker "") (in promise) TypeError: Import assertions are deprecated. Use `with` keyword, instead of 'assert' keyword.

import meta from "../deno.json" assert { type: "json" };

  at https://deno.land/x/skia_canvas@0.5.5/src/ffi.ts:13:1

    const mod = await import(url);
                ^
    at async createSite (https://deno.land/x/lume@v2.3.3/cli/utils.ts:26:17)
    at async buildSite (https://deno.land/x/lume@v2.3.3/cli/utils.ts:45:16)
    at async build (https://deno.land/x/lume@v2.3.3/cli/build_worker.ts:35:16)
error: Uncaught (in promise) Error: Unhandled error in child worker.
    at Worker.#pollControl (ext:runtime/11_workers.js:204:19)
    at eventLoopTick (ext:core/01_core.js:175:7)

The cms entry was removed in the new version of Lume. I will update later.

This issue should have been fixed.
I can't test it in detail now, so feel free to reopen it if you still have problems.

Sorry but it seems both problems are still present.
I deleted the lume installation folder and tried installing it from scratch again. I'm not quite sure if there is some caching going on but just to make sure everything is aligned here is the imports section from the json config:
  "imports": {
    "lume/"<EMAIL_ADDRESS>    "shiraha/"<EMAIL_ADDRESS>    "shiraha/jsx-runtime"<EMAIL_ADDRESS>    "lume/cms/"<EMAIL_ADDRESS>  },

Sorry but it seems both problems are still present.

Oops... I forgot to release a new version.

v0.1.0-alpha.6 has been released.
  "imports": {
    "lume/"<EMAIL_ADDRESS>-   "shiraha/"<EMAIL_ADDRESS>+   "shiraha/"<EMAIL_ADDRESS>-   "shiraha/jsx-runtime"<EMAIL_ADDRESS>+   "shiraha/jsx-runtime"<EMAIL_ADDRESS>    "lume/cms/"<EMAIL_ADDRESS>  },


Getting waring in React 16.8.6 about ComponentWillRecieveProps

The warinig is as follows:
Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-async-component-lifecycle-hooks for details.

Move data fetching code or side effects to componentDidUpdate.
If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state
Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run npx react-codemod rename-unsafe-lifecycles in your project source folder.

Please update the following components: ReactSwipableView

According to react 16.9.0 componentWillMount, componentWillReceiveProps and componentWillUpdate were deprecated and will be removed in 17.x version
https://alligator.io/react/whats-new-in-react-16.9/

Still receiving the error message. version 0.13.2

Hi, I also get this issue, here is the complete error message from the console :

| printWarning | @ | react-dom.development.js:11494
-- | -- | -- | --
  | lowPriorityWarning | @ | react-dom.development.js:11513
  | dll_01f9a3fa864a7b7414d8../node_modules/react-dom/cjs/react-dom.development.js.ReactStrictModeWarnings.flushPendingUnsafeLifecycleWarnings | @ | react-dom.development.js:11680
  | flushRenderPhaseStrictModeWarningsInDEV | @ | react-dom.development.js:23134
  | commitRootImpl | @ | react-dom.development.js:22428
  | unstable_runWithPriority | @ | scheduler.development.js:643
  | runWithPriority$2 | @ | react-dom.development.js:11305
  | commitRoot | @ | react-dom.development.js:22414
  | scheduleUpdateOnFiber | @ | react-dom.development.js:21421
  | scheduleRootUpdate | @ | react-dom.development.js:24319
  | updateContainerAtExpirationTime | @ | react-dom.development.js:24347
  | updateContainer | @ | react-dom.development.js:24436
  | (anonymous) | @ | react-dom.development.js:24963
  | unbatchedUpdates | @ | react-dom.development.js:21687
  | legacyRenderSubtreeIntoContainer | @ | react-dom.development.js:24962
  | hydrate | @ | react-dom.development.js:25029
  | renderReactElement | @ | index.js:32
  | _callee4$ | @ | index.js:42
  | tryCatch | @ | runtime.js:45
  | invoke | @ | runtime.js:271
  | prototype. | @ | runtime.js:97
  | asyncGeneratorStep | @ | asyncToGenerator.js:5
  | _next | @ | asyncToGenerator.js:27
  | (anonymous) | @ | asyncToGenerator.js:34
  | F | @ | _export.js:36
  | (anonymous) | @ | asyncToGenerator.js:23
  | _doRender | @ | index.js:42
  | doRender | @ | index.js:38
  | _callee2$ | @ | index.js:23
  | tryCatch | @ | runtime.js:45
  | Promise.then (async) |   |
  | asyncGeneratorStep | @ | asyncToGenerator.js:15
  | _next | @ | asyncToGenerator.js:27
  | Promise.then (async) |   |
  | asyncGeneratorStep | @ | asyncToGenerator.js:15
  | _next | @ | asyncToGenerator.js:27
  | (anonymous) | @ | asyncToGenerator.js:34
  | F | @ | _export.js:36
  | (anonymous) | @ | asyncToGenerator.js:23
  | (anonymous) | @ | index.js:20
  | ./node_modules/next/dist/client/next-dev.js | @ | next-dev.js:7
  | webpack_require | @ | bootstrap:792
  | checkDeferredModules | @ | bootstrap:45
  | webpackJsonpCallback | @ | bootstrap:32
  | (anonymous)

react-select had this issue lately and they fixed it with this pr. something similar could be done temporarily.

react-select had this issue lately and they fixed it with this pr. something similar could be done temporarily.

It will still be temporary solution

Still facing problem

Still facing problem

Receiving the same warning. Any update on a fix?

Hi.
I received the same warning, too.
"Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles for details."
on the console.
I will wait for your fix.
Thank you :)

I have no interest in investing time on this project anymore.
The return is too low compare to the time I can bet on Material-UI.
Does anyone wants to keep up the development of it? Thanks.

@oliviertassinari It will be great if you add a big "Looking For Maintainers" heading in the README.md.

@oliviertassinari, you mean that material UI could replace this project? And what would be the most important functions to implement or problems to fix? Any possible roadmap for the new maintainers?

To clarify, I meant that I don't have time to dedicate to this project.
On Material-UI side, we will work on a carousel, but it's unclear if we will actually use this library.

Receiving the same warning. Any update on a fix?

Help please!!

@oliviertassinari is there a repo I could check out for the Material-UI carousel component? Thanks!

@dohomi The carousel we will build for Material-UI will likely not use this component.

@oliviertassinari great news that it will land in Material-UI itself. Will it be part of v4 and the material-ui/lab? Thanks for the info!

@dohomi we will soon start the v5 effort. I think that it will come after.

Hey Guys, I see that this wonderful stuff is getting outdated, and maintenance is not provided. I moved to https://github.com/express-labs/pure-react-carousel after trying a lot of jQuery ported solutions such as slick. I think this, pure-react-carousel is the best alternative out there at the moment.

@oliviertassinari please add Deprecation label or stale label to the Git repo so we may stop using it. Thank you for this wonderful library

Workaround implemented in #616, release coming soon.

Do we have confirmation from the owner that this will continued to be maintained? We are intending to use this for production and this seems like the best and most suitable we have tested yet.

Hi Guys,
it looks like it is still a open issue? Are there any plans to fix it?
[Error] Warning: Using UNSAFE_componentWillReceiveProps in strict mode is not recommended and may indicate bugs in your code. See https://reactjs.org/link/unsafe-component-lifecycles for details.

* Move data fetching code or side effects to componentDidUpdate.
* If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://reactjs.org/link/derived-state

Please update the following components: ReactSwipableView

Hi Guys,
it looks like it is still a open issue? Are there any plans to fix it?
[Error] Warning: Using UNSAFE_componentWillReceiveProps in strict mode is not recommended and may indicate bugs in your code. See https://reactjs.org/link/unsafe-component-lifecycles for details.

* Move data fetching code or side effects to componentDidUpdate.
* If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://reactjs.org/link/derived-state

Please update the following components: ReactSwipableView

I'm too getting this Warning in dev console.

Hi Guys,
it looks like it is still a open issue? Are there any plans to fix it?
[Error] Warning: Using UNSAFE_componentWillReceiveProps in strict mode is not recommended and may indicate bugs in your code. See https://reactjs.org/link/unsafe-component-lifecycles for details.

* Move data fetching code or side effects to componentDidUpdate.
* If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://reactjs.org/link/derived-state

Please update the following components: ReactSwipableView

I'm too getting this Warning in dev console.

A fix is ready in PR but, if my understanding is right, it won't be merged, the author advises using the MUI lib instead.
https://github.com/oliviertassinari/react-swipeable-views/pull/654

Why does the author advise using MUI ? Is there a similar component in MUI ?

@korbav Why does the author advise using MUI ? Is there a similar component in MUI ?

To be honest, I'm not sure I'm not really getting it.
To my knowledge, there's nothing similar.

@korbav Why does the author advise using MUI ? Is there a similar component in MUI ?

Because he is "CEO, co-founder at https://github.com/mui"

@korbav Why does the author advise using MUI ? Is there a similar component in MUI ?

Because he is "CEO, co-founder at https://github.com/mui"

@t-kanstantsin Okay, this answers the "Why?".
Could you help me out with the "How?". ? Or provide any guidance or hint on it?

@agnel Sorry I don't have solution or replacement.
I just pointed why there is no chance to receive support in this repository.

the author advises using the MUI lib instead.

I doubt it, since the author explicitly refers from mui’s docs to react-swipeable-views instead: mui/material-ui#507

omg he made a carousel out of it, guys, we are in a loop. please help!

I am probably gonna receive some thumbs down for this, but I got annoyed by the error just enough to implement the following wrapper for console.error to silence this particular message.
const consoleError = console.error;

console.error = function filterErrors(msg, ...args) {
    if (/UNSAFE_componentWillReceiveProps/.test(msg) && args[0] === 'ReactSwipableView') {
        return;
    }
    consoleError(msg, ...args);
};

@Grsmto took the time to publish a fix in a forked package (thank you!). It works on my side (I didn't want to search for an alternative). I keep using the original name to benefit from typings...
Just use:

npm install react-swipeable-views@npm:@gromy/react-swipeable-views
yarn add react-swipeable-views@npm:@gromy/react-swipeable-views
pnpm add react-swipeable-views@npm:@gromy/react-swipeable-views
or install @gromy/react-swipeable-views directly

@Grsmto took the time to publish a fix in a forked package (thank you!). It works on my side (I didn't want to search for an alternative). I keep using the original name to benefit from typings...
Just use:

npm install react-swipeable-views@npm:@gromy/react-swipeable-views
yarn add react-swipeable-views@npm:@gromy/react-swipeable-views
pnpm add react-swipeable-views@npm:@gromy/react-swipeable-views
or install @gromy/react-swipeable-views directly

fyi does not work with React 18..


Missing parameters' documentation in "Publish Code Coverage Results task"

There is no documentation for these parameters:
#reportDirectory: # Optional
#additionalCodeCoverageFiles: # Optional
I do need to understand what additionalCodeCoverageFiles is supposed to do.
Thanks!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c6ac4ff4-9839-6a6d-8d20-a25084d221ef
Version Independent ID: bd09f139-8e69-8ea1-6671-b7bba8e17c23
Content: Publish Code Coverage Results task - Azure Pipelines
Content Source: docs/pipelines/tasks/test/publish-code-coverage-results.md
Product: devops
Technology: devops-cicd-tasks
GitHub Login: @PBoraMSFT
Microsoft Alias: pbora

@loicmorvan-ansys Thank you for the feedback, assigning this to the author for review.
Please refer to the repo for these descriptions and note the latest version of this task is now V2.

Adding @shashban as I have moved to a different team.

Thanks for letting us know. This issue is fixed in our new task reference here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/publish-code-coverage-results-v1?view=azure-pipelines
Please check it out and let us know what you think. Thank you.


Merge ign-gui3 ➡  ign-gui6

➡  Forward port
Port ign-gui3  ➡  ign-gui6
Branch comparision: https://github.com/ignitionrobotics/ign-gui/compare/ign-gui6...ign-gui3
Note to maintainers: Remember to Merge with commit (not squash-merge or rebase)

@chapulina Can we wait a moment before merging this PR so we can get this one-line fix for GzColor in this forward-porting? https://github.com/gazebosim/gz-gui/pull/459


Bump version for v23.1.0

@rail thanks for the approval! However, the E2E-Test failed. Should this pause the merge?
Not sure if this is related to https://github.com/cockroachdb/helm-charts/issues/310

closing in favor of https://github.com/cockroachdb/helm-charts/pull/313


project distributed as module instead of package

Probably related to #11, but since it might cause some complication i think a new issue serves better.
I noticed that synthizer right now is distributed as module-only, it basically just installs the .so / .pyd file and nothing else, no .pyx, no .pyi and also not the typing indication. I don't know if it is intentional that way although they are to be collected by the setup.py file, but such files can only be included within package projects, not module projects. The solution to this would be to release it as package (probably called synthizer again), containing the .so / .pyd and the typing files etc. To prevent this change from breaking anything, we'd need to add a init.py file which either imports all relevant objects by name (preferred), which needs to be maintained whenever something new is added in that should be available at package level, or import *, which will forward everything from the shared lib at package level, but import * should generally be avoided due to namespace pollution etc.
Overall this should be easy to do and i'd be willing to do it, I just need to get a setup that properly builds a wheel to test things (will probably do so under Linux). Its probably best to discuss this before getting started in case i'm missing something important here. And it might introduce some maintenance overhead in the future since new objects need to be re-imported at package level.

I submitted a draft PR which fixes this error without breaking existing code. It now ships the typing support for sure (tested against my pyAGE project) and is extensible in case some other modules have to be added in the future. No further maintenance should be needed due to a 1:1 forward via * import.

I don't understand the problem.  What I do already should work, and it did work for @chrisnorman7 for a long time.  What actually breaks?  I've never heard of any project having to reexport a C extension to get typing working.

It cannot work by definition, because the wheels don't contain any typing declarations right now (just download one of the wheels and check for yourself). All they contain until this PR is the pyd/so file and thats it. One module and nothing else, except the egg metadata. Thats what this PR changes, it packages everything as a package instead of a module and therefore can supply the typing definitions with it. Chris probably is using an old version that worked previously? I don't know, but 0.12 deffinitely doesn't contain any typing-relevant files within the wheels.

I'm not opposed to this change, I just want to make sure I understand.  Looks like the info is in PEP 561, but as usual Python packaging docs are lacking to say the least.
@chrisnorman7
You wrote the original support for this.

@ahicks92 I did? Well, I did warn you about my memory.

Yeah, this was back in your typed Python phase iirc. Maybe I'm mixing you up with someone else but I don't think so.

I've landed the pr. I'm going to wait a week in case @Timtam finds something else to report. (fwiw the Python 3.7 etc. wheels went up the other day)

this should now be released.


Update user archetypes to fit with Messaging Summary deck

User Story
As a ReportStream teammate, I want to improve upon the user archetypes so they are consistent with the Messaging Summary deck.
Background and context
User archetype deck needs to align with Messaging Summary deck so that branding, language, and content are more consistent and aligned.
Working links

Messaging Summary deck
WIP Engagement Archetypes and Personas

Acceptance criteria

[ ] Match secondary message language and content from deck

Not in scope

[ ] User archetype overhaul

Synced up with Audrey yesterday! She did a pass through the WIP Mural and so did I. Waiting on approval from her.

Final updates this round to the archetypes are in the Engagement_Sender User Archetypes and Personas Mural! Archetypes have been squared away with Messaging deck language (the titles of the Secondary messages). Work has been closed out for this sprint, so moving to 'Closed'.


JKNS-257: add java/nodejs sidecar pod templates examples

/assign @adambkaplan
/assign @akram
e2e's are in accompanying PR https://github.com/openshift/jenkins-sync-plugin/pull/406 in the sync plugin repo (as we use CI step-registry now to call e2e's directly from sync/client plugin)
I will then submit a openshift-docs PR to update existing jenkins doc for @rolfedh to either iterate on and merge, or use as a starting point for PRs he wants to construct (either approach works for me).  Those updates will include both old and new style of jenkins pipeline.
In the interim, this java based pipeline works:
          try {
             timeout(time: 20, unit: 'MINUTES') {

                node("java-sidecar") {
                    container("java") {
                        sh "mvn --version"
                    }
                }
             }
          } catch (err) {
             echo "in catch block"
             echo "Caught: ${err}"
             currentBuild.result = 'FAILURE'
             throw err
}

and this nodejs based pipeline works:
          try {
             timeout(time: 20, unit: 'MINUTES') {

                node("nodejs-sidecar") {
                    container("nodejs") {
                        sh "npm --version"
                    }
                }
             }
          } catch (err) {
             echo "in catch block"
             echo "Caught: ${err}"
             currentBuild.result = 'FAILURE'
             throw err
}

non related failures in e2e-aws
jenkins e2e's passed
/test e2e-aws

names updated per office hours discussion @akram @adambkaplan PTAL

By the way @akram the new e2e-jenkins-image-tests actually did not run the tests.  Here is the full test log:
Testing the jenkins template based install on openshift
The directory '/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
The directory '/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Collecting setuptools
  Downloading https://files.pythonhosted.org/packages/40/a9/7deac76c58fa47c95360116a06b53b9b62f6db11336fe61b6ab53784d98b/setuptools-59.5.0-py3-none-any.whl (952kB)
Installing collected packages: setuptools
  Found existing installation: setuptools 39.2.0
    Uninstalling setuptools-39.2.0:
      Successfully uninstalled setuptools-39.2.0
Successfully installed setuptools-59.5.0
You are using pip version 9.0.3, however version 21.3.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
The directory '/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
The directory '/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Collecting pip
  Downloading https://files.pythonhosted.org/packages/a4/6d/6463d49a933f547439d6b5b98b46af8742cc03ae83543e4d7688c2420f8b/pip-21.3.1-py3-none-any.whl (1.7MB)
Installing collected packages: pip
  Found existing installation: pip 9.0.3
    Uninstalling pip-9.0.3:
      Successfully uninstalled pip-9.0.3
Successfully installed pip-21.3.1
./scripts/test-jenkins-template-install.sh: line 22: oc: command not found
Assigning value to variable TEST_NAMESPACE=
Starting cleanup
./scripts/test-jenkins-template-install.sh: line 29: oc: command not found
./scripts/test-jenkins-template-install.sh: line 30: oc: command not found
./scripts/test-jenkins-template-install.sh: line 31: oc: command not found
./scripts/test-jenkins-template-install.sh: line 32: oc: command not found
Logs directory created at {/home/prow/go/src/github.com/openshift/jenkins/out/logs/smoke}
./scripts/test-jenkins-template-install.sh: line 44: oc: command not found
Starting local Jenkins instance
WARNING: The directory '/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you should use sudo's -H flag.
Running smoke tests in namespace with TEST_NAMESPACE=
Logs will be collected in /home/prow/go/src/github.com/openshift/jenkins/out/smoke
Exception AssertionError: KUBECONFIG needs to be set in the environment
Traceback (most recent call last):
  File "/home/prow/go/src/github.com/openshift/jenkins/out/venv3/bin/behave", line 8, in <module>
    sys.exit(main())
  File "/home/prow/go/src/github.com/openshift/jenkins/out/venv3/lib64/python3.6/site-packages/behave/__main__.py", line 183, in main
    return run_behave(config)
  File "/home/prow/go/src/github.com/openshift/jenkins/out/venv3/lib64/python3.6/site-packages/behave/__main__.py", line 127, in run_behave
    failed = runner.run()
  File "/home/prow/go/src/github.com/openshift/jenkins/out/venv3/lib64/python3.6/site-packages/behave/runner.py", line 804, in run
    return self.run_with_paths()
  File "/home/prow/go/src/github.com/openshift/jenkins/out/venv3/lib64/python3.6/site-packages/behave/runner.py", line 809, in run_with_paths
    self.load_step_definitions()
  File "/home/prow/go/src/github.com/openshift/jenkins/out/venv3/lib64/python3.6/site-packages/behave/runner.py", line 796, in load_step_definitions
    load_step_modules(step_paths)
  File "/home/prow/go/src/github.com/openshift/jenkins/out/venv3/lib64/python3.6/site-packages/behave/runner_util.py", line 412, in load_step_modules
    exec_file(os.path.join(path, name), step_module_globals)
  File "/home/prow/go/src/github.com/openshift/jenkins/out/venv3/lib64/python3.6/site-packages/behave/runner_util.py", line 386, in exec_file
    exec(code, globals_, locals_)
  File "smoke/features/steps/build_steps.py", line 6, in <module>
    oc = Openshift()
  File "/home/prow/go/src/github.com/openshift/jenkins/smoke/features/steps/openshift.py", line 22, in __init__
    self.cmd = Command()
  File "/home/prow/go/src/github.com/openshift/jenkins/smoke/features/steps/command.py", line 16, in __init__
    assert kubeconfig is not None, "KUBECONFIG needs to be set in the environment"
AssertionError: KUBECONFIG needs to be set in the environment
Logs collected in /home/prow/go/src/github.com/openshift/jenkins/out/smoke

the AWS us-east issues mentioned in announce-testplatform sabotaged the e2e-aws* e2e's
i'll retest once we hear that AWS use-east has recovered.

/retest

/retest

more terraform / cluster start up pain
/retest

past installer/AWS issues
the sync plugin test seems like a ran out of time / slow / possible resource constrained thing
/retest

/retest

/lgtm


GIT_COMMIT_MESSAGE is set from inputs but never used

GIT_COMMIT_MESSAGE seems set as input but never used anywhere.

https://github.com/kustomize-everything/action-promote/pull/81


fix(security): Patch Dragonberry Cosmos SDK security advisory [DEV-1824]

Task linked: DEV-1824 Create an official cheqd-node Dragonberry patch on release/0.6.x branch


CASMCMS-8828 - increase default IMS job memory size.

Summary and Scope
When PVC's were introduced for image storage we decreased the memory requests and limit sizes to make scheduling jobs easier. With some larger jobs, the new default was not sufficient, so this bumps it back up a bit.
Code PR: https://github.com/Cray-HPE/ims/pull/100
Issues and Related PRs

Resolves CASMCMS-8828

Testing
Tested on:

Slice

Test description:
Manual change of the setting resulted in successful job completion.

Were the install/upgrade-based validation checks/tests run (goss tests/install-validation doc)? N
Were continuous integration tests run? If not, why? N
Was upgrade tested? If not, why? N
Was downgrade tested? If not, why? N
Were new tests (or test issues/Jiras) created for this change? N

Risks and Mitigations
Very low risk - just increasing resource allocations.
Pull Request Checklist

[X] Version number(s) incremented, if applicable
[X] Copyrights updated
[X] License file intact
[X] Target branch correct
[X] CHANGELOG.md updated
[X] Testing is appropriate and complete, if applicable

/backport release/1.5


Support #![allow()]

Problem
The generated code will probably violate many lint (e.g. Clippy) rules.
This will lead to extraneous warning messages each time you compile.
Solution
Let the user specify #![allow(...)] to disable the linter within the generated file.

Closing in favor of #18. #18 is a generalization of this.


Filename not supported in Windows

When I cloned the project and tried to run it I got the error
'Resistance.py' is not recognized as an internal or external command,
Maybe filename with & is not supported in windows.  When I changed the file name to ps.py it worked.

I run it on windows without problems, but I changed the filename in case anyone else has the same problem. Thanks for bringing it up.


Updated to NTS 2.0 and removed use of GeoAPI where required. Also Fixed 2 Bugs

I just made this because since I am having issues with or without contractions I figured I should help to try and track the issue down, this was a low hanging fruit and gets the later version of NTS in the library.
All tests seemed to pass on my machine so it's possible this threading issue is fixed in the develop branch of reminiscence, I will add a few more tests to make sure but there was already GetTestRandomRoutesParallel but it was not being run so I added that to the list of tests to run.

This should resolve https://github.com/itinero/routing/issues/256

Fixed in latest commit

@xivk , this should be okay to merge now, let me know if you find anything else.
Also please note that the nugets seem to be built for x86 which may have caused some of the other issues I was reporting about OOM

There was also a reference to the older NTS library from OSM Sharp which I fixed in https://github.com/OsmSharp/core/pull/101

Please let me know if you need anything else to get this merged easily and thank you for your interest / hard work!

Also addresses https://github.com/itinero/routing/issues/304

Removed code which was causing the difference as seen in https://github.com/itinero/routing/issues/293, also added unit tests to support.

Added code which seems to resolve #279

@xivk, please see the comments in the review.
I removed that code to fix the issue in the minimal case but it resurfaces with the larger test case.
Debugging this is hard without some additional direction / comments.
I am unsure if my code removal is appropriate in light of the fact the GetAugmentedWeightHandler does not experience the same issue.

Also noting that TestBicycleWithCyclenetwork seems to fail on the first Assert.IsNull(route.Value.From.From); however the 2nd run seems to produce a successful result

Also noting that ManyToManyWeightsBidirectionalDykstra seems to have an issue as when I defer the code to instead execute Itinero.Algorithms.Default.ManyToMany it seems to solve the issue both in the reduced test case etc
I will see about making another patch for this...

Updated the code and it seems to solve both the minimal and extended tests for EdgeBasedContraction

Also wondering if the same fix should be applied @ https://github.com/itinero/routing/blob/11fe52e71548ec4fe9419c85fd99bda2121068e4/src/Itinero/Router.cs#L1176

@xivk, please let me know when  you get a chance to review this and the other PR's submitted.

Hey @juliusfriedman I appreciate all this hard work but the pull request has multiple changes on different features and some features of a new C# version are introduced. All these things that are great as improvements but it's gotten a bit more difficult for me to review.
Is this getting merged something you need urgently? I should be able to check this next week Wednesday.  Sorry, struggling to keep up with everything these days.

No problem, I didn't mean to make your life harder.
The fix I would need most importantly relates to reminisce because of the usage of Parallel. The quick fix here would be to lock on the db but it's no longer required after the change in reminisce.
The importance of that change is due to differences seen when routing using parallel or outright exceptions.
Take your time as I also addressed a distance calculation issue and made a change to use the ManyToMany algorthimm to resolve issues with weight handling which was reported by other users.
Next week should be fine. Just let me know if there's anything I can do to make this easier on you

@xivk  I double and triple checked this and added notes on what was addressed. Please let me know ASAP if this is correct so I can close my PR's and delete my branches.

Just let me know if there's anything I can do to make this easier on you

@juliusfriedman looking through this PR, it looks like you've lumped many different things together.  I would recommend making one PR that just does the NTS 2.0 upgrade, since that should be mostly signature changes that happen to affect many files and therefore much easier to review that part of it.  Afterward, you can make other changes on top, and each would be easier to review on their own.
For example, consider 2fe7e3d.  Looking at that, I question the need for it... ignoring the (fixable) problem that the new test provides latitude values outside of the legal range, is the intent to try to improve accuracy over very large distances?

If that's the case, then is that worth the incremental performance cost of 4 trig functions and 1 sqrt function per call*, in Itinero?  The name already suggests that it's going to be inaccurate, and it's still going to be inaccurate because the Earth isn't a perfect sphere, so I expect speed to matter a lot more than accuracy.
My point here isn't to specifically resolve this one point of discussion, but rather to show that the more unrelated changes you pack into one PR, the more different things a reviewer needs to think about; one minute I'm looking at a change from GeoAPI --> NetTopologySuite, and the next I'm on the Wikipedia page for great-circle distances.

If you also want to fix some bugs, then I'd recommend doing that in other PRs; if those fixes affect code that's tightly coupled to NTS, then maybe it would make sense to wait to submit those until the NTS 2.0 upgrade is merged, since merge conflicts would add friction to that effort.
*plus multiple Math.Pow calls, though all of them are Math.Pow(x, 2), so we could optimize them by doing x * x ourselves, so it would be unfair to call these out.

//https://github.com/itinero/routing/issues/279
            const double DegreesToRadians = Math.PI / 180.0;
            var d1 = latitude1 * DegreesToRadians;
            var num1 = longitude1 * DegreesToRadians;
            var d2 = latitude2 * DegreesToRadians;
            var num2 = longitude2 * DegreesToRadians - num1;
            var d3 = Math.Pow(Math.Sin((d2 - d1) / 2.0), 2.0) + Math.Cos(d1) * Math.Cos(d2) * Math.Pow(Math.Sin(num2 / 2.0), 2.0);

            return (float)(6376500.0 * (2.0 * Math.Atan2(Math.Sqrt(d3), Math.Sqrt(1.0 - d3))));

What x * x can replaced with the Math.Pow call here?
Math.Sin(num2 / 2.0) * 2.0;

If thats the big change I can make that bug the method (Pow) is aggressively inlined anyway AFAIK.
The changes were done like this because they required changes in Remininscence, those have been accepted and thus these can now be reviewed and accepted as well.
Not sure what you mean by breaking them down into parts all parts effects almost all others.

And just to be clear:

With my fixes and some as of yet uncommitted all tests cases are passing in Itinero.Algorithmns.Default.EdgeBased

What x * x can replaced with the Math.Pow call here?

Again, my point isn't to specifically resolve this one, but to answer this question:
//https://github.com/itinero/routing/issues/279
    const double DegreesToRadians = Math.PI / 180.0;
    var d1 = latitude1 * DegreesToRadians;
    var num1 = longitude1 * DegreesToRadians;
    var d2 = latitude2 * DegreesToRadians;
    var num2 = longitude2 * DegreesToRadians - num1;
    var temp1 = Math.Sin((d2 - d1) / 2.0); // extracted from the expression that produces d3
    var temp2 = Math.Sin(num2 / 2.0); // extracted from the expression that produces d3
    var d3 = (temp1 * temp1) + Math.Cos(d1) * Math.Cos(d2) * (temp2 * temp2);

    return (float)(6376500.0 * (2.0 * Math.Atan2(Math.Sqrt(d3), Math.Sqrt(1.0 - d3))));

Not sure what you mean by breaking them down into parts all parts effects almost all others.

One specific suggestion I made was to start with a PR that only does the NTS 2.0 conversion.  This would be easier to review and less likely to break things, and it would make the remainder easier to review as well, since it would all stand out on its own.

With my fixes and some as of yet uncommitted all tests cases are passing in Itinero.Algorithmns.Default.EdgeBased

All that that means is that the tests pass.  Every (valid) user-visible bug is further evidence that the automated test suite is either incomplete or incorrect.
For example, I already noted that the new test for #279 is providing latitude values outside of the legal range.  This test is therefore incorrect (how can the expected value be any number, when the two inputs don't even refer to actual locations?), yet it passes.  For now, code review is our primary defense against those kinds of problems.

this PR sat here for weeks (maybe more) so I do not feel the onus is not on me here to break this down.

I would argue the opposite, actually: it takes longer to review more changes that do more things than to review fewer changes that do fewer things, and reviews tend to be overall more effective when they're focused on just one thing.  Of course, if that "one thing" is a solution to a complicated problem that truly requires making many changes that affect one another, then it can't be helped.
From my perspective, the only potential breakdown I specifically commented on was "NTS 2.0 / everything else", for a couple of reasons:

I don't know the details of the Itinero architecture well enough, nor did I scan through enough code, to be able to conclusively say how much of "everything else" can be broken down further, and
I do know what kinds of changes we made in NTS 2.0, and what kind of impact they should have on downstream solutions.  For sure, the need to upgrade the OsmSharp.Geo (and therefore OsmSharp) package references to prereleases of newer major versions complicates this significantly, but changes like the one I happened to notice and comment on above suggest that there are still some opportunities to split out at least one other PR (possibly more).

If something is not desired simply remove it during the merge.

I don't have merge privileges, so it's not my call.  I responded because you invited this kind of feedback:

please let me know if you need anything else to get this merged easily

and

Just let me know if there's anything I can do to make this easier on you

Since it's been a couple of months since @xivk last responded on this thread, I felt like you may benefit from hearing this perspective.  Maybe I'm wrong, and this PR is exactly what he wants to see, but after reading his last comment on this thread, I would guess otherwise.

That comment he made I believe he was referring to at that time which was missing pieces which would not compile and contained local references to the Reminiscence project and those conversations have been resolved AFAIK.
The last comment he made was about newer C# features (which are not used anywhere outside of what was already used) so I was confused and applied only the last change for: https://github.com/itinero/routing/issues/306
Which I began to test however I ran into additional problems when resolving as I could no longer contract databases however I can use them after contraction so long as the fix in https://github.com/itinero/routing/issues/306 is applied after the contraction is made.
I have no idea why and I have not found a case where it effects me so I did not move further on that.
Beyond that it seems there are multiple places that Itinero.Algorithms.Contracted.Dual.RouterExtensions.CalculateManyToMany provides incorrect results however when it's replaced with Itinero.Algorithms.Default.ManyToMany those issues are gone. I needed @xivk  to advise but I believe it should either be Itinero.Algorithms.Contracted.Dual.RouterExtensions.CalculateManyToMany should either be fixed or removed in favor of Itinero.Algorithms.Default.ManyToMany however I am not sure that Itinero.Algorithms.Default.ManyToMany uses the contraction based optimizations ...
The same seems to occur with ManyToManyWeightsBidirectionalDykstra, however again when that code instead uses Itinero.Algorithms.Default.ManyToMany the problem resolves.
The last thing I have to say is that the automated tests are failing because there are incorrect tests in the code for example TestBicycleWithCyclenetwork either that or the logic which provides the result is incorrect, my fixes for this are noted above but not in the PR.
Let me know how else I can be of assistance @xivk  or @airbreather
P.S. The changes for distance were for correctness regardless of input, a check to ensure they are valid is technically outside the scope of that function because floats are given and not Coordinate instances, and when Coordinate instances are provided their Longitude and Latitude is passed in the correct order to the function so I am not sure what you problem exactly is. Adding validation logic there for -180 < || > 180 || <-90 || >90 is trivial but performed way before that code is executed at least as called from Itinero as they have first been converted to Coordinate by LocalGeo

@airbreather
Everything passes in this PR and I fixed the order of the Coordinate tests.
The only thing which does not pass is RouterTests.TestBicycleWithCyclenetwork and that's because in this code the last 2 nodes are null, not sure if this a typo or intended.

Finally I also adjusted for your Math.Pow2 calls to X*X but please remember the JIT should optimize Math.Pow these especially in later builds See also https://github.com/dotnet/runtime/pull/31978

Waiting for another review or merge @xivk, @airbreather .
In my local code I have another few things which are as of yet uncommitted e.g. the use of CalculateManyToMany not sure if replacing that with the algorithm is the best thing to do if there are optimizations that CalculateManyToMany uses that the algorithm does not.
The odd thing is that if these types of issues don't occur using the AugmentedWeightHandler then perhaps when contracted it should become the default?
Just lmk.


Page on okfn.org still referring to OKFestival as something in the future

https://okfn.org/get-involved/events/
Still says "OKFestival 2014 coming up" :)

fixed


readme file

create your readme file with detail information about the whole projects.

nice but u need to explain how to use the model you created in case someone want to improve on it.


Refactor engine controller to use structured logging

By switching to structured logging and removing the common element
information from the individual log messages it becomes much simpler to
correlate a log statement with some code flow. The structured log fields
also allow us to easily filter logs based on specific element keys.
depends on longhorn/longhorn-manager#661
longhorn/longhorn#1724
longhorn/longhorn#1725
Signed-off-by: Joshua Moody<EMAIL_ADDRESS>

This depends on #661 and I will rebase this once #661 has been merged.

Please only review the last commit (engine-controller) the other code is covered by #661 (please add review comment there instead) and will not be part of this pr once #661 is committed

addressed issues and rebased.

Rebased and Ready for review, added some more withError calls.


sed error

I'm on linux. I get the following error with docker when I try to build after configure.
xxxx@home-desktop  ~/code/esp32/tools/nodemcu-firmware   dev-esp32 ●  docker run --rm -ti -v `pwd`:/opt/nodemcu-firmware marcelstoer/nodemcu-build build
sed: -e expression #1, char 99: unknown option to `s'

What are the special characters in the command you posted?
Could you try docker run --rm -ti -v pwd:/opt/nodemcu-firmware marcelstoer/nodemcu-build /bin/bash and then run the sed commands from https://github.com/marcelstoer/docker-nodemcu-build/blob/master/build-esp32 manually to help me find out which command actually fails?

What are the special characters in the command you posted?
that's just my zsh prompt. command being run is everything after docker.

here's the sed commands
root@fc49106ab9f8:/opt/nodemcu-firmware# BRANCH="$(git rev-parse --abbrev-ref HEAD | sed -r 's/[\/\\]+/_/g')"
root@fc49106ab9f8:/opt/nodemcu-firmware# echo $BRANCH
dev-esp32
root@fc49106ab9f8:/opt/nodemcu-firmware# SDK_VERSION="$(git submodule status|grep esp32|sed -r 's/.*\((.+)\)/\1/')"
root@fc49106ab9f8:/opt/nodemcu-firmware# echo $SDK_VERSION
-fc19954376654c3e1b4bec5c25cfa5ca241d39d1 sdk/esp32-esp-idf
root@fc49106ab9f8:/opt/nodemcu-firmware# sed -i '/#define LUA_RELEASE[[:space:]]/ s/$/ " on ESP-IDF '"$SDK_VERSION"'"/g' "$lua_header_file"
sed: -e expression #1, char 99: unknown option to `s'

I haven't made any changes at all...
Meanwhile, I did edit the build-esp32 file and removed the line so I could move forward. I'm puzzled as well!
I'll check lua.h again and just to make sure, run a fit clean as well tomorrow and report back

No edits in the working directory other than  modified:   components/platform/include/user_version.h

i am a newbie and have same problem sed: -e expression #1, char 99: unknown option to `s'
can anyone show my detail how to fixed it ?

I have checked the file: /opt/build-esp32.  I find that the sed line contained $SDK_VERSION causes the problem.  it is because the string $SDK_VERSION contains slash '/' character that conflict with the search-and-replace syntax.   I try to replace the '/' to '|' and it works.  Here is the fixed line I use:
append " on ESP-IDF xxx" to the Lua version
sed -i '/#define LUA_RELEASE[[:space:]]/ s/$/ " on ESP-IDF '"$SDK_VERSION"'"/g' "$lua_header_file"
sed -i '/#define LUA_RELEASE[[:space:]]/ s|$| " on ESP-IDF '"$SDK_VERSION"'"|g' "$lua_header_file"

Thanks for the proposed fix but $SDK_VERSION is not supposed to contain a '/'. Can you insert a echo "$SDK_VERSION" to show what its value is?

@imediabank this is unrelated to the issue we're discussing here pls create a new ticket
-> I will delete the comment
However, I have the feeling yours is completely unrelated to this Docker image.

the value of "$SDK_VERSION" is sdk/esp32-esp-idf
How I get this value:
$ cd {path to nodemcu-firmware}
$ docker run --rm -ti -v `pwd`:/opt/nodemcu-firmware marcelstoer/nodemcu-build bash
root@xxxx: vi /opt/build-esp32
...
root@xxxx: build

The version of nodemcu-firmware I use:
On branch dev-esp32
Your branch is up to date with 'origin/dev-esp32'.

My OS is Ubuntu 18.04.1 LTS

Ok, found it...it's a user error but a mean one. The hint was actually right there in @raghur's 2nd comment; I just didn't see it.
root@fc49106ab9f8:/opt/nodemcu-firmware# SDK_VERSION="$(git submodule status|grep esp32|sed -r 's/.*\((.+)\)/\1/')"
root@fc49106ab9f8:/opt/nodemcu-firmware# echo $SDK_VERSION
-fc19954376654c3e1b4bec5c25cfa5ca241d39d1 sdk/esp32-esp-idf

$SDK_VERSION obviously has the wrong value, something which @hk-badbuta also reported. It should be something like v3.3-dev-149-g1c4d9f2 (what I have here). This happens if you don't tell Git to resolve submodules upon checkout/clone as per https://nodemcu.readthedocs.io/en/dev-esp32/en/build/#linux-build-environment
I will add a note to https://github.com/marcelstoer/docker-nodemcu-build#build-for-esp32

Ok - So I think there's more to this. I checked my repo... Interestingly, from my host if I run git submodule status I get
1c4d9f2acacc666a4eb02f1450abd400e7df58c3 sdk/esp32-esp-idf (v3.3-dev-149-g1c4d9f2ac)

# git version
raghu@home-desktop  ~/code/esp32/tools/nodemcu-firmware   dev-esp32 ●  git --version
Found existing alias for "git". You should use: "g"
git version 2.17.1

However, when I run the same thing inside the docker container, I get
root@14e279a1a318:/opt/nodemcu-firmware# git submodule status | grep esp32
-1c4d9f2acacc666a4eb02f1450abd400e7df58c3 sdk/esp32-esp-idf

root@14e279a1a318:/opt/nodemcu-firmware# git --version
git version 1.9.1

Within the container, if I run git submodule update --init somehow seems to fix things - after that git submodule status shows the tag version in brackets. Perhaps a good idea to include that in the build-esp32 script?

@raghur thanks for your detailed feedback. The behavior you're seeing is different from the one I saw when I briefly tested on Windows. So, does seem to be related to #57 after all.

I see (or probably I dont).. in my case, I'm on Ubuntu KDE neon 18.04, if that's of any use.

@marcelstoer , I'm facing the same issue on MacOS (followed the exact procedure from README) and was able to fix it based @raghur 's finding.
docker run --rm -ti -v `pwd`:/opt/nodemcu-firmware marcelstoer/nodemcu-build bash
git submodule update --init
exit

and it works.

Same for me as @dacodekid, along with the suggested fix working.

@dacodekid thank you very much. this solve my problem.


Add Examples folder

I would like to gitcloning and get examples :)
Thanks!

A problem w/ embedded example folders is that everyone adding the library as a dependency has to download the samples too. But maybe it's still worth it.

+1 for more examples, but -1 for embedded them in a subdirectory of this repository.
@helje5 Since you own the @SwiftWebUI organization, you have a nice built-in way to keep examples separate but still within a cohesive namespace. Each example app should be self-contained and deployable on its own, building from the main SwiftWebUI project as a dependency.

Well, yes, that is the current setup :-) I think it's OK. BTW: Another great example app might be a port of that Movies SwiftUI app that circled around a week ago.

@helje5 yesterday I tried your examples, but I avoided to use the Xcode. I recreated a simple structure using SwiftPM and moved your example files into it. If you want, I can do again and send you as a PR. Make sense to you?
Why I did that?
For some reason, the SPM integration on Xcode isn't working well yet. My credentials are configured, but every time when I try to refresh the package dependencies, Xcode ask me to do the process again. (login, 2fa and so on)

I've added an SPM manifest for AvocadoToast in the Linux branch already (and adjusted the file structure for SPM), probably going to do the same for Tinker2. So I suppose I don't need this particular PR :-) But thanks for the offer!

Awesome @helje5! Thanks for the quick answer!

OK, they all have SPM manifests now. I also added the minimal HelloWorld to the main project.
I guess I close this for now. That more examples are cool should be obvious :-)


Q: Login with Microsoft 365 account

Feature Description
Is there a way to configure authentication for Microsoft 365 (formerly Office 365) online accounts?
I know about Active Directory (local) authentication - LDAP.
Thank you for clarifications.
Screenshots
No response

Yup, you can use OIDC for Azure: https://blog.anoff.io/2019-03-23-configure-azure-ad-for-gitea/


Translations

Translations to english.
I can help with that and spanish too.

There is no need to translate in english because obviously all text are writed in english then translate into french with the "fr" PO.
For spanish i created the "es" PO in the last release, you are welcome to fill it. Keep aware that there will be future updates, so you have to maintain the PO file, else i will probably remove it.


v3.9 marketplace offering

We need to create a v3.9 marketplace offering, this require several steps.

[x] update docker files with latest (OS and v3.9)
[x] deploy docker images to docker hub
[x] deploy docker images to public ECR
[x] deploy docker images to marketplace ECR
[x] update CFTs (including new web app with data mart)
[x] test CFTs
[x] create new marketplace offering

removed stream-loader for issue #144

PR merged, release created


Update about.html

Added recent experiences.

Added recent experiences.

Added recent experiences.

Added recent experiences.

Added recent experiences.


release: bumping stable release to osquery 3.2.6

Don't merge this, the windows MSI is just a hash of nothing. @muffins will unblock when the MSI is updated, we can just update the hash here.

I left my key at home, so will get to this first thing next week ;)

@theopolis:
~ ❯ shasum -a 256 ~/Downloads/osquery-3.2.6.msi
0632a43c37e1c169ff313290b9460258d6bd6edc7764b446ec2de02e588905bf  /Users/thor/Downloads/osquery-3.2.6.msi


query-frontend: option --query-range.align-range-with-step can not be turned off

I will keep this bug report very short because it is very straightforward:
The --query-range.align-range-with-step option of the Query Frontend can not be turned off.
As a cmd flag defaulting to true turning it off could be possible with:
```--query-range.align-range-with-step=false````
However this yields the following error:
```thanos: error: unexpected false````

I just realized that --no-query-range.align-range-with-step works..


fixed typo in policy files for defect 107410

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

ok to test

LGTM. :+1:  Okay to merge when tests pass.


Fixed crash in your delegation

#86959jact

Task linked: CU-86959jact Android. Crash on your delegations

Release severity: Normal
Release notes:
Fix crash on the "Your delegations" screen


feat(deploy): UI based deploy flow

closes #4969 closes #5216
Testing steps,

Create cli with this: make cli
Start cloud (needs docker running): ./rill devtool start cloud
(Optional) Copy cli to home cp ./rill ~/rill and remove quarantine: sudo xattr -d com.apple.quarantine ~/rill
Run this within a new folder or existing folder: ~/rill start

This will work for non-github and github based projects. Redeploy wont show for projects deployed before this.

Hey Aditya! When I click on Deploy, I get a 500 error

We should avoid this parse error, and anyways we should probably not show the .rillcloud directory in the file explorer. Can we add .rillcloud to the default ignore_paths? Or will that prevent the runtime from writing to the directory?


Convert test39 into a new style test

Codecov Report

Merging #5324 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5324      +/-   ##
==========================================
- Coverage   82.24%   82.23%   -0.02%
==========================================
  Files         134      134
  Lines      147573   147573
==========================================
- Hits       121374   121354      -20
- Misses      26199    26219      +20

Impacted Files
Coverage Δ

src/drawscreen.c
83.52% <0%> (-0.38%)
:arrow_down:

src/mark.c
89.85% <0%> (-0.36%)
:arrow_down:

src/os_unix.c
63.5% <0%> (-0.18%)
:arrow_down:

src/edit.c
85.56% <0%> (-0.17%)
:arrow_down:

src/drawline.c
84.64% <0%> (-0.14%)
:arrow_down:

src/change.c
81.98% <0%> (-0.11%)
:arrow_down:

src/channel.c
84.18% <0%> (-0.08%)
:arrow_down:

src/screen.c
84.63% <0%> (-0.05%)
:arrow_down:

src/gui.c
63.78% <0%> (+0.05%)
:arrow_up:

Continue to review full report at Codecov.

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


Atom 1.19.0 crashes instantly after launching

Prerequisites

[X] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
Atom crashes right away after I launch it. I don't even get to see any window.
Steps to Reproduce
Launch Atom.
Expected behavior: [What you expect to happen]
Atom should not crash.
Actual behavior: [What actually happens]
Atom crashes.
Reproduces how often: [What percentage of the time does it reproduce?]
100%
Versions
I cannot get information via atom --version as it crashes right away. Atom is the new version 1.19.0, please let me know if you need more info.
apm info:
apm  1.18.2
npm  3.10.10
node 6.9.5 x64
python 2.7.10
git 2.2.1
Mac OS X 10.8.5
Additional Information
The issue started after updating to 1.19.0, it never occured, when I was still with 1.18.x.
Here's the console log of such a crash:
Process:         Atom [8382]
Path:            /Applications/Atom.app/Contents/MacOS/Atom
Identifier:      com.github.atom
Version:         1.19.0 (1.19.0)
Code Type:       X86-64 (Native)
Parent Process:  launchd [201]
User ID:         501

Date/Time:       2017-08-14 12:51:30.122 +0200
OS Version:      Mac OS X 10.8.5 (12F2560)
Report Version:  10

Crashed Thread:  0

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Library not loaded: /System/Library/Frameworks/GameController.framework/Versions/A/GameController
  Referenced from: /Applications/Atom.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
  Reason: image not found

Binary Images:
       0x103ff2000 -        0x103ff2ff7 +com.github.atom (1.19.0 - 1.19.0) <CB63147A-C9DC-308B-8CA1-EE92A5042E8E> /Applications/Atom.app/Contents/MacOS/Atom
       0x103ff7000 -        0x107c7cf73 +com.github.electron.framework (0) <02EEB879-495F-3A71-9D22-B9C1710D7DC4> /Applications/Atom.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
       0x1082c7000 -        0x1082e1fff +com.github.Squirrel (1.0 - 1) <4C459C36-AFB6-3B8A-8FEC-76C192C17E30> /Applications/Atom.app/Contents/Frameworks/Squirrel.framework/Versions/A/Squirrel
       0x10830d000 -        0x108370ff7 +org.reactivecocoa.ReactiveCocoa (1.0 - 1) <701B20DE-3ADD-3643-B52A-E05744C30DB3> /Applications/Atom.app/Contents/Frameworks/ReactiveCocoa.framework/Versions/A/ReactiveCocoa
       0x1083ee000 -        0x108402fff +org.mantle.Mantle (1.0 - ???) <31915DD6-48E6-3706-A076-C9D4CE17F4F6> /Applications/Atom.app/Contents/Frameworks/Mantle.framework/Versions/A/Mantle
       0x10841b000 -        0x1092a7fff +libnode.dylib (0) <DAB1C2BB-5D2E-3517-B257-830B9D737750> /Applications/Atom.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib
       0x10951e000 -        0x109779fef +libffmpeg.dylib (0) <D787CAF4-FE4E-3859-906E-E1E54DE385B6> /Applications/Atom.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib
       0x109987000 -        0x1099d1ff7  com.apple.audio.midi.CoreMIDI (1.9 - 78) <28B1D3A5-973A-359A-99DC-18BE8C30C6B8> /System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI
    0x7fff63bf2000 -     0x7fff63c2693f  dyld (210.2.3) <A40597AA-5529-3337-8C09-D8A014EB1578> /usr/lib/dyld
    0x7fff897d2000 -     0x7fff89835fff  com.apple.audio.CoreAudio (4.1.2 - 4.1.2) <FEAB83AB-1DE5-3813-BA48-7A7F2374CCF0> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
    0x7fff89a01000 -     0x7fff8a62efff  com.apple.AppKit (6.8 - 1187.40) <F12CF463-6F88-32ED-9EBA-0FA2AD3CF576> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
    0x7fff8a66c000 -     0x7fff8a670fff  com.apple.IOSurface (86.0.5 - 86.0.5) <4841B89D-501E-306D-8891-3651AA9326E6> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
    0x7fff8a72b000 -     0x7fff8a8d9fff  com.apple.QuartzCore (1.8 - 304.5) <5674D50C-D96C-3A2D-95C5-C93311C7FB56> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
    0x7fff8a903000 -     0x7fff8a971fff  com.apple.framework.IOKit (2.0.1 - 755.42.2) <18E64CC5-2671-3C47-B2C6-0EEEDF899461> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff8abae000 -     0x7fff8ae8bfff  com.apple.security (7.0 - 55719.16.12) <C66C10FF-3ED8-3195-82D0-D5B2FB81E831> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff8b23c000 -     0x7fff8b23dff7  libSystem.B.dylib (169.3) <365477AB-D641-389D-B8F4-A1FAE9657EEE> /usr/lib/libSystem.B.dylib
    0x7fff8b693000 -     0x7fff8b693fff  com.apple.quartzframework (1.5 - 1.5) <6403C982-0D45-37EE-A0F0-0EF8BCFEF440> /System/Library/Frameworks/Quartz.framework/Versions/A/Quartz
    0x7fff8b892000 -     0x7fff8b892ffd  com.apple.audio.units.AudioUnit (1.9.2 - 1.9.2) <6D314680-7409-3BC7-A807-36341411AF9A> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
    0x7fff8b893000 -     0x7fff8b8fbff7  libc++.1.dylib (65.1) <20E31B90-19B9-3C2A-A9EB-474E08F9FE05> /usr/lib/libc++.1.dylib
    0x7fff8bbb7000 -     0x7fff8bd09fff  com.apple.audio.toolbox.AudioToolbox (1.9.2 - 1.9.2) <DC5F3D1B-036A-37DE-BC24-7636DC95EA1C> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
    0x7fff8c0e0000 -     0x7fff8c10aff7  com.apple.CoreVideo (1.8 - 99.4) <E5082966-6D81-3973-A05A-38AA5B85F886> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
    0x7fff8c18d000 -     0x7fff8c377ff7  com.apple.CoreFoundation (6.8 - 744.19) <0F7403CA-2CB8-3D0A-992B-679701DF27CA> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff8c401000 -     0x7fff8c52bfff  com.apple.avfoundation (2.0 - 361.40.1) <82E0EE8C-6026-33AD-8947-B20D2ED7B2E1> /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation
    0x7fff8c566000 -     0x7fff8c566fff  com.apple.Carbon (154 - 155) <372716D2-6FA1-3611-8501-3DD1D4A6E8C8> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
    0x7fff8dbcb000 -     0x7fff8dc1cff7  com.apple.SystemConfiguration (1.12.2 - 1.12.2) <A4341BBD-A330-3A57-8891-E9C1A286A72D> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff8ebaf000 -     0x7fff8ebe3fff  com.apple.securityinterface (6.0 - 55024.4) <614C9B8E-2056-3A41-9A01-DAF74C97CC43> /System/Library/Frameworks/SecurityInterface.framework/Versions/A/SecurityInterface
    0x7fff90214000 -     0x7fff9025ffff  com.apple.CoreMedia (1.0 - 926.107) <405690E6-D857-3136-AC3A-5EDC6C3ABF60> /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia
    0x7fff902b1000 -     0x7fff90610fff  com.apple.Foundation (6.8 - 945.19) <C98E55BA-553B-314B-B056-849FFB20C220> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff9108e000 -     0x7fff910adff7  libresolv.9.dylib (51) <0882DC2D-A892-31FF-AD8C-0BB518C48B23> /usr/lib/libresolv.9.dylib
    0x7fff9149f000 -     0x7fff91610ff7  com.apple.QTKit (7.7.1 - 2599.54) <12F9CD59-5BCC-3847-BA6F-2002DC865DFE> /System/Library/Frameworks/QTKit.framework/Versions/A/QTKit
    0x7fff929e6000 -     0x7fff929e6fff  com.apple.ApplicationServices (45 - 45) <A3ABF20B-ED3A-32B5-830E-B37831A45A80> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
    0x7fff937da000 -     0x7fff937e9fff  com.apple.opengl (1.8.10 - 1.8.10) <AD49CF56-B7C1-3598-8610-58532FC41345> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
    0x7fff952f5000 -     0x7fff952f5fff  com.apple.Accelerate (1.8 - Accelerate 1.8) <878A6E7E-CB34-380F-8212-47FBF12C7C96> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate

And yes, I reinstalled and reset to factory settings, it still crashes.

I cannot get information via atom --version

Just running that on the command line crashes?  Is there any output on the command line?
Also, can you clarify how you start Atom?  From the command line, spotlight, etc.?  And does Atom crash no matter how you start it?
Lastly, if you start Atom like this is there any output?
atom --safe --foreground

Hello,
Similar issue here, I cannot launch the latest Atom 1.1.19 on OSX 10.8.5.
After many test (trashing prefs,.atom, reinstalling, etc.) I revert back to 1.1.18 and it works fine again.
Here is just part of the log:
*Application Specific Information:
dyld: launch, loading dependent libraries
Dyld Error Message:
Library not loaded: /System/Library/Frameworks/GameController.framework/Versions/A/GameController
Referenced from: /Applications/Atom.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
Reason: image not found*
Best,
Eric

Here is a screenshot

Sorry I'm having issue commenting with my much too old Safari version unsupported on github...

I'm trying to disable autoupdate too in 1.1.18, please check this popup too:

@rsese

Just running that on the command line crashes? Is there any output on the command line?

Exactly. No, there is no output. Here's a screenshot along with the same error message that @sbgraphic also posted, only in German this time.

Also, can you clarify how you start Atom? From the command line, spotlight, etc.? And does Atom crash no matter how you start it?

Yes, it crashes no matter, how I start it. I have tried command line, Spotlight, application launcher (Alfred) and double clicking. It all crashes instantly.

Lastly, if you start Atom like this is there any output?

atom --safe --foreground

This also crashes Atom right away, but this does write an output to the console:
dyld: Library not loaded: /System/Library/Frameworks/GameController.framework/Versions/A/GameController
  Referenced from: /Applications/Atom.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
  Reason: image not found
/usr/local/bin/atom: line 130: 10235 Trace/BPT trap: 5       "$ATOM_PATH/$ATOM_APP_NAME/Contents/MacOS/$ATOM_EXECUTABLE_NAME" --executed-from="$(pwd)" --pid=$$ "$@"

Let me know if I can provide any more info.

Thanks for the details - it looks like you're both on macOS 10.8.5, I wonder if that's related.  I'll bring it up with the team - you don't happen to have this version available for testing @ungb?

@rsese @ungb
Is there any update on this / is somebody looking into this? Are there any Mac OS X 10.8.5 specific infos you need from me?
I assume updating to 1.19.2 won't fix this problem, right?

Between Atom v1.18 and Atom v1.19, we upgraded to a new version of Electron, v1.6.9. This new version of Electron is no longer compatible with OS X v10.8 and requires OS X v10.9 at a minimum. If you want to continue using Atom on OS X v10.8, you will have to downgrade to Atom v1.18 and disable Atom's automatic updates. You can do this by:

Launching Atom
Opening the Settings View with Cmd+,
Unchecking "Automatically Update"

If you update the version of OS X you're using, you can go back to using the latest version of Atom normally by checking the same box.

Sigh … nothing much I can do then, I guess.
I think in this case the sentence "For macOS 10.8 or later" on Atom's front page should be replaced by "For macOS 10.9 or later".
Oh well, back to Sublime, I guess. :/

I think in this case the sentence "For macOS 10.8 or later" on Atom's front page should be replaced by "For macOS 10.9 or later".

Thanks for pointing this out. I'll take care of that right now.

And actually come to think of it, it should not auto-update in the first place to a version that it won't be able to run. (I hate it when that happens. I probably spend days of my life downgrading software that let me upgrade to non-functioning updates.)
Should I file a new issue about that?

@trych No, thank you. I'm not sure how we would even do that exactly, especially in a cross-platform way and this is the first time in the three-and-a-half years that Atom has been out that we've changed the minimum version of an OS we support. I'm not sure that we would prioritize detecting and handling this for how rarely it would come up.
I'll check with the Electron team to see if there's something they could do on their end though. It is a good suggestion.


nixos/clamav: use StateDirectory to ensure creation

Description of changes
upon first starting clamav with the following settings
      clamav = {
        daemon.enable = true;
        updater.enable = true;
      };

I got the following error
ystemd[1]: Starting ClamAV daemon (clamd)...
ystemd[1]: Started ClamAV daemon (clamd).
lamd[3312752]: LibClamAV Error: cl_load(): No such file or directory: /var/lib/clamav
lamd[3312752]: ERROR: Can't get file status
ystemd[1]: clamav-daemon.service: Main process exited, code=exited, status=1/FAILURE
ystemd[1]: clamav-daemon.service: Failed with result 'exit-code'.

I'm not sure why StateDirectory isn't used here. That would ensure that the statedirectory is created before boot.

Another thing that I wanted to do was to make the user a dynamic user (I don't see a need IMO for creating a user and groupid here). However that would be a breaking change, so I'm refraining from doing that here and just seeing if anyone involved with the PR would be ok with it.

## Things done

<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->

- Built on platform(s)
  - [ ] x86_64-linux
  - [ ] aarch64-linux
  - [ ] x86_64-darwin
  - [ ] aarch64-darwin
- For non-Linux: Is sandboxing enabled in `nix.conf`? (See [Nix manual](https://nixos.org/manual/nix/stable/command-ref/conf-file.html))
  - [ ] `sandbox = relaxed`
  - [ ] `sandbox = true`
- [ ] Tested, as applicable:
  - [NixOS test(s)](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
  - and/or [package tests](https://nixos.org/manual/nixpkgs/unstable/#sec-package-tests)
  - or, for functions and "core" functionality, tests in [lib/tests](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or [pkgs/test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
  - made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) 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](https://github.com/Mic92/nixpkgs-review#usage)
- [ ] Tested basic functionality of all binary files (usually in `./result/bin/`)
- [23.11 Release Notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2311.section.md) (or backporting [23.05 Release notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2305.section.md))
  - [ ] (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
- [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).

<!--
To help with the large amounts of pull requests, we would appreciate your
reviews of other pull requests, especially simple package updates. Just leave a
comment describing what you have tested in the relevant package/service.
Reviewing helps to reduce the average time-to-merge for everyone.
Thanks a lot if you do!

List of open PRs: https://github.com/NixOS/nixpkgs/pulls
Reviewing guidelines: https://nixos.org/manual/nixpkgs/unstable/#chap-reviewing-contributions
-->

I suspect that the clamav-daemon might want root access, but you could try DynamicUser and  CAP_DAC_READ_OVERRIDE instead.

upon testing I realised that clamav-daemon also needs RuntimeDirectory.
I've added it to clamav-freshclam as well to keep the config exactly like it was before.
(we can remove it in another PR of course).
I've just tested this and it worked perfectly.
I had to systemctl restart clamav-daemon for the changes to actually take effect though.

Am I understanding this correctly?

clamav is running as root but with /var/lib/clamav owned by the clamav user (in master branch)?
This PR changes it to run as clamav user instead of root (and systemd automatically handles the /var/lib/clamav ownership)?

@bjornfor this is also my understanding.
So far i havent gotten any errors running clamav with this configuration.

@bjornfor this is also my understanding. So far i havent gotten any errors running clamav with this configuration.

Ok. Then I think the commit message should mention this. It's (IMHO) the bigger functional change than what mechanism is used to create the state directory. Or better, it should be two different commits.

I understand your point, I've split it in 2 commits.
Let me know of course if I there is anything else.

After reading the arch linux documentation https://wiki.archlinux.org/title/ClamAV, here is the tldr of what I learned.

the clamav daemon is not supposed to run as root.
The normal database of viruses is not enough, that is unfortunate.
The scanning is supposed to be done by the user, and the thing doing the scanning needs to have the permissions and pass those with a file descriptor to the daemon.

I'm now more confident in this change.


All Windows get moved to primary Monitor on switching Virtual Desktops

I have just discovered workspacer and am trying to understand how the config works. I general, it does close to what i want. Until now, i heavily used Windows's own virtual Desktops. Those seem to somehow conflict with workspacer.
Upon entering a Virtual Desktop, all it's Windows get moved to the primary Monitor. It doesn't matter which Workspace i'm on at all.
Also, the virtual Desktop Switcher Overlay (Win + Tab) gets tiled too. This leads to some pretty nasty visuals with two Screens. I'm sure that can be fixed with an exception.

I think part of the benefit of using something like workspacer is that workspaces replace virtual desktops. Maybe take a look at how do I define custom workspaces? and see if that helps.


https://admin.youtube.com/

Thank you for using bruh.tk!
The shortened link is available at bruh.tk/<issue number>.

Comment on ferme une issue ?

(as a millionaire)


Password flag missing for 'influx v1 auth set-password' command

In influxdb v2.0.2 , password setting for v1 authentication is missing the flag "--password" , althought in the official documentation this flag is there.
#-----
root@monitoring-influxdb-8fd4884f9-lcvzf:/# influx version
Influx CLI 2.0.2 (git: 84496e507a) build_date: 2020-11-19T03:59:35Z
root@monitoring-influxdb-8fd4884f9-lcvzf:/# influx v1 auth set-password -h
Set a password for an existing authorization
Usage:
influx v1 auth set-password [flags]
Flags:
-c, --active-config string   Config name to use for command; Maps to env var $INFLUX_ACTIVE_CONFIG
--configs-path string    Path to the influx CLI configurations; Maps to env var $INFLUX_CONFIGS_PATH (default
"/root/.influxdbv2/configs")
-h, --help                            Help for the set-password command
--host string                  HTTP address of InfluxDB; Maps to env var $INFLUX_HOST
--id ID                            The ID of the authorization; Maps to env var $INFLUX_ID
--skip-verify                   Skip TLS certificate chain and host name verification.
-t,  --token string                Authentication token; Maps to env var $INFLUX_TOKEN
--username string           The username of the authorization; Maps to env var $INFLUX_USERNAME
#----------------

Hi @ved-pal, this is expected, --password was added as an option in v2.0.3

Hi @ved-pal, this is expected, --password was added as an option in v2.0.3

ok, then i think i should pull v2.0.3. Thanks for update !!
Closing this issue.

ok, then i think i should pull v2.0.3. Thanks for update !!
Closing this issue.


Error ..types/vue relative mddule not found in lib/main.js

After an installation of package, i have encountered this error:
ERROR  Failed to compile with 1 errors
This relative module was not found:

* ../types/vue in ./node_modules/vue-cookies-ts/lib/main.js
Type checking and linting in progress...

Version: typescript 3.6.2, tslint 5.19.0
Time: 3895ms

After an installation of package, i have encountered this error:
ERROR  Failed to compile with 1 errors
This relative module was not found:

* ../types/vue in ./node_modules/vue-cookies-ts/lib/main.js
Type checking and linting in progress...

Version: typescript 3.6.2, tslint 5.19.0
Time: 3895ms

Hi, I fixed this issue in version 1.5.17, thanks for using : )


Modal don't show

I have a question. when my app is foreground, I would show a modal, then the background modal will close, but I using appState, the modal doesn't show. How i can show a modal when the app is foreground ?? like paypal

it's not modal. You can see instructions and follow:
https://jonaskuiler.medium.com/creating-a-security-screen-on-ios-and-android-in-react-native-97703092e2de
or use
rnbootsplash
hope this helps

@hoanglam10499 thanks :)))