isInternetReachable is returning null on first attempt on ios

Environment
System:
OS: macOS 12.1
CPU: (8) x64 Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
Memory: 1.02 GB / 16.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 17.0.1 - /usr/local/bin/node
Yarn: 1.22.17 - /usr/local/bin/yarn
npm: 8.1.0 - /usr/local/bin/npm
Watchman: 2<IP_ADDRESS> - /usr/local/bin/watchman
Managers:
CocoaPods: 1.11.2 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.2, iOS 15.2, macOS 12.1, tvOS 15.2, watchOS 8.3
Android SDK: Not Found
IDEs:
Android Studio: 4.0 AI-193.69<IP_ADDRESS>26763
Xcode: 13.2.1/13C100 - /usr/bin/xcodebuild
Languages:
Java: Not Found
npmPackages:
@react-native-community/cli: Not Found
react: 17.0.2 => 17.0.2
react-native: 0.66.3 => 0.66.3
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
Platforms
iOS
Versions

iOS: 15.2.1
react-native-netinfo: "^7.0.0"
react-native: "0.66.3"
react: "17.0.2"

Description
This is happening on real device (iPhone 11)
On my app, in an on click event, i am trying to get some data from api. Before that i am checking internet connectivity.
When i'm using this
import NetInfo from "@react-native-community/netinfo";

NetInfo.fetch().then(internetState => {
  console.log(internetState);
  if (internetState.isConnected && internetState.isInternetReachable) {
    // rest of my code
  }else{
    // some warning
  }
});

on first attempt it is returning this, with isInternetReachable is returning null.
LOG {"details": {"bssid": null, "ipAddress": "<IP_ADDRESS>", "isConnectionExpensive": false, "ssid": null, "subnet": "<IP_ADDRESS>"}, "isConnected": true, "isInternetReachable": null, "type": "wifi"}
but if i click the button again, now isInternetReachable is returning true
LOG {"details": {"bssid": null, "ipAddress": "<IP_ADDRESS>", "isConnectionExpensive": false, "ssid": null, "subnet": "<IP_ADDRESS>"}, "isConnected": true, "isInternetReachable": true, "type": "wifi"}
Its only happening on ios. any idea guys?
Reproducible Demo
https://snack.expo.dev/@rassemdev/login-page

Could it be the delay that there is when the native code performs a head request to Google (or what you configured) and your fetch call? Not sure if possible to set a different default to the internet flag, but maybe if you override any of the connectivity checks configurations you can work around it .

I haven't configured any default value. Could you provide any example with snack! it would be really helpful for me and others if anyone facing any problem similar to me.

 Added configuration, yet having same problem.

Got some code to show? Including where exactly you’re calling the code.

At all times please keep these in mind:
https://stackoverflow.com/help/minimal-reproducible-example
https://stackoverflow.com/help/how-to-ask

@rassemdev I've just confirmed your issue on iOS. The first call to the listener set with NetInfo.addEventListener returns isInternetReachable = null.  However, a second callback is fired right after (~100ms later) with the correct value.
I don't know the exact cause, but my guess above still applies (the time between the check is made and the header request response is received). You should not rely on one single result when checking whether there's internet or not, as it will be constantly changing.
I will still dig a bit to see if something can be improved, but I doubt it.

@rassemdev did you find any solution here?

This is not a good workaround, but gets the work done:
const internetReachable = async () => {
  const timeout = (milliseconds: number) =>
    new Promise(resolve => setTimeout(resolve, milliseconds));

  let isInternetReachable: boolean | null = false;

  isInternetReachable = (await NetInfo.fetch()).isInternetReachable;

  if (isInternetReachable) {
    return isInternetReachable;
  }

  await timeout(200);

  isInternetReachable = (await NetInfo.fetch()).isInternetReachable;
  return isInternetReachable;
};

  isInternetReachable = (await NetInfo.fetch()).isInternetReachable;

  if (isInternetReachable) {
    return isInternetReachable;
  }

  await timeout(200);

  isInternetReachable = (await NetInfo.fetch()).isInternetReachable;

No, I'm still waiting for their fix.

"their" --> It is open source. There is no "they", you are the they! All users of the library are the library developers! Welcome to the club :hugs:
"waiting ... " --> no need to wait! Make a PR with the fix!

Hi @mikehardy I'm happy to send a PR for this but what would be an acceptable solution here?
I think you'd agree that a random wait is not ideal.
Do you reckon this PR could be of use here? by exposing a refresh function, users can then choose to refresh after some condition/timeout is met?
Or do you think the library should indeed retry internally (since/if this is a platform issue and all apps on iOS need this fix)?

Definitely going to merge the refresh PR it's just a holiday here, been busy
If there really is a platform issue I'd welcome any PR that fixes it

Haven't got the time to further test and see if this indeed is an iOS issue but just tried out ^8.3.0 with the above mentioned PR merged and the following seems to work.
import { useEffect } from 'react';
import NetInfo, { useNetInfo } from '@react-native-community/netinfo';

NetInfo.configure({
  reachabilityUrl: "endpoint/my/api/reachable",
  reachabilityShortTimeout: 2000, // 2 seconds
  reachabilityRequestTimeout: 15 * 1000, // 15s
  reachabilityTest: async response => response.status === 200,
  reachabilityShouldRun: () => true,
});

export function useApiIsReachable() {
  const { isConnected, isInternetReachable } = useNetInfo();

  useEffect(() => {
    console.log('isInternetReachable ', isInternetReachable);
    if (!isInternetReachable) {
      console.log('refreshing...');
      NetInfo.refresh();
    }
  }, [isInternetReachable]);

  return { isConnected, isInternetReachable };
}

This issue is still happening.

@n-ii-ma have you tried the approach I pasted above?
This workaround seems to work.
import NetInfo, { useNetInfo } from '@react-native-community/netinfo';

const { isConnected } = useNetInfo();
useEffect(() => {
  if (isConnected === null) {
    console.log('refreshing...')
    NetInfo.refresh();
  }
}, [isConnected]);
console.log('isConnected ', isConnected);

@mikehardy do you think this is something that this library can/should do (at least once)? Like on first render, if (isConnected === null) then refresh once? any potential issues this might cause?

This is what I am using right now:
import NetInfo from '@react-native-community/netinfo';
import { useEffect } from 'react';

export const useInternet = () => {

  useEffect(() => {
    // Fixes first call to NetInfo.fetch() returning `isInternetReachable` null on iOS
    // https://github.com/react-native-netinfo/react-native-netinfo/issues/572
    NetInfo.fetch();
  }, []);

  const hasConnectionError = async () => {
    const state = await NetInfo.fetch();
    const { isConnected, isInternetReachable } = state;
    return !isConnected || !isInternetReachable;
  };

  return { hasConnectionError };
};

Hey everyone! I've been struggling with this as our app is handling VoIP calls. VoIP calls usually came when app was killed or in background mode, so isInternetReachable not set on iOS was a blocker for us. I wanted to use hooks, but since handlers on iOS and Android are different for VoIP notifications and are on different places (eg. index), i had to make a class. We are using it as a Singleton. This is what i came up with.
function timeout(ms: number) {
    return new Promise((resolve) => setTimeout(resolve, ms));
}

type NetworkState = Pick<NetInfoState, 'isConnected' | 'isInternetReachable'>;

class CloudTalkConnectionService {
    private connection: NetworkState = {
        isConnected: false,
        isInternetReachable: false
    };

    constructor() {
        // Initialize the network status and add event listeners
        NetInfo.fetch().then(async (state: NetInfoState) =>
            this.setConnection(this.transformToLocalNetInfo(state))
        );

        NetInfo.addEventListener((state: NetInfoState) =>
            this.setConnection(this.transformToLocalNetInfo(state))
        );
    }

    private transformToLocalNetInfo = (state: NetInfoState): NetworkState => ({
        isConnected: state?.isConnected,
        isInternetReachable: state?.isInternetReachable
    });

    private setConnection = (state: NetworkState) => {
        this.connection = state;
    };

    /**
     * Force refreshes the NetInfo state. If the isInternetReachable
     * variable is not set, it will recursively call itself until
     * the variable is set, regardless of value.
     *
     * Mitigates issue where reachability is not set after app startup on iOS:
     * https://github.com/react-native-netinfo/react-native-netinfo/issues/572
     */
    isReachabilityAvailable = async (): Promise<boolean> => {
        const state = await NetInfo.refresh();

        if (state?.isInternetReachable === null) {
            // Allow NetInfo to recover
            await timeout(100);
            return this.isReachabilityAvailable();
        }

        this.setConnection(this.transformToLocalNetInfo(state));
        return true;
    };

    checkInternetConnection = (): boolean =>
        this.connection.isConnected && this.connection.isInternetReachable;
}

This is what I am using right now:
import NetInfo from '@react-native-community/netinfo';
import { useEffect } from 'react';

export const useInternet = () => {

  useEffect(() => {
    // Fixes first call to NetInfo.fetch() returning `isInternetReachable` null on iOS
    // https://github.com/react-native-netinfo/react-native-netinfo/issues/572
    NetInfo.fetch();
  }, []);

  const hasConnectionError = async () => {
    const state = await NetInfo.fetch();
    const { isConnected, isInternetReachable } = state;
    return !isConnected || !isInternetReachable;
  };

  return { hasConnectionError };
};

thank you for the idea, but i prefer this
import { useEffect, useRef } from 'react';
import NetInfo from '@react-native-community/netinfo';

const useInternet = () => {
  useEffect(() => {
    // Fixes first call to NetInfo.fetch() returning `isInternetReachable` null on iOS
    // https://github.com/react-native-netinfo/react-native-netinfo/issues/572
    NetInfo.fetch();
  }, []);

  const hasInternet = async () => {
    const { isConnected, isInternetReachable } = await NetInfo.fetch();
    return isConnected && isInternetReachable ? true : false;
  };

  return { hasInternet };
};

export default useInternet;

I get this too:

LOG  {"netInfo": {"details": null, "isConnected": null, "isInternetReachable": null, "type": "unknown"}}
LOG  {"netInfo": {"details": {"ipAddress": "<IP_ADDRESS>", "isConnectionExpensive": false, "subnet": "<IP_ADDRESS>"}, "isConnected": true, "isInternetReachable": null, "type": "wifi"}}

"@react-native-community/netinfo": "9.3.10",

so do we know for sure if this is only on the first call? If you send out two requests close enough together, will the second one always return with a value? I think the recursive call is likely the best answer in this thread, but the real solution is to have some indicator as to why that value is null in the first place, and not return the call from fetch until whatever needs to init has inited, right?

+1

+1

+1

I am using this function. Works well.
import NetInfo from '@react-native-community/netinfo';

export const internetConnected = async (): Promise<boolean> => {
  const timeout = (milliseconds: number) => new Promise((resolve) => setTimeout(resolve, milliseconds));

  // We need to make two calls to NetInfo.fetch() to get the correct network state
  // See: https://github.com/react-native-netinfo/react-native-netinfo/issues/572
  let networkState = await NetInfo.fetch();
  if (networkState.isInternetReachable === null) {
    await timeout(1);
    networkState = await NetInfo.fetch();
  }

  // Check if the device is connected to the internet
  const internetIsConnected = networkState.isConnected === true && networkState.isInternetReachable === true;
  return internetIsConnected;
};

