text:
2023:08:16 Added: Webview for Privacy Policy.

Checklist
Common

[x] I am ran the app before creating PR
[x] I am ran all tests before creating PR

UI

[x] I am ran the app for visual checks.

Logic

[x] I am tested basic app functionality.

Changes
Describe all changes here:

Create a WebView Fragment.
Created xml layout for webview.

Comments
Added WebView fragment which shows the privacy policy in the inner webview.
Describe all additional information here.

@fartem  Suggest if any changes require.

#264

Done.

Working on it

@fartem can these work
public class WebViewer {
    private static Context context;
    private String url;

    public WebViewer(String url) {
        this.url = url;
    }

    public static Context getContext() {
        return  context;
    }
    public static void setContext(Context context) {
        WebViewer.context = context;
    }

    public void dispalyWebView() {
        MainActivity activity = (MainActivity) WebViewer.getContext();
        activity.showFragment(new WebFragment(this.url));
    }
}

    public void initPrivacyPolicy() {
        Preference privacyPolicyPreference = findPreference(getString(R.string.key_privacy_policy));
        if (privacyPolicyPreference != null) {
            privacyPolicyPreference.setOnPreferenceClickListener(preference -> {
                WebViewer.setContext(getActivity());
                PrivacyPolicyWebLinksBottomSheet bottomSheet = new PrivacyPolicyWebLinksBottomSheet();
                bottomSheet.show(fragmentManager, bottomSheet.key());
                return false;
            });
        }
    }

        @Override
        protected void callItemClick() {
            if (webLink.getLinkResId() == WebLink.PRIVACY_POLICY.getLinkResId()) {
                new WebViewer(getContext().getString(webLink.getLinkResId())).dispalyWebView();
                dismissBottomSheet();
                return;
            }
            String link = getContext().getString(webLink.getLinkResId());
            WebUtils.openWebLink(getContext(), link);
            dismissBottomSheet();
        }

Here static is used to store the context that we get from getActivity() of initPrivacyPolicy() of SettingFragment.

@ManishDait, thanks.

authors: ManishDait fartem

repo: hash-checker/hash-checker


text:
Add ability for player to move around and interact with stuff.

Possibly a key bind that allows the user to control their player when in freecam mode.

Great mod btw!

Added in 1.0.0

source: gharchive/issue

authors: CookByTheBook hashalite

repo: hashalite/Freecam

license: MIT

license_type: permissive

license_source: github-api


text:
Usage with external registry

I am running an instance of harbor on a VM outside my cluster, I can't go around that. Also, I have a few ci pipelines that use kaniko as a way to build and push images. Is there a way to use this project to replicate the push function of kaniko (without docker-daemon)?
My team has been looking for an alternative for a while.
Thank you very much for this project.

@saharlaor thanks for sharing your use-case! This project does not currently support image building (though it could). The primary function of this package is being able to govern access to push images from outside of a cluster to a registry running in-cluster using k8s RBAC. It sounds like you may be doing the opposite (build images in cluster, push to registry outside). Does that sound right? What shortcomings are you seeing with kaniko that you would like to address?

authors: hasheddan saharlaor


text:
fix: unable to parse some contract transaction reverted, resulting in "TypeError: Cannot read properties of null (reading 'transactions')"

Description

Be able to parse the error message, instead of "unknown error"

Steps to reproduce

Submit this transaction: https://hashscan.io/testnet/transaction/1687274355.056813003
Observe that transaction is reverted
But there is no error message on Hashscan
Observe in browser error: Unknown error invoking RPC - full message copied below
Observe RPC relay error: TypeError: Cannot read properties of null (reading 'transactions') - logs copied below

Additional context
Error message in browser (from Metamask):
MetaMask - RPC Error: [ethjs-query] while formatting outputs from RPC '{"value":{"code":-32603,"data":{"jsonrpc":"2.0","id":6696677332751,"error":{"code":-32603,"name":"Internal error","message":"[Request ID: 66de5563-d3e5-47d2-9d3d-444f557ace76] Unknown error invoking RPC"}}}}'

Relevant part of log output from RPC Relay:
[2023-06-20 15:19:16.579 +0000] DEBUG (consensus-node/91353 on admins-MacBook-Pro.local): [Request ID: 66de5563-d3e5-47d2-9d3d-444f557ace76] 0.0.3996280@1687274343.363097580 eth_sendRawTransaction EthereumTransaction record status: CONTRACT_REVERT_EXECUTED (33), cost: 1.81207359 ℏ
[2023-06-20 15:19:17.045 +0000] TRACE (mirror-node/91353 on admins-MacBook-Pro.local): [Request ID: 66de5563-d3e5-47d2-9d3d-444f557ace76] Retry delay 250 ms
[2023-06-20 15:19:17.529 +0000] TRACE (mirror-node/91353 on admins-MacBook-Pro.local): [Request ID: 66de5563-d3e5-47d2-9d3d-444f557ace76] Retry delay 500 ms
[2023-06-20 15:19:18.110 +0000] INFO (consensus-node/91353 on admins-MacBook-Pro.local):  0.0.3996280@1687274346.358351484 eth_sendRawTransaction FileContentsQuery status: SUCCESS (22), cost: 36 tℏ
[2023-06-20 15:19:18.264 +0000] TRACE (mirror-node/91353 on admins-MacBook-Pro.local): [Request ID: 66de5563-d3e5-47d2-9d3d-444f557ace76] Retry delay 750 ms
[2023-06-20 15:19:18.556 +0000] INFO (consensus-node/91353 on admins-MacBook-Pro.local):  0.0.3996280@1687274347.117995795 eth_sendRawTransaction FileContentsQuery status: SUCCESS (22), cost: 23 tℏ
0
[2023-06-20 15:19:19.256 +0000] DEBUG (mirror-node/91353 on admins-MacBook-Pro.local): [Request ID: 66de5563-d3e5-47d2-9d3d-444f557ace76] [GET] transactions/0.0.3996280-1687274343-363097580 404 status
[2023-06-20 15:19:19.256 +0000] ERROR (relay-eth/91353 on admins-MacBook-Pro.local): [Request ID: 66de5563-d3e5-47d2-9d3d-444f557ace76] Failed to successfully submit sendRawTransaction for transaction 0x02f9013582012881828459682f0086020ad23ad70083061a80943a8bac3ce0dbe706f377600c117c9f2aed2a403680b8c4b68a4ba00000000000000000000000003a8bac3ce0dbe706f377600c117c9f2aed2a403600000000000000000000000000000000000000000000000000000002540be400000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000020000000000000000000000001c29e31d241f0d06f3763221f5224a6b82f09cce0000000000000000000000009a814b5afd6b0fff1e9548dcba4d09cdd8c81568c080a0891cfa17b17ad82645cd3fd7fa5fd782fc3f9434b87e0a751f0b691b601f28f8a020c3b646a3a276e67e2663963711f319b8a99d6ed7716c60e9a4dd5b0e953191
    err: {
      "type": "TypeError",
      "message": "Cannot read properties of null (reading 'transactions')",
      "stack":
          TypeError: Cannot read properties of null (reading 'transactions')
              at EthImpl.<anonymous> (/Users/user/code/hedera/hedera-json-rpc-relay/packages/relay/dist/lib/eth.js:878:28)
              at Generator.next (<anonymous>)
              at fulfilled (/Users/user/code/hedera/hedera-json-rpc-relay/packages/relay/dist/lib/eth.js:24:58)
              at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    }
[2023-06-20 15:19:19.257 +0000] INFO (rpc-server/91353 on admins-MacBook-Pro.local): [Request ID: 66de5563-d3e5-47d2-9d3d-444f557ace76] [POST] eth_sendRawTransaction: -32603 2931 ms
[2023-06-20 15:19:19.257 +0000] ERROR (rpc-server/91353 on admins-MacBook-Pro.local): [Request ID: 66de5563-d3e5-47d2-9d3d-444f557ace76] returning error to sender: Unknown error invoking RPC
[2023-06-20 15:19:19.257 +0000] ERROR (rpc-server/91353 on admins-MacBook-Pro.local): [Request ID: 66de5563-d3e5-47d2-9d3d-444f557ace76] [POST] eth_sendRawTransaction: 500 (-32603) (JSON RPC ERROR) 2931 ms

Hedera network
testnet
Version
Reproduced on both v0.25.0 and HEAD of main (46d7f485a6ec3547c9265288d13f28873b1a70cd) of the RPC relay
Operating system
macOS

Closing this issue.
Reason:

Unable to reproduce this on latest commit of main branch (b3621e).

Details:

eth_sendRawTransaction now has a completely different implementation, from https://github.com/hashgraph/hedera-json-rpc-relay/pull/1345
The above error (TypeError: Cannot read properties of null (reading 'transactions')) was within the previous eth_sendRawTransaction implementation which did not involve the mirror node (communicated with consensus nodes directly)
The new eth_sendRawTransaction implementation has a different code path which invokes mirror nodes instead
I assume that this is indirectly related to HIP-584 - Mirror EVM Archive Node, as that describes switching from consensus nodes to mirror nodes for eth_sendRawTransaction + adding a true eth_estimateGas implementation (instead of hardcoded values)

It's likely the issue here is related to https://github.com/hashgraph/hedera-json-rpc-relay/blob/main/packages/relay/src/lib/eth.ts#L1157 where tx could be null yet we're still trying to get transactions out of it

authors: Nana-EC bguiz

repo: hashgraph/hedera-json-rpc-relay


text:
Run tests automatically in the PR checks workflow (PR)

Description:
This PR adds commands to start and stop the local node during the PR checks.
Updated the YAML script
Related issue(s):

https://github.com/hashgraph/hedera-sdk-cpp/issues/201
https://github.com/hashgraph/hedera-sdk-cpp/issues/164

Fixes https://github.com/hashgraph/hedera-sdk-cpp/issues/257
Notes for reviewer:

Checklist

[x] Documented (Code comments, README, etc.)
[x] Tested (unit, integration, etc.)

Create 2 new issues to track the commented tests:

https://github.com/hashgraph/hedera-sdk-cpp/issues/259
https://github.com/hashgraph/hedera-sdk-cpp/issues/260

source: gharchive/pull-request

repo: hashgraph/hedera-sdk-cpp


text:
HIE automatically downloads and uses old HIE