I am using this function. Works well.
import NetInfo from '@react-native-community/netinfo';

export const internetConnected = async (): Promise<boolean> => {
  const timeout = (milliseconds: number) => new Promise((resolve) => setTimeout(resolve, milliseconds));

  // We need to make two calls to NetInfo.fetch() to get the correct network state
  // See: https://github.com/react-native-netinfo/react-native-netinfo/issues/572
  let networkState = await NetInfo.fetch();
  if (networkState.isInternetReachable === null) {
    await timeout(1);
    networkState = await NetInfo.fetch();
  }

  // Check if the device is connected to the internet
  const internetIsConnected = networkState.isConnected === true && networkState.isInternetReachable === true;
  return internetIsConnected;
};

====================================
LOG  false
LOG  ====================================
LOG  ====================================
LOG  true
LOG  ====================================
LOG  ====================================
LOG  true
LOG  ====================================

This is not a good workaround, but gets the work done:
const internetReachable = async () => {
  const timeout = (milliseconds: number) =>
    new Promise(resolve => setTimeout(resolve, milliseconds));

  let isInternetReachable: boolean | null = false;

  isInternetReachable = (await NetInfo.fetch()).isInternetReachable;

  if (isInternetReachable) {
    return isInternetReachable;
  }

  await timeout(200);

  isInternetReachable = (await NetInfo.fetch()).isInternetReachable;
  return isInternetReachable;
};

This work for me

this wrk for me
export const useIsOffline = () => {
const [netInfoState, setNetInfoState] = useState(undefined);
const [isOffline, setIsOffline] = useState(false);
useEffect(() => {
NetInfo.addEventListener((state) => {
if (state.isInternetReachable !== null) {
setNetInfoState(state);
}
});
}, []);
useEffect(() => {
if (netInfoState !== undefined) {
setIsOffline(!netInfoState.isInternetReachable);
}
}, [netInfoState]);
return isOffline;
};


Mocking soap services with nock

I'm working on a node app that communicates with soap services, using the foam module to parse json into a valid soap request and back again when the response is received. This all works fine when communicating with the soap services.
The issue I'm having is writing unit tests for this (integration tests work fine). I'm using nock to mock the http service and send a reply. This reply does get parsed by foam and then I can make assertions against the response.
So I cannot pass a json object as a reply because foam expects a soap response. If I try to do this I get the error:
Error: Start tag expected, '<' not found

Storing XML in javascript variables is painful and doesn't work (i.e. wrapping it in quotes and escaping inner quotes isn't valid), so I wanted to put the mocked XML response into a file and pass that as a reply.
I've tried reading the file in as a stream
return fs.createReadStream('response.xml')

...and replying with a file
.replyWithFile(201, __dirname + 'response.xml');

Both fail with an error of
TypeError: Cannot read property 'ObjectReference' of undefined

Here is the XML in the file
<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
    <env:Header></env:Header>
    <env:Body>
        <FLNewIndividualID xmlns='http://www.lagan.com/wsdl/FLTypes'>
            <ObjectType>1</ObjectType>
            <ObjectReference>12345678</ObjectReference>
            <ObjectReference xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:nil='true'/>
            <ObjectReference xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:nil='true'/>
        </FLNewIndividualID>
    </env:Body>
</env:Envelope>

The module being tested is
var foam = require('./foam-promise.js');

module.exports = {
    createUserRequest: function(url, operation, action, message, namespace) {
        var actionOp = action + '/actionRequestOp',
            uri = url + '/actionRequest';

        return new Promise(function(resolve, reject) {
            foam.soapRequest(uri, operation, actionOp, message, namespace)
            .then(function(response) {
                resolve(response.FLNewIndividualID.ObjectReference[0]);
            })
            .catch(function(err) {
                reject(err);
            });
        });

    }
};

The assertion is using should-promised
return myRequest(url, operation, action, data, namespace)
    .should.finally.be.exactly('12345678');

So it looks like the xml parser won't just accept a file (which makes sense). Does the stream not complete before it is tested?
Can an XML reply be mocked successfully with nock?
NB: Also asked on Stack Overflow http://stackoverflow.com/questions/30664686/mocking-soap-services-with-nock

@ssbrewster It can. I don't know foam well, but I guess you have to set the response content type header (see https://github.com/pgte/nock#specifying-reply-headers ) so that the client can parse the XML correctly.
@ssbrewster please reopen this if this doesn't work.

thanks @pgte I will try this out and let you know how I get on

All good see here http://stackoverflow.com/a/31293297/1230663


[🐞] v2 re-renders when attribute is removed

Which component is affected?
Qwik Runtime
Describe the bug
In v2 alpha 1, elements re-render the moment a data attribute is removed. This happens with any signal.
Reproduction
https://qwikdev-build-v2.qwik-8nx.pages.dev/playground/#f=Q0o0xoZYmyI6iNqXwlYJJCgyi8HVJbASskWYrJGWmFOcCnQS%2BY0XUACAWyaICrkaYjfcRj1gngWWxrYKimhCteCqXRdcc
Steps to reproduce

Check inspector tool
Click button
Click button again and see re-render

System Info
N/A

Additional Information
No response

I want doing this


Call deploy_cert() in hooks-file with alias

When defining a SAN-certificate in domains.txt it's possible to specify an alias. E.g.
foo.example.com bar.example.com > example.com

Unfortunately it's not possible to use the alias ("example.com" in this case) in the hooks-file.
Our use case is: In deploy_cert() we update the certificate in our loadbalancer. The only "name" I can use for referencing the certificate in the lb is DOMAIN. So I have no chance to name the certificate "le-cert-example.com" because the hooks-file does not know about the alias.
My workaround in deploy_cert() for the time being is
ALIAS=`/bin/echo -n "${KEYFILE}" | /usr/bin/awk -F "/" '{print $(NF-1)}'`

There should already be a variable alias (lowercase) exported to the hooks environment ;)

Your're right, thank you very much! Just found the commit for that: https://github.com/lukas2511/dehydrated/commit/b6b56d0df7af02a6d9f28255fc36d5aede7a2b38
Didn't find anything in the documentation, though. Is there a reason why it's not a parameter? Would be way more explicit, feels a bit "magical" this way.

It's not a parameter because I didn't want to change the syntax. Aliases were mostly designed for use with edge-cases on some wildcard certificates so they are not really a "first class feature".
Documentation needs a lot of work, there's a lot of things missing but I don't want to just throw everything in as it might result in more confusion. It's something I'm trying to work on but I didn't really find the time yet.

Sounds reasonable! :+1: Thank you very much for your great work!


Workflow re-work

** Changes in this branch depend on this landing/merging **
In a previous PR, I discussed the reasons for making these changes; After further review, some things were changed to streamline the process a bit more The original reasons for this change is here:
Work that remains to be done for this to work as expected:

the files that result from running 'arc liberate' inside the container should be committed to this repo and copied into their proper locations via the production Dockerfile.
mozphab/entrypoint.sh should have a section added to it to run the functional tests and this should be the default CMD for the :test container
a mozilla/phabext (or something clearly naming the production container) should be created and pushed to via circle.

thoughts? Apologies in advance if this is worded in 'ckolos-speak' and is not clear in the least.

@ckolos I made it work (including phutil files). Please take a look.
https://github.com/mozilla-conduit/phabricator-extensions/compare/ck/workflow-rework...zalun:workflow-rework?expand=1

@zalun - your changes lgtm (after changing the FROM of course).
Do you want me to merge your branch into mine for the PR?


ci: Fix coveralls report branch

Because the branch we use is origin/master and not master, the
coveralls report does not get reported to the main page of our
different repos. Basically the information on the badge is not
updated.
We have applied the same thing to our virtcontainers repo.
Fixes #697

Nice - thanks @sboeuf !


Please check all of the platforms you are having the issue on (if platform is not listed, it is not supported)

[ ] iOS
[ ] Android
[x] UWP
[ ] watchOS
[ ] tvOS
[ ] Tizen
[ ] .NET Standard

Feature Library

[ ] Core
[ ] BluetoothLE
[ ] Beacons
[ ] Locations
[ ] HTTP Transfers
[x] Notifications
[ ] Sensors

Version of Library
<PackageReference Include="Shiny.Notifications" Version="<IP_ADDRESS>0" />
Version of OS(s) listed above with issue
I think everywhere, but I don't know exactly.
Steps to Reproduce
I don't know exactly know why this is reported in the UWP partner center. App center doesn't report this one.
Expected Behavior
No errors are reported, I guess.
Actual Behavior
Following error is reported viaUWP partner center:
stowed_exception_system.exception_80070718_cloudmatic.uwp.dll!shiny::jobs::jobmanager.schedulenative

StackTrace:
0	System.Private.Interop.dll	System::Runtime::InteropServices::McgMarshal.ThrowOnExternalCallFailed	0x0000000000000021
1	CloudMatic.UWP.McgInterop.dll	__Interop::ComCallHelpers.Call	0x00000000000000BE
2	CloudMatic.UWP.McgInterop.dll	__Interop::ForwardComStubs.Stub_4_System.__Canon,_System.__Canon_	0x0000000000000037
3	Shiny.Core.dll	Shiny::Jobs::JobManager.ScheduleNative	0x00000000000001C7
4	Shiny.Core.dll	Shiny::Jobs::AbstractJobManager::_Schedule_d__25.MoveNext	0x000000000000004A
5	SharedLibrary.dll	System::Runtime::ExceptionServices::ExceptionDispatchInfo.Throw	0x0000000000000021
6	SharedLibrary.dll	System::Runtime::CompilerServices::TaskAwaiter.ThrowForNonSuccess	0x0000000000000070
7	SharedLibrary.dll	System::Runtime::CompilerServices::TaskAwaiter.HandleNonSuccessAndDebuggerNotification	0x0000000000000038
8	SharedLibrary.dll	System::Runtime::CompilerServices::TaskAwaiter.ValidateEnd	0x0000000000000017
9	SharedLibrary.dll	System::Runtime::CompilerServices::TaskAwaiter.GetResult	0x000000000000000B
10	Shiny.Core.dll	Shiny::JobExtensions::__c__DisplayClass1_0::__RegisterJob_b__0_d.MoveNext	0x00000000000000BE

The app and the notifications are working fine (for me in debug and release). I don't know if it's important for you, just wanted to let you know.
-- Eddy

I need something actionable and reproducible.  The above stack isn't giving me any details for something actionable


valueProp and labelProp in type select

I'm submitting a:
[ ] bug report => search github for a similar issue or PR before submitting
[X ] feature request
[ ] support request

Current behavior
valueProp and labelProp not work. In ng-formly work fine.
Expected behavior
I need map a json for select and it has not value and label elements...
Minimal reproduction of the problem with instructions
What is the motivation / use case for changing the behavior?
Now I map it without native formly
Please tell us about your environment:

Angular version: 2.0.1

Browser: [all | Chrome X | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Language: [all | TypeScript 7.0 | ES6/7 | ES5]

@jcga82 Can you look into this and make a PR. Would be appreciated.

I do not think I can but I'll try it.

You will have to make changes to this file https://github.com/formly-js/ng2-formly/blob/master/src/ui-bootstrap/types/select.ts


Add CI workflow for building the Linux AppImage executable.

This PR adds support for building the Linux AppImage binary during CI workflow.
Overview
The workflow file is .github/workflows/appimage.yml and is structured as follows:
Step 1: Checks if the docker container exists or needs to be updated, if not, go to Step 3.
Step 2: Builds the appimage/docker/Dockerfile  for compiling packetry and creating an appimage.
Step 3: Runs pretty much the same workflow as the rust.yml workflow to compile & test packetry inside the docker container.
Step 4: Invokes a custom action appimage/action.yml to build the Linux AppImage binary.
Step 5: Uploads the Linux AppImage binary artifact.
Docker Image Notes

Docker image has two args:

GTK_VERSION sets the version of GTK sources to be downloaded and built.
NODE_VERSION sets the version of node to install for the use of Swatinem/rust-cache@v2

I took great care to build the image with minimal use of USER root but it turns out that was wasted because
GitHub Actions does not support containers running as anything but root:

Worse than that, it overrides $HOME for the root user with /github/home which of course causes all the
things to fail.
But even more worse than that, if you have the bright idea to provide /github/home in your container, GitHub actions will happily delete the contents.
Workaround is a combo of overriding the containers /etc/passwd to change root home dir to /github/home during the container build and then copying everything you need into $HOME before running the workflow.
Also see: https://github.com/actions/checkout/issues/1014

Docker images are stored on ghcr.io and have private visibility.
Docker images are named & tagged according to <repo>-gtk-<gtk-version>:<branch> so we don't run into issues when working on branches or PR's.

Outstanding issues

[x] Licenses
[x] Configure ghcr.io access for the packetry repo.
[x] Desktop Icon File

Closes #117

Firstly, thank you for a great and gentle review @martinling! :-)

* `appimage/docker/files/etc/passwd`: presumably this is required because the Docker image needs an `/etc/passwd` for various tools to function, but there are a lot of what seem like extraneous lines here. Where did these come from, and do we really need all of them? Can we trim this down, or copy most of it from somewhere and just add what we need at build time?

So this is an excellent point. At the time of review this was pulled from the Docker image and modified before adding it to the repo but I've since updated the Dockerfile to just do an in-place edit of the /etc/passwd file.

* `appimage/packetry.AppDir/usr/share/doc/*/copyright`: These are presumably Debian `copyright` files - but from what set of package versions, and why those particular packages? I thought at first perhaps it was just `libgtk-4-1` and its dependencies, but `libharfbuzz-dev` is also included. And why are they committed to the Packetry repo, rather than just being copied from the versions used at build time?

This was the stickiest issue of all of them. The short version is that the AppImage linuxdeploy tool can only provide the licenses for packages that are installed on the system as the machine-readable Debian copyright format is not part of the source distribution. So basically, I had to get the gtk4 licenses from  upstream and add them as manual licenses.
I talk a bit more about our longer-term options in the maintenance notes.

  1. There is a lot of hand-written addition of `.so` symlinks here, using filenames of specific library versions. Can this be made less fragile? I would have thought that `ldconfig` with the right parameters could create the symlinks automatically, for instance.

The short version is that ldconfig is being a right royal pain in the posterior with the gtk4 libs so I just did it manually. That said, this has now been replaced by a small shell script that should spark more joy.

  2. There are hand-coded lists of library dependencies that aren't actually linked to in the current version. But code changes in Packetry or gtk-rs could easily cause some of these to start being linked in as we vary our usage of GTK. Is this something we can automate, with some scripting using `ldd` and `dpkg -S` perhaps?

So there are two kinds of lib here:

Libraries being pulled in even though we don't link to them. I've managed to eliminate all of these with some judicious surgery on installed system packages.
Libraries being pulled in that we do link to, but which we really don't want in there because they're going to break things if the runtime environment is using different versions. Normally we'd be excluding these explicitly via the linuxdeploy command line but the linuxdeploy-plugin-gtk messes with this somewhat.

That said, I think our newly streamlined list no longer has anything left in it that will cause problems if we change our usage of gtk4:
rm -f libX*
rm -f libblkid*
rm -f libbsd*
rm -f libpixman*
rm -f libxcb-render*
rm -f libzstd*

The answer to any or all of these things may be "these things are hardcoded because automating it is more faff than it's worth right now", and that's not unreasonable, but as it stands, if I were looking at needing to make a new release tomorrow without you, I wouldn't know what I needed to do.
So I think if we're not able to automate these details, then we at least need a bit of documentation in the repo that explains how the AppImage build process works, what steps may be needed to update it, and when and how those steps need to be done.

Fair point! I've added some docs to the directory that should help: appimage/README.md
In the longer run, when there's a bit more faff available I would like to work on two things:

Come up with a solution for the gtk4 licenses that won't require us to track upstream license changes.
Deprecate our use of linuxdeploy-plugin-gtk in favour of a homebrewed solution.

appimage/docker/files/etc/passwd

So this is an excellent point. At the time of review this was pulled from the Docker image and modified before adding it to the repo but I've since updated the Dockerfile to just do an in-place edit of the /etc/passwd file.

Great, that's a lot tidier!