It makes a lot of unnecessary debugging.
2019-04-17 03:08:19.057640292 [ThreadId 4] - run entered for hie-wrapper(hie-wrapper) Version 0.8.0.0 (2530 commits) x86_64 ghc-8.6.4
2019-04-17 03:08:19.06195586 [ThreadId 4] - Current directory:.../foundationdb-haskell
Downloading lts-11.13 build plan ...
Downloaded lts-11.13 build plan.
2019-04-17 03:08:51.325263859 [ThreadId 4] - Cradle directory:.../foundationdb-haskell
2019-04-17 03:08:51.325999133 [ThreadId 4] - Using stack GHC version
2019-04-17 03:08:51.586280534 [ThreadId 4] - Project GHC version:8.2.2
2019-04-17 03:08:51.587647332 [ThreadId 4] - hie exe candidates :["hie-8.2.2","hie-8.2","hie"]
2019-04-17 03:08:51.60171636 [ThreadId 4] - found hie exe at:.../.local/bin/hie-8.2.2
2019-04-17 03:08:51.602510839 [ThreadId 4] - args:["--lsp"]
2019-04-17 03:08:51.604104318 [ThreadId 4] - launching ....

2019-04-17 03:08:51.975795 [ThreadId 4] - Using stack GHC version
2019-04-17 03:08:52.243654 [ThreadId 4] - Run entered for HIE(hie-8.2.2) Version 0.6.0.0, Git revision 5245042a317944f394de20b29c55afd0bb0dbc76 (dirty) (2426 commits) x86_64 ghc-8.2.2
2019-04-17 03:08:52.318327 [ThreadId 4] - Current directory:.../foundationdb-haskell
2019-04-17 03:08:55.498324 [ThreadId 10] - Using stack GHC version
Using hie version: Version 0.6.0.0, Git revision 5245042a317944f394de20b29c55afd0bb0dbc76 (dirty) (2426 commits) x86_64 ghc-8.2.2
Using hoogle db at: .../.hoogle/default-haskell-5.0.17.hoo
hie-8.2.2: user error (Failed to find requested hint files:
  .../.local/bin/data/hlint.yaml
)

What is the bug here? Are you actually reporting the final line ?
hie-8.2.2: user error (Failed to find requested hint files:
  .../.local/bin/data/hlint.yaml
)

HIE shouldn't try to use such old version in the first place: HIE(hie-8.2.2) Version 0.6.0.0, Git revision 5245042a317944f394de20b29c55afd0bb0dbc76 (dirty) (2426 commits) x86_64 ghc-8.2.2

That is a good point. The wrapper should be a lot more precise about which version of hie it invokes.

Why shouldn't it try to use a version of hie that fits to the used GHC?
No old hie version is ever being downloaded, if this version is being used, then it was installed on the system.
I dont see why the wrapper should perform a version check in this case. I should be able to use an old hie version if I want to, maybe it is more stable for my project, or I dont want to recompile every version.

I think very old versions should be rejected (Accept only 8.x.x in this case). And should warn or notice the use of old version (with 8.x.x).

Why should it? they are still working, older versions support sometimes older ghc versions, e.g. pre 8.x.x is supported only by very old versions. However, if they work for you, why should you be spammed for it?

I thought old versions of HIE are not needed. If old versions are sometimes needed, they have to be accepted.

They are not really needed, but also it is not a strict requirement to always have the most up-to-date version.
It is also somewhat hard to know when there is a more recent version, what should the wrapper do, call home and ask what the most recent version is? Or is the version hard-coded in each wrapper version?
If we can define a solution here, it shouldn't be too hard to implement.

I think I would prefer it if the wrapper used absolute paths but I'm not a user.

authors: falsandtru fendor mpickering

repo: haskell/haskell-ide-engine


text:
dpkg: error: cannot access archive '/base/kontar2opc_0.1.2-1_amd64.deb': No such file or directory

Hi,
This is my first time writing on Github and I apologize if I posted this question in the wrong place )))
Problem/Motivation

I am using a very old application "kontar2opc", created more than 10 years ago and running on Host. This is an OPCUA-server, for controlling a heating boiler via OPCUA protocol. I am afraid that due to regular updates of Debian 12 and Home Assistant supervised my application may stop working (dependencies will break or some library of this application will conflict with new libraries). I have been trying for a long time to run OPCUA-server on Node-red, but I could not figure out how to create a correct configuration. Therefore, I decided to create my first add-on, using your work

I don't understand where the file kontar2opc_0.1.2-1_amd64.deb should be located to solve this error. I tried copying this file to different folders, but the error remains
Expected behavior