appimage/packetry.AppDir/usr/share/doc/*/copyright

This was the stickiest issue of all of them. The short version is that the AppImage linuxdeploy tool can only provide the licenses for packages that are installed on the system as the machine-readable Debian copyright format is not part of the source distribution. So basically, I had to get the gtk4 licenses from upstream and add them as manual licenses.
I talk a bit more about our longer-term options in the maintenance notes.

I'm not sure if I'm understanding correctly.
We build GTK4 from source rather than having libgtk-4-1 installed on buster, so we can't just grab /usr/share/doc/libgtk-4-1/copyright, I get that. But we're not building GTK's dependencies from source. So can't we just copy the copyright files from the buster system into the AppDir, for all of:

libgdk-pixbuf-2.0-0
libglib2.0-0
libgraphene-1.0-0
libpango-1.0-0
libpangocairo-1.0-0
libpangoft2-1.0-0

Or are we bundling newer versions of those libraries, from a later distro version, when we actually build the AppImage? And if so... how do we know what versions those are, and how do we know whether we still have the correct corresponding license and copyright info for them? As far as I can see, we can't tell.
I'm fine with using the buster versions, because that distro is no longer getting updates, and I'm fine with the GTK4 version, because the version used for that is explicitly set in the build scripts.
But if anything else is ending up in the AppImage, then that's a moving target which can become out of sync with what we have in the Packetry repo, at any time, and without any warning.

The short version is that ldconfig is being a right royal pain in the posterior with the gtk4 libs so I just did it manually. That said, this has now been replaced by a small shell script that should spark more joy.

Joy is duly sparked, thank you.

So there are two kinds of lib here:

Libraries being pulled in even though we don't link to them. I've managed to eliminate all of these with some judicious surgery on installed system packages.

Why are these pulled in at all? Is this due to the difference in dependencies between the minimal GTK we build from source, and that of the distro packages?

Libraries being pulled in that we do link to, but which we really don't want in there because they're going to break things if the runtime environment is using different versions. Normally we'd be excluding these explicitly via the linuxdeploy command line but the linuxdeploy-plugin-gtk messes with this somewhat.

These are supposed to be dealt with by the AppImage excludelist, aren't they?

That said, I think our newly streamlined list no longer has anything left in it that will cause problems if we change our usage of gtk4:
rm -f libX*
rm -f libblkid*
rm -f libbsd*
rm -f libpixman*
rm -f libxcb-render*
rm -f libzstd*

I'm fine with hardcoding this list if all of our dependencies are hardcoded to fixed versions, and if CI will fail in some way if we get out of sync. Is that the case, though?

Fair point! I've added some docs to the directory that should help: appimage/README.md

These are very helpful, thank you! I think I'm still not fully understanding though, as is probably clear from the above.

In the longer run, when there's a bit more faff available I would like to work on two things:

Come up with a solution for the gtk4 licenses that won't require us to track upstream license changes.

I'm fine with tracking upstream license changes by hand, if we're also updating dependency versions by hand.
But if we're going to have a situation where the binaries can get out of sync with the license/copyright text, just because a distro shipped new packages and the CI picked them up, that's not really OK.

Deprecate our use of linuxdeploy-plugin-gtk in favour of a homebrewed solution.

Is the original beyond improvement?

I'm not sure if I'm understanding correctly.
We build GTK4 from source rather than having libgtk-4-1 installed on buster, so we can't just grab /usr/share/doc/libgtk-4-1/copyright, I get that. But we're not building GTK's dependencies from source. So can't we just copy the copyright files from the buster system into the AppDir, for all of:
* libgdk-pixbuf-2.0-0

* libglib2.0-0

* libgraphene-1.0-0

* libpango-1.0-0

* libpangocairo-1.0-0

* libpangoft2-1.0-0

Or are we bundling newer versions of those libraries, from a later distro version, when we actually build the AppImage?

Ah, now I understand the confusion.
So all of those are generated by the gtk4 build. This means they will always correspond to the release version of the sources we're compiling.
This confused the hell out of me as well because at one point we were pulling libharfbuzz from the buster packages because it got pulled in by some other utterly random dependency that we also didn't need but the gtk build scripts die if it's not there.
This was causing a whole bunch of other stuff to not be built from gtk4 sources and then getting pulled into the AppImage from buster that should have been supplied by the sources.
So to answer your first question:

And if so... how do we know what versions those are, and how do we know whether we still have the correct corresponding license and copyright info for them? As far as I can see, we can't tell.

We're only extracting and copying the copyright file from the upstream .deb files. They have nothing to do with the build process except for the hour I spent copying them into the git repo and will only need to be checked for updates if we switch to a newer gtk4 source release.
This is why I think we're okay with the current approach.

But if anything else is ending up in the AppImage, then that's a moving target which can become out of sync with what we have in the Packetry repo, at any time, and without any warning.

Nope, nothing else from upstream ending up in the AppImage except the copyright files.
So I reckon we're good?

Libraries being pulled in that we do link to, but which we really don't want in there because they're going to break things if the runtime environment is using different versions. Normally we'd be excluding these explicitly via the linuxdeploy command line but the linuxdeploy-plugin-gtk messes with this somewhat.

These are supposed to be dealt with by the AppImage excludelist, aren't they?

Yeah exactly that, in a non linuxdeploy* workflow we'd be doing something like that.

That said, I think our newly streamlined list no longer has anything left in it that will cause problems if we change our usage of gtk4:
rm -f libX*
rm -f libblkid*
rm -f libbsd*
rm -f libpixman*
rm -f libxcb-render*
rm -f libzstd*

I'm fine with hardcoding this list if all of our dependencies are hardcoded to fixed versions, and if CI will fail in some way if we get out of sync. Is that the case, though?

All dependencies are hardcoded to fixed versions.
Unless we change:
a) the gtk release version we're building from or
b) the base image we're using for the Dockerfile
…it will keep running until the day that CI breaks because our gtk4 release is too old to compile packetry anymore. 🫠

I'm fine with tracking upstream license changes by hand, if we're also updating dependency versions by hand.

👌

But if we're going to have a situation where the binaries can get out of sync with the license/copyright text, just because a distro shipped new packages and the CI picked them up, that's not really OK.

💯

Deprecate our use of linuxdeploy-plugin-gtk in favour of a homebrewed solution.

Is the original beyond improvement?

It's more a case of what I'd like it (and in some cases linuxdeploy) to not do.
Having now spent a couple of weeks working with them both I think there's a strong case to be made for keeping the tool surface area as narrow as possible. Both those tools are (understandably) making very broad assumptions that we then have to undo as part of our workflow.
It would probably be a lot cleaner and more maintenance-friendly in the long run to just generate packetry.AppDir ourselves. Then have appimagetool generate the final redistributable. But that's another conversation for another day…

Ahh, OK! I hadn't realised that the GTK4 tarball build would pull those other projects in directly.
Please add something about this to the docs! 😄

Done 😆

...and that the action.yml part must be implicit, but I'd missed that on my first pass through. So a comment at that spot explaining that the action definition can be found in appimage/action.yml would be helpful.

Done, good call!


BUG Fix incorrect BASE_DIR inferred in CLI

Also fixes Director::mockRequest() mocking incorrect $url
Fixes #7689

I'd prefer this to go into the 4 branch given the new API and people suffering from this issue can fix it locally by defining SS_BASE_URL as they should be.

Sounds good.

I think those linting issues are from the updates to codestyle checker. I'll fix. :)

Rebased and pushed.


React Native NfcManager.isSupported() returns false

I have installed 'react-native-nfc-manager' package, and have followed all the installation instructions, I have no errors, except that when I run the code below, it returns false.
let isSupported = await NfcManager.isSupported();
console.log('isSupported:', isSupported);
I didn't find any answer on Stackoverflow about this issue and neither on Github, I hope to get a response.

@ShiriNmi1520 thanks for the reply, I am testing it on Samsung Galaxy A30. I still didn't test it on a iOS device.

@arbnorhaxhiu94 According to this spec, Samsung Galaxy A30 seems don't have the NFC features, did you got another device that is available to test?

@ShiriNmi1520 Thank you.

@ShiriNmi1520 Thank you. I tried it on another device, it worked. Seems like all the phones older than 2020 do not support nfc.

Glad to help :)


feature: check if copilot is authorised before trying to initialize

Feature request
I only have copilot on some machines, so it would be good to check if copilot is available and print a small warning, instead of producing this intrusive message.

Motivation
No response
Other
No response

not sure what is intrusive about this, we have stated in the README.md for copilot backend to either have copilot.vim or copilot.lua setup for auth.
Therefore, I don't think there is anything wrong with raising an error here


Automate quick-start in setup.sh and teardown.sh

@F21 My apologies that your comments are gone because I messed up my previous pull request. Anyway, I increase timeout of Vault being deploying and being running to 5 minutes and 10 seconds respectively. Please give it a try.

hey @JulianWei
Thanks for the updates! I just tried the setup script, but it still exits in 5 seconds while waiting for the Vault pod to be started.
Other than that, it looks great!

@JulianWei Thanks for your work on the script. I've carried your work into #38.


Improve logging

Update all strings to start with a capital
Update all strings not to end with a dot
Re-order daemon startup a bit to always end with binding TCP
Clarify some errors

Signed-off-by: Stéphane Graber<EMAIL_ADDRESS>

:+1: for the second :-)


fix broken links

The fix is of three links on the page recorded in the first column in the pic in the ticket.

There were broken, found out when I ran yarn lint:dead

Yes, there are three broken links that you fixed by creating dummy pages for. That is not necessary.
The changelog links you fixed aren't broken, for example: https://era.zksync.io/docs/api/js/getting-started.html try it.

Yes, there are three broken links that you fixed by creating dummy pages for. That is not necessary.
The changelog links you fixed aren't broken, for example: https://era.zksync.io/docs/api/js/getting-started.html try it.

Totally agree the pages ain't necessary, I did a redirect instead(happy to know your thoughts on this). However, when we do have all the SDK revamped we should add a README.md file in them just like the others.

It doesn't look broken on prod, but it does on local, it just makes sense to link properly, the ENV(local, staging, or prod notwithstanding). yeah?

Yes, there are three broken links that you fixed by creating dummy pages for. That is not necessary.
The changelog links you fixed aren't broken, for example: https://era.zksync.io/docs/api/js/getting-started.html try it.

Totally agree the pages ain't necessary, I did a redirect instead(happy to know your thoughts on this). However, when we do have all the SDK revamped we should add a README.md file in them just like the others.

I'm not convinced a README page with nothing on it but a manual toc which we have to remember to keep up to date is a good idea.

It doesn't look broken on prod, but it does on local, it just makes sense to link properly, the ENV(local, staging, or prod notwithstanding). yeah?

I don't have the issue locally. Have you got the latest updates?


[Bug]: report link seems not working and is redirected to the template page

Prerequisites

[X] I have written a descriptive issue title.
[X] I have searched all issues/PRs to ensure it has not already been reported or fixed.
[X] I have verified that I am using the latest version of Scoop and corresponding bucket.

Package Name
scoop
Expected/Current Behaviour
When installing/updating an app and the hash doesn't match, usually, at the end of the log, a link will be shown with formatted title to report:
https://github.com/ScoopInstaller/Extras/issues/new?title=cpu-z%402.03%3a+hash+check+failed
It should bring me to a new issue page and fill the title for me, but now this link is redirected to the template page:
https://github.com/ScoopInstaller/Extras/issues/new/choose
Steps to Reproduce
NA

Possible Solution
NA
Scoop and Buckets Version
NA

Scoop Config
NA

PowerShell Version
NA

Additional Softwares
I confirmed this on Chrome 107.0.5304.107 (Official Build) (64-bit) (incognito, no extensions) and MS Edge Version 107.0.1418.56 (Official build) (64-bit)

@ScoopInstaller this should be moved to the https://github.com/ScoopInstaller/Scoop repostitory.


[IMPROVEMENT] Improve backupstore volume and backup list by event notifications

Is your improvement request related to a feature? Please describe
The volumes and backups are periodically listed, compared with the backupVolume and backup resources and updated the associated resources. Most s3 vendors provide event notidifcations (e.g. aws s3). longhorn can just update the resources after receiving the object creation and deletion notifications from the s3 service. The event notification mechanism can make the update process more efficient and also reduce costs. For the NFS or other filesystem-based backup targets, longhorn can fall back to the current method.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Tracked by https://github.com/longhorn/longhorn/issues/8368


Not ready for review: feature: trestle import

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.
[x] All commits are signed.

Current draft PR for trestle import - this is currently in review.
Note that I've picked up a few small fixes along the way with this PR. I should split this out separately however it also relates to
#204
#203

Segregated into different pull requests.


Auto-populate hub template variables

Removes need to manually 'refresh' hub variables
after each deploy of the dashboard

/cc @minrk

Nice! I'm getting 403 on the api("/datasources") request. Is this perhaps not in the Editor role?

@minrk yeah, I don't think editors can do things to datasources. I'll document that we need admin role?

Yeah, that makes sense. It'd be nice to not need it, so maybe a comment indicating which step requires the admin role in case we find another way to achieve the goalo?

@minrk done!

This is rad! Only improvement I can think of is to set the initial value as the first item in the list, if that's possible. As it is now, the dashboard starts with a bunch of "No data" since the variable is empty.


EOF error while reading interfaceIndices

System.IO.EndOfStreamException: Unable to read beyond the end of the stream.
  at System.IO.MemoryStream.InternalReadInt32 () [0x00032]
    in <a17fa1457c5d44f2885ac746c1764ea5>:0
  at (wrapper remoting-invoke-with-check) System.IO.MemoryStream.InternalReadInt32()
  at System.IO.BinaryReader.ReadInt32 () [0x00015]
    in <a17fa1457c5d44f2885ac746c1764ea5>:0
  at Il2CppDumper.BinaryStream.ReadInt32 () [0x00000]
    in [...]/Il2CppDumper-YuanShen/Il2CppDumper/IO/BinaryStream.cs:42
  at Il2CppDumper.BinaryStream.ReadPrimitive (System.Type type) [0x000fc]
    in [...]/Il2CppDumper-YuanShen/Il2CppDumper/IO/BinaryStream.cs:109
  at Il2CppDumper.BinaryStream.ReadClass[T] () [0x00017]
    in [...]/Il2CppDumper-YuanShen/Il2CppDumper/IO/BinaryStream.cs:142
  at Il2CppDumper.BinaryStream.ReadClassArray[T] (System.Int64 count) [0x0000e]
    in [...]/Il2CppDumper-YuanShen/Il2CppDumper/IO/BinaryStream.cs:201
  at Il2CppDumper.BinaryStream.ReadClassArray[T] (System.UInt64 addr, System.Int64 count) [0x00009]
    in [...]/Il2CppDumper-YuanShen/Il2CppDumper/IO/BinaryStream.cs:209
  at Il2CppDumper.Metadata..ctor (System.IO.Stream stream) [0x001ab]
    in [...]/Il2CppDumper-YuanShen/Il2CppDumper/Il2Cpp/Metadata.cs:87
  at Il2CppDumper.Program.Init (System.String il2cppPath, System.String metadataPath, Il2CppDumper.Metadata& metadata, Il2CppDumper.Il2Cpp& il2Cpp) [0x00013]
    in [...]/Il2CppDumper-YuanShen/Il2CppDumper/Program.cs:122
  at Il2CppDumper.Program.Main (System.String[] args) [0x001d6]
    in [...]/Il2CppDumper-YuanShen/Il2CppDumper/Program.cs:97

A breakpoint at line 87 (Metadata.cs) shows that header.interfacesOffset is at 188555283 (0xB3D2013).
Game version: 1.1.0 (timestamp 2020-11-03)

not tested for version 1.1 please do change offsets by yourself, also make sure the input global-metadata is decrypted.


Move bytecode translation tests to engine module

BENCHMARKS
   NATIVEWASMTIME   BENCHMARKMASTERPRDIFFMASTERPRDIFFWASMTIME OVERHEAD    execute/count_until  2.14ms  2.16ms  :white_circle: 0.17%  9.80ms  9.65ms  :green_circle: -1.35%  :red_circle: 346%execute/factorial_iterative  1.67µs  1.66µs  :white_circle: -0.01%  3.34µs  3.32µs  :white_circle: -0.39%  :yellow_circle: 99%execute/factorial_recursive  2.16µs  2.15µs  :white_circle: -0.29%  4.17µs  4.17µs  :white_circle: -0.03%  :yellow_circle: 94%execute/fib_iterative  10.06ms  10.05ms  :white_circle: -0.13%  15.52ms  15.53ms  :white_circle: -0.05%  :yellow_circle: 55%execute/fib_recursive  19.07ms  19.23ms  :white_circle: 1.58%  38.62ms  38.68ms  :white_circle: 0.23%  :red_circle: 101%execute/global_bump  3.66ms  3.66ms  :white_circle: 0.02%  13.41ms  13.36ms  :white_circle: -0.46%  :red_circle: 265%execute/host_calls  32.92µs  33.17µs  :white_circle: 0.65%  107.87µs  106.70µs  :white_circle: -0.86%  :red_circle: 222%execute/memory_fill  8.63ms  8.60ms  :white_circle: -0.22%  14.79ms  14.81ms  :white_circle: 0.21%  :yellow_circle: 72%execute/memory_sum  7.82ms  7.81ms  :white_circle: -0.12%  14.96ms  14.99ms  :white_circle: 0.26%  :yellow_circle: 92%execute/memory_vec_add  15.19ms  15.14ms  :white_circle: -0.12%  30.37ms  30.33ms  :white_circle: 0.00%  :yellow_circle: 100%execute/recursive_is_even  2.87ms  2.82ms  :green_circle: -1.78%  6.61ms  6.62ms  :white_circle: 0.23%  :red_circle: 135%execute/recursive_ok  423.09µs  426.98µs  :white_circle: 1.08%  917.32µs  912.71µs  :white_circle: -0.54%  :red_circle: 114%execute/recursive_scan  497.97µs  489.51µs  :white_circle: -0.65%  1.30ms  1.30ms  :white_circle: -0.06%  :red_circle: 166%execute/recursive_trap  43.05µs  45.33µs  :red_circle: 5.02%  97.29µs  97.28µs  :white_circle: 0.05%  :red_circle: 115%execute/regex_redux  3.44ms  3.43ms  :white_circle: -0.08%  5.08ms  5.11ms  :white_circle: 0.72%  :green_circle: 49%execute/rev_complement  3.08ms  3.13ms  :red_circle: 1.90%  4.94ms  4.93ms  :white_circle: 0.03%  :yellow_circle: 57%execute/tiny_keccak  2.64ms  2.64ms  :white_circle: -0.24%  4.15ms  4.16ms  :white_circle: 0.16%  :yellow_circle: 58%execute/trunc_f2i  3.61ms  3.60ms  :white_circle: -0.41%  9.11ms  9.11ms  :white_circle: 0.12%  :red_circle: 153%instantiate/wasm_kernel  77.43µs  77.62µs  :white_circle: 0.54%  135.82µs  104.03µs  :green_circle: -23.56%  :green_circle: 34%translate/wasm_kernel  6.05ms  6.04ms  :white_circle: -0.05%  12.32ms  12.03ms  :green_circle: -2.30%  :yellow_circle: 99%
Link to pipeline

Codecov Report

Merging #503 (f72e5e2) into master (3b6f220) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #503   +/-   ##
=======================================
  Coverage   79.23%   79.23%
=======================================
  Files          74       74
  Lines        6313     6313
=======================================
  Hits         5002     5002
  Misses       1311     1311

Impacted Files
Coverage Δ

crates/wasmi/src/engine/mod.rs
80.58% <ø> (ø)

crates/wasmi/src/engine/tests.rs
98.66% <ø> (ø)

crates/wasmi/src/module/mod.rs
82.40% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Update model names

Generates the libraries after adding model names to our OpenAPI spec
here: https://github.com/mxenabled/openapi/pull/43

:shipit:


Apply the security context to the post install job (fixes #25)

one thing that I've been doing is to also add
serviceAccountName:
if securityContext is enabled.
I get what I am doing can be a bit misleading because defining a serviceAccount is not strictly related to securityContext, but it's related to how PSPs are being used. I wonder if I should extract out the serviceAccountName from the if block and set it to default by default. what are your thoughts on that?

Yeah that's a good point. I think we should pull out the service account and make it configurable, setting it to default in the values.yaml. Can you create an issue on this repo to do that as its own change?


Can do set thumbnail when upload video ?

I don't find any document about set thumbnail when upload video.
If have document or code about that, please provide it or show for me.
Thanks so much.

The thumbnail is automatically generated from the video file. The Google Photos Library API does not support setting a custom thumbnail for a video.
You could file a feature request for the API, outlining your exact use case and how you would like to use it. More details here: https://developers.google.com/photos/library/support/how-to-get-help#bugs-feature


UX Study feedback

All questions/concerns/changes raised during the UX study have been documented as an issue. Also, most of them have been addressed for P2.
I'm going to close this issue and keep updating the individual ones.


Update .codecov.yml

Pull Request Test Coverage Report for Build 566

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 67.081%

Totals

Change from base Build 560:
0.0%

Covered Lines:
1186

Relevant Lines:
1768

💛  - Coveralls


Re-implement graphical display of database search results

Rewrite https://github.com/labstructbioinf/pLM-BLAST/blob/main/scripts/plot.py and integrate with the current version.

The plot.py script seems to be broken for me:
$ python $PLMBLAST_PATH/scripts/plot.py output.csv query.fasta plot.png -mode score -ecod Traceback (most recent call last):   File "/home/bin/pLM-BLAST/scripts/plot.py", line 82, in <module>     query_seq = query_df.loc[qid].sequence   File "/home/resources/conda_envs/env_dirs/plmblast/lib/python3.10/site-packages/pandas/core/indexing.py", line 1103, in __getitem__     return self._getitem_axis(maybe_callable, axis=axis)   File "/home/resources/conda_envs/env_dirs/plmblast/lib/python3.10/site-packages/pandas/core/indexing.py", line 1343, in _getitem_axis     return self._get_label(key, axis=axis)   File "/home/resources/conda_envs/env_dirs/plmblast/lib/python3.10/site-packages/pandas/core/indexing.py", line 1293, in _get_label     return self.obj.xs(label, axis=axis)   File "/home/resources/conda_envs/env_dirs/plmblast/lib/python3.10/site-packages/pandas/core/generic.py", line 4095, in xs     loc = index.get_loc(key)   File "/home/resources/conda_envs/env_dirs/plmblast/lib/python3.10/site-packages/pandas/core/indexes/range.py", line 349, in get_loc     raise KeyError(key) KeyError: 'g001590.m1_alloascoidea_hylecoeti'

@DaRinker Thank you for providing the sample data. The issue should now be resolved.


Change view height during scroll

Hello.
I have two views. One is ImageView and the other is ObservableListView. Both wrapper in group view:
<android.support.v4.widget.SwipeRefreshLayout
    android:id="@+id/refresh"
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="org.antczak.whereIsMyPackage.activity.DetailsActivity">

    <RelativeLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="vertical">

        <ImageView
            android:id="@+id/infos"
            android:src="@drawable/bamboo"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:scaleType="centerCrop"/>

        <com.github.ksoichiro.android.observablescrollview.ObservableListView
            android:id="@+id/scroll"
            android:layout_below="@id/infos"
            android:layout_width="match_parent"
            android:layout_height="fill_parent"/>

    </RelativeLayout>
</android.support.v4.widget.SwipeRefreshLayout>

What I want to achieve is to gradually hide image during list scrolling. Using ViewHelper.setTranslationY I'm able to slide up image, but it's container is still there.
I want the list to fill space which image released.
Now it looks like one screenshot
How to reduce image container height during scroll?

Sorry for my late reply.
Have you solved your issue?
I think one of the following might solve your issue...

Resize ListView on onScrollChanged

Like this: listView.getLayoutParams().height = xxx; listView.requestLayout();
But this might cause bad scrolling animation

Set transparent padding view as the header to the ListView

Like FlexibleSpaceWithImageListViewActivity (in the sample app) does

I could only achieve to make the listView scroll along with imageView. But it maintains its height, causing blank space on bottom.


No overlays. I tried 6.1, 6.0, and 5.1

Describe the bug
Autoortho does not generate an overlay folder in the custom scenery folder, and does not place overlay folder in the ini file either. Here is a screenshot of the folder.
Screenshots

(please complete the following information):

OS: Windows 10
XPlane Version:XP12.07
AutoOrtho Version 6.1, 6.0, 5.1
Filesystem type NTFS

I don't know if there is a problem with the pack installer but as a workaround you can download the overlays from here directly:
https://github.com/kubilus1/autoortho-scenery/releases

I tested right quick to see if there is an issue with the server or install process. It worked great. I didn't need to copy anything.
I keep my scenery on a remote drive normally but for this exercise I deleted all my symlinks and installed Australia on my main XP drive, in Custom Scenery as a standard installation. Using v0.5.1-3.
It should work fine as long as you 1. Run AO executable as administrator. and 2. You specify your target folder correctly i.e. "z:\X-Plane 12\Custom Scenery" not just "z:\X-Plane 12".
Noticed that when I browsed for the folder, I had to be careful to select the right folder, as it doesn't act like a native Windows select, it grabs whatever is under the mouse so I mouse to Custom Scenery and drag off, if that makes sense. Maybe that's what happened to you. BTW I used the installer in v0.7.0 a few days ago to iinstall the data for Australia on my remote drive and it worked fine too.
OS: Windows 10
XPlane Version:XP12.07
AutoOrtho Version 0.5.1.-3, 0.6.0, 0.6.1, 0.7.0
Filesystem type NTFS

DL speed ws 17MB/s here

And AO does not add the entry in the scenery_packs.ini file either. That's up to you to organize.


How to set the height of row?

In my case, the rows of calendar is too short.
Is there any way to change the height of rows in calendar as longer?
(the height of collection view cell size)

The row height is automatically calculated based on the whole size of calendar. You can make height of whole calendar longer, then the row height would be longer.

@WenchaoD Thx :D


There is no microsoft/caslogcollector image on Docker Hub

Guys, this makes the whole idea of Docker deployment impossible.

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

ID: e21ac1e4-295d-74f4-8217-087203c54bb7
Version Independent ID: 229ddf62-fd89-8e05-a55a-6a894a57c13a
Content: Configure automatic log upload for continuous reports
Content Source: CloudAppSecurityDocs/discovery-docker-ubuntu.md
Service: cloud-app-security
GitHub Login: @rkarlin
Microsoft Alias: rkarlin

I have found some these lines from MCASInstallDocker.sh:
docker login -u caslogcollector -p C0llector3nthusiast > /dev/null 2>&1 || exit_on_error "Login to hub failed" docker pull microsoft/caslogcollector 2>/dev/null || exit_on_error "Failed pulling latest collector image"
I assume that image either should be made public or at least the article should get some explanation.

Hi @OrdinaryGuy, please open a support ticket so that we can help you with this. Thanks!

@OrdinaryGuy I had issue loading the files for an Ubuntu 16.04

Any chance to get more details on this?

Hi,
thanks for your feedback. This is a great place to provide feedback on the documentation for Cloud App Security. For issues using the Docker, please open a support ticket.
thanks for reaching out!

Hello,
Could this docker image run on windows server 2012 r2 with docker engine installed or Windows server 2016?
Regards

Hi @mmendozaf
Please contact the product team at<EMAIL_ADDRESS>thanks,
Rachel


Update all references to 'Redis' in titles with 'Choreo-managed Caches/Caching'

Purpose
$title - due to Redis licensing changes.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


App always refreshes feed at start despite "manually" is selected

As the title says.
I explicitly chose the manual refresh method, so the app should only catch feeds whenever I pull down the list.
App version 2024.07.1009

hey @HarriBuh - let me take a look. When I added "Manually," my intention was to include "On Start" as well. I'll see what I can do to split out these two conditions.

"Manually only" now skips the on-start refresh in the latest release.


Make it build with ghc-9.6

Co-Authored: Nadia Yvette Chambers<EMAIL_ADDRESS>Description
Make it build with ghc-9.6
Checklist

[ ] Commit sequence broadly makes sense and commits have useful messages
[ ] New tests are added if needed and existing tests are updated.  These may include:

golden tests
property tests
roundtrip tests
integration tests
See Runnings tests for more details

[ ] Any changes are noted in the CHANGELOG.md for affected package
[ ] The version bounds in .cabal files are updated
[ ] CI passes. See note on CI.  The following CI checks are required:

[ ] Code is linted with hlint.  See .github/workflows/check-hlint.yml to get the hlint version
[ ] Code is formatted with stylish-haskell.  See .github/workflows/stylish-haskell.yml to get the stylish-haskell version
[ ] Code builds on Linux, MacOS and Windows for ghc-8.10.7 and ghc-9.2.7

[x] Self-reviewed the diff

Note on CI
If your PR is from a fork, the necessary CI jobs won't trigger automatically for security reasons.
You will need to get someone with write privileges.  Please contact IOG node developers to do this
for you.

This is needed for the nix builds to use ghc-9.6.x:

diff --git a/nix/haskell.nix b/nix/haskell.nix
index b4707a328..523d9bb16 100644
--- a/nix/haskell.nix
+++ b/nix/haskell.nix
@@ -20,9 +20,9 @@ let
     {
       src = ../.;
       name = "cardano-node";
-      compiler-nix-name = lib.mkDefault "ghc8107";
+      compiler-nix-name = lib.mkDefault "ghc96";
       # extra-compilers
-      flake.variants = lib.genAttrs ["ghc927"] (x: {compiler-nix-name = x;});
+      flake.variants = lib.genAttrs ["ghc8107" "ghc927"] (x: {compiler-nix-name = x;});
       cabalProjectLocal = ''
         repository cardano-haskell-packages-local
           url: file:${CHaP}

I'm working on fixing this error to send upstream to you:
`[nyc@nyc-laptop]~/src/cardano-node% nice -19 nix build '.#cardano-node'
error:
… while evaluating the attribute 'packages'
     at /nix/store/cp6ni03d3832sglwim4mw8a9k4pqvfwk-source/flake.nix:376:11:

      375|
      376|           packages = packages // {
         |           ^
      377|             # Built by `nix build .`

   … in the left operand of the update (//) operator

     at /nix/store/cp6ni03d3832sglwim4mw8a9k4pqvfwk-source/flake.nix:376:31:

      375|
      376|           packages = packages // {
         |                               ^
      377|             # Built by `nix build .`

   (stack trace truncated; use '--show-trace' to show the full trace)

   error: builder for '/nix/store/d7j0id6qdclfpjvzjidyx9l20ngr9ym2-cardano-node-plan-to-nix-pkgs.drv' failed with exit code 1;
   last 10 log lines:
   > template-haskell-<IP_ADDRESS>, template-haskell-<IP_ADDRESS>, template-haskell-<IP_ADDRESS>,
   > template-haskell-<IP_ADDRESS>, template-haskell-<IP_ADDRESS> (constraint from
   > non-upgradeable package requires installed instance)
   > [__8] fail (backjumping, conflict set: template-haskell, threepenny-gui)
   > After searching the rest of the dependency tree exhaustively, these were the
   > goals I've had most trouble fulfilling: snap-server, snap-core,
   > template-haskell, threepenny-gui, network, websockets-snap, cardano-tracer,
   > base, network-mux, cardano-client-demo, ouroboros-network-protocols
   > Try running with --minimize-conflict-set to improve the error message.
   > )
   For full logs, run 'nix log /nix/store/d7j0id6qdclfpjvzjidyx9l20ngr9ym2-cardano-node-plan-to-nix-pkgs.drv'.

[`


Thumbnail

Fixes #250
Bonus: dev version of publishLandingPage

Not sure if there's a better way to get the thumbnails on the unpublished viz's, but it's a step in the right direction

Changes Unknown when pulling 7da50bd782f2eaad0dd6cf6028b137a2d72ca4f4 on ldecicco-USGS:thumbnail into ** on USGS-VIZLAB:master**.

Changes Unknown when pulling a39098b971a17e4f8055b689fac8ff8c20c884ef on ldecicco-USGS:thumbnail into ** on USGS-VIZLAB:master**.

Changes Unknown when pulling 0fafc65578e5a0832599ef0e403f17188a8befe4 on ldecicco-USGS:thumbnail into ** on USGS-VIZLAB:master**.


[breaking] render raw response when unexpected error occurs in endpoint

..instead of failing completely. Also catch possible fetch error (which would occur when network fails).
Closes #4801
There are still some code paths which would bubble up to the handler, but these are of the kind "you use a wrong SvelteKit option" or during prerendering ("cannot use mutative methods .."). The other all look like they have a try-catch around code paths where errors could occur.
Not sure if a test is needed here. We could theoretically do one for the endpoint error.
This is a breaking change insofar as people could have relied on this behavior somehow.
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

I've seen people asking to have their API endpoints return JSON when failing. I'm not sure we necessarily need to address that now, but thought I'd mention it since this seems like it could return HTML errors more often


Implement all optional dependencies as setup tools extras

Proposed Changes
Throughout the documentation there are many places to pip3 install foo such as napalm, django-storages, etc...
I would like to implement these as extras instead, for example to install nautobot w/ napalm:
pip3 install nautobot[napalm]

or for SSO dependencies (just examples):
pip install nautobot[sso]
pip install nautobot[sso,oidc]
pip install nautobot[sso,saml]
pip install nautobot[ldap]

or to install Nautobot with ALL optional dependencies
pip3 install nautobot[all]

Justification
This simplifies the installation and reduces the need for additional pip3 install commands for common cases and also allows us to certify vetted versions of those optional dependent libraries.

Actually adding these to the package is pretty straightforward, but we'll need to think about how to incorporate this into the installation and (especially) upgrade workflow. install.sh is still our recommended upgrade workflow, but it currently doesn't take any inputs that would allow the user to specify extras to include in the pip3 install nautobot command; it does look for and use the local_requirements.txt file though.

I believe this is addressed by #1073?

This has been done for some time:
https://github.com/nautobot/nautobot/blob/51bf0f1cba6c842b58f19fecf81552a9816dc28a/pyproject.toml#L145-L155


Fixed #34917 -- Underlined Links in Django Admin.

Trac ticket number

ticket-34917
Branch description
Continue @Myrausman's PR
Add underline to "a" tags outside the "main content area" in the Django admin.
Checklist

[ ] This PR targets the main branch.
[ ] The commit message is written in past tense, mentions the ticket number, and ends with a period.
[ ] I have checked the "Has patch" ticket flag in the Trac system.
[ ] I have added or updated relevant tests.
[ ] I have added or updated relevant docs, including release notes if applicable.
[ ] I have attached screenshots in both light and dark modes for any UI changes.

I looking for the "a" tags used outside the "main content area."

I tried adding underlines to a tags in a way that minimizes impact on areas outside the "main content area." I'm now considering how to apply underlines to places like logout or delete pages that don't have specific class or id in their structure. Could you provide any advice on this?


Triggering Chromium Arguments

Hi,
I'm developing a desktop app for windows 7 and I'm compiling the app with Chromium Args set to --enable-file-cookies
However, when running the app in windows 7 chromium seems to not have started with the argument options as inspector shows that the option is still disabled.
the package.json has the option so I'm not sure what is the problem here

I don't think that option exists for chromium (which is what NW.js uses). The full list of chromium args is here. I did a Ctrl-F to find "cookies" but no option containing that word could be found.
It looks like that flag was removed a little while ago

This may help you https://github.com/nwjs/nw.js/wiki/Window#windowcookies if desired you could store info in any preferred way then use remove and set as desired.

I was wondering as one article says that chrome removed it...however another article was saying that it was simply disabled by default leaving us with the option to enable it if necessary

@karneaud Did our information help you? I'm closing this issue, but feel free to open it again if you have any related problems.


Is it possible to return the image itself after successfully scanning a barcode?

yes, this is possible, you can see this in action and find the needed javascript at example:
https://serratus.github.io/quaggaJS/examples/live_w_locator.html


Unable to use Jquery UI Autocomplete in divi custom module

Problem Description
Hi, I have created a custom divi builder module and I want to use Jquery UI auto complete in it. When i use Jquery Auto complete code, it is giving me this error:
Uncaught TypeError: $(...).autocomplete is not a function
Can you guide me how to include jquery ui script in my custom divi builder module?
Steps To Reproduce

Screenshot and/or gif

@umnex
Well, it might not be easy to tell what's causing the error without seeing more code. Typical causes are:

Forgetting to enqueue the jQuery UI library
Enqueueing the jQuery UI library before the jQuery library (could you please ensure that you specify jquery as a dep in the call to wp_enqueue_script that you're using to load the jQuery UI script?)
Enqueueing the jQuery library more than once (could you please view page source to check for this?)
Specifying an incorrect path to the jQuery UI script (please check your browser console to be sure that you don't have 404)

Thanks. I need to understand where to put the enqueue script for Jquery UI.

Shall i do it in custom module PHP file?


Use a precompiled NIF

This PR introduces the ability to download a precompiled NIF and remove the need of having the Rust toolchain installed.
It is going to work for the majority of popular Operational Systems.
The following targets are supported:

aarch64-apple-darwin - MacOS on M1
x86_64-apple-darwin
x86_64-unknown-linux-gnu
x86_64-unknown-linux-musl
arm-unknown-linux-gnueabihf
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc

You can play with it using this snippet (requires Elixir ~> 1.12):
Mix.install([
  {:html5ever,
   git: "https://github.com/philss/html5ever_elixir.git", branch: "ps-download-precompiled"}
])

html = """
<!doctype html>

  <title>Testing</title>

Hello world

"""

Html5ever.parse(html)

The Release workflow
Most of the work is done by the CI server, which in this case is GitHub Actions.
Upon each new pushed tag we trigger the "release" workflow - which is independent of Hex.
That workflow is going to build the NIF files and upload to the release page. We use the tool "cross" to help with some of the cross compilations.
You can see one of the releases here: https://github.com/philss/html5ever_elixir/releases/tag/testing-release30
The "release" workflow was heavily inspired by this: https://github.com/sharkdp/lscolors/blob/c6e191b91f637058ba932a4f7b065f2e19d8a1ba/.github/workflows/CICD.yml
Open questions

Should we compress the files (tar.gz)?
Should we include the license files together?
In case the precompiled NIF is not available, should we always force a compilation? Today we raise an error.

@philss btw, I think we should .tar.gz it. Can you do a quick test and see how much size does it save?

@josevalim the files are much smaller now. I will change the load process to decompress it.
Previous

Current - with tar.gz

PS: the maOS build failed for the current. This does not change the results.

Really nice work!
Some thoughts, sorry this is a bit of a mess:
Open questions

Should we compress the files (tar.gz)?

I think it makes sense to do so. This also makes it possible to package other files in there, but this is probably not needed yet.

In case the precompiled NIF is not available, should we always force a compilation? Today we raise an error.

I think raising is the correct behavior by default. We also need an option somehow to enable compilation.
An environment variable might not be the right option here, is this something we could put in config instead?

NIF versions
This is the quote that José sent me from the OTP team regarding NIF version compatibility:

It’s a bit of both, we guarantee not to make NIFs incompatible for two major OTP versions, and that you can load NIFs of the same major NIF version.
That is, a NIF compiled for OTP 24 will be loadable in OTP 26, and probably even OTP 27 if we don’t bump the NIF major version.

Usually a NIF will use a specific feature set, and that is usally the limiting factor as to what NIF versions it supports.
If a NIF doesn't use any new features from 2.15 or 2.16, It could compile for 2.14. Since this is a minor NIF version bump, it should be compatible with all future BEAM versions supporting 2.xx NIF versions.
Is there any advantage to compiling versions supporting 2.15 and 2.16 if a NIF compiled for 2.14 could be loaded just fine?
The downloading logic could probably choose the latest compatible NIF version (major version matching, minor version <= current).
Then what NIFs to compile would be a concern for the CI configuration. If no recent features are used, the library might choose to build only one version. If newer NIF API versions provide some advantage (new NIF API function added that makes things more efficient or something), several versions could be compiled.

The version selection logic seems to be already implemented, but (unless I misread) it might not be filtering for minor version <= current VM minor version?

An environment variable might not be the right option here, is this something we could put in config instead?

A configuration is not a bad idea. We could support both if necessary. Keep in mind that env vars can also be given to deps: {:html5ever, "~> 1.0", system_env: %{"HTML5EVER_BUILD" => 1}}

Is there any advantage to compiling versions supporting 2.15 and 2.16 if a NIF compiled for 2.14 could be loaded just fine?

Could we have optimizations/enhancements/fixes in 2.16 that are not leveraged by 2.14? 🤔 I am not well-versed on the C side of things to say.

The version selection logic seems to be already implemented, but (unless I misread) it might not be filtering for minor version <= current VM minor version?

You are correct. Great catch.

A configuration is not a bad idea. We could support both if necessary. Keep in mind that env vars can also be given to deps: {:html5ever, "~> 1.0", system_env: %{"HTML5EVER_BUILD" => 1}}

What's your thoughts about this?
I was thinking that whether you want to fall back to compilation is more an application config concern than something you want to set in your environment. I imagine it could get very annoying making sure you have the right shell environment set up in order for mix invocations to work.
I don't necessarily want my libraries to try invoking Rust behind my back by default, but if I explicitly opt into it on an application config level, I want it to be as unannoying as possible to deal with.

Could we have optimizations/enhancements/fixes in 2.16 that are not leveraged by 2.14? thinking I am not well-versed on the C side of things to say.

I don't mean specifically for html5ever_elixir, more that it's something we want to consider.
An example:
Rustler has functions for getting the type of a term (Term::get_type).
Before OTP 22.0, this function had to be implemented as calls to a chain of is_[...] functions in the NIF API, since there was no function that returned the type of the term.
After OTP 22.0, we got enif_term_type.
This means that, while Term::get_type works on previous versions as well, it can have a much more efficient implementation on newer NIF API versions.
Maybe not the best example, but at least it demonstrates that this might be something we want to think about.

I was thinking that whether you want to fall back to compilation is more an application config concern than something you want to set in your environment.

I think it can be both. For example, I may be running on a platform that has no precompiled archives, so I want to force the build on my machine but no affect my coworkers. :) I agree on the application environment examples you gave too.

I don't mean specifically for html5ever_elixir, more that it's something we want to consider for when some of this work makes it into Rustler.

Ah, really good example. So that's a reason to compile to the latest nif version possible if we can, no?

Ah, really good example. So that's a reason to compile to the latest nif version possible if we can, no?

Yep, it's probably a good idea to compile for all versions now that I think about it. The always-safe approach is to select the latest possible version, and it's not like we are limited on CI resources :)

@hansihe thanks for the review!
For the application config I choose to not add a new option because :skip_compilation? does something similar. WDYT about using that?
If we choose to add another option, we are probably need to define something outside the NIF module scope, since Rustler uses that to build its own config (we can also change Rustler to accept that).
@josevalim thanks for the suggestion! I added some tests to it. Please check.

Feel free to merge whenever you are ready @philss.
We should remember to change the URLs as appropriate before merging.


Android Basics: Amphibians app , can not call the getAmphibianList() method

In update the UI from the ViewModel , step 1 , we can not call the getAmphibianList() method from the ViewModel in AmphibianListFragment because it is a private method , it's better to add init {getAmphibianList()} in the AmphibianViewModel

Great solution! Thank you!


Fix for shifted end-of-day

Rearranged updating the old date to repair functionality of the shifted end-of-day

Nice catch! The bug was that a reference date was updated with the current date, before it checked the offset with the current date. Hence, part of the logic wouldn't trigger.
I've moved the merge to the dev branch, to ensure that I can bundle a couple of fixes before releasing a new version to the master branch.


drush: 6.1.0 -> 8.1.16

Semi-automatic update. These checks were performed:

built on NixOS
found 8.1.16 with grep in /nix/store/flbrvbi6y2jf3csc7a3phl98hpna716m-drush-8.1.16
found 8.1.16 in filename of file in /nix/store/flbrvbi6y2jf3csc7a3phl98hpna716m-drush-8.1.16

@GrahamcOfBorg build drush

Success on aarch64-linux (full log)
Partial log (click to expand)
stripping (with command strip and flags -S) in /nix/store/s0dqdxyfh4zvriwjhmdxfznn2ax4jimr-drush-8.1.16/bin
patching script interpreter paths in /nix/store/s0dqdxyfh4zvriwjhmdxfznn2ax4jimr-drush-8.1.16
/nix/store/s0dqdxyfh4zvriwjhmdxfznn2ax4jimr-drush-8.1.16/src/.drush-wrapped: interpreter directive changed from "/usr/bin/env php" to "/nix/store/1n291ix51dln925k99hhqbgb75g1izn3-php-7.2.2/bin/php"
/nix/store/s0dqdxyfh4zvriwjhmdxfznn2ax4jimr-drush-8.1.16/src/misc/windrush_build/windrush_build: interpreter directive changed from "/bin/bash" to "/nix/store/lnws52qanbi5vz8qg24v4ym57nznfndg-bash-4.4-p12/bin/bash"
/nix/store/s0dqdxyfh4zvriwjhmdxfznn2ax4jimr-drush-8.1.16/src/examples/git-bisect.example.sh: interpreter directive changed from "/usr/bin/env sh" to "/nix/store/lnws52qanbi5vz8qg24v4ym57nznfndg-bash-4.4-p12/bin/sh"
/nix/store/s0dqdxyfh4zvriwjhmdxfznn2ax4jimr-drush-8.1.16/src/examples/drush.wrapper: interpreter directive changed from "/usr/bin/env sh" to "/nix/store/lnws52qanbi5vz8qg24v4ym57nznfndg-bash-4.4-p12/bin/sh"
/nix/store/s0dqdxyfh4zvriwjhmdxfznn2ax4jimr-drush-8.1.16/src/drush.php: interpreter directive changed from "/usr/bin/env php" to "/nix/store/1n291ix51dln925k99hhqbgb75g1izn3-php-7.2.2/bin/php"
/nix/store/s0dqdxyfh4zvriwjhmdxfznn2ax4jimr-drush-8.1.16/src/drush.launcher: interpreter directive changed from "/usr/bin/env sh" to "/nix/store/lnws52qanbi5vz8qg24v4ym57nznfndg-bash-4.4-p12/bin/sh"
checking for references to /build in /nix/store/s0dqdxyfh4zvriwjhmdxfznn2ax4jimr-drush-8.1.16...
/nix/store/s0dqdxyfh4zvriwjhmdxfznn2ax4jimr-drush-8.1.16

Success on x86_64-linux (full log)
Partial log (click to expand)
stripping (with command strip and flags -S) in /nix/store/flbrvbi6y2jf3csc7a3phl98hpna716m-drush-8.1.16/bin
patching script interpreter paths in /nix/store/flbrvbi6y2jf3csc7a3phl98hpna716m-drush-8.1.16
/nix/store/flbrvbi6y2jf3csc7a3phl98hpna716m-drush-8.1.16/src/drush.php: interpreter directive changed from "/usr/bin/env php" to "/nix/store/l1bw75fakjkafc2a5l8hxmg6sk4dffi0-php-7.2.2/bin/php"
/nix/store/flbrvbi6y2jf3csc7a3phl98hpna716m-drush-8.1.16/src/drush.launcher: interpreter directive changed from "/usr/bin/env sh" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/sh"
/nix/store/flbrvbi6y2jf3csc7a3phl98hpna716m-drush-8.1.16/src/examples/drush.wrapper: interpreter directive changed from "/usr/bin/env sh" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/sh"
/nix/store/flbrvbi6y2jf3csc7a3phl98hpna716m-drush-8.1.16/src/examples/git-bisect.example.sh: interpreter directive changed from "/usr/bin/env sh" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/sh"
/nix/store/flbrvbi6y2jf3csc7a3phl98hpna716m-drush-8.1.16/src/misc/windrush_build/windrush_build: interpreter directive changed from "/bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/flbrvbi6y2jf3csc7a3phl98hpna716m-drush-8.1.16/src/.drush-wrapped: interpreter directive changed from "/usr/bin/env php" to "/nix/store/l1bw75fakjkafc2a5l8hxmg6sk4dffi0-php-7.2.2/bin/php"
checking for references to /tmp/nix-build-drush-8.1.16.drv-0 in /nix/store/flbrvbi6y2jf3csc7a3phl98hpna716m-drush-8.1.16...
/nix/store/flbrvbi6y2jf3csc7a3phl98hpna716m-drush-8.1.16

cc @lovek323

There is 8.1.17 that's been released meanwhile. @ryantm would you be kind and do your magic for the new update?
I see that @lovek323  didn't respond; @joachifm any reason we shouldn't upgrade otherwise?


Feature Flag export JSON and CSV modals with crud changes

This PR contains all the changes of feature Flag export JSON and email CSV models with crud changes on the frontend side and integration with relevant components.
Email FF Data Modal

Export FF Design Modal

Export ALL FF Designs Modal

Disable the button during the req

Modal close on Successful Export

I have run out of time today to really review, but I was nodding my head going through it, I think structurally is what we want and can use that thing for many of the other million confirm modals we'll need eventually 🏄♂

sry, I have another annoying request for this. I've got some more comments, but the common-component part looks good to go and is more important for MVP.
Can we pause this PR and split off the code for creating a simple confirm component into it's own PR? It really should have been it's own story in the first place. I will create that now and assign it to you and we can that part knocked out. Then we can pull that into this branch and return to some of the other comments for these functions.

Is there any other suggestions apart from moving that effect code for download to separate service?

ty @Yagnik56 simple confirm modal merged, that will help me go through this, I do have some other suggestions
.

I made some comments but mostly we can just remove functionality related to exporting multiple feature flag designs. no need to keep anything in there 'for later', we can add it when later.

looks good, just needs to remove the one file i'll approve/merge it

scratch that, yagnik will follow-up


Make the inference window size same as the video size?

When I run inference with a live webcam the window that contains the webcam feed with the bounding boxes takes the full screen while my webcam video is 640x480.
So I end up with a huge black window and a tiny video in the top-left corner of the screen.
Is there a way to make that window be same size as the video?

Hi @ramvelyan, I believe you are on the depth dev branch, and there I have added some new functions to glDisplay, including glDisplay::SetSize()
So you should be able to do something like this:
display->SetSize(camera->GetWidth() + 10, camera->GetHeight() + 30);

The +10 and +30 are for a bit of a border so the feed doesn't get chopped off by the window.  I don't think I have the Python bindings for display.SetSize() yet, although you can pass width and height to the display constructor now:
display = jetson.utils.glDisplay(width=camera.GetWidth()+10, height=camera.GetHeight()+30)

In the future, I plan to add auto-resizing of glDisplay to match the video feed(s).

Thanks Dusty, I will try it out.
I managed to display the glCamera in an OpenCV window with showimg() but I notice a very slight drop in video frame rate (Network FPS are unaffected though).
Quick question on the side, is Jetson Inference an official Nvidia software that will be supported on the long run or is it an initiative on the side?
I hope it continues to develop because it's absolutely great.

It's pretty official by GitHub standards, it's also on the NVIDIA website and maintained in the long run.  The project is already several years old and continues to add features.  Glad that it is helpful to you.

From: rsamvelyan<EMAIL_ADDRESS>Sent: Friday, June 5, 2020 11:11:05 PM
To: dusty-nv/jetson-inference<EMAIL_ADDRESS>Cc: Dustin Franklin<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [dusty-nv/jetson-inference] Make the inference window size same as the video size? (#605)
Thanks Dusty, I will try it out.
I managed to display the glCamera in an OpenCV window with showimg() but I notice a very slight drop in video frame rate (Network FPS are unaffected though).
Quick question on the side, is Jetson Inference an official Nvidia software that will be supported on the long run or is it an initiative on the side?
I hope it continues to develop because it's absolutely great.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/dusty-nv/jetson-inference/issues/605#issuecomment-639967162, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADVEGKYDQIPTLDXZB44M5RTRVGXUTANCNFSM4NTGR6CQ.

This totally worked. It's awesome:
display = jetson.utils.glDisplay(width=camera.GetWidth()+10, height=camera.GetHeight()+30)
I hope to see all these features in the documentation at some point.
Thanks a lot!!


Fix founding of standup-helper.sh

Fir for my issue https://github.com/notwaldorf/tiny-care-terminal/issues/71

As of version 1.2.0 there's a new way to use the terminal that doesn't involve the bash script. To use that, set the TTC_GITBOT environment variable to gitlog. This will become the default way in the future, I'm just giving it a bit of time in the wild before switching to it


Wrong Password?

Just attempted a CLI update to 3.0.2 on a Raspberry Pi 4. Update seemed to have gone fine, auto restart works, but when I attempt to login, I get a wrong password error.
The config json file had a long character strings for both the settings and producer passwords. I assume they were encrypted, but I tried changing them to 12345 per current docs to no avail.
Suggestions?

We took a look at the code this morning to see if we could temporarily comment out the password check. While looking for that we noticed there has been a update to the code to use the bcrypt library - perhaps to store a hash of the password in config.json instead of the raw password. Didn't have enough time to dig further, but suspect this hasn't been fully tested.

Hey @wrldtvlr! Would you mind uploading a copy of your config json?
We've been testing and using the new authentication system successfully for a while now with no issue.

Hi @wrldtvlr,
null or 12345 won't work because the password from the config file must always be a hash. When logging in, the password from the input field is compared with the hash.
You could try something like https://bcrypt-generator.com/ to generate a suitable hash and put it in your config.
In the future, we could add like a reset password CLI option.

Still not clear what is going on here. Generated a hash for 12345 at bcrypt-generator.com, pasted it in, rebooted. Accessing the settings page still results in "Wrong username or password!".

Oh - How many rounds should I be using when generating the hash?

Looked at the code linked above and thought the number of rounds might be 10. This resulted in the hash below, which did not work.
"username": "admin",
"password": "$2a$10$5c81Ep72a3PUK8qTRI.19uvVEJhosg2QLrGkVPpOg6vwWxtSANlW2",
"roles": "admin"

@wrldtvlr can you try running TA from the new branch fix_auth?
I'm sorry, I was very busy in these weeks, and I didn't tried the config migration a lot before merging...
There was a bug in the config migration system, so the JWT Private Key (required for JWT-based auth) was not generated, and the login function failed. Now every login error is logged into TA Logs.
It should work now.
I'm opening a PR right now.

I'll be in the booth tomorrow morning and give it a try!

Is the 10 round hash I posted above correct?

Is the 10 round hash I posted above correct?

Yes, it is

As far as I know, more rounds just make the hash more secure - and as the comparison function does not need to know how many rounds were used when generating the hash, I'd say that any number of rounds should work.

@hrueger can we detect if a string is a valid bcrypt-hashed string or just a string?
It would be awesome if TA detects plaintext password, hash them and save the config on startup.
Do you think it's possible?

I think that the generated hashes are always 60 chars (or 59 according to stackoverflow). Maybe we can just check if the length is different and if yes, treat it as a plaintext password?

Sorry - my knowledge of npm is very limited. We're running TA using the CLI install process. I know how to update to a specific version using this syntax: npm update<EMAIL_ADDRESS>but I don't know if it would be possible to designate a specific branch. i.e. fix_auth. Is this possible?

Ahh... A little more research suggests I should be able to use this: npm install --g tallyarbiter#fix_auth

Sorry - my knowledge of npm is very limited

Never mind!
Unfortunately, npm install --g tallyarbiter#fix_auth won't work, because this branch is not published to npm. As we're using TypeScript and Angular, some build steps need to happen in order to generate a distributable form of TallyArbiter which is then published to npm.
To run this branch (in development mode), you need to follow the instructions from the Readme.
After step three you need to switch to this branch using git checkout fix_auth and then continue with the other steps

Ok. Uninstalled the npm version, cloned the repo and set the fork. Angular takes forever to compile on a Pi...

Just an update - let things run overnight and not surprisingly found an insufficient memory error when I came in this morning. Increased the memory allocation and restarted things. Will see if that makes any difference. I now remember why I chose the CLI install method previously. Getting the dev environment running on a Pi is not easy. I may need to wait until the auth fix is published before testing.

I wasn't able to get the dev environment for 3.0.2 auth fix installed, so I had to remove it and will reinstall 3.0.1 tomorrow. Will be glad to load it when a package is available.

Never mind, I wouldn't have though that the Angular Compilation is that slow on a pi... May I ask which Pi version do you have?
Anyway, we'll test this change and release a new version as soon as one of us finds some time to do that ;-)

OK, I'm at a complete loss here. I can't get TA (any version) to recognize the settings or producer password. With the latest CLI package running, the log says this:
2022-03-29 10:36:25] info: User admin (ip addr ::ffff:<IP_ADDRESS>) has attempted a login: wrong username or password.
[2022-03-29 10:36:46] info: User producer (ip addr ::ffff:<IP_ADDRESS>) has attempted a login: wrong username or password.
The password section of the config.json file in ~/local/share/TallyArbiter says this:
"username": "producer",
"password": "$2a$12$RdlK3dTxUkvqpfyXkFPPuuZ4js6YcBBv7Sygxho3340TyGwsp.2Jm",
"roles": "producer"
},
{
"username": "admin",
"password": "$2a$12$RdlK3dTxUkvqpfyXkFPPuuZ4js6YcBBv7Sygxho3340TyGwsp.2Jm",
"roles": "admin"
The hashes were generated at the Bcrypt-generate website for password 12345. We don't even need passwords for TA access. Any suggestions on what might be wrong?

What do you mean with latest v2?

Yes. What you get when you do npm install -g tallyarbiter.

This should be 3.0.2
Unfortunately, I don't know what's going on there currently, but I also don't have time to release @MatteoGheza's fix... Sorry for that, its quite busy right now.

I'm at a loss as well. I just tried installing 3.0.1 over 3.0.2 (npm install --global<EMAIL_ADDRESS>as that version was working fine but get the same password error. I assume I'm doing something wrong with the hash, but I can't figure out what.

Are you editing the correct config file?
We once changed the path to where it's saved, but I don't remember if that was between 1 and 2 or between 2 and 3.

That seems like the most likely. I've been editing ~/.local/share/tallyarbiter/config.json. Is there another location I should look for?

OK - the details are a little fuzzy as I was working on this for several more hours this morning and the steps all blur together, but this is what I think I know as far as installing on a Raspberry Pi:

Installing TA server on a Raspberry Pi using the developer option (i.e. compiling everything) is almost impossible given the limited memory and cpu.
Installing using the CLI method is a bit tricky as the permissions are not clear. It seems to be necessary to use sudo npm install rather than just npm install.
Upgrading from a previous install is very unclear. I think the v2 install location is ~/.local/share/TallyArbiter. The v3.0.2 location when using sudo npm install -global is actually /root/.local/share/TallyArbiter.
Installing v3.0.2 as an upgrade seems to be missing a security key in the config.json file. Although TA server runs just fine, this results in the password being invalid when attempting to log in.

So, I created a brand new Raspian OS image, reinstalled node and npm (with sudo), then reinstalled TA 3.0.1 using
sudo npm install -global<EMAIL_ADDRESS>I then went in and set /root/.local/share/TallyArbiter directory and file permissions to 777 as the changes to the config.json file weren't getting written out.
I'm sure some of this was unnecessary or just plain wrong, but at least everything is running. Once 3.0.2 has been fixed and tested on a Raspberry Pi, I'll try installing that on a clean Raspian image.

Can you try to update to 3.0.3?

Sure. I'll start by installing 3.0.3 on a clean Raspian image and try to minimize the use of sudo. On my list for Monday morning.


Stdout is broken by a recent commit

Hello -- looks like there's a recent regression caused by d88b7ccc which makes stdout not work properly anymore. Things like (prn "HI") or (println "HI") just output nil now. (I found this commit using git bisect.)
FYI @pdenno

The most recent commit fixes this.


Add credentials, necessary modules, and key for Spotify API

Installed all packages so its a lot of things.


Maid 1459 hole punch example

r? @canndrew
(maidsafe_highfive has picked a reviewer for you, use r? to override)

@inetic, I release a new temp_utp version with your changes and now tests pass correctly: https://github.com/maidsafe/crust/pull/366 (please don't pull the dummy commit, it was done only to trigger the CI that somebody has cancelled)
I think you can revert/discard commit 7b82dbd9a796eb9b597fd2bceb49597727368566 already.