Get an add-on with the kontar2opc application running, and two ports on the Host (port 2554 for receiving data from the heating controller and port 16664 for controlling the controller via Node red or custom_component HA

Actual behavior

When trying to create a container, everything ends with the error "dpkg: error: cannot access archive '/base/kontar2opc_0.1.2-1_amd64.deb': No such file or directory"

Steps to reproduce

Using SSH&Terminal HA add-on

cd /addons
git clone https://github.com/hassio-addons/addon-debian-base.git
cd /addons/addon-debian-base/base/
wget --no-check-certificate 'https://drive.google.com/uc?export=download&id=1CJ9uGyDlZ3RkKPoL6YKesGVhRd6s-qQ8' -O kontar2opc_0.1.2-1_amd64.deb

I added to the Dockerfile:
RUN echo "deb http://security.debian.org/debian-security buster/updates main" > /etc/apt/sources.list.d/buster_main.list \
   && apt-get update \
   && dpkg -i kontar2opc_0.1.2-1_amd64.deb \
   && apt --fix-broken install -y

and
# Copy data for add-on
COPY run.sh /
RUN chmod a+x /run.sh

CMD [ "/run.sh" ]

tried adding to RUN section
&& apt-get install wget
&& wget --no-check-certificate 'https://drive.google.com/uc?export=download&id=1CJ9uGyDlZ3RkKPoL6YKesGVhRd6s-qQ8' -O kontar2opc_0.1.2-1_amd64.deb

but this results in wget installation error
Added to config.yaml file:
startup: services
ports:
  2554/tcp: 2554
  16664/tcp: 16664

Created a run.sh file:
#!/usr/bin/with-contenv bashio

sudo systemctl start Kontar2Opc.service

Proposed changes

(If you have a proposed change, workaround or fix,
describe the rationale behind it)

I did everything wrong((. Sorry for the inconvenience. Great base for creating add-ons for your components.
Thanks for your work

repo: hassio-addons/addon-debian-base


text:
Upgrade to Hidden Service v3

I only submit this patch because from the open issues it appears this essential addon is at risk of becoming totally useless by October when all tor browsers will officially be incompatible with v2, and that would be a shame.
Proposed Changes

Change HiddenServiceVersion from 2 to 3 in order for this addon to survive the impending depreciation of v2. Patch is fully tested as Local Addon. No issues, though users will obviously have to take note of the new domain & update any bookmarks to the old one. I

Related Issues

(Github link to related issues or pull requests)

I have a hard time believing this is all that is needed to change.

I simulated this change by overwriting the torrc configuration file before the service starts with:
docker cp ~/docker/tor/torrc 6ed88f6762d6:/etc/tor/torrc
Changing the service version from 2 to 3 the service will generate new keys and overwrite the hosts file with the new V3 address.
It really does seem to be that simple. Probably because this would be the expected behavior when someone updates tor to a  version that defaults to v3 since this value usually isn't explicitly set.
Sometime in October, the tor network will drop support for routing v2 addresses entirely. Currently, as nodes are updating v2 address will progressively get harder to reach up until the October deadline. This can already be seen in several of my clients' log files where they have to repeatedly try introductory points to find one that still supports v2.

I have a hard time believing this is all that is needed to change.

It really is though. Try it yourself. I've been remotely accessing my server as a v3 service for over a month now without any problems. And when you think about it, it make sense (if you've ever run or configured Tor on a Linux system, anyway). This patch simply alters the contents written to the dynamic torrc prior to execution, so when Tor starts it creates the expected certificates where they don't yet exist.

Just checking if this is planned to be accepted and merged or not. No rush, just that otherwise, I'll have to start looking into alternatives.

I would like to kindly ask that this PR get merged sooner rather than later. I've personally had a very difficult time finding any vpn server that will work with my internet provider and this add-on is the easiest way for me to access my network from afar, not just HA, but other devices as well. This add-on will become obsolete if it is not updated.
The following is quoted from torproject's wiki on the subject:
"It's easy! Just use your regular onion service torrc and add HiddenServiceVersion 3 in your hidden service torrc block."
From the tor log on HA:
Sep 24 10:42:22.308 [warn] DEPRECATED: Onion service version 2 are deprecated. Please use version 3 which is the default now. Currently, version 2 is planned to be obsolete in the Tor version 0.4.6 stable series.

Rebased PR onto the latest main branch.

Just checking if this is planned to be accepted and merged or not

Sorry for the delay, my holiday did not end as planned. I'm slowly catching up.

This may be sufficient for enabling v3, but it will only create a publicly exposed v3 onion service. It does not replace the stealth v2 with v3 client authorization, which will result in all the stealth onions that were set up using this addon will be publicly reachable on upgrade.

@bluenix This is a merged and closed PR. Commenting something like that doesn't help, cannot be tracked for progress or fixed. If you have an issue, please raise an issue. Thanks 👍

authors: Seamus-Mccartin bluenix foo-calls-bar frenck ghgeiger sveip

repo: hassio-addons/addon-tor


text:
Differentiated uses for alt/cltr/shift

It would be a good idea, and very useful, to separate the functions of the shift, control and alt keys, for example:

Pressing Shift could make the roll with advantage (Rolled Eldritch Blast (ADV).
Pressing Control could be done with disadvantage (Rolled Eldritch Blast (DIS).
Pressing Alt could roll basic critical damage, doubling the die to roll, but adding only once the bonus (Rolled Eldritch Blast (CRIT).
This would be enhanced if the text could be modified in some way, for example, by darkening the result that will not be taken into account (the lowest or highest, depending on whether the roll is made with advantage or disadvantage), thus highlighting the white text more as the result to be taken, or making only the result that corresponds be shown on the screen.

This image is a simple photoshop retouching.

Yes, adding options to let people control these a bit more is something I want to do.
TaleSpire doesn't really let us do much more than sending label and dice to it, so we currently can't tell it to highlight the lower/higher.

I've pushed an update where you can behavior a bit for the modifier keys. It just let's you change the text within the paranthesis to ADV, DIS and ADV/DIS, but it makes your intention a bit clearer to other players at least.
TaleSpire has also said they're looking into a new more powerful dice syntax, so the other items might be possible in the future. :smile:

authors: MrProditio haste

repo: haste/tales-beyond


text:
Make ob-racket-runtime-typed rely on ob-racket-runtime-private.

As discussed in https://github.com/hasu/emacs-ob-racket/pull/10, this PR rewrites ob-racket-runtime-typed.rkt to "simply re-export" the relevant symbols from ob-racket-runtime-private.rkt.
Typed Racket cannot import macros from untyped code (and vice versa), meaning that ob-racket-runtime-typed.rkt still has to explicitly reproduce the definitions of ob-racket-begin-print-elisp and ob-racket-begin-print-table. However, the underlying functions datum->elisp and datum->table are directly imported from ob-racket-runtime-private.rkt with the appropriate type signatures.
https://github.com/hasu/emacs-ob-racket/pull/10 mentions that the original version of ob-racket-runtime-typed.rkt had more restrictive type signatures than the untyped code had.  This issue is no longer present in the new simplified code for ob-racket-runtime-typed.rkt, which indeed only assigns 2 very general type signatures.
Finally, I do not think that we incur a major performance penalty by introducing additional contract checks on the boundary between ob-racket-runtime-typed and ob-racket-runtime-private, because this boundary should be traversed at most once per evaluation of the code block, and the additional cost is probably very small compared to other costs associated with evaluating a code block.

Great. As short as one could've hoped for. Thank you.

authors: hasu scolobb

repo: hasu/emacs-ob-racket

license: mit

license_source: bigquery


text:
field 'update_schema_event' not found in type: 'query_root',

am doing this query and am always getting
error Message: field 'update_schema_event' not found in type: 'query_root', Locations: [], Extensions: map[code:validation-failed path:$.selectionSet.update_schema_event]
when i do it in hasura console it works
code
func UpdateSchemaResult(id int, result string) error {
	client := startgraphqlconnection()

	var mutation struct {
		update_schema_event struct {
			Affected_Rows int `json:"affected_rows"`
		} `graphql:"update_schema_event(where: { id: { _eq: $id }}, _set: { result_id: $result })"`
	}
	variables := map[string]interface{}{
		"id":     id,
		"result": result,
	}

	err := client.Query(context.Background(), &mutation, variables)
	if err != nil {
		fmt.Println("error", err)
		return err
	}
	return nil
}

i also tried with this method but the same result
	var mutation struct {
		Updateschemaevent struct {
			AffectedRows int `graphql:"affected_rows"`
		} `graphql:"update_schema_event(where: $where, _set: $set)"`
	}
	variables := map[string]interface{}{
		"where": schema_event_bool_exp{
			"id": map[string]interface{}{
				"_eq": id,
			},
		},
		"set": schema_event_set_input{
			"result_id": result,
		},
	}

thanks for help

The console uses an admin secret with full access to the GraphQL schema. You should check if the client also set x-hasura-admin-secret  or Authorization header if the client uses JWT/custom auth

i already defined that , i have another query that works fine , and am using the root user have all permissions

authors: MohamedKHALILRouissi hgiasac

repo: hasura/go-graphql-client


text:
🛑 Analytics Server is down

In 4e4ee84, Analytics Server (https://analytics.arash-hatami.ir) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Analytics Server is back up in 99989cc.


text:
[HxFormValue] Shrunk when displaying null/empty value

@crdo, please give me some styling instructions or fix on your own... ;-)

I suggest to rethink the idea of this component in general as it does not follow the readonly or readonly-plaintext form-controls in Bootstrap and it does not feel right from UX perspective either.
https://getbootstrap.com/docs/5.2/forms/form-control/#readonly
https://getbootstrap.com/docs/5.2/forms/form-control/#readonly-plain-text

I am not sure with the input="text" in the readonly&readonly-plain-text samples while they do not support word wrapping. I guess we want the long content to wrap instead of "overflow to hidden".

Decreasing priority as there is currently a temporary workaround implemented ( ).

authors: crdo hakenr jirikanda


text:
[HxGrid] "Uncaught (in promise) DOMException: The user aborted a request."

When using HxGrid component with ContentNavigationMode set to InfiniteScroll, there is an issue while canceling requests because the user scrolled over the requested page to the next one before data was successfully loaded.

Visually it leaves the user stuck on loading the next page but it will never load. User can recover by scrolling back a bit.

Repro steps

Clone Repro using NewProjectTemplate-Blazor
Launch Web.Server project
Start scrolling down fast on the Home page with HxGrid component configured to use infinite scrolling

Adding Task.Delay() to the server implementation of ICountryFacade to delay backend response will help with reproducing the issue.

Successfully reproduced by the @alexax578 repository.
The problem disappears when I change
var result = await CountryFacade.GetCountriesAsync(dataFragmentRequest, request.CancellationToken);
to the
var result = await CountryFacade.GetCountriesAsync(dataFragmentRequest, CancellationToken.None);
FYI, @hakenr. I guess there is some issue with gRPC stack.

Hm... Using gRPC stack without HxGrid looks well.
There is no issue with "self cancelling token".
    protected async Task HandleClickAsync()
    {
        if (ts != null)
        {
            ts.Cancel();
            ts.Dispose();
        }
        ts = new CancellationTokenSource();
        await CountryFacade.GetCountriesAsync(new DataFragmentRequest<CountryVM> { StartIndex = 0, Count = 100 }, ts.Token);
    }

Does NOT reproduce with HttpClient (no grpc):
This works well:
 public async Task<GridDataProviderResult<CountryVM>> GetCountriesAsync(GridDataProviderRequest<CountryVM> request)
    {
        DataFragmentRequest<CountryVM> dataFragmentRequest = new()
            {
                StartIndex = request.StartIndex,
                Count = request.Count
            };

        await HttpClient.GetAsync("/slow", request.CancellationToken);

        return new()
            {
                Data = Enumerable.Repeat(new CountryVM { IsoCode = "IsoCode" }, request.Count.Value),
                TotalCount = 10000
            };
    }

Virtualize (instead of HxGrid) with gRPC also works well.
<Virtualize TItem="CountryVM" ItemsProvider="GetDataAsync">
    <p>@context.IsoCode</p>
</Virtualize>

   public async ValueTask<ItemsProviderResult<CountryVM>> GetDataAsync(ItemsProviderRequest request)
    {
        DataFragmentRequest<CountryVM> dataFragmentRequest = new()
            {
                StartIndex = request.StartIndex,
                Count = request.Count
            };
        var result = await CountryFacade.GetCountriesAsync(dataFragmentRequest, request.CancellationToken);

        return new ItemsProviderResult<CountryVM>(result.Data, result.TotalCount);
    }

Reprosteps: https://github.com/jirikanda/HxGridInfiniteScrollNet7Repro
Just run HomeIndex.razor, scroll, scroll, scroll up/down and watch the console (an error with red line does NOT kill the page).
FYI, @hakenr

Note: Disabling the CancellationWorkaroundGrpcClientInterceptor does break the Virtualize cancellation feature (the original exception still does not contain original CancellationToken).

Reduced the repro to plain Blazor WASM with Grpc.Net.Client.Web + reported to MSFT:
https://github.com/dotnet/aspnetcore/issues/46011

Fixed in .NET 7.0.4

authors: alexax578 hakenr jirikanda


text:
Unable to load preload script: .../electron-flutter/preload.js

Hey,
Thank you for this interesting template :smiley:
Unfortunately, I cannot get it to work: Neither npm run dev nor npm run build works on my machine.
After following the instructions I don't get the Flutter Hello, World! screen.
When opening the developer console in the application, I see the following output:

electron/js2c/renderer_init.js:91 Unable to load preload script: /home/elias/electron-flutter/preload.js
electron/js2c/renderer_init.js:91 Error: Cannot find module '/home/elias/electron-flutter/preload.js'
    at Module._resolveFilename (internal/modules/cjs/loader.js:972)
    at Function.i._resolveFilename (electron/js2c/renderer_init.js:35)
    at Module._load (internal/modules/cjs/loader.js:848)
    at Function.f._load (electron/js2c/asar_bundle.js:5)
    at Object.<anonymous> (electron/js2c/renderer_init.js:91)
    at Object../lib/renderer/init.ts (electron/js2c/renderer_init.js:91)
    at __webpack_require__ (electron/js2c/renderer_init.js:3)
    at electron/js2c/renderer_init.js:3
    at ___electron_webpack_init__ (electron/js2c/renderer_init.js:3)
    at electron/js2c/renderer_init.js:172
electron/js2c/renderer_init.js:111 Electron Security Warning (Insecure Content-Security-Policy) This renderer process has either no Content Security
    Policy set or a policy with "unsafe-eval" enabled. This exposes users of
    this app to unnecessary security risks.

For more information and help, consult
https://electronjs.org/docs/tutorial/security.
This warning will not show up
once the app is packaged.

I am running a Linux system, though I don't know if that's related to the problem :sweat_smile:
Best regards,
Elias

fixed in https://github.com/hayderux/electron-flutter/commit/4c799a82b729936cdd18d7bcc03a328188ef2d4e

repo: hayderux/electron-flutter


text:
Getting ready for bzlmod

It would be good to get bazel_ruloes_hdl ready for bzlmod and add a MODULE.bazel.
https://bazel.build/external/migration
The oldest currently still maintained bazel 5 (and that can only work with old-school WORKSPACE ) is on the way out at the end of the year , bazel 6 allows to have bzlmod enabled and bazel 7 enables it by default.

Are there any updates here? I'm finding it very painful to use this with modules and would appreciate some guidance on the correct approach to do so in the interim.

authors: MaxwellBo hzeller


text:
没有EXE文件怎么用？

可否发布的时候带上 exe方便粉丝追更。

README 上面有下载地址。


text:
🛑 stagin-env is down

In 133b523, stagin-env (https://staging.lessonpal.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: stagin-env is back up in 856aab4 after 7 minutes.

repo: heIsThePirate/upptime-lessonpal


text:
app: plugins: Fix validateArchiveURL to support github/gitlab/bitbucket

So release tar.gz files can be put on there.

For some reason my local npm run format is not working the same as CI.

While this adds some extra security that we only allow downloading from managed services like these, theoretically plugins can be hosted anywhere, e.g. GitHub / Cloudflare pages, NPM repos,... So we should understand whether this is short list is really needed.

Fixed a test failure.

authors: illume joaquimrocha


text:
Screenshots

Is it possible to add support for screenshot generation?

Surf is only an HTTP user-agent, it doesn't actually do any rendering. Sorry!

repo: headzoo/surf


text:
Can't build on Win 10

Describe the bug
Can't build on Win 10
C:\Programs\label-studio>npm run start

> label-studio@0.1.6 start C:\Programs\label-studio
> npm run copy-examples && react-scripts start

> label-studio@0.1.6 copy-examples C:\Programs\label-studio
> bash scripts/copy.sh
Starting the development server...
Failed to compile.

./src/env/development.js
Module not found: Can't resolve '../examples/audio_classification' in 'C:\Programs\label-studio\src\env'

@Dene33
Thank you, need to configure bash script for Windows environment. (https://github.com/heartexlabs/label-studio/blob/master/scripts/copy.sh). The next release will be with functionality.
But if you want to use LS with python backend you can run without development configuration:

Docs: https://labelstud.io/guide/backend.html
Docker:

docker run -p 8200:8200 -t -i heartexlabs/label-studio -c config.json -l ../examples/chatbot_analysis/config.xml -i ../examples/chatbot_analysis/tasks.json -o output

The frontend part is moved to https://github.com/heartexlabs/label-studio-frontend
Please, report there if the problem still exists.

authors: Dene33 niklub shevchenkonik

repo: heartexlabs/label-studio


text:
Installation issues

Hi, I have tried to install gemBS in multiple ways: gemBS, gemBS-rs, container images(like singularity), and Bioconda.

gemBS/gemBS-rs: failing compilation (I have attached parts of words from the errors when I tried gemBS-rs compiling.) , it seems to have a
errors.txt
errors.txt

similar issue when it passed around bcf tools even in gemBS.

container image- it works but when I even tried to check the example run from the tutorials gemBS prepare -c example.conf -t example.csv. It says either example.conf does not exist or example.csv does not exist although I have run the code in the folder which has both files.

Bioconda download is consistently failed as well. I tried to install other programs like samtools etc., and all of them worked. I checked if it exists using conda search, and it showed that bioconda channel has gemBS but the connection was frozen and not moving forward.

I'm very frustrated since I can't even compile gemBS or run the tutorial data set (the 1st step: "prepare" part).

Sorry to hear about your problems with installation and testing.  From the error files you provide it looks as though you will need to install libssl and libcom_err to be able to finish compilation.
For the container issues - can you tell me which version of singularity you are using?  With earlier versions (2.x I think) it was often the case that only the home filesystem was mounted by default in the container, so if you ran it from a mounted filesystem (I see you were running on gpfs) it is possible that the files were not accessible.  In the instructions for the previous version of gemBS (v3) I included instructions for dealing with this issue (see http://statgen.cnag.cat/gemBS/v3/UserGuide/_build/html/containers.html)

Thank you for the reply.
I am using school’s HPC and they are not allowed to let me use sudo for installing it. So, I have tried now in my local setting but it still seems to have issues.
I have attached the error after installing all required things including libssl and libcom_err.
And, I will try it with singularity issue as well.
From: Simon @.>
Sent: Thursday, March 25, 2021 4:32 AM
To: @.>
Cc: Yuna @.>; @.>
Subject: Re: [heathsc/gemBS-rs] Installation issues (#3)
Sorry to hear about your problems with installation and testing. From the error files you provide it looks as though you will need to install libssl and libcom_err to be able to finish compilation.
For the container issues - can you tell me which version of singularity you are using? With earlier versions (2.x I think) it was often the case that only the home filesystem was mounted by default in the container, so if you ran it from a mounted filesystem (I see you were running on gpfs) it is possible that the files were not accessible. In the instructions for the previous version of gemBS (v3) I included instructions for dealing with this issue (see http://statgen.cnag.cat/gemBS/v3/UserGuide/_build/html/containers.htmlhttps://urldefense.com/v3/__http:/statgen.cnag.cat/gemBS/v3/UserGuide/_build/html/containers.html__;!!PhOWcWs!g7RSxwFJnrFUjkrm6GxSLVDt46dS5d2WsjUTyaKZpIJlSeuk0GPZ-1Uz4Yx1aMir_TY$)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/heathsc/gemBS-rs/issues/3*issuecomment-806464183__;Iw!!PhOWcWs!g7RSxwFJnrFUjkrm6GxSLVDt46dS5d2WsjUTyaKZpIJlSeuk0GPZ-1Uz4Yx1bS7ajo4$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ALGWH6K7VAEZQBIAG5I4VFTTFLYIDANCNFSM4ZY23U3Q__;!!PhOWcWs!g7RSxwFJnrFUjkrm6GxSLVDt46dS5d2WsjUTyaKZpIJlSeuk0GPZ-1Uz4Yx1qNQcWdc$.
@.VirtualBox:~/gemBS-rs$ make install
make -f Makefile.gemBS install
make[1]: Entering directory '/home/yuna/gemBS-rs'
make -C c_tools
make[2]: Entering directory '/home/yuna/gemBS-rs/c_tools'
make --directory=gem3-mapper
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper'
make --directory=resources release
make[4]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/resources'
make[4]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/resources'
make --directory=src release
make[4]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src'
make --directory=align release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/align'
make --directory=pattern release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/align/pattern'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/align/pattern'
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/align'
make --directory=approximate_search release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/approximate_search'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/approximate_search'
make --directory=archive release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive'
make --directory=builder release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive/builder'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive/builder'
make --directory=search release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive/search'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive/search'
make --directory=score release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive/score'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive/score'
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive'
make --directory=filtering release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering'
make --directory=candidates release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering/candidates'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering/candidates'
make --directory=region release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering/region'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering/region'
make --directory=region_profile release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering/region_profile'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering/region_profile'
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering'
make --directory=fm_index release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/fm_index'
make --directory=sa_builder release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/fm_index/sa_builder'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/fm_index/sa_builder'
make --directory=bwt release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/fm_index/bwt'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/fm_index/bwt'
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/fm_index'
make --directory=gpu release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/gpu'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/gpu'
make --directory=io release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/io'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/io'
make --directory=mapper release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/mapper'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/mapper'
make --directory=matches release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches'
make --directory=align release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches/align'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches/align'
make --directory=classify release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches/classify'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches/classify'
make --directory=scaffold release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches/scaffold'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches/scaffold'
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches'
make --directory=neighborhood_search release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/neighborhood_search'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/neighborhood_search'
make --directory=profiler release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/profiler'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/profiler'
make --directory=search_pipeline release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/search_pipeline'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/search_pipeline'
make --directory=stats release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/stats'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/stats'
make --directory=system release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/system'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/system'
make --directory=text release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/text'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/text'
make --directory=utils release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/utils'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/utils'
make --directory=tools release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/tools'
make --directory=interface release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/tools/interface'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/tools/interface'
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/tools'
make[4]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src'
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper'
make --directory=htslib && make --directory=htslib install
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools/htslib'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools/htslib'
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools/htslib'
mkdir -p -m 755 /home/yuna/gemBS-rs/c_tools/tmp_root/bin /home/yuna/gemBS-rs/c_tools/tmp_root/include /home/yuna/gemBS-rs/c_tools/tmp_root/include/htslib /home/yuna/gemBS-rs/c_tools/tmp_root/lib /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man1 /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man5 /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man7 /home/yuna/gemBS-rs/c_tools/tmp_root/lib/pkgconfig
if test -n ""; then mkdir -p -m 755 ; fi
install -p -m 644 libhts.so /home/yuna/gemBS-rs/c_tools/tmp_root/lib/libhts.so.1.11
ln -sf libhts.so.1.11 /home/yuna/gemBS-rs/c_tools/tmp_root/lib/libhts.so
ln -sf libhts.so.1.11 /home/yuna/gemBS-rs/c_tools/tmp_root/lib/libhts.so.3
sed -e @.@@.@@***.**PACKAGE_VERSION@#1.11#g' htslib.pc.tmp > /home/yuna/gemBS-rs/c_tools/tmp_root/lib/pkgconfig/htslib.pc
chmod 644 /home/yuna/gemBS-rs/c_tools/tmp_root/lib/pkgconfig/htslib.pc
install -p bgzip htsfile tabix /home/yuna/gemBS-rs/c_tools/tmp_root/bin
if test -n ""; then install -p  ; fi
install -p -m 644 htslib/.h /home/yuna/gemBS-rs/c_tools/tmp_root/include/htslib
install -p -m 644 libhts.a /home/yuna/gemBS-rs/c_tools/tmp_root/lib/libhts.a
install -p -m 644 bgzip.1 htsfile.1 tabix.1 /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man1
install -p -m 644 faidx.5 sam.5 vcf.5 /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man5
install -p -m 644 htslib-s3-plugin.7 /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man7
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools/htslib'
make --directory=htslib -f Makefile.bgzip-shared bgzip-shared && cp htslib/bgzip-shared /home/yuna/gemBS-rs/c_tools/tmp_root/bin/bgzip
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools/htslib'
gcc -fvisibility=hidden  -o bgzip-shared bgzip.o -L. -lhts -llzma -lbz2 -lz -lm   -lcurl -lcrypto -lpthread
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools/htslib'
make --directory=samtools all
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools/samtools'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools/samtools'
make bin/bcftools
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools'
make --directory=bcftools all
make[4]: Entering directory '/home/yuna/gemBS-rs/c_tools/bcftools'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/home/yuna/gemBS-rs/c_tools/bcftools'
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools'
make[2]: Leaving directory '/home/yuna/gemBS-rs/c_tools'
make -C rust
make[2]: Entering directory '/home/yuna/gemBS-rs/rust'
GEMBS_INSTALL_ROOT=/usr/local/lib/gemBS RUSTFLAGS="-L /home/yuna/gemBS-rs/c_tools/tmp_root/lib" cargo build --release
/bin/sh: 1: cargo: not found
make[2]: *** [Makefile:10: all] Error 127
make[2]: Leaving directory '/home/yuna/gemBS-rs/rust'
make[1]: *** [Makefile.gemBS:60: rust] Error 2
make[1]: Leaving directory '/home/yuna/gemBS-rs'
make: *** [Makefile:7: install] Error 2

It looks like you might not have rust installed in your local setting.  Have you tried installing with:
curl https://sh.rustup.rs -sSf > rust.sh && sh rust.sh -y
?

Thank you for suggesting. So, I previously installed the rust but I reinstalled again and it works until last moment and it made executable gemBS but it showed these errors:
Finished release [optimized] target(s) in 21m 29s
cp target/release/gem_bs bin/gemBS
cp target/release/read_filter bin/
cp target/release/bs_call bin/
cp target/release/snpxtr bin/
cp target/release/mextr bin/
cp target/release/dbsnp_index bin/
make[2]: Leaving directory '/home/yuna/gemBS-rs/rust'

copy shell script gemBS to a directory in your PATH (i.e., /usr/local/bin or /home/yuna/bin)

echo "#!/bin/sh" > gemBS
echo 'LD_LIBRARY_PATH=/usr/local/lib/gemBS/lib:$LD_LIBRARY_PATH /usr/local/lib/gemBS/bin/gemBS $@' >> gemBS
chmod 755 gemBS
mkdir -p /usr/local/lib/gemBS
mkdir: cannot create directory ‘/usr/local/lib/gemBS’: Permission denied
make[1]: *** [Makefile.gemBS:65: /usr/local/lib/gemBS] Error 1
make[1]: Leaving directory '/home/yuna/gemBS-rs'
make: *** [Makefile:7: install] Error 2
So, I tried to execute again with sudo make install. But, it was not working and I did delete whole gemBS_rs folder and re-install all the things again. And, I still get the similar empty container error and it was not resolved by installing rust again. Interestingly, if I execute “make install” not “ sudo make install”, I got the similar error again from the first attempt->
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools/htslib'
mkdir -p -m 755 /home/yuna/gemBS-rs/c_tools/tmp_root/bin /home/yuna/gemBS-rs/c_tools/tmp_root/include /home/yuna/gemBS-rs/c_tools/tmp_root/include/htslib /home/yuna/gemBS-rs/c_tools/tmp_root/lib /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man1 /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man5 /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man7 /home/yuna/gemBS-rs/c_tools/tmp_root/lib/pkgconfig
if test -n ""; then mkdir -p -m 755 ; fi
install -p -m 644 libhts.so /home/yuna/gemBS-rs/c_tools/tmp_root/lib/libhts.so.1.11
install: cannot remove '/home/yuna/gemBS-rs/c_tools/tmp_root/lib/libhts.so.1.11': Permission denied
make[3]: *** [Makefile:562: install-so] Error 1
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools/htslib'
make[2]: *** [Makefile:43: /home/yuna/gemBS-rs/c_tools/tmp_root/include/htslib/hts.h] Error 2
make[2]: Leaving directory '/home/yuna/gemBS-rs/c_tools'
make[1]: *** [Makefile.gemBS:60: c_tools] Error 2
make[1]: Leaving directory '/home/yuna/gemBS-rs'
make: *** [Makefile:7: install] Error 2
I have attached the result(text files) from “sudo make install” after removing everything as well.
From: Simon @.>
Sent: Thursday, March 25, 2021 5:01 AM
To: @.>
Cc: Yuna @.>; @.>
Subject: Re: [heathsc/gemBS-rs] Installation issues (#3)
It looks like you might not have rust installed in your local setting. Have you tried installing with:
curl https://sh.rustup.rshttps://urldefense.com/v3/__https:/sh.rustup.rs__;!!PhOWcWs!h0IpLo0KXddX5-ETV1jDz-2Wycre7LPLtnTX19_bSN01h_mmrSYoaB_6kcBOs976vOM$ -sSf > rust.sh && sh rust.sh -y
?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/heathsc/gemBS-rs/issues/3*issuecomment-806481335__;Iw!!PhOWcWs!h0IpLo0KXddX5-ETV1jDz-2Wycre7LPLtnTX19_bSN01h_mmrSYoaB_6kcBO0H7eIms$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ALGWH6JLO2QEW56HZLX7QGLTFL3XFANCNFSM4ZY23U3Q__;!!PhOWcWs!h0IpLo0KXddX5-ETV1jDz-2Wycre7LPLtnTX19_bSN01h_mmrSYoaB_6kcBObw6R74A$.
make -C rust
make[2]: Entering directory '/home/yuna/gemBS-rs/rust'
cp gemBS/Cargo.toml.in gemBS/Cargo.toml
echo default = ["slurm"] >> gemBS/Cargo.toml
mkdir bin
GEMBS_INSTALL_ROOT=/usr/local/lib/gemBS RUSTFLAGS="-L /home/yuna/gemBS-rs/c_tools/tmp_root/lib" cargo build --release
/bin/sh: 1: cargo: not found
make[2]: *** [Makefile:10: all] Error 127
make[2]: Leaving directory '/home/yuna/gemBS-rs/rust'
make[1]: *** [Makefile.gemBS:60: rust] Error 2
make[1]: Leaving directory '/home/yuna/gemBS-rs'
make: *** [Makefile:7: install] Error 2
@.***VirtualBox:~/gemBS-rs$ curl https://sh.rustup.rs -sSf > rust.sh && sh rust.sh -y
info: downloading installer
info: profile set to 'default'
info: default host triple is x86_64-unknown-linux-gnu
warning: Updating existing toolchain, profile choice will be ignored
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: default toolchain set to 'stable-x86_64-unknown-linux-gnu'
stable-x86_64-unknown-linux-gnu unchanged - rustc 1.50.0 (cb75ad5db 2021-02-10)
Rust is installed now. Great!
To get started you need Cargo's bin directory ($HOME/.cargo/bin) in your PATH
environment variable. Next time you log in this will be done
automatically.
To configure your current shell, run:
source $HOME/.cargo/env
@.VirtualBox:~/gemBS-rs$ source $HOME/.cargo/env
@.VirtualBox:~/gemBS-rs$ sudo make install
make -f Makefile.gemBS install
make[1]: Entering directory '/home/yuna/gemBS-rs'
make -C c_tools
make[2]: Entering directory '/home/yuna/gemBS-rs/c_tools'
make --directory=gem3-mapper
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper'
make --directory=resources release
make[4]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/resources'
make[4]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/resources'
make --directory=src release
make[4]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src'
make --directory=align release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/align'
make --directory=pattern release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/align/pattern'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/align/pattern'
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/align'
make --directory=approximate_search release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/approximate_search'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/approximate_search'
make --directory=archive release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive'
make --directory=builder release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive/builder'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive/builder'
make --directory=search release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive/search'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive/search'
make --directory=score release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive/score'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive/score'
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/archive'
make --directory=filtering release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering'
make --directory=candidates release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering/candidates'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering/candidates'
make --directory=region release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering/region'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering/region'
make --directory=region_profile release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering/region_profile'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering/region_profile'
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/filtering'
make --directory=fm_index release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/fm_index'
make --directory=sa_builder release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/fm_index/sa_builder'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/fm_index/sa_builder'
make --directory=bwt release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/fm_index/bwt'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/fm_index/bwt'
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/fm_index'
make --directory=gpu release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/gpu'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/gpu'
make --directory=io release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/io'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/io'
make --directory=mapper release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/mapper'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/mapper'
make --directory=matches release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches'
make --directory=align release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches/align'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches/align'
make --directory=classify release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches/classify'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches/classify'
make --directory=scaffold release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches/scaffold'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches/scaffold'
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/matches'
make --directory=neighborhood_search release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/neighborhood_search'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/neighborhood_search'
make --directory=profiler release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/profiler'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/profiler'
make --directory=search_pipeline release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/search_pipeline'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/search_pipeline'
make --directory=stats release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/stats'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/stats'
make --directory=system release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/system'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/system'
make --directory=text release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/text'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/text'
make --directory=utils release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/utils'
make[5]: Nothing to be done for 'release'.
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/utils'
make --directory=tools release
make[5]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/tools'
make --directory=interface release
make[6]: Entering directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/tools/interface'
make[6]: Nothing to be done for 'release'.
make[6]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/tools/interface'
make[5]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src/tools'
make[4]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper/src'
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools/gem3-mapper'
make --directory=htslib && make --directory=htslib install
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools/htslib'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools/htslib'
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools/htslib'
mkdir -p -m 755 /home/yuna/gemBS-rs/c_tools/tmp_root/bin /home/yuna/gemBS-rs/c_tools/tmp_root/include /home/yuna/gemBS-rs/c_tools/tmp_root/include/htslib /home/yuna/gemBS-rs/c_tools/tmp_root/lib /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man1 /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man5 /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man7 /home/yuna/gemBS-rs/c_tools/tmp_root/lib/pkgconfig
if test -n ""; then mkdir -p -m 755 ; fi
install -p -m 644 libhts.so /home/yuna/gemBS-rs/c_tools/tmp_root/lib/libhts.so.1.11
ln -sf libhts.so.1.11 /home/yuna/gemBS-rs/c_tools/tmp_root/lib/libhts.so
ln -sf libhts.so.1.11 /home/yuna/gemBS-rs/c_tools/tmp_root/lib/libhts.so.3
sed -e @.@@.@@.**PACKAGE_VERSION@#1.11#g' htslib.pc.tmp > /home/yuna/gemBS-rs/c_tools/tmp_root/lib/pkgconfig/htslib.pc
chmod 644 /home/yuna/gemBS-rs/c_tools/tmp_root/lib/pkgconfig/htslib.pc
install -p bgzip htsfile tabix /home/yuna/gemBS-rs/c_tools/tmp_root/bin
if test -n ""; then install -p  ; fi
install -p -m 644 htslib/.h /home/yuna/gemBS-rs/c_tools/tmp_root/include/htslib
install -p -m 644 libhts.a /home/yuna/gemBS-rs/c_tools/tmp_root/lib/libhts.a
install -p -m 644 bgzip.1 htsfile.1 tabix.1 /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man1
install -p -m 644 faidx.5 sam.5 vcf.5 /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man5
install -p -m 644 htslib-s3-plugin.7 /home/yuna/gemBS-rs/c_tools/tmp_root/share/man/man7
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools/htslib'
make --directory=htslib -f Makefile.bgzip-shared bgzip-shared && cp htslib/bgzip-shared /home/yuna/gemBS-rs/c_tools/tmp_root/bin/bgzip
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools/htslib'
gcc -fvisibility=hidden  -o bgzip-shared bgzip.o -L. -lhts -llzma -lbz2 -lz -lm   -lcurl -lcrypto -lpthread
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools/htslib'
make --directory=samtools all
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools/samtools'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools/samtools'
make bin/bcftools
make[3]: Entering directory '/home/yuna/gemBS-rs/c_tools'
make --directory=bcftools all
make[4]: Entering directory '/home/yuna/gemBS-rs/c_tools/bcftools'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/home/yuna/gemBS-rs/c_tools/bcftools'
make[3]: Leaving directory '/home/yuna/gemBS-rs/c_tools'
make[2]: Leaving directory '/home/yuna/gemBS-rs/c_tools'
make -C rust
make[2]: Entering directory '/home/yuna/gemBS-rs/rust'
GEMBS_INSTALL_ROOT=/usr/local/lib/gemBS RUSTFLAGS="-L /home/yuna/gemBS-rs/c_tools/tmp_root/lib" cargo build --release
/bin/sh: 1: cargo: not found
make[2]: *** [Makefile:10: all] Error 127
make[2]: Leaving directory '/home/yuna/gemBS-rs/rust'
make[1]: *** [Makefile.gemBS:60: rust] Error 2
make[1]: Leaving directory '/home/yuna/gemBS-rs'
make: *** [Makefile:7: install] Error 2

By default the installation directory is /usr/local/lib/gemBS.  You can either run the install using sudo or change the installation directory by editing gemBS_config.mk.in  and re-running the install.
Simon

Hi Simon,
I have tried to install following your suggestion and it works. And, regarding the odd behavior in singularity run, it seems like my HPC-singularity has some issues with calling the program properly. It doesn’t have issues when I ran it in my local computer. I am asking my HPC people to install gemBS since I don’t have a permission but glad to know it doesn’t have an issue to install the program itself. Many thanks and I will close my ticket!
From: Simon @.>
Sent: Thursday, March 25, 2021 6:31 AM
To: @.>
Cc: Yuna @.>; @.>
Subject: Re: [heathsc/gemBS-rs] Installation issues (#3)
By default the installation directory is /usr/local/lib/gemBS. You can either run the install using sudo or change the installation directory by editing gemBS_config.mk.in and re-running the install.
Simon
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/heathsc/gemBS-rs/issues/3*issuecomment-806538076__;Iw!!PhOWcWs!jpzcfq9MyKyT_cOY9xOG6wgtZLxYUL7gMaZUKC70RB6_QJda9Neo1aGds0B522smIOg$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ALGWH6PT2RZWK5T3EVSQF3LTFMGIVANCNFSM4ZY23U3Q__;!!PhOWcWs!jpzcfq9MyKyT_cOY9xOG6wgtZLxYUL7gMaZUKC70RB6_QJda9Neo1aGds0B5NqN9PJQ$.

authors: heathsc sunabcun

repo: heathsc/gemBS-rs


text:
udp模式下断线重连后貌似不能调用更新脚本

使用了很多天，功能正常，非常稳定，但貌似有个小问题：
udp模式下断线重连后貌似不能调用更新脚本
我开了两个转发，一个tcp，一个udp，当pppoe拨号断线重连后，tcp模式下能正常调用更新脚本更新IP，udp模式下不能正常调用脚本。

上图两个，上面tcp是断线重连后自动调用的日志，下面udp的是我发现不能自动更新后手动杀掉进程重新运行后更新的日志

感谢反馈~ UDP我这不用，没能及时发现问题。刚尝试进行了修复，自测正常，请再确认:
https://github.com/heiher/natmap/releases/tag/20221111

感谢反馈~ UDP我这不用，没能及时发现问题。刚尝试进行了修复，自测正常，请再确认:
https://github.com/heiher/natmap/releases/tag/20221111

已经正常，感谢修复！

authors: heiher kwxiaozhu

repo: heiher/natmap


text:
dropFlowHere

https://github.com/heikokue/node-red/blob/4b2d5040bc709ca4e9b6c8356ebfe7021e533e0d/packages/node_modules/%40node-red/editor-client/locales/de/editor.json#L54
 "dropFlowHere": "Hier kann der Flow eingefügt werden",

@jwende Bitte schließen, wenn OK

@jwende Bitte schließen, wenn OK

authors: heikokue jwende

repo: heikokue/node-red


text:
Cache Levenshtein completions

Cache completions for subsequent calls.
Currently, if there is an early typo, we do Levenshtein on the complete set on every subsequent call. If we cache the top n results from the first call we likely save a lot of CPU and latency.
In a sense, that is: dynamically add prefixes with typos to the lookup table.

9a1658477999651d869baeb921ff442a8822fd91 adds the cache

repo: heimdalr/berlinplaces


text:
rm -rf is not a valid command on Windows

I tried to run npm install, but I got an error when it got to the rm -rf dist/ part of the package.json file.
https://github.com/hejianxian/vddl/blob/5ffb105ae49ba1fce59b9dd49161c7050d56bcc4/package.json#L11
One solution would be to include 'shx' and just prepend it infront of non-windows commands. Like they've done in this commit: https://github.com/ReactiveX/rxjs/pull/1681/files
I could submit a PR with it if you want.
I was planning on trying to fix the duplicate item bug as well (#4).

Of course, look forward to your PR!

@AWulkan  For bug #4 , do you have any ideas? I tried some methods, but none of them succeeded.

I will have to take a look at the code this weekend, probably sunday. It is crucial that it works for me since I'm using it for a real world application.
Before moving to this tool I had built a custom list of draggable items in normal JS, but it lacked nested groups, which later became a requirement by the client. So we moved to Vue and found this neat project. :)
Gonna close this issue and continue in #4.

authors: AWulkan hejianxian

repo: hejianxian/vddl


text:
[Addition]: Huge cluster of hummingbird miners in China XiaMenShi

Hotspot b58 Addresses
11sUtbsoD3ufVxbw4Gsq7qXLPucRXbtNg6XfscYy43iXKdqfSKE
11aZR9kz64wc84P3Q2TCKTjZRqAjAtL6JyonwpAE6YoS5uUwbrx
112sq9Q7txzHUXPygCeDp6XA9h4Y46TjNKtVhNaSEPzKNtYayMD
112XJ9rzkGHMdxzAnGWucS9jTbCPW3Q6rnb8QAUEkBMcEA5MsrHA
112rWdhHKTfu2nVY83qDDAu3yw7WNpbR8wSKFD3xMd4gntYCRADP
112EB9UJZsXhCJqz2wsit82AxDEDaLrqg9ZWrCZ4YWoAHmH4o4m4
11DG43dGGUn4DXMt39f1mxTkQnYn4noG4HWtwtAAhzFYEL9M2GH
118XWm7NqvrDRMkCf22rDNVbeiyHFoQpaDW3wMqaMU68MT56aZJ
112uHWpUxyEsa5EGhNyjBooNdzfHyejszRuDqKzwEA7Rw5sRkoSN
112EoJ3ZCujknknFn1sYyd7pmpMnxpLMkRLYbDqCsXzyTmEU7CeA
11x7M93gBQDkX7PyfwLU6a5wnUXPc8bxYdEL4YoEwpuUEhW74We
112pQGUZnMGnoY7WrFPod38giXYykB6AepaTQfSs65HNRF5rAarj
11KGwmKMJMLx6C3wAnsYbDDb2ZFfuHgCMYsCRmG3A1ke7u2t5Ev
1129SEvYubFHNk2w61bep8VPCWnPLVwiw92uMqWgq5iesJBG2Aad
112R6PZMiMh9TkWqrT2U8u1Si4h7wbujqLNdFzqauN2znqJs7pri
11kgRDTnkLTKuC1CNAVyrjZCufYaEogMLUQKr2xBxmPLocZmSb6
112HRHcPZD9UGqdjqeBmT8ZBmU8o62mgHg8bVcjNLgnzJwjuvpzk
112pmvbp4hC4N8Cm4PMp5nY1w4oo5AiX4hVr6JRv9Wx4xwiua1uK
112YgR1pM51NCABBZfgTjiLKbLzkUC1KNt46sQWQ6Vx1oC9uhCSR
112FaBrdQzFMVMpogAXGJFKdZRUQpTEVSGMqLWQDj9cdtz5iebg4
11uaoZMdz4HCFXSee1862ot8rFff1yqqtm24XpUCiuEisL4Z8pr
11oa9zq28qDjK3p9upond3QbPk8ydDqGw9hM1uwUctE5LLA3VUC
112YhQimP3tnA7bjLhgurd3JmmJsqekQbUMvjmtvnTkHip8QfdGJ
116fAFXr6ukT3ZN3e2Gjii3NfQ7a36DYTbRJzNUadPKKCFHMGvw
11zwxaMa8ihAdxhENbf8DwqQW2z1LEwB98moNHgyq1MLA8VgmHZ
1126YWyDeoZU475BuEgCqDdNzM8Scng4jjqgQHnzbLFHbrrvZ1c
112wgcZn9EoKRtRwQxKqtBG6cKN8QnkDZ2qJtUC4tCCsWEiRQBKy
118MjMSNBMRwMcR96uF1hDeQfy2QM313hPyst496qTvZXEzPAC6
11rUUz6EG9k64qujWvQwvxTJKhfXoCt9t8FHtz59TuawX4ZjHM2
112FyfoEWV2UYPqJxNeTGMSMZVntpQaGjvF465aes7HxTheQ3FYS
112VP16CNT1MPKmTmb6vycy65VmNE9Bbjoj9DbAH8MfwRfFUHMmf
Discord Handle
No response
Reason(s)
They only witness hummingbird hotspots, with no exception, I checked more than 10 hotspots, and they all only witness each other.
One of them always witnesses the same other 14 hotspots.

They all belong to the same wallet address, exactly 20 of them.

Already added

repo: helium/denylist


text:
[Addition]: Same maker witnessing cluster

Hotspot b58 Addresses
11Y2jhoVFX2jL8LRaTGqJFHysjCg96yCDChLfnNzKDLNYnmY1U8
11u1jnr7fPMcStCMH3HqDw1MnL1H1KzvwReB7eifJ7rDyzLkXLA
11TdSNJ47KxHPdRvuaB98TPJf5UETmieEcCEDu1f5LZRbXbauNG
11rYQzC5AKksq5vzEgWozDM5xrobEzhnyHv7veLP5RM4vtKo2j5
11mqSedARWDpCt4b28kYiSzJ1j6SmThm8PCBRbXXSVk5bxzVS8h
11mpUSRQbFgqQkUVeT52dEwD2yZ4ZxagkPzHmdzhjdmJsqBemwC
11M6upkfdYT8yExRQCgig7Zbkv4qB9KCRjsAbEDG83yt7cJmveZ
11h6m8XoDdayyMFCWi7abS2JDkNsNdk1JJakrkxWZUcc7nnR2Ks
11eRAq4Qhfu93AgizhnKH5X6bf7Dm59t8ovbRoDbWH5PtbhQ3nJ
11EPDYGYReu1NLZwZmHPYY6QGtueb24dy2H1CPj95SgSTLgf5Zr
11efxmc9tAFA6pdM4UjKGgcPmXo91uWUbVheWis9iMMtjD62fv3
11e1BiEsT6e19NxuUmrYTdMn7vjLNjZDsq28WXKshA5f3UXwSqK
11cFLfiV1rXVWEXPK2YA1sccta4KguYTHKUXG1sqsccA6CCnmHS
11BR7KNm3qFUDbNGrsyyU3mHcaHxUMFB7W94yZZppJ62djkG28T
117aB7mSqF7YWZF36jv2FdXjdaz2aEVyGF25z3uBCqoQ1iDdTR1
116BygYzYrBY2rMwL8ys1Qubb93yWCy4MEFHMD9KfsmqfEwtP3t
1146qbhV5y9xRReevqLkxnTCWYffPqggejF7KSoJEbiYLmw75Bn
112WC9RTRa3AgKKskHvXzHmRwygB8sPpT7qWTTo349rz9jAtzYr7
112W3vCXtfd2TfLrj8Hv1UP5DLsHVBQbxsjvX2jDRNLHFgC7TXBn
112t1GW89PaHJznN44iNZgHpniFEeV8yiMfdQGaZs1LTrMMi5gDw
112saaUTk1B87nAxszW38HQffo6Km5Pr9jGfj2ywFUhJ5ZPhHhM1
112Q9BvqPcsXgcRLxLfbVPxFzSuWFNZ32LnJEUgcrapubNXWAxoT
112PGfdhS9Ff9wY6q5VLvLykFjHkosgzpxDL3WDQoBPQDuEK3cBk
112kQ3ZA7tC4oS1j2HDW9JbhKfZb6CmCdSewY9s23q4SY9DCGmHY
112EYKTXTMxuq3pMeqpoRVutReySpjf8QLVeYkAesKa9nvPK7FUm
112DD5a7rDoGdDrDjMn9pJb6LGnWBWFMCZHEtNdntgRCtZJjBqi6
112bUqKBfR44gHcGw1LZDBGRyYQWTHGP68pdc9cLsYQNMa9jEYMX
112BuaAQGMDmH4You1M8Xy9JnWCWp2a4J7CZRUS7cpaSxt8PWWX
1128ZX6PExKrYTqFMCzxFsCaEBNoxZPxLTm5dgZkSrhgifUi5URf
1127wEBXioitCneVqqR6Q5BGgRRhXCRLrUefJr9wwJbAWP33bgeC
1123y4a4gBVNUnVPZSXwAhNsqaAxV8Bh6bJFtyokRLvG8vfZ25X4
1117wafV7YZdP5d6gDfXhGkuzuSTsF7yA9jngKAc7DxC1dh8EwC
Discord Handle
No response
Reason(s)
Some clusters witnessing only same maker.
Some different rssi/snr/distance patterns.
Witnessing cross country / cross continent and not seeing other makers.

query_result_2022-04-25T15_23_12.789028-04_00.csv

High clique size. Short assertion times.


text:
[Removal]: 3 nebras mistakenly linked to Dusun & Heltec cluster in Kuala Lumpur

Hotspot Name
Zesty Tweed Puppy
Hotspot b58 Address
112vpZBQtNeNRAKXiWKguwDzMCuTFqq9ZkjjZ5yQsEcrUSq5tjh4
Discord Handle
No response
Hotspot Manufacturer
Nebra
Removal Reason
Hotspot reported in error due to packet stuffing
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information
In #7648 I reported a spoofed cluster of heltec and dusun in Kuala lumpur
Several owners raised issues in github and discord that this included a mistake and several nebra had been mistakenly included.
From further review (see notes in #7648) I've confirmed I did make a mistake and these 3 nebra should not have been included. It seems likely they were caught up as the cluster may have been packet stuffing from the local area. There is no suggestion that these 3 nebra were involved in this gaming.
As such these 3 nebra should be removed from the denylist - sorry for the error here.
112vpZBQtNeNRAKXiWKguwDzMCuTFqq9ZkjjZ5yQsEcrUSq5tjh4
11TSADJCsRxudhN9BcEWCBhypeb4Swt9K7Gh272jAJAyM4uLbTx
11QHvffzQF1BkudW8iCzhRqQfgkmFdhsTn2QyhX2kiBoRjQPgna
@6CornerDefender
@matkool
@evilman3624
and I think @vinc69 (can't be sure you are the other owner)

Hi, may I know when the deny list will be removed as almost 1 week there are no reward receive, we been added into deny list without any compensation. I no expect any compensation but just urge your side to remove us as soon as possible


text:
CSV export should be able to show all fees or expenses (e.g. location assert)

Some users may be using CSV exports to hand off to their accounting department, and so the transactions that get included in the CSV should probably include anything that could be counted as an expense.
Relevant code in /components/ExportCSV/ExportModal:
const { address } = this.props
    const { startDate, endDate, txn, fee } = this.state

    const filterTypes = []
    if (txn.includes('payment')) filterTypes.push('payment_v1', 'payment_v2')
    if (txn.includes('reward')) filterTypes.push('rewards_v1')

    const list = await this.client.account(address).activity.list({
      filterTypes,
    })

Need to look into it more, but I think it could look something like adding a line like this:
    if (txn.includes('fee')) filterTypes.push('assert_location_v1', '...')

And it could potentially just be an option instead of the default behaviour.
Relevant conversation here: https://discord.com/channels/404106811252408320/750533049623773304/786412623377858560

My wish is for an option to include all transactions that affect the balance (positive or negative). These transactions seem to be visible in the UI, so would be great to include in the export csv file as well. Most likely use case is for accounting. If you think they should not be included by default, that is OK, as long as there is an option to include all.

authors: danielcolinjames jiceorange

repo: helium/explorer


text:
Adds keypair from/into_bytes implementation

This  does not implement the higher level keypair independent encoding used by the wallet

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@7cc976a). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #1   +/-   ##
=======================================
  Coverage        ?   94.40%
=======================================
  Files           ?        5
  Lines           ?      125
  Branches        ?        0
=======================================
  Hits            ?      118
  Misses          ?        7
  Partials        ?        0

Continue to review full report at Codecov.

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

authors: codecov-io madninja

repo: helium/helium-crypto-rs


text:
Refactored library to be log-agnostic

BC is completely broken, but it is fine for 0.x IMO. The next step is to do the hook for https://github.com/uber-go/zap, update some examples and release 1.0 with api stabilisation.

👍

+1

authors: rafaeljesus stefvaessen vgarvardt

repo: hellofresh/stats-go


text:
rabbitmqctl list_queues return protocol undefined error

Version of Helm and Kubernetes:
# helm version
Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
# kubectl version
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.3", GitCommit:"435f92c719f279a3a67808c80521ea17d5715c66", GitTreeState:"clean", BuildDate:"2018-11-26T12:57:14Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.3", GitCommit:"435f92c719f279a3a67808c80521ea17d5715c66", GitTreeState:"clean", BuildDate:"2018-11-26T12:46:57Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
rabbitmq
What happened:
When deploy rabbitmq helm chart on k8s with istio enabled, return protocol undefined error as follow.
bash-4.2$ rabbitmqctl list_queues
Timeout: 60.0 seconds ...
Listing queues for vhost / ...
name    messages
test    0
** (Protocol.UndefinedError) protocol Enumerable not implemented for :error. This protocol is implemented for: Date.Range, File.Stream, Function, GenEvent.Stream, HashDict, HashSet, IO.Stream, List, Map, MapSet, Range, Stream
    (elixir) lib/enum.ex:1: Enumerable.impl_for!/1
    (elixir) lib/enum.ex:141: Enumerable.reduce/3
    (elixir) lib/stream.ex:923: Stream.do_enum_transform/7
    (elixir) lib/enum.ex:1942: Enum.reduce_while/3
    (rabbitmqctl) lib/rabbitmq/cli/core/output.ex:45: RabbitMQ.CLI.Core.Output.print_output_0/3
    (rabbitmqctl) lib/rabbitmq/cli/core/output.ex:31: RabbitMQ.CLI.Core.Output.print_output/3
    (rabbitmqctl) lib/rabbitmqctl.ex:132: RabbitMQCtl.process_output/3
    (rabbitmqctl) lib/rabbitmqctl.ex:36: RabbitMQCtl.main/1

What you expected to happen:
Hope the queues can be listed out successfully.
How to reproduce it (as minimally and precisely as possible):
Deploy rabbitmq helm chart with envoy sidecar.
Anything else we need to know:

There is the analysis of this issue from rabbitmq support team:
https://groups.google.com/forum/#!topic/rabbitmq-users/KZeZcpj_EmA
Here is the service definition of internal service:
apiVersion: v1
kind: Service
metadata:
  name: {{ template "rabbitmq.fullname" . }}
  labels:
    app: {{ template "rabbitmq.name" . }}
    chart: {{ template "rabbitmq.chart" .  }}
    release: "{{ .Release.Name }}"
    heritage: "{{ .Release.Service }}"
spec:
  type: ClusterIP
  clusterIP: None
  ports:
  - name: epmd
    port: 4369
    targetPort: epmd
  - name: dist
    port: {{ .Values.rabbitmq.amqpPort | add 20000 }}
    targetPort: dist
  selector:
    app: {{ template "rabbitmq.name" . }}
    release: "{{ .Release.Name }}"

Hi @haiyangu
What version of the RabbitMQ chart are you using? The current templates uses to define the RabbitMQ services (both the svc and the svc-headless) are very different. See:

https://github.com/helm/charts/blob/master/stable/rabbitmq/templates/svc-headless.yaml
https://github.com/helm/charts/blob/master/stable/rabbitmq/templates/svc.yaml

What do you obtain when running the command below?
$ helm search stable/rabbitmq

Please note you can update the chart to the latest version by running the command: $ helm repo update

repo: helm/charts


text:
[stable/keycloak] Upgrade to newer keycloak version

Is this a request for help?:
Yes
I am currently using the Helm chart version: 4.6.1 and I want to upgrade to the newest one. When looking at the documentation, there are a few steps needed to upgrade to the latest Keycloak version. What kind of upgrade process is needed when using this Helm chart?

@unguiculus @thomasdarimont

The Keycloak chart here is being deprecated (#13316) and moved to a new home:
https://github.com/codecentric/helm-charts
I'm closing this issue. Feel free to open a new issue in the new repo. Thanks.

authors: juv unguiculus


text:
[stable/concourse] Default baggageclaimDriver to detect

Is your feature request related to a problem? Please describe.
A long time ago (https://github.com/helm/charts/commit/8e9a005c76cd0cadbe9751c5c27b6b79c733aeac#diff-95cc28250f44d26990fee96ad2fbd63d), it was taken the decision that, by default, naive should be used as the baggageclaim driver.
While it's true that naive is the most compatible driver (it uses plain cps and directory creations instead of subvolumes / snapshots), it's also the slowest and the one that leads to the most amount of disk utilization (it assumes no copy-on-write capabilities).
This leads to folks running Concourse workers using the naive driver and seeing a lot of slowness when they first try it out.

Describe the solution you'd like
Since then, detect was implemented - a way of letting the worker figure out which driver to choose from the set of possible drivers:
	if cmd.Driver == "detect" {
		if supportsBtrfs {
			cmd.Driver = "btrfs"
		} else if kernelSupportsOverlay {
			cmd.Driver = "overlay"
		} else {
			cmd.Driver = "naive"
		}
	}

(from https://github.com/concourse/baggageclaim/blob/6fee2c8029decd1325b5e9d6d4069ea4a7c4578d/baggageclaimcmd/driver_linux.go#L52-L60).
My proposal is to switch from naive as a default to detect.
Thanks!

👀

https://github.com/helm/charts/pull/15680 🙌

🙌

🙌


text:
[stable/kube2iam] Allow the use of a specific image digest

What this PR does / why we need it:
Using a digest ensures the image being pulled has not been compromised and allows testing release against images without having to tag them.
Special notes for your reviewer:
This pr is closely based on https://github.com/helm/charts/pull/8910
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] title of the PR contains starts with chart name e.g. [stable/chart]

/assign @unguiculus

Placing on hold until https://github.com/helm/charts/issues/13449 is resolved.
/hold

authors: drastawi jlegrone


text:
[stable/postgresql] servicemonitor resource for prometheus operator

What this PR does / why we need it:
Add a servicemonitor resource for prometheus operator
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @desaintmartin

By the way, remember to rebase your branch from master to resolve the conflicts in the Chart.yaml

/ok-to-test
/lgtm


text:
[stable/nginx-ingress] respect build numbers usage in nginx-ingress versioning (#17775)

[stable/nginx-ingress] respect build numbers usage in nginx-ingress versioning (#17775)
Signed-off-by: Erhan Kesken erhankesken@gmail.com
What this PR does / why we need it:
We want to use build versions to track our private changes over upstream charts, with a convention like that:
<ORIGINAL_VERSION>+<TEAM_NAME>.<TEAM_VERSION>
ex: v0.7.0+cre.01

Which is compatible with semver rules, but this kind of versioning ends up with following error for nginx-ingress chart:
Error: release nginx-ingress failed: PodDisruptionBudget.policy "nginx-ingress-controller" is invalid: metadata.labels: Invalid value: "nginx-ingress-1.7.0+cre.01": a valid label must be an empty string or consist of
alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyValue',  or 'my_value',  or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?')

We should respect semver, and allow usage of build numbers in chart version, for that it's enough to replace + with _ before using in label fields, with a template function.
Which issue this PR fixes

fixes #17775

Special notes for your reviewer:
We considered just using - instead of +, because semver + means build number, - means prebuild. And prebuilds are ignored by helm upgrade/install commands
if you're using a Helm repo over HTTP and do not pass chart version explicitly.
See github.com/Masterminds/semver/constraints.go#L212-L217
Issue #21: Per the SemVer spec (section 9) a pre-release is unstable and might not satisfy the intended compatibility.
The change here ignores pre-releases on constraint checks (e.g., ~ or ^) when a pre-release is not part of the constraint.
For example, ^1.2.3 will ignore pre-releases while ^1.2.3-alpha will include them.

So semver library used by Helm is skipping pre releases on purpose. If you use v0.7.0-cre.01 as, then you'll get an error
like this Error: chart "cert-manager" not found in http://127.0.0.1:8879 repository.
Checklist

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

/ok-to-test
/lgtm
Thanks!

authors: ChiefAlexander ekesken


text:
[stable/kubewatch] Unify and refactor README.md

Signed-off-by: Carlos Rodriguez Hernandez crhernandez@bitnami.com
What this PR does / why we need it:
Unify and refactor README.md across charts
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] DCO signed
[X] Chart Version bumped
[X] Variables are documented in the README.md
[X] Title of the PR starts with chart name (e.g. [stable/mychartname])

/lgtm
/ok-to-test

authors: carrodher javsalgar


text:
[stable/vsphere-cpi] Update for CPI v1.2.1

What this PR does / why we need it:
This PR makes the following updates:

bumps the version of the CPI chart to the latest release v1.2.0 (https://github.com/kubernetes/cloud-provider-vsphere/releases/tag/v1.2.1)
When the option to generate the configmap is selected, the YAML based cloud-config is generated instead of INI
updates to RBAC needed for CPI
uses stringdata instead of base64 encoding secret data
the security context is set to true now and the runAs is set to the new non-root user 1001 as supported in the CPI image
useHostNetwork: true is default set to true

Which issue this PR fixes
NA
Special notes for your reviewer:
Tested using on vSphere 7.0:

configmap generation
provided my own configmap

Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/assign @andrewsykim


text:
Annotation "helm.sh/resource-policy": keep not honored when uninstalling

Output of helm version:
version.BuildInfo{Version:"v3.7.2", GitCommit:"663a896f4a815053445eec4153677ddc24a0a361", GitTreeState:"clean", GoVersion:"go1.16.10"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.11", GitCommit:"38d3c1f3d5306401bcf39a71bad3b5a5106033d7", GitTreeState:"clean", BuildDate:"2022-03-16T14:08:11Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.11", GitCommit:"38d3c1f3d5306401bcf39a71bad3b5a5106033d7", GitTreeState:"clean", BuildDate:"2022-03-16T14:02:06Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}

Helm documentation states that:

The annotation "helm.sh/resource-policy": keep instructs Helm to skip deleting this resource when a helm operation (such as helm uninstall, helm upgrade or helm rollback) would result in its deletion.

As I commented on issue #3673, I noticed that the annotation "helm.sh/resource-policy": keep on a resource is not honored when the release is uninstalled.
I see it was fixed for Update method, could it be that this change needs also to be included in the Delete method?

when will we have this feature supported in helm uninstall? This sounds like a valid usecase and would be great, if we can have this PR merged into master. Thanks.

This hit me today.
I did set the annotation with kubectl annotate pvc -n hedgedoc helm.sh/resource-policy=keep but the resources were deleted by helm delete

version.BuildInfo{Version:"v3.9.0", GitCommit:"7ceeda6c585217a19a1131663d8cd1f7d641b2a7", GitTreeState:"clean", GoVersion:"go1.17.5"}

The docs should be updated then, because they state that uninstall honors the annotation:
From https://helm.sh/docs/howto/charts_tips_and_tricks/#tell-helm-not-to-uninstall-a-resource

The annotation "helm.sh/resource-policy": keep instructs Helm to skip deleting this resource when a helm operation (such as helm -->uninstall<--, helm upgrade or helm rollback) would result in its deletion.

Helm uninstall seems to respect the annotation now, tried latest version version.BuildInfo{Version:"v3.12.3", GitCommit:"3a31588ad33fe3b89af5a2a54ee1d25bfe6eaa5e", GitTreeState:"clean", GoVersion:"go1.20.7"}

Helm uninstall seems to respect the annotation now, tried latest version version.BuildInfo{Version:"v3.12.3", GitCommit:"3a31588ad33fe3b89af5a2a54ee1d25bfe6eaa5e", GitTreeState:"clean", GoVersion:"go1.20.7"}

This is NOT the case for me even on version.BuildInfo{Version:"v3.12.3", GitCommit:"3a31588ad33fe3b89af5a2a54ee1d25bfe6eaa5e", GitTreeState:"clean", GoVersion:"go1.20.7"} helm.sh/resource-policy=keep was still ignored during helm uninstall and the resources were deleted when they should not be.
PR #10893 needs to be merged to fix this.

Hi there, I found that annotating by kubectl does not make effect. But if you make the annotation through helm it is respected later in the uninstall process. In my case, I modified the chart I was using for testing purpose. This may work as a workarround.
Regards

I can also confirm that if the annotation is deployed with Helm, then the resources will stay intact.
helm delete crds
These resources were kept due to the resource policy:
[CustomResourceDefinition] crdA
[CustomResourceDefinition] crdB
[CustomResourceDefinition] crdC

release "..." uninstalled

I did not test to add the annotation by hand.
Helm version v3.12.0

@fischerman I tested adding the annotation manually to a Helm managed CRD and it will be ignored (CRD will be removed with helm uninstall).

Faced the same issue =(
Patching the resource with kubectl doesn't prevent deletion (helm uninstall/upgrade).

Any news on this?

I think is not bug. Because, helm manages it's state through a secret. It don't compare with the final manifest of the resource. So if you want to respect this behavior, the configuration should be added by helm. It is only an opinion.

@Pela2silveira is correct. Helm appears to look only at the Secret called sh.helm.release.v{#}.{chartname-randomstring}.v{#} that it creates whenever you helm install or helm upgrade a chart. This secret contains the entire chart rendered out fully as if you did helm template (including Secrets and generated passwords), then gzip'd and converted to base64 and then stored in this one 'release' Secret.
I think there is something being worked on here (although I'm not 100% following why the work has gone to the GitHub Actions Runner repo instead of the main Helm repo but never mind my confusion 😇) to enable us to go helm upgrade --custom-annotations=(...) or something along those lines. Not sure what the status is of that work; asked for a follow-up... we'll see.

The use case of the annotation helm.sh/resource-policy=keep should support ondemand basic by using kubectl though without upgrading again the helm chart. It will be hard to deal with helm chart which is shared with multiple apps. 😔

authors: AndreaScarselliAx Pela2silveira Shrooblord Subetov bczoma fischerman iAnomaly mlorenzo-stratio odise r10r smaanika zip-chanko

repo: helm/helm


text:
[Question] How to ensure the state of helm hook

Hello everyone, I am using helm to write my project, in my project I need to initialize the database first, I used a pre-install helm hook to achieve this, now I intend to execute the subsequent operation when the status of the pod corresponding to that helm hook changes to completed(NOT running). What can i do to resolve this problem? Thanks a lot.

What is the "subsequent operation"?
Generally, if you want to synchronize with helm operations, you want to specify the --wait flag to install, update, rollback, etc.

What is the "subsequent operation"?
Generally, if you want to synchronize with helm operations, you want to specify the --wait flag to install, update, rollback, etc.

"subsequent operation" are the operations that should be executed after the status of the job pod turns to "Completed".


text:
helm create command: too much boilerplate generated

this issue is pretty self explanatory.
this is a personal complaint about the amount of boilerplate which is generated by the helm create command, with no available flag to not generate it. I find this to be annoying. Maybe other people agree.
If approved, I would like to submit a PR which adds an optional flag for helm create command to only create the minimal config.
ie:
helm create --no-boilerplate

knock knock. anyone home?

What would be your suggested minimal level of boilerplate?

@gWOLF3 To add some context...

The helm create command isn't required for people to use. I've created numerous charts without using it.
helm create can be passed a starter that will scaffold out a different starter chart. Starters are not included with the Helm install
The chart scaffolded out by helm create shows a lot of good practices and parts. That includes labels for k8s, tests, and more. This is helpful in showing people what they can do. Especially when they are newer

With that being said, what would you suggest specifically and why?

Hi, @gWOLF3 - thanks again for offering your views. We've replied with more context and options, so we're closing this issue as answered. Thanks.

authors: bacongobbler bridgetkromhout gWOLF3 mattfarina