Promote the error print of guest-components

Currently, the error information printed by guest-components is not well-formatted. An expected one from my point of view should looks like
some error
Caused by: level 1 reason
Caused by: some more detailed reason
...

This follows the discussion of https://github.com/confidential-containers/trustee/pull/327#discussion_r1503563955
BTW, we should think about whether the concrete error information should be reported to higher level. A most simple way is to report a rough error type to the caller of the guest components, and the concrete guest component itself should log the error information in the format mentioned above.
wdyt? @mkulke and probably @kartikjoshi21

The caller of guest-components would be api-server-rest in this case?
I think we should probably define what is sensible, ASR is mostly a convenience facility, so it would be nice for it to produce some readable error messages. I can image that e.g. a 404 we receive from KBS can be propagated to the ASR response, but for anything else it could be a simple 500 http status, with additional information in the process logs. An in-container user would not be able to resolve an internal error in normal circumstances.
not sure there is a logging crate that will print multiline error traces. we might have to build it ourselves

Yes, possibly related to https://github.com/confidential-containers/guest-components/issues/529
Also keep in mind that sometimes we should be careful about what error messages are exposed to the host.

not sure there is a logging crate that will print multiline error traces. we might have to build it ourselves

With thiserror, we could impl a macro format_error where we needs to generate a multiple line error information as mentioned in the message
macro_rules! format_error {
    ($err:expr) => {{
        let mut error_string = format!("{}", $err);
        let mut current_error = $err.source();
        while let Some(source) = current_error {
            error_string.push_str(&format!("\nCaused by: {}", source));
            current_error = source.source();
        }
        error_string
    }};
}

I think we should probably define what is sensible, ASR is mostly a convenience facility, so it would be nice for it to produce some readable error messages. I can image that e.g. a 404 we receive from KBS can be propagated to the ASR response, but for anything else it could be a simple 500 http status, with additional information in the process logs. An in-container user would not be able to resolve an internal error in normal circumstances.

It makes sense that we should concrete internal error information should be not be delivered. I also agree that your potential point that we should do error truncation before delivering to concrete end user.
Let me make a table to show where the errors information will be exposed to non-guest-components

Interface
source

Host
kata-agent's CDH call <-- CDH API error

App container
ASR's web api <-- CDH/AA API error

so we have two choices to truncate the error information. either in

CDH/AA's API implementation: Means that CDH/AA will log the whole error information, but with a brief error information in API response.
or the caller side (ASR and kata-agent): Means that kata-agent and ASR will get the whole error information, but it will only leave the first line of the error and abondon other lines. Related to #529, if error happens in ASR, a 500 http status will be returned.

Both are practical. One thing to note that if we use way 1, a CDH client tool will not get the whole error message. So I am with way 2. The rationale behind is that kata-agent and ASR are all abstract "guest-components", so logs are secure to transfer in-between them.


BigDecimalRangeRandomizer does not generate values with configured scale

https://github.com/j-easy/easy-random/blob/0426dcd8b2df555d276a16513ab92d79f99f8de5/easy-random-core/src/main/java/org/jeasy/random/randomizers/range/BigDecimalRangeRandomizer.java#L84
Argument scale is incorrectly passed to DoubleRangeRandomizer as seed parameter.

Resolved in #486


Document and make consistent JDBC binding return codes

Currently there are 4 different return codes coming from the JDBC binding. They are not consistent across operation methods but roughly equate to:
-2 = Operational Error (Used rarely, could probably be consolidated to -1)
-1 = Configuration/Operational Error
0 = Success
1 = Successful but unexpected result from database
It should be easy to make these consistent within the JDBC module, but are there guidelines for return codes across all YCSB modules?

There aren't, but I think it would be great if there were. I started on this in cmccoy@621d5151af79ea61a86f443024abc13118bf23ca.  The HBase bindings also use -3 to indicate that the requested record wasn't found.

@cmccoy that link ended up as a mailto?

Sorry. How about here?

Cool, any plan on merging in StatusCode.java? I think making that a standard is a good idea, though may take some work to see what types of errors are being reported from the other modules and mixing that in where applicable. I think you may be able to get a tad more granular on error types.

Opened #469. I agree that we could be more granular. Would you mind posting your suggestions there?

I believe this is closed by #469. @kruthar - feel free to re-open if you disagree.


[Blueprints, 02-at-scale] Spot Instance Architecture Best Practices

Sport Architecture Best Practices per https://aws.amazon.com/blogs/compute/cost-optimization-and-resilience-eks-with-spot-instances/. It is applied into Jenkins Infra here: https://github.com/jenkins-infra/aws/blob/main/cik8s-cluster.tf
See also EKS Spot Best Practice: https://repost.aws/knowledge-center/eks-spot-instance-best-practices

Please be sure to read https://docs.cloudbees.com/docs/cloudbees-ci/latest/pipelines/restart-aborted-builds#_restarting_pipeline_node_blocks_using_the_retry_option

I will also include Timeout closure


fix(zitadel): Remove unused Proto Import

Fix Warning zitadel/features.proto: warning: Import google/protobuf/timestamp.proto but not used.

we fixed this issue with another branch. but thanks for contributing.


H2 embedded driver: remove mv.db from url

When connect to embedded H2 it can append mv.db to the database file path.
So if you use browse button or just copy-paste database file path then it will produce wrong url.
We need to check this in H2 connector and remove explicit mv.db from the url

verified


Not working :(

I cant seem to get it working, and I keep getting "index out of range [-1]". Im using the latest build and have tried other websites, and I either get that or something similar. I noticed some other people posting about similar issues with index out of range, but none of them seem to work for me. Please help :(

Hi,
it works for me. Can you please do me a favor and wrap the URL in ""?
This is the output you should get:
get-sauce -i "https://hstream.moe/hentai/futei-with-the-animation-1"

 Site:      https://hstream.moe/
 Title:     Futei with... The Animation - 1
 Type:      video
 Captions:  # All available languages

     [0]  -------------------
     Language:            English
     # download with: get-sauce -c 0 ...

 Streams:   # All available qualities
     [0]  -------------------
     Type:            video
     Info:            av01.0.12M.08
     Quality:         2880x1920
     Parts:           169
     Size:            0 B
     # download with: get-sauce -s 0 ...

     [1]  -------------------
     Type:            audio
     Info:            mp4a.40.2
     Quality:         x
     Parts:           169
     Size:            0 B
     # download with: get-sauce -s 1 ...

     [2]  -------------------
     Type:            video
     Info:            av01.0.08M.08
     Quality:         1920x1080
     Parts:           169
     Size:            0 B
     # download with: get-sauce -s 2 ...

     [3]  -------------------
     Type:            video
     Info:            avc1.64001f
     Quality:         1280x720
     Parts:           169
     Size:            0 B
     # download with: get-sauce -s 3 ...

Wrapping the quotations in "" still gave me the same result, but I tried something different that seemed to work for me. Switching to a different Wifi network seemed to get it to work properly for me though, and switching back  to the original network afterwards seemed to fix it permanently. Thanks for the help :)


[BUG] column width is too wide when creating column

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
When creating a column, it's very wide. But when switching back and forth, the column width is adjusted.
Steps to reproduce the behavior:

create column
go to another note then back to the database

Expected behavior
create column with normal width
Screenshots
https://user-images.githubusercontent.com/38974541/171598207-93ad59a2-dab7-410e-8277-16289031eff4.mov
Desktop (please complete the following information):

OS: MacOs monterey 12.3.1
Version Obsidian 0.14.6 Installer 0.14.6

the width of column will be refactored with https://github.com/RafaelGB/obsidian-db-folder/issues/50. Its a known problem
Added the reference of this issue and closed as a duplicate


auto-instrumentation: increase default memory request to 100Mi

What does this PR do?
Increases the default memory request for the auto instrumentation container from 20Mi to 100Mi.
100Mi is closer to the recommended minimum memory requirements for Alpine.
Motivation
Right now the containers may get OOM Killed when copying lib injection files from the lib injection container to the application container. This memory usage comes from the cp command's usage of sendfile and is correlated to the total number of files being copied.
From @levan-m:

From my perspective, making this change in Agent is cleaner. Memory increase will be tied to a specific Agent version upgrade. On the other hand, Operator config may change while Agent version is pinned (or vice versa). This could create a situation where Operator overrides default value in future Agent versions, or sets higher limit on older installations which work fine with 20mb.

Additional Notes
Possible Drawbacks / Trade-offs
Describe how to test/QA your changes
Testing limits manually.
Before:
$ docker run -it --rm  --memory=20Mib --memory-swap=20Mib -v "$(pwd):/out" gcr.io/datadoghq/dd-lib-python-init:2.12 /datadog-init/copy-lib.sh /out/
Killed

After:
$ docker run -it --rm  --memory=100Mib --memory-swap=100Mib -v "$(pwd):/out" gcr.io/datadoghq/dd-lib-python-init:2.12 /datadog-init/copy-lib.sh /out/

Changes lgtm. Could you add the note from @levan-m comment that we're adding this limit here as a cleaner solution. Also, are we adding the limits to Helm & Operator as well? If so, could you please link the PRs here.

@alexbryukhanova, if we cherry-pick this change on 7.57.x branch, we could include it in 7.57.1 and remove the need to implement the workaround in the helm-chart and Operator.

/merge


cmd/compile: align formal parameters with actual argument when reporting incorrect number of arguments

What version of Go are you using (go version)?

$ go version
go version go1.13 linux/amd64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/klak/.cache/go-build"
GOENV="/home/klak/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/klak"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build664638301=/tmp/go-build -gno-record-gcc-switches"

What did you do?
https://play.golang.org/p/Jgg2p681cOG
What did you expect to see?

./prog.go:7:5: not enough arguments in call to foo
	have (number, number, number, number)
	want (int,    int,    int,    int, int, int)

What did you see instead?

./prog.go:7:5: not enough arguments in call to foo
	have (number, number, number, number)
	want (int, int, int, int, int, int)

CC @griesemer @mdempsky

There may be better ways to report this error, but aligning the output will only cause more problems (one can easily imagine overlong lines that are harder to decipher than what's here now).
Not urgent.


escape seperator

I found that :: not escaped and if some one insert data contain :: search result is wrong
var triples = [
    {subject: "a::a::a", predicate: "b", object: "c"},
    {subject: "a", predicate: "b", object: "c"},

];

db.put(triples, function (err) {
    if (!err) {
        console.log('ok!');
        db.get({subject: "a"}, function (err, list) {
            console.log(JSON.stringify(list));
            //real: [{"subject":"a::a::a","predicate":"b","object":"c"},{"subject":"a","predicate":"b","object":"c"}]
            //expected: [{"subject":"a","predicate":"b","object":"c"}]
        });
    }
});

Thanks for spotting this bug! Would you mind sending in a PR to fix this?

check this diff
it escape values in index key.
convert all : to \: and \ to \\

Can you send a PR?

#137

Release as 1.1.2.


update yarnpkg gpg key in apt.

fix for #144
The GPG key for Yarn in Ubuntu is expired. This adds updating the GPG key in APT before running apt operations, as per https://github.com/yarnpkg/yarn/issues/7866

Hey @brettcave thank you for calling this out. The CodeBuild team has actually updated their image resolving this issue.


Predicate-based forEach() [HPPC-9]

Next to the forEach method we have now, we could have a version with [type]Predicate as an argument. The predicate-based version would be similar to jQuery.each: if the predicate returns true, the iteration will be finished (equivalent of break), for false, the iteration will continue (equivalent of continue).

Issue: HPPC-9 (migrated from JIRA), created by Stanisław Osiński (@stanislawosinski), resolved Mar 10 2010

Comment by Dawid Weiss (@dweiss) (migrated from JIRA)
In trunk for all ObjectContainers. Associative containers don't have this, but you can apply a predicate to the container returned from the keySet() method.


AP-TEE Sealing Interface

We may want to eventually extend the attestation TG-ABI to support data sealing.
The generic use-case for sealing is basically for a TVM to seal a piece of data that can be migrated to and unsealed by another TVM, synchronously or not. For example a TVM guest could seal a secret key or piece of data to an AP-TEE sealing key, store it in an untrusted storage and then later fetch it back to unseal it.
In order to unseal it, a TVM willing to use a previously sealed data blob must be able to generate the same sealing key that the blob was originally sealed with. As sealing keys are derived from CDIs, we must clearly define how those sealing CDI are composed.
We want to define to which security attributes a sealed piece of data would be bound to, and guarantee that a TVM running with the same (or stronger) attributes would be able to generate sealing keys that could unseal it. The sealing CDI composition, from which sealing keys are derived, provides that guarantee.
Moreover, we want sealed data to be protected against software and firmware rollbacks: For the same TVM TCB, current and future software versions should be able to unseal but older ones must not be able to do so. This anti rollback unsealing attribute can be provided through versioned sealing keys.
Sealing CDI
Sealing keys derive from the sealing CDI, which should be generated by the TSM as follows:
Sealing_CDI_N = KDF(N, Sealing_CDI_N-1, H(SealingInputValues), "SealingCDI")
Where SealingInputValues are:

All TVM static measurements
All TVM dynamic measurements
Platform state
Platform manufacturer ID

With those input values, two same TVMs (i.e. running with the same measurements), running on identical platforms operating in the same state should generate the same sealing CDI, regardless of platform software or firmware updates.
Versioned Sealing Keys
Not binding the sealing CDI to software or firmware components allows for sealed data to be unsealed by a TVM running on an older, potentially vulnerable platform TCB. To prevent that we want sealing keys to be versioned, i.e. to be derived first from a sealing CDI and then from a set of software and firmware versions.
References
OpenDice Versioned Sealing Keys

cc @rsahita

queued for v2


feat(cdk/interactivity-checker) add config parameter to isFocusable

Adds config object to isFocusable so that it can optionally return true
even when an element is invisible. Example use case: call isFocusable
with ignoreVisibility=true to find a focusable element within a
collapsed element. If isFocusable returns true, expand the collapsed
element and focus the focusable element.
Fixes #6468.

Friendly ping! Do you think this one could be merged soon? It seems like we can be fairly confident it won't break google3 since it just added an optional parameter, and I was hoping to use it for a small a11y feature.  I saw it got tagged with "commit message fixup". Let me know if there's anything I can do to help clean that up!

I marked it P2 to bump it up the caretaker's priority queue. The commit message fixup thing is just a note to the caretaker to change the message when they go to merge it, nothing you need to address.

Thank you!!


feat(#226): Decompile Only Files With Supported Opcodes"

In this PR I added SelectiveDecompiler that decompiles only files that contain supported opcodes. If SelectiveDecompiler faces a file with unknown opcode, it just skips it and copies as is.
I encorporated this decompiler to staticize and fuse integration tests.
This changes are important printing xmir->phi. Now we can print only files that are fully decompiled. This saves time for spring-fat integration test.
Related to #226.
History:

feat(#226): add unit tests for selective decompiler
feat(#226): calculate supported opcodes
feat(#226): make all tests pass
feat(#226): add DummyStorage
feat(#226): try to integrate SelectiveDecompiler
feat(#226): fix the bug related to 'frame' parsing
feat(#226): add logs
feat(#226): add selective decompiler to 'fuse' integration test
feat(#226): add IRETURN handler to decompiler
feat(#226): add several puzzles for RawXml class
feat(#226): add puzzle to refactor SelectiveDecompilerTest
feat(#226): add javadocs for SelectiveDecompiler
feat(#226): fix all the rest qulice suggestions

PR-Codex overview
This PR updates the project to use Java 11, adds a new RawXml class, enhances XmirEntry with an XPath method, and refactors the decompiler classes.
Detailed summary

Updated project to use Java 11.
Added RawXml class for parsing XML.
Enhanced XmirEntry with an xpath method.
Refactored decompiler classes for better clarity.

The following files were skipped due to too many changes: src/test/resources/xmir/Known.xmir, src/main/java/org/eolang/opeo/ast/RawXml.java, src/main/java/org/eolang/opeo/SelectiveDecompiler.java, src/test/java/org/eolang/opeo/decompilation/SelectiveDecompilerTest.java

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@rultor merge

@volodya-lombrozo OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@volodya-lombrozo Done! FYI, the full log is here (took me 7min)


Add quiescence detection test with GPU Manager

Original issue: https://charm.cs.illinois.edu/redmine/issues/1990

Added an example program to test QD with GPU Manager.

Original date: 2018-10-09 20:08:33

Gerrit patch: ~~https://charm.cs.illinois.edu/gerrit/#/c/charm/+/4653/~~ https://github.com/UIUC-PPL/charm/commit/43c212f2b29f63bf35bb66831e4e4adf76efd21b


Another "racer binary not set" issue

Like #4, I'm having an issue with an incorrect "racer binary not set" error when trying to use deoplete-rust. Unlike #4, I'm already using the full path to racer:
:let g:deoplete#sources#rust#racer_binary
g:deoplete#sources#rust#racer_binary  /home/mqudsi/.cargo/bin/racer

I'm not sure what other info to provide. Using the latest (master) versions of deoplete and deoplete-rust, deoplete works well otherwise. This is on WSL.

I dug into the deoplete-rust source, and this isn't a deoplete-rust bug, it's a neovim issue.
https://github.com/neovim/neovim/issues/7034


feat: Getregion function

Continues of #11579
It is not only for visual mode.

I think this is a nice addition. I think we should call it getline_region() so that it comes close to the description of the getline() function.
However, we need tests here. Including testing what happens with invalid positions, multibyte character support, tab handling, and testing failure modes if possible.

I think this is a nice addition. I think we should call it getline_region() so that it comes close to the description of the getline() function.

Well, the rename is needed?

However, we need tests here. Including testing what happens with invalid positions, multibyte character support, tab handling, and testing failure modes if possible.

Yes.  The tests are needed...

I have fixed the bug and I have added basic visual mode tests.

However, we need tests here. Including testing what happens with invalid positions, multibyte character support, tab handling, and testing failure modes if possible.

Can you add them?

Thinking about this some more, does it handle block mode correctly? I mean for a text like this:
one
foobar
a

With :call cursor(1,1), how do we get the proper region for: :norm! \<c-v>jj  vs:  norm! \<c-v>jj$ ?  Don't we need to add an argument for the type of selection?
I am also wondering, if instead of values for the line() function, the positions should be what e.g. getpos() returns. That would be more flexible I think.
Hm, actually, reading the documentation again:
		The result is a list of strings where each item is a line
		from {pos1} to {pos2}.
                For possible values of {pos1} and {pos2} see |line()|.

This seems strange.  line() returns only the line number, how is this different from getline({pos1}, {pos2}) ? That does exactly the same? Or not?

I am hoping that this PR inherits what was in original visualtext() that works with visual block selections as well. https://github.com/vim/vim/pull/11579

This seems strange. line() returns only the line number, how is this different from getline({pos1}, {pos2}) ? That does exactly the same? Or not?

The arguments are same with getpos().
But in getpos() documentation,
							*getpos()*
getpos({expr})	Get the position for String {expr}.  For possible values of
		{expr} see |line()|.  For getting the cursor position see
		|getcurpos()|.

So I have inherited it.

With :call cursor(1,1), how do we get the proper region for: :norm! \<c-v>jj vs: norm! \<c-v>jj$ ? Don't we need to add an argument for the type of selection?

The selection type is known from Vim internal state.

I have added the visual block mode tests.

How about to add functionality to specify the way to get text such as charwise, linewise, and blockwise?
For example, add a optional third argument in dictionary:
call getregion("'a", "'b", #{mode: 'v'})  " Get text in charwise mode.
call getregion("'a", "'b", #{mode: 'V'})  " Get text in linewise mode.
call getregion("'a", "'b", #{mode: "\<C-v>"})  " Get text in blockwise mode.

Different from the base visualtext function, getregion function can get not only the selected text in visual mode but also any text between two marks.  Therefore it's not reasonable that the type of region is just set from the current mode and users cannot change it.
I'm not sure for this but maybe it's better to have a functionality to specify selection (old, inclusive, or exclusive) like this: getregion("'a", "'b", #{selection: 'exclusive'}).

Oh, too many request here...  Please wait.  I need time to fix them.

How about to add functionality to specify the way to get text such as charwise, linewise, and blockwise?
For example, add a optional third argument in dictionary:

Well, the suggestion may be good.
But it will increase complexity for interface and implementation.
I think the simple interface should be implemented in the first instead of perfect interface.
You can extend the implementation if you really needed.

The original API virtualtext() cannot be extended.
But this API can be added the following opts.
winid, mode, inclusive

Well, the suggestion may be good.
But it will increase complexity for interface and implementation.
I think the simple interface should be implemented in the first instead of perfect interface.
You can extend the implementation if you really needed.

I see. OK, thank you.

How about to add functionality to specify the way to get text such as charwise, linewise, and blockwise?
For example, add a optional third argument in dictionary:

Well, the suggestion may be good. But it will increase complexity for interface and implementation.
I think the simple interface should be implemented in the first instead of perfect interface. You can extend the implementation if you really needed.

I think the suggestion is good however. Otherwise, what the getregion() returns depends on whether the user used v, V or Ctrl-V before calling the getregion() function. I think we should explicitly allow for a blockmode option therefore

I think we should explicitly allow for a blockmode option therefore

Well, I should add the argument?

I think we should explicitly allow for a blockmode option therefore

Well, I should add the argument?

Yes please. Something like this:
getregion({pos1}, {pos2}, {dict})			*getregion()*
		Returns the list of strings from {pos1} to {pos2}.
		For possible values of {pos1} and {pos2} see |line()|.
		This function uses the line and column number from the
		specified position.
		It is useful to get text starting and ending in different
		columns, such as |characterwise-visual| selection.

		The {dict} argument allows to specify additional options.
		Currently it supports the following members:

			type	Type of the selection. One of
				"v" for |characterwise| text,
				"V" for |linewise| text or
				"<CTRL-V>" for |blockwise| text
				selection.

That gives us the opportunity to specify more behaviours (like the selection setting mentioned elsewhere) when the need arises.

I think opt argument should be added in the next PR.
But I will add explicit selection mode.

I have added the argument.

Memory leak
=================================================================
==16754==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 2 byte(s) in 2 object(s) allocated from:
    #0 0x564cfabe91cf in __interceptor_malloc ??:?
    #1 0x564cfac269e7 in lalloc /home/runner/work/vim/vim/src/alloc.c:246:11
    #2 0x564cfae6368d in block_def2str /home/runner/work/vim/vim/src/evalfunc.c:5467:11
    #3 0x564cfae3d379 in f_getregion /home/runner/work/vim/vim/src/evalfunc.c
    #4 0x564cfb7af51d in call_bfunc /home/runner/work/vim/vim/src/vim9execute.c:1332:5
    #5 0x564cfb7561f6 in exec_instructions /home/runner/work/vim/vim/src/vim9execute.c:4379:7
    #6 0x564cfb793c00 in call_def_function /home/runner/work/vim/vim/src/vim9execute.c:6325:11
    #7 0x564cfb6b89cb in call_user_func /home/runner/work/vim/vim/src/userfunc.c:2866:6
    #8 0x564cfb6b7b00 in call_user_func_check /home/runner/work/vim/vim/src/userfunc.c:3299:10
    #9 0x564cfb6b22df in call_func /home/runner/work/vim/vim/src/userfunc.c:3923:15
    #10 0x564cfb6b0772 in get_func_tv /home/runner/work/vim/vim/src/userfunc.c:2013:8
    #11 0x564cfb6db13b in ex_call_inner /home/runner/work/vim/vim/src/userfunc.c:6103:6
    #12 0x564cfb6db13b in ex_call /home/runner/work/vim/vim/src/userfunc.c:6451:11
    #13 0x564cfaed5097 in do_one_cmd /home/runner/work/vim/vim/src/ex_docmd.c:2582:2
    #14 0x564cfaeccac3 in do_cmdline /home/runner/work/vim/vim/src/ex_docmd.c:994:17
    #15 0x564cfae15126 in ex_execute /home/runner/work/vim/vim/src/eval.c:7556:6
    #16 0x564cfaed5097 in do_one_cmd /home/runner/work/vim/vim/src/ex_docmd.c:2582:2
    #17 0x564cfaeccac3 in do_cmdline /home/runner/work/vim/vim/src/ex_docmd.c:994:17
    #18 0x564cfb6ba85c in call_user_func /home/runner/work/vim/vim/src/userfunc.c:3126:2
    #19 0x564cfb6b7b00 in call_user_func_check /home/runner/work/vim/vim/src/userfunc.c:3299:10
    #20 0x564cfb6b22df in call_func /home/runner/work/vim/vim/src/userfunc.c:3923:15
    #21 0x564cfb6b0772 in get_func_tv /home/runner/work/vim/vim/src/userfunc.c:2013:8
    #22 0x564cfb6db13b in ex_call_inner /home/runner/work/vim/vim/src/userfunc.c:6103:6
    #23 0x564cfb6db13b in ex_call /home/runner/work/vim/vim/src/userfunc.c:6451:11
    #24 0x564cfaed5097 in do_one_cmd /home/runner/work/vim/vim/src/ex_docmd.c:2582:2
    #25 0x564cfaeccac3 in do_cmdline /home/runner/work/vim/vim/src/ex_docmd.c:994:17
    #26 0x564cfb425507 in do_source_ext /home/runner/work/vim/vim/src/scriptfile.c:1761:5
    #27 0x564cfb42336e in do_source /home/runner/work/vim/vim/src/scriptfile.c:1907:12
    #28 0x564cfb42336e in cmd_source /home/runner/work/vim/vim/src/scriptfile.c:1253:14
    #29 0x564cfaed5097 in do_one_cmd /home/runner/work/vim/vim/src/ex_docmd.c:2582:2
    #30 0x564cfaeccac3 in do_cmdline /home/runner/work/vim/vim/src/ex_docmd.c:994:17
    #31 0x564cfbaa01b4 in exe_commands /home/runner/work/vim/vim/src/main.c:3173:2
    #32 0x564cfbaa01b4 in vim_main2 /home/runner/work/vim/vim/src/main.c:790:2
    #33 0x564cfba98c0c in main /home/runner/work/vim/vim/src/main.c:441:12

Memory leak

Fixed.

I think it's almost good :) Just a few more tests for the different type() values as Yegappan suggested.

I have added tests.

Thank you @Shougo and the rest who helped!

Why doesn't this return a list of positions? Return text is the least useful part about a region. How can plugin authors get the positions that correspond to a visual block region (for example)? That is still an unsolved problem.

Why doesn't this return a list of positions? Return text is the least useful part about a region.

The functionality of this function was to be to get the buffer content of whatever those positions would define. Au contraire, getting the buffer content was an unsolved problem before, positions would need to be known before hand so I fail to see how this would be "more useful".
How can plugin authors get the positions that correspond to a visual block region (for example)? That is still an unsolved problem.
You can use getpos() of those positions already. Don't see why this is a problem.

For blockwise Visual selection it'll probably need a combination of getpos(), virtcol() and virtcol2col().

correct and visualmode()

You can use getpos() of those positions already. Don't see why this is a problem.

You cannot easily get the dimensions of the buffer text that is described by a region. This is the code that is currently required to do that: https://github.com/neovim/neovim/blob/d35a8a9bbe385daf808984ba0fc7f07f51a96da0/runtime/lua/vim/_editor.lua#L509-L578

(Note that this is not as trivial as it seems once you add multibyte and ambiwidth unicode characters to the mix.)

Well, I should add the option to return the range feature?

I think range feature is good. but shouldn't add to getregion().
Should split entry point to another function because determine return type by arguments is hard to understand.

correct, there was a single purpose for the getregion() function, which was to retrieve the selected text between 2 different (start and end) positions. Now why the discussion now moves away to get different usecase. That should be a new vimscript function. However, I still don't understand the need for it:
We are giving already positions to the getrange() function. You are talking about dimensions of positions, which I don't understand. What exactly do you mean by that? Can you please give concrete examples? Why exactly are start and end positions not enough? Can you spell out the help documentation for what this function should do?

Yes, but you already have those positions. So where do those positions come then from? In other words if you already have the positions, why do you need to use getregionpos()?
BTW: I have for years used a similar approach to this in one of my plugins. Set the marks '<  and '> to those positions and then set the selection type. Use norm! gv to reselect those regions. Has worked quite well.

Yes, but you already have those positions. So where do those positions come then from?

No we don't; that's exactly what we're asking from here. (We have a hack that works in some situations, but not enough.)

Then it's even more curious why you mention it here in the PR for getregion(), since that function already receives the position. Can you please create a new issue with whathever you like to have? Please also mention what the help description should explain.

(To be clear, I'm not the one complaining here; just trying to provide some additional context.)

sure understood and thanks. (And to be clear, I am just trying to understand the missing pieces)

Basically, given a pair of positions (which could be '< and '> -- the main use case, in fact) return an array of positions { line1 = {col_start, col_end}, line2 = {col_start, col_end}} that respects

setreg-style selection type (char/line/block)
whether ending column is inclusive/exclusive
'virtualedit'
works with double-width (flag emoji) and amiwidth (thai) unicode
...

Basically, convert a visual-block selection to an array of line-wise selections to then, say, apply highlights to. (Main use case here: highlight-on-yank as in https://github.com/machakann/vim-highlightedyank.) Especially the last points basically rely on Vim internals to be guaranteed to be correct

Basically, convert a visual-block selection to an array of line-wise selections to then, say, apply highlights to.

"to char-wise", right?

(Main use case here: highlight-on-yank as in https://github.com/machakann/vim-highlightedyank.)

To @chrisbra 's point, if nvim_buf_set_extmark accepted {pos1}, {pos2}, {regtype}, {inclusive} parameters, then we wouldn't need getregionpos() for that particular case.
This raises the more general question about how a buffer region is described. Currently in Vim, a buffer region is described by those 4 parameters. So we have 2 choices:

every API that accepts a "region" has those 4 parameters
introduce a getregionpos() which returns a list of start/end positions, and then APIs only need to accept start/end parameters, because the caller can use getregionpos() and feed its result into any such API.


Add scoped beans support

cloud-config/configserver, cloud-discovery/discoveryclient, wavefront-sleuth and zipkin-sleuth samples are broken on 0.11.x, a NPE is thrown by org.springframework.context.bootstrap.generator.event.EventListenerMethodRegistrationGenerator.writeEventListenersRegistration(EventListenerMethodRegistrationGenerator.java:96) because scoped beans are not supported.
See this related PR that fixes the NPE but not the root cause.

I've pushed basic support in https://github.com/spring-projects-experimental/spring-native/commit/8f9ef08b91e9fd42f548f327f43bd09733c7cb18 but we need to take care of creating the proxies when one is required. A bean that requires one now fails in native.

Now unfortunately I don't know one of of a scoped proxy bean from another :) But let me describe what I see. The batch-io sample builds with 0.10 Spring Native and works as a native image, in the target classes folder we see two proxies were generated at build time to support the app in 0.10:
./target/classes/org/springframework/batch/core/launch/support/SimpleJobOperator$$SpringProxy$fde47779.class
./target/classes/com/example/batch/ItemReaderListener$$SpringProxy$bd3dea77.class

With 0.11 the exact same application is failing. The same two proxies are there:
./target/classes/org/springframework/batch/core/launch/support/SimpleJobOperator$$SpringProxy$fde47779.class
./target/classes/com/example/batch/ItemReaderListener$$SpringProxy$bd3dea77.class

but in addition on 0.11 it is looking for extra proxies for lambda clauses in the application.  This bit of code:
	@JobScope
	@Bean
	public ItemProcessor<Person, Person> itemProcessor() {
		return person -> new Person(person.getFirstName(), person.getLastName().toUpperCase());
	}

is causing this error at runtime:
Caused by: org.springframework.aop.framework.AopConfigException: Unexpected problem loading and instantiating proxy for target class class com.example.batch.configuration.BatchConfiguration$$Lambda$c42fa1503ed3c74f174a192774d0edc19cbfda63; nested exception is java.lang.IllegalStateException: Class proxy missing at runtime, hint required at build time: @AotProxyHint(targetClass=com.example.batch.configuration.BatchConfiguration$$Lambda$c42fa1503ed3c74f174a192774d0edc19cbfda63.class, interfaces={org.springframework.aop.scope.ScopedObject.class, java.io.Serializable.class, org.springframework.aop.framework.AopInfrastructureBean.class, org.springframework.batch.item.ItemProcessor.class})

My question is why is a proxy required for this lambda in 0.11 and not in 0.10? Is it because 0.10 was making a mistake and 0.11 has fixed it?
Addressing this with a hint is not trivial because the lambda class that is the superclass of the required proxy doesn't exist at build time.  The app can be reworked to use anonymous inner classes instead of lambdas but that feels wrong (even though it does work because you can then add the hint).


XML driver harvesting only the first element

Currently the xml driver only harvests the first element with a given name. It should harvest all of them. To verify see the metadata here and using this branch, run bin/get harvard scw --limit 20 > data.csv
There are multiple elements under .//mods:subject/mods:topic but only the first is being harvested.

I think this is an issue with the harvard/scw configuration.
For example if you look at the aims XML at https://feed.podbean.com/themaghribpodcast/feed.xml you can see the first <guid> element is:
themaghribpodcast.podbean.com/7ab002fd-c4ac-3b48-96fa-eb83f4f324d5

and if you run bin/get aims aims the first row has an ID of:
themaghribpodcast.podbean.com/7ab002fd-c4ac-3b48-96fa-eb83f4f324d5

This was a good find. It looks like the XML driver is pretty broken at the moment for all providers. If you run the entire dataset bin/get harvard scw > harvard.csv and then count how many times the id values appear you can see that there are duplicate rows, and
>>> import pandas
>>> df = pandas.read_csv('harvard.csv')
>>> df
          id  ...                                            preview
0   22535138  ...  https://nrs.harvard.edu/urn-3:FHCL:35350111?wi...
1   22535185  ...  https://nrs.harvard.edu/urn-3:FHCL:35350205?wi...
2   10898498  ...  https://nrs.harvard.edu/urn-3:FHCL:23018086?wi...
3   10898499  ...  https://nrs.harvard.edu/urn-3:FHCL:23018088?wi...
4   10898505  ...  https://nrs.harvard.edu/urn-3:FHCL:23018100?wi...
..       ...  ...                                                ...
95  16199346  ...  https://nrs.harvard.edu/urn-3:FHCL:27735221?wi...
96  16199347  ...  https://nrs.harvard.edu/urn-3:FHCL:27735229?wi...
97  20329473  ...  https://nrs.harvard.edu/urn-3:FHCL:32602011?wi...
98  20329474  ...  https://nrs.harvard.edu/urn-3:FHCL:32602013?wi...
99  20329475  ...  https://nrs.harvard.edu/urn-3:FHCL:32602015?wi...

[100 rows x 12 columns]

>>> df.id.value_counts()
22535138    10
22535185    10
10898498    10
10898499    10
10898505    10
16199346    10
16199347    10
20329473    10
20329474    10
20329475    10

The same is true for bin/get aims aims except there are 144 duplicate rows...
I've added a simple test to first capture what we think should be the correct behavior over in https://github.com/sul-dlss/dlme-airflow/pull/245


Making StatusResponseHandler singleton and fixing all its instantiation invocations

Making StatusResponseHandler singleton and fixing all its instantiation invocations.

@leventov ,   I see this failure.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process (process-resource-bundles) on project druid-hll: Error resolving project artifact: Could not transfer artifact org.hyperic:sigar:pom:<IP_ADDRESS> from/to sonatype (https://oss.sonatype.org/content/repositories/releases/): Access denied to: https://oss.sonatype.org/content/repositories/releases/org/hyperic/sigar/<IP_ADDRESS>/sigar-<IP_ADDRESS>.pom, ReasonPhrase: Forbidden. for project org.hyperic:sigar:jar:<IP_ADDRESS> -> [Help 1]

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process (process-resource-bundles) on project druid-hll: Error resolving project artifact: Could not transfer artifact org.hyperic:sigar:pom:<IP_ADDRESS> from/to sonatype (https://oss.sonatype.org/content/repositories/releases/): Access denied to: https://oss.sonatype.org/content/repositories/releases/org/hyperic/sigar/<IP_ADDRESS>/sigar-<IP_ADDRESS>.pom, ReasonPhrase: Forbidden. for project org.hyperic:sigar:jar:<IP_ADDRESS> -> [Help 1]

Travis was having some issues yesterday, this looks related to what I was seeing with other failures. I will restart and see if it does better today.

thanks @clintropolis 👍

@leventov , implemented the review comments.


Minor improvements of CLI output

What is the new feature about?

When no deckfile is specified, i.e. running with deck get ., the output is [INFO] Reading Deckfile: .. This could be changed to [INFO] Reading Deckfile: deck.yaml, as deck.yaml is the default.
When a local cluster already exists, the output of get is [INFO] Cluster already exists, starting it. This could be enhanced so that the clustername is included, such as it is when a new cluster is created.

Why would such a feature be important to you?
Minor output improvements in the vein of "explicit is more implicit"
Anything else we need to know?
No response

This issue was solved with version 0.11.1

I can confirm the first one, however when running deck get when the cluster already exists, I still get following output:
[INFO] Cluster already exists, starting it

I can confirm the first one, however when running deck get when the cluster already exists, I still get following output:

True, furthermore the [INFO] Reading Deckfile: . still exists when there is no deck.yml in the cwd.

I found another small thing, what do you think about adding http:// to the ingress output? Currently it's the following:
[INFO] Ingress: foo.<IP_ADDRESS>.nip.io -> /admin
[INFO] Ingress: foo.<IP_ADDRESS>.nip.io -> /

If it would be http://foo.<IP_ADDRESS>.nip.io it would be directly clickable from the terminal. Of course one might have https configured, however I would expect there to be a redirect to https from http.

Just another thing that I realized. I was using the -I flag to install the deckfile-resources into my current kubecontext, which was a GKE cluster. In the output I also got [INFO] Cluster already exists, starting it.
When using the -I flag, getdeck won't be able to start a cluster, or would it? Shall we change the output of that line completely, or even omit it when using -I?


Is it possible to make the tagname of the contentEditable variable?

The addon is always loading a contentEditable as a  but would be nice to be able to change this to a  or other html tags.
I would like to put it in a span for example, because of the inline-block property wins I would get out of it. (only changing it with css does not always change the way the browser interacts with it's content.

Sorry about the late reply. Yes, this would be possible. Please submit a PR and I'll be happy to merge it.


Delete All Data in trial org causes Divide by 0 in CRLP

I am not involved with this issue, but I noticed this post by a Hub participant stating that Setup > Delete All Data in a trial org caused MathException Divide by 0 errors in customizable rollups:
https://powerofus.force.com/s/question/0D51E00005I7xJm/unable-to-delete-all-data-using-setup-function?s1oid=00D00000000hWLM&s1nid=0DB800000004Fa7&emkind=chatterCommentNotification&s1uid=0058000000DE9g6&emtm=1587575048376&fromEmail=1&s1ext=0
Here's the post detail.  Apparently he had imported only contacts and accounts, no opportunities:
Imported some data improperly (about 500 contact/account records) for a new org and thought it would be easier to just start fresh. However the Delete All Data function launched from Setup only partially removes a small number of data records. On the first run, about 9 account/contact records were removed, and three error messages were sent via email (see below). Decided to run Delete All a second time and after it stopped, about 15 more account/contact records were deleted, but no error messages were in the log. I have no customizations - it's a new trial setup.
Any advice or should I just keep submitting the Delete All request ?
Error #1:
Error Type: System.MathException
Error Date: 2020-04-21 16:04:47
Message: "Divide by 0
Rollups State:"
Context: CRLP
Error #2:
Error Type: Job Error
Error Date: 2020-04-21 16:04:46
Message: "There were one more errors updating or inserting the following records:

0013h000008Lc46AAC: ENTITY_IS_DELETED- entity is deleted"
Context: CRLP.AccountHardCredit
Error #3:
Error Type: Job Error
Error Date: 2020-04-21 16:04:46
Message: "There were one more errors updating or inserting the following records:
0013h000008Lc2eAAC: ENTITY_IS_DELETED- entity is deleted"
Context: CRLP.AccountHardCredit

@davidchengIC thank you for taking the time to loop us in, but we only create Issues in GitHub for bugs that can be recreated in clean orgs. At this point we have noticed a few posts in the hub with the same error but in quite different scenarios, and there is no known bug at this point. We're keeping an eye on the situation and testing in our own orgs, and we'll be sure to create an Issue if we find a problem with the NPSP (rather than with Salesforce core for example).
Thanks for being an amazing Community member!!


Adding modin.pandas.melt for pandas concordance

What do these changes do?

Related issue number
Resolves #324

[x] passes git diff upstream/master -u -- "*.py" | flake8 --diff
[x] passes black --check modin/

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Modin-PRB/203/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Modin-Performance-PRB/141/
Test PASSed.


[v2] Align Components to Patterns

Inventory needs to be taken of the existing components, and audit them against the patterns being established in the Watson IoT Design System. Document defects so we can fix.
Components

[ ] Table #339, #331
[ ] Navigation/UI Shell - #357
[ ] ...
[ ] ... please add more here w/ linked issue

closing. out of date


macOS: Font weight is permanently bold after latest update

#214390 appears to be back in the just-released v1.92.0. I'm experiencing the issue as previously reported (and later resolved in v1.90.1):

I use Operator Mono first this issue occurred in Insider release, and now with the latest release both versions of VS Code only show bold font weight. 300 is too thin. 400 is too bold. This wasn't the case before.

Version: 1.92.0
Commit: b1c0a14de1414fcdaa400695b4db1c0799bc3124
Date: 2024-07-31T23:26:45.634Z
Electron: 30.1.2
ElectronBuildId: 9870757
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 22.6.0

Appears to be a regression of this issue: https://github.com/microsoft/vscode/issues/214390
The same fix from last time works again. Quit out of VSCode and then launch it from your terminal with the following command
open -a "Visual Studio Code" --args --disable-blink-features=FontMatchingCTMigration

I am also experiencing this regression. See this comment for documentation and screenshots.

@trevorwright thank you for sharing, this fixes it on my side. Hopefully this can be properly patched sometime soon.

Same problem here

I'm using Ubuntu 22.04 and font looks funny and bigger after the update (v1.92.0), screenshot: https://prnt.sc/Twi3ckgzi0YA
Version: 1.92.0
Commit: b1c0a14de1414fcdaa400695b4db1c0799bc3124
Date: 2024-07-31T23:26:45.634Z
Electron: 30.1.2
ElectronBuildId: 9870757
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.6.22-060622-generic

I am using Linux Mint and the font has also suddenly increased in size after the update like @kowsar89

I also have this problem. I also see the bolded font in the right click menu. I never previously had this problem in any version I'd used before.

Been also having this issue, using same font, but it actually goes back to a few...not from the latest update.
MacOS Sonoma.

Appears to be a regression of this issue: #214390
The same fix from last time works again. Quit out of VSCode and then launch it from your terminal with the following command
open -a "Visual Studio Code" --args --disable-blink-features=FontMatchingCTMigration

Thank you for sharing this.

@michael-andreuzza THANK YOU!!! I can't express how much I was about to give up on being a developer lol

I'm experiencing the same issue. I did everything.
Uninstall the app completely
Tried the command in the terminal.
Nothing is working.

@deepak1556 The latest VSCode already uses Electron 30, this TODO can be removed safely at this point?

Same issue as last time, my fix from last time seems to work:
https://github.com/microsoft/vscode/issues/214390#issuecomment-2154931444
For anyone else wondering, open VS using terminal with the below command:
open -a "Visual Studio Code" --args --disable-blink-features=FontMatchingCTMigration

@michael-andreuzza THANK YOU!!!  However the font weight matching is still regressed with the core text path for certain fonts and seems like https://chromium.googlesource.com/chromium/src/+/3bef104fb08126b6b68bab46b0ce132e1cc574a7 accidentally addresses it by using the appkit path as default which is available from Chromium 125. Issue is however present with the core text path in latest canary --enable-blink-features=FontFamilyStyleMatchingCTMigration. I will disable the CT engine again as candidate fix and follow-up in upstream to address the root issue.

Steps for verification:

Install the font variants from PP_Neue_Montreal_Mono.zip
Set "editor.fontFamily": "PP Neue Montreal Mono", "editor.fontWeight": 400
Verify that Book variant is chosen over thin variant

Version: 1.92.0 (Universal)
Commit: b1c0a14de1414fcdaa400695b4db1c0799bc3124
Date: 2024-07-31T23:26:45.634Z
Electron: 30.1.2
ElectronBuildId: 9870757
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 23.3.0

same issue, it looked like have appeared before. And open -a "Visual Studio Code" --args --disable-blink-features=FontMatchingCTMigration works for me after  using Command + Q to quit vscode.

Closing for verification.

@deepak1556 Thanks for sorting this one out!

Adding verified.
Before (broken) it looked like

Now with the fix it looks like

Users - if something is off in this image do let us know!

@dannyuk1982 the fix has not yet been released in stable. Should be out in next 24h

Should be out now.

@bpasero yup that is working fine for me! thanks

I'm using Ubuntu 22.04 and font looks funny and bigger after the update (v1.92.0), screenshot: https://prnt.sc/Twi3ckgzi0YA
Version: 1.92.0
Commit: b1c0a14de1414fcdaa400695b4db1c0799bc3124
Date: 2024-07-31T23:26:45.634Z
Electron: 30.1.2
ElectronBuildId: 9870757
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.6.22-060622-generic

I don't think it's fixed for me after the update ie.
Version: 1.92.1
Commit: eaa41d57266683296de7d118f574d0c2652e1fc4

@kowsar89 this issue is specific to macOS, can you open a separate issue for your case. Thanks!

@kowsar89 this issue is specific to macOS, can you open a separate issue for your case. Thanks!

Multiple people (me included) have said this issue also affects Linux but for some reason macOS was put in the title and other OSes were ignored.

I'm not impacted by the Linux issues, but taking up @deepak1556's suggestion above and opened an issue for y'all: https://github.com/microsoft/vscode/issues/225434


Iv 1975 rightscale nss

Initial pull request, NSS plugin to support user managed login.

Changes not made by me LGTM

LGTM


NavCoin QT 4.6.0 forked/stoped accepting new blocks on my machine

I have a local navcoin-qt running 4.6.0 and seems to have forked somehow and is unable to sync.
Here is debug.log details,
It seems that the wallet synced correctly up to block 397db81e64408823be5abd2a04cf0457f34960cf6b2e43606bea18daa37c016d
2019-05-14 23:37:21 UpdateTip: new best=3a4365b2d91f354466ccb8baf1097864aebc333809f8659c7bb098d5050b2f8d height=3129453 version=0x7131e1ff log2_work=72.962707 tx=6546443 date='2019-05-14 23:37:20' progress=1.000000 cache=11.4MiB(35813tx)
2019-05-14 23:37:29 UpdateTip: new best=727c175789f454f9923d7e3cb47e9eff0aeb83352cda5f9b277f0e78f107fe18 height=3129454 version=0x7131e1ff log2_work=72.962708 tx=6546445 date='2019-05-14 23:37:36' progress=1.000000 cache=11.4MiB(35815tx)
2019-05-14 23:37:53 UpdateTip: new best=f48c1cb5429570befb730c8cac458599768b6a61eca2e85502e06b3051087041 height=3129455 version=0x7131e1ff log2_work=72.962708 tx=6546447 date='2019-05-14 23:37:52' progress=1.000000 cache=11.4MiB(35817tx)
2019-05-14 23:40:06 UpdateTip: new best=397db81e64408823be5abd2a04cf0457f34960cf6b2e43606bea18daa37c016d height=3129456 version=0x7131e1ff log2_work=72.962709 tx=6546449 date='2019-05-14 23:40:00' progress=1.000000 cache=11.4MiB(35819tx)
2019-05-14 23:40:16 UpdateTip: new best=fdbff3c300cf81da7a8a88102711fbd031a119a3b3e302342c7162b0612fdcb3 height=3129457 version=0x7131e1ff log2_work=72.962709 tx=6546451 date='2019-05-14 23:40:16' progress=1.000000 cache=11.4MiB(35822tx)
2019-05-14 23:41:04 UpdateTip: new best=794cd2e69dd56fcfd63fc43cd7a93e7fb3d39a93ccb67c4e64bced2db9fbdf29 height=3129458 version=0x7131e1ff log2_work=72.96271 tx=6546453 date='2019-05-14 23:41:04' progress=1.000000 cache=11.4MiB(35825tx)
2019-05-14 23:41:29 UpdateTip: new best=ad764e0f4ba3620f5bc93ede3f8c68a74f0b09ef91a1d703e732f6c538055010 height=3129459 version=0x7131e1ff log2_work=72.96271 tx=6546455 date='2019-05-14 23:41:36' progress=1.000000 cache=11.4MiB(35827tx)

But then later it rejected block 397db81e64408823be5abd2a04cf0457f34960cf6b2e43606bea18daa37c016d
2019-05-15 17:04:31 ERROR: CheckBlock() : cant find payment request block<PHONE_NUMBER>000000000000000000000000000000000000000000000000000000
2019-05-15 17:04:31 InvalidChainFound: invalid block=1d3f25869fa642d046d0ed2470e8ff0f19a33b4b6f9de870d975416ff8367e8a  height=3124851  log2_work=72.960596  date=2019-05-13 08:32:32
2019-05-15 17:04:31 InvalidChainFound:  current best=e56e058e17eb0bd979b4536040fa5a00d7d53c801303631d9635053354360964  height=3124850  log2_work=72.960596  date=2019-05-13 08:32:16
2019-05-15 17:04:31 ERROR: ConnectTip(): ConnectBlock 1d3f25869fa642d046d0ed2470e8ff0f19a33b4b6f9de870d975416ff8367e8a failed:
2019-05-15 17:04:31 InvalidChainFound: invalid block=1d3f25869fa642d046d0ed2470e8ff0f19a33b4b6f9de870d975416ff8367e8a  height=3124851  log2_work=72.960596  date=2019-05-13 08:32:32
2019-05-15 17:04:31 InvalidChainFound:  current best=e56e058e17eb0bd979b4536040fa5a00d7d53c801303631d9635053354360964  height=3124850  log2_work=72.960596  date=2019-05-13 08:32:16
2019-05-15 17:04:32 ERROR: AcceptBlockHeader: block 397db81e64408823be5abd2a04cf0457f34960cf6b2e43606bea18daa37c016d is marked invalid
2019-05-15 17:04:32 ERROR: invalid header received
2019-05-15 17:04:32 ProcessMessages(headers, 164003 bytes) FAILED peer=9
2019-05-15 17:04:32 ERROR: AcceptBlockHeader: block 397db81e64408823be5abd2a04cf0457f34960cf6b2e43606bea18daa37c016d is marked invalid
2019-05-15 17:04:32 ERROR: invalid header received
2019-05-15 17:04:32 ProcessMessages(headers, 164003 bytes) FAILED peer=23
2019-05-15 17:04:32 ERROR: AcceptBlockHeader: block 397db81e64408823be5abd2a04cf0457f34960cf6b2e43606bea18daa37c016d is marked invalid

best hash on forked chain: e56e058e17eb0bd979b4536040fa5a00d7d53c801303631d9635053354360964
I tried:
invalidateblock e56e058e17eb0bd979b4536040fa5a00d7d53c801303631d9635053354360964
reconsiderblock 397db81e64408823be5abd2a04cf0457f34960cf6b2e43606bea18daa37c016d

And I got these in debug.log:
2019-05-15 17:29:12 InvalidChainFound: invalid block=397db81e64408823be5abd2a04cf0457f34960cf6b2e43606bea18daa37c016d  height=3129456  log2_work=72.962709  date=2019-05-14 23:40:00
2019-05-15 17:29:12 InvalidChainFound:  current best=e56e058e17eb0bd979b4536040fa5a00d7d53c801303631d9635053354360964  height=3124850  log2_work=72.960596  date=2019-05-13 08:32:16
2019-05-15 17:29:13 connect() to [2601:241:8e00:13f0:7c85:4c1d:289e:b158]:44440 failed: Network is unreachable (101)
2019-05-15 17:29:19 ERROR: CheckBlock() : cant find payment request block<PHONE_NUMBER>000000000000000000000000000000000000000000000000000000
2019-05-15 17:29:19 InvalidChainFound: invalid block=1d3f25869fa642d046d0ed2470e8ff0f19a33b4b6f9de870d975416ff8367e8a  height=3124851  log2_work=72.960596  date=2019-05-13 08:32:32
2019-05-15 17:29:19 InvalidChainFound:  current best=e56e058e17eb0bd979b4536040fa5a00d7d53c801303631d9635053354360964  height=3124850  log2_work=72.960596  date=2019-05-13 08:32:16
2019-05-15 17:29:19 ERROR: ConnectTip(): ConnectBlock 1d3f25869fa642d046d0ed2470e8ff0f19a33b4b6f9de870d975416ff8367e8a failed:
2019-05-15 17:29:19 InvalidChainFound: invalid block=1d3f25869fa642d046d0ed2470e8ff0f19a33b4b6f9de870d975416ff8367e8a  height=3124851  log2_work=72.960596  date=2019-05-13 08:32:32
2019-05-15 17:29:19 InvalidChainFound:  current best=e56e058e17eb0bd979b4536040fa5a00d7d53c801303631d9635053354360964  height=3124850  log2_work=72.960596  date=2019-05-13 08:32:16
2019-05-15 17:29:19 connect() to <IP_ADDRESS>:44440 failed after select(): Connection refused (111)
2019-05-15 17:29:20 receive version message: /NavCoin:4.6.0/: version 70020, blocks=3131549, us=<IP_ADDRESS>:32850, peer=18
2019-05-15 17:29:21 receive version message: /NavCoin:4.6.0/: version 70020, blocks=3131558, us=<IP_ADDRESS>:60402, peer=19
2019-05-15 17:29:22 ERROR: AcceptBlockHeader: block 0d13ed4db56e3841ed22a2db13a1a366acdc4f804cb7c8efb83865f4a26083cb is marked invalid
2019-05-15 17:29:22 ERROR: invalid header received
2019-05-15 17:29:22 ProcessMessages(headers, 164003 bytes) FAILED peer=9
2019-05-15 17:29:22 receive version message: /NavCoin:4.5.2/: version 70020, blocks=3131558, us=<IP_ADDRESS>:35344, peer=20
2019-05-15 17:29:23 ERROR: AcceptBlockHeader: block 397db81e64408823be5abd2a04cf0457f34960cf6b2e43606bea18daa37c016d is marked invalid
2019-05-15 17:29:23 ERROR: invalid header received
2019-05-15 17:29:23 ProcessMessages(headers, 164003 bytes) FAILED peer=19
2019-05-15 17:29:23 ERROR: AcceptBlockHeader: block 397db81e64408823be5abd2a04cf0457f34960cf6b2e43606bea18daa37c016d is marked invalid
2019-05-15 17:29:23 ERROR: invalid header received

I tried this again:
invalidateblock e56e058e17eb0bd979b4536040fa5a00d7d53c801303631d9635053354360964
reconsiderblock 397db81e64408823be5abd2a04cf0457f34960cf6b2e43606bea18daa37c016d

and got this debug.log:
2019-05-15 17:33:21 UpdateTip: new best=e24a01cc9f30902454aaadf6144b68a83a64b1422c6556bf5f36b8d636ba5bd4 height=3124849 version=0x7131e1ff log2_work=72.960595 tx=6537199 date='2019-05-13 08:32:00' progress=0.993348 cache=0.0MiB(4tx)
2019-05-15 17:33:21 InvalidChainFound: invalid block=e56e058e17eb0bd979b4536040fa5a00d7d53c801303631d9635053354360964  height=3124850  log2_work=72.960596  date=2019-05-13 08:32:16
2019-05-15 17:33:21 InvalidChainFound:  current best=e24a01cc9f30902454aaadf6144b68a83a64b1422c6556bf5f36b8d636ba5bd4  height=3124849  log2_work=72.960595  date=2019-05-13 08:32:00
2019-05-15 17:33:22 connect() to <IP_ADDRESS>:44440 failed after select(): Connection refused (111)
2019-05-15 17:33:22 connect() to [2601:644:8000:9f21:c0ce:2ea0:27c8:8366]:44440 failed: Network is unreachable (101)
2019-05-15 17:33:24 connect() to [2001:0:2851:782c:28c7:efff:da07:6323]:44440 failed: Network is unreachable (101)
2019-05-15 17:33:26 connect() to <IP_ADDRESS>:44440 failed after select(): Connection refused (111)
2019-05-15 17:33:27 UpdateTip: new best=e56e058e17eb0bd979b4536040fa5a00d7d53c801303631d9635053354360964 height=3124850 version=0x7131e1ff log2_work=72.960596 tx=6537201 date='2019-05-13 08:32:16' progress=0.993348 cache=0.0MiB(5tx)
2019-05-15 17:33:27 ERROR: CheckBlock() : cant find payment request block<PHONE_NUMBER>000000000000000000000000000000000000000000000000000000
2019-05-15 17:33:27 InvalidChainFound: invalid block=1d3f25869fa642d046d0ed2470e8ff0f19a33b4b6f9de870d975416ff8367e8a  height=3124851  log2_work=72.960596  date=2019-05-13 08:32:32
2019-05-15 17:33:27 InvalidChainFound:  current best=e56e058e17eb0bd979b4536040fa5a00d7d53c801303631d9635053354360964  height=3124850  log2_work=72.960596  date=2019-05-13 08:32:16
2019-05-15 17:33:27 ERROR: ConnectTip(): ConnectBlock 1d3f25869fa642d046d0ed2470e8ff0f19a33b4b6f9de870d975416ff8367e8a failed:
2019-05-15 17:33:27 InvalidChainFound: invalid block=1d3f25869fa642d046d0ed2470e8ff0f19a33b4b6f9de870d975416ff8367e8a  height=3124851  log2_work=72.960596  date=2019-05-13 08:32:32
2019-05-15 17:33:27 InvalidChainFound:  current best=e56e058e17eb0bd979b4536040fa5a00d7d53c801303631d9635053354360964  height=3124850  log2_work=72.960596  date=2019-05-13 08:32:16
2019-05-15 17:33:27 connect() to [2002:4d25:a205:0:b56f:ef24:a38c:6308]:44440 failed: Network is unreachable (101)
2019-05-15 17:33:27 connect() to [2a02:a03f:3efc:ae00:59c5:2d0:5bf9:c7c8]:44440 failed: Network is unreachable (101)
2019-05-15 17:33:28 connect() to [2a01:e0a:1dc:240:d99b:2adf:2883:abd]:44440 failed: Network is unreachable (101)
2019-05-15 17:33:29 connect() to [2a01:e35:8b30:9b00:2cae:2570:4686:885d]:44440 failed: Network is unreachable (101)
2019-05-15 17:33:29 connect() to [2601:645:8300:662d:b9f6:1daa:e0ed:28dc]:44440 failed: Network is unreachable (101)

Then wallet crashed

Wallet crashes with:
zsh: segmentation fault (core dumped)  navcoin-qt

As requested, here is listproposals:
[
  {
    "version": 2,
    "hash": "67d2ebaa24e831cabcb13c561bd2f83a370573f2b9359f6569e3cde5ffa18a7c",
    "blockHash": "042c2b1016a0feb38a58e00ed23b68250f3db0c61e0942c93d7647cad04a4a11",
    "description": "Drone show (https://youtu.be/wFlwY5h_sD4) in the sky of San Francisco and two other cities (in Japan and South Korea)",
    "requestedAmount": "180000.00",
    "notPaidYet": "180000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "Ngab7g8CyG91E2W7GRH4y4wuq5pVWxbzoe",
    "proposalDuration": 15634800,
    "votesYes": 1122,
    "votesNo": 11962,
    "votingCycle": 6,
    "status": "rejected",
    "state": 2
  },
  {
    "version": 2,
    "hash": "b51d07537cfd2693d65aa03e9d77e4b9d3635bb50e74da0fe5e53de3d9e44b82",
    "blockHash": "ba8b04af01d9fcfaf7480ff3a1f2b671995681d07434e59cb904a4a7bebc48eb",
    "description": "navcoin-core dev bounty fund. more info at https://www.reddit.com/r/NavCoin/comments/bd1mku/navcoincore_dev_bounty_fund/",
    "requestedAmount": "25050.0001",
    "notPaidYet": "0.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NQdX9anXfZig6yxGyKbramw6cUJopTVMD6",
    "proposalDuration": 5184000,
    "expiresOn":<PHONE_NUMBER>,
    "votesYes": 11022,
    "votesNo": 187,
    "votingCycle": 1,
    "status": "accepted",
    "state": 1,
    "stateChangedOnBlock": "ee414e56285374c6e2bd7fb1d2144c479b82cf6b541232268a0e2925681a9c1e",
    "paymentRequests": [
      {
        "version": 2,
        "hash": "bcbe9ea141558c3fb1bea595ad71860bee1264a38e496a175ab0365062f7ef27",
        "blockHash": "322b5d6d521968e78868f101f4e97c5ccffc6c4e5b9a77c5505e56e640aab499",
        "description": "Request for withdrawing the coins for use with the NavCoin core dev bounty",
        "requestedAmount": "25050.0001",
        "votesYes": 10465,
        "votesNo": 192,
        "votingCycle": 0,
        "status": "accepted",
        "state": 1,
        "stateChangedOnBlock": "0953658ba02450e40e39c07ccea0562e60dd9d3fb44110bf896c4a6af70ed953",
        "paidOnBlock": "2e6a45c2d2b22d4cde11e49b0117b483e553a881115a4297147e2140570ee02f"
      }
    ]
  },
  {
    "version": 2,
    "hash": "943dd83d7f84afbf3f30ec58f5a847a906f11e68edb2e571abb8ccf25be1eb8d",
    "blockHash": "ae7a0691cfeaa97daaef0fcefc682cf714374c61bfb1fbfeb6e21623f6e65214",
    "description": "This Community Fund project is to fund the creation of the weekly news and supporting social media content for 3 months (13 weeks).\n\n  https://collab.navcoin.org/s/weekly-news/custom_pages/container/view?id=20",
    "requestedAmount": "22677.00",
    "notPaidYet": "22677.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NPHDkjvaGXXwgrquxUBhhaA74Q2gabmTxE",
    "proposalDuration": 10544400,
    "expiresOn":<PHONE_NUMBER>,
    "votesYes": 11834,
    "votesNo": 485,
    "votingCycle": 1,
    "status": "accepted",
    "state": 1,
    "stateChangedOnBlock": "cc6e9c798ee0465c22da846aa29d65a67a0cebdca1ba5d5e8d1468a8332906ff",
    "paymentRequests": [
      {
        "version": 2,
        "hash": "d95d62377c416f738634f504d444cd693283b675502f51e5e6dfc522bf35535b",
        "blockHash": "8c60a9fa28b1c77dda7b7bd44b51ad1ee4beba25449eee46c7ea23ce1d22bdf7",
        "description": "We have successfully delivered 7 weeks of community news & twitter updates since the acceptance of this proposal. This payment reqest is for a proportional amount of the 13 weeks proposed.",
        "requestedAmount": "12210.00",
        "votesYes": 0,
        "votesNo": 0,
        "votingCycle": 2,
        "status": "pending",
        "state": 0,
        "stateChangedOnBlock": "0000000000000000000000000000000000000000000000000000000000000000"
      }
    ]
  },
  {
    "version": 2,
    "hash": "7a42807685c889b9b6d1c7ff316b3166efa1eeba2a0bcc49c8e7dd1aed079596",
    "blockHash": "7aa334ac833ffd9123e543dc53cd5700a8b4ba86a715199ba739c935d721763b",
    "description": "This proposal will be used to fund research, development and creation of educational content around the Zero Confidential Transactions protocol described in https://www.researchgate.net/publication/330366788_Zero_Confidential_Transactions",
    "requestedAmount": "100000.00",
    "notPaidYet": "0.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NbvhwjyUwxdh54i91i7Eh7NPd7bVXrqMKH",
    "proposalDuration": 31622400,
    "expiresOn":<PHONE_NUMBER>,
    "votesYes": 11499,
    "votesNo": 1611,
    "votingCycle": 4,
    "status": "accepted",
    "state": 1,
    "stateChangedOnBlock": "4300aa7715b2d65f20d9f30f5d7791fb689c5ed70369462429b0f3a2fe9cc853",
    "paymentRequests": [
      {
        "version": 2,
        "hash": "1ce1e9478f171c604545032d17fd503fe8e364d939eeba5554e241ba985b70b1",
        "blockHash": "bd42b47b150d1e33fe0513fb4f4c68ad0592e0e67746da79cafdd007ae35cdf4",
        "description": "Release of source code/testnet implementation of ZeroCT 1st Phase",
        "requestedAmount": "50000.00",
        "votesYes": 11557,
        "votesNo": 187,
        "votingCycle": 1,
        "status": "accepted",
        "state": 1,
        "stateChangedOnBlock": "5c015632e19ff8c69762c716c241ae834f27fa1f13dcff11929dac7ea57b5bee",
        "paidOnBlock": "3a98e4a9788a393fbd6b2d0936c1ea2bcd9d54889f45c7d7936fc5ec2f39d72e"
      },
      {
        "version": 2,
        "hash": "98aead65205364f732f6bcb827df84fa374ff3f311297e6db7b6f06886e85ad4",
        "blockHash": "54253d107bbcc1ce6382c56ce1cf3c4ea31c21285ac167ec1bd737f71204a9eb",
        "description": "Bulletproofs Rangeproof Library finished, code committed https://github.com/NAVCoin/navcoin-core/pull/412/commits/577761f02da267e9b97b78fd14282c916d15a807\n",
        "requestedAmount": "25000.00",
        "votesYes": 12913,
        "votesNo": 372,
        "votingCycle": 1,
        "status": "accepted",
        "state": 1,
        "stateChangedOnBlock": "fd1b4efff5c599dbf810896b1abd9a09f043f94548fa1a077813d8a920fe50a2",
        "paidOnBlock": "1b3e9630db785b2666d1cc3bedd1940cb69189097ed56fe589aea0ca02f7ebf4"
      },
      {
        "version": 2,
        "hash": "8702a1e833d592792baf9b8d539599f44848f68f3e9d1b68be7ff0aa6e7fd27d",
        "blockHash": "4147e42f39ffd2fe286e2ebb94dfb31d676fc5826a79fcc48de8864d701b0038",
        "description": "Transaction amount obfuscation and ZeroCT staking - full paper implementation - https://github.com/NAVCoin/navcoin-core/pull/412/commits/b71221a481be0ea53ba29cdc4787a10c90eae805",
        "requestedAmount": "25000.00",
        "votesYes": 12292,
        "votesNo": 160,
        "votingCycle": 1,
        "status": "accepted",
        "state": 1,
        "stateChangedOnBlock": "e2a904676d5f8a28abb999c9128ad8c5132d8b69822249f57a5c90ddd4dd9c18",
        "paidOnBlock": "2dec195d2835f332ea6da59df312cc89a90f48c8d041f9ee6bc29c5dbbf465f9"
      }
    ]
  },
  {
    "version": 2,
    "hash": "a4b24b1db4363ed184bc2b84f0a9facb83cf5111158df39b3ba02ee6bc433e9b",
    "blockHash": "f6e1674c4dfb8c1fa6a9cbaf87a94cb068817f178910f9d7edc114e90d165ff7",
    "description": "Hi, my name is Natalie. I am a writer focused on blockchain industry. I am proposing to write an analysis article about NavCoin and share it through the social media. ",
    "requestedAmount": "1000.00",
    "notPaidYet": "1000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NP1Z8sNPnpeY1XnEcv4wFrzCoXxkauG2oa",
    "proposalDuration": 93780,
    "votesYes": 19,
    "votesNo": 8,
    "votingCycle": 1,
    "status": "pending",
    "state": 0
  },
  {
    "version": 2,
    "hash": "56c424f3778263322c039d98e95b91ec06be2257c239b4fe56ec82889cebd69b",
    "blockHash": "6a0e41ba1d936a305f9d4a256b8a50289164164b4b258d441066ff5aefde6ca6",
    "description": "Vote “YES” to this proposal to have complete privacy, at the expense of auditability and being considered a store of value. Please see https://tinyurl.com/y68clejy for the detailed description.",
    "requestedAmount": "50.00",
    "notPaidYet": "50.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NSqb7DNeBpLddVgZGRYc19wUKfJ2gErPye",
    "proposalDuration": 604800,
    "votesYes": 18,
    "votesNo": 6,
    "votingCycle": 2,
    "status": "pending",
    "state": 0
  },
  {
    "version": 2,
    "hash": "997f51323f7fbe73dfe47926734e6e9812446eb6bbb8e3ffdea490c24cd8529f",
    "blockHash": "e1c5088646a839a6fb50d9cfd2cf1c7d69cbe10818beb9e39a18dedef6831af7",
    "description": "NavCoin NEXT Mobile Application for Android & iOS https://navcommunity.net/navcoin-next-mobile-wallet",
    "requestedAmount": "40000.00",
    "notPaidYet": "40000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NTMvqtX5b21QVMSNwuvSDkw85rRi9JPvTE",
    "proposalDuration": 31104000,
    "votesYes": 24,
    "votesNo": 12,
    "votingCycle": 2,
    "status": "pending",
    "state": 0
  },
  {
    "version": 2,
    "hash": "e3b49149d2580c770a2029721388b07f56fdd64192fc85483d3d813e2fa82675",
    "blockHash": "76c276b37ca8cfcc515a05ac82ca006babfbf0ea849c9b1bb6fad92c74ada162",
    "description": "Vote “YES” to this proposal to preserve NavCoin as a store of value with complete auditability, at the expense of complete privacy. (current system) Please see https://tinyurl.com/y68clejy for the detailed explanation.",
    "requestedAmount": "50.00",
    "notPaidYet": "50.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NSqb7DNeBpLddVgZGRYc19wUKfJ2gErPye",
    "proposalDuration": 604800,
    "votesYes": 0,
    "votesNo": 0,
    "votingCycle": 2,
    "status": "pending",
    "state": 0
  },
  {
    "version": 2,
    "hash": "b1de35e16ce84ba260cae530febb6ba60744feffb21e29e57c4612fe56f6f0aa",
    "blockHash": "2b33dc397a6401076662c184361664fa5d04e251ce18dca57ece374d2be87d05",
    "description": "NavCoin Electrum Wallet Update & Resolving Issues on Github",
    "requestedAmount": "25000.00",
    "notPaidYet": "25000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NTyJLqaM8GSTuDHYGs7jqovWoncv1XBDPg",
    "proposalDuration": 630420,
    "votesYes": 3762,
    "votesNo": 9481,
    "votingCycle": 3,
    "status": "rejected",
    "state": 2
  },
  {
    "version": 2,
    "hash": "4cdf6475fe73427662d12bac606e79b3045c189ccf20c94dfad9b47be249aec5",
    "blockHash": "eff52e79d19d582060ac950fe98bcc0f640916e59e980cbf641544d590ee45e4",
    "description": "Ledger Nano S Integration for NavCoin. For more details visit https://collab.navcoin.org/s/ledger-nano-s-integration/custom_pages/container/view?id=13",
    "requestedAmount": "135000.00",
    "notPaidYet": "135000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NXdPupsNnLTvMoGFZrY6xN2g11UhLdM7hL",
    "proposalDuration": 31536000,
    "votesYes": 3294,
    "votesNo": 10093,
    "votingCycle": 6,
    "status": "rejected",
    "state": 2
  },
  {
    "version": 2,
    "hash": "e8b46f55fd222cf269ab2eb935ba38cc7c9d19b775d9dd781fb6c7b88059bdde",
    "blockHash": "eb13b36a533637c1381f41c2149718ecb409f4f80bbc0c0f5b6e1ef586f1f9da",
    "description": "Translation of NAVCOIN.ORG to Slovak and Czech (RESUBMITTED)",
    "requestedAmount": "5000.00",
    "notPaidYet": "5000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NRfmMwfErwewXPrBpwJqPFShzw3tBr3mKz",
    "proposalDuration": 15552000,
    "votesYes": 0,
    "votesNo": 0,
    "votingCycle": 3,
    "status": "pending",
    "state": 0
  },
  {
    "version": 2,
    "hash": "d8a9461bebe119a62c43e95f74e7264123ae8f12e76dfbffb0b422907c73e8e1",
    "blockHash": "51a7bebdca258a1012e39365c37ce996111f4a7bbb3a23ace3347528767e3b4e",
    "description": "Dev = mntyfrsh - Navdroid stakebox images and software packages for Odroid XU4. NavPi is no longer being developed and Navdroid is the intended replacement.",
    "requestedAmount": "15000.00",
    "notPaidYet": "15000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NbMFZByhwD3ioJBKLA1zkq22BiYeXnoER6",
    "proposalDuration": 864000,
    "votesYes": 16,
    "votesNo": 1,
    "votingCycle": 1,
    "status": "pending",
    "state": 0
  },
  {
    "version": 2,
    "hash": "9a3fc137ee0fd0118c109e6d9a05ee609aac67001270048e1e29b0182e41d8f5",
    "blockHash": "1473b8a9b0766195bafd9ac7b94e843b613a0f0e54f5838c230acf6476ea754f",
    "description": "https://collab.navcoin.org/content/perma?id=1148",
    "requestedAmount": "4200.00",
    "notPaidYet": "4200.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NXUcWamd3VR6xyYg3qGz4VVJB7i7nfh5Y2",
    "proposalDuration": 5184000,
    "votesYes": 1344,
    "votesNo": 11430,
    "votingCycle": 1,
    "status": "rejected",
    "state": 2
  },
  {
    "version": 2,
    "hash": "4206f890851a65cc4e15098a63732ee45ebb6c56f3c13104e9e7921a1e5f87ff",
    "blockHash": "7882ce2a08406cca50a45b97f8a7cdba1de2adc9766266abb262dce89932f0d8",
    "description": "NavCoin NEXT Wallet (https://navcommunity.net/navcoin-next-wallet-2019-roadmap)",
    "requestedAmount": "34900.00",
    "notPaidYet": "0.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NTMvqtX5b21QVMSNwuvSDkw85rRi9JPvTE",
    "proposalDuration": 31536000,
    "expiresOn":<PHONE_NUMBER>,
    "votesYes": 11704,
    "votesNo": 510,
    "votingCycle": 5,
    "status": "accepted",
    "state": 1,
    "stateChangedOnBlock": "ea1ac138143176ddccada8a089018c8a9d3d343c7639674b902d6615123344b4",
    "paymentRequests": [
      {
        "version": 2,
        "hash": "0ea4529d19e5f541fdde9b8e8de78770e7b126bc82717214ab48cc570c7b4a3c",
        "blockHash": "0f65dfdce87350220cf0977af079296b5b8561e5858ae587b7e132f8ed020553",
        "description": "Initial Development",
        "requestedAmount": "24900.00",
        "votesYes": 10944,
        "votesNo": 274,
        "votingCycle": 3,
        "status": "accepted",
        "state": 1,
        "stateChangedOnBlock": "325945593b292c586848e35a1a08d102e10ac3697a45ef9d597c6111a8710d1c",
        "paidOnBlock": "dd352566a59bb29c6817266fc6ff088a52feba271970cea0ecbacf273620d391"
      },
      {
        "version": 2,
        "hash": "106a053f99e5064167b449fb5c2a2025f37aa080bfcd5c729e3a70dbf3ccdc6f",
        "blockHash": "cabca4f2f05ad9dcaaaa903607259f647e68637f2be144b854dd84856a9c021e",
        "description": "Lite wallet implementation on NEXT Wallet https://blog.navcommunity.net/2019/03/24/next-lite-wallet-rc1-live/",
        "requestedAmount": "10000.00",
        "votesYes": 10234,
        "votesNo": 260,
        "votingCycle": 0,
        "status": "accepted",
        "state": 1,
        "stateChangedOnBlock": "f499ccb22d7cb6917be0f54e8ae30fdb15e1e12cd53276cb35d02610f7bfa7b3",
        "paidOnBlock": "1889a0990a4da739c83f35c56670daf6fe3849fbbb3efb296edac00e436d59d9"
      }
    ]
  },
  {
    "version": 2,
    "hash": "577bfc39406a55a61742c7634750fd0cf64ac149dcb096d31036c7d19df05402",
    "blockHash": "62affa38e29f7054e6dc702357fa170d15be9fec76a71b2ed70b8e76e30dfdf5",
    "description": "NavPool - https://collab.navcoin.org/s/navpool/custom_pages/container/view?id=19",
    "requestedAmount": "30000.00",
    "notPaidYet": "30000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NNWhXsLhe7iwHnV4Mr339ggoJJpV1LjyTr",
    "proposalDuration": 31556952,
    "expiresOn":<PHONE_NUMBER>,
    "votesYes": 13305,
    "votesNo": 547,
    "votingCycle": 1,
    "status": "accepted",
    "state": 1,
    "stateChangedOnBlock": "cc6e9c798ee0465c22da846aa29d65a67a0cebdca1ba5d5e8d1468a8332906ff",
    "paymentRequests": [
      {
        "version": 2,
        "hash": "7bf4feca3c8c1f25d3e3a40a9955d7cb134cf3b7f26aeee0a5a125dea29cd133",
        "blockHash": "77813672410d3d7d6358341ecd2120367edfd7c908a24d252b121c790b95e0a1",
        "description": "NavPool Node and Voting API launched on MainNet with successful staking",
        "requestedAmount": "10000.00",
        "votesYes": 0,
        "votesNo": 0,
        "votingCycle": 2,
        "status": "pending",
        "state": 0,
        "stateChangedOnBlock": "0000000000000000000000000000000000000000000000000000000000000000"
      }
    ]
  },
  {
    "version": 2,
    "hash": "86d521a55e402fe2a34ff72a96af9c43108d6726fe134eb3521d4d0210459e0e",
    "blockHash": "f49141110f93643ac7e0f4b7720ba921fa7e10434d02e5d7614534f54eb80bb7",
    "description": "Social Media Marketing + Crypto Advertising for NAV 2019 - https://collab.navcoin.org/content/perma?id=1116",
    "requestedAmount": "22500.00",
    "notPaidYet": "22500.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NNXposEe2cTQKg1MsKbV8nMpSAjxk7F3Z1",
    "proposalDuration": 2592000,
    "votesYes": 16,
    "votesNo": 20,
    "votingCycle": 6,
    "status": "pending",
    "state": 0
  },
  {
    "version": 2,
    "hash": "c9bb6a509b601a2a233154d60b04e6f9bce6cdc8636bbe667743593060ef9a13",
    "blockHash": "c462cd26db8c4d7bd46edda5341bd3dff61e3530faabf7ac20f1027b0b85e9fd",
    "description": "NavCoin Core v4.6.0 release candidate Community Fund request https://www.reddit.com/r/NavCoin/comments/bhs1g1/navcoin_core_v460_release_candidate_community/",
    "requestedAmount": "30000.00",
    "notPaidYet": "30000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NaCsidsB3UNDyVnCycZ1xAP2dei7RBgKsf",
    "proposalDuration": 5184000,
    "expiresOn":<PHONE_NUMBER>,
    "votesYes": 11546,
    "votesNo": 323,
    "votingCycle": 1,
    "status": "accepted",
    "state": 1,
    "stateChangedOnBlock": "2420b7c39ac6e7d8097b4dacb847031ee0cc5c9d3ad14bf15afb4adaac1ba29c",
    "paymentRequests": [
      {
        "version": 2,
        "hash": "785491267ef2cce458dd7fd6c273887b9bb33cd36caa86f4d5898e65ae1deb5e",
        "blockHash": "29bd754b4a8f3966c8dead17c5450fae5a95e25cae8bf2ca6328179acdaddc22",
        "description": "NavCoin v4.6.0 release payment request aguycalled - https://github.com/NAVCoin/navcoin-core/releases/tag/4.6.0",
        "requestedAmount": "30000.00",
        "votesYes": 27,
        "votesNo": 1,
        "votingCycle": 1,
        "status": "pending",
        "state": 0,
        "stateChangedOnBlock": "0000000000000000000000000000000000000000000000000000000000000000"
      }
    ]
  },
  {
    "version": 2,
    "hash": "1bfe004a6329b64d59f3d2dc9e0ee7cd049cc986faced30f5d27ef1785e38c1d",
    "blockHash": "fd072a0980e2443f5314abe67f06104645bf2b6ed9fe805924e3fbbabd2a85c1",
    "description": "Short Film about Love, Family, Lifes struggle Featuring NavCoin as the Payment in the Story. International Film Festival Exposure.",
    "requestedAmount": "14100.00",
    "notPaidYet": "14100.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NNzaMWgAUKbNQzq5ZFrVafRwVqXNkdPjAx",
    "proposalDuration": 2073600,
    "votesYes": 2837,
    "votesNo": 9240,
    "votingCycle": 5,
    "status": "rejected",
    "state": 2
  },
  {
    "version": 2,
    "hash": "e3382843b4487d7fe848873a29ff64970f3d1892f7b3a3a21acf38747ca2a120",
    "blockHash": "7fb0560a2120dfdeba0732c6a89650f8145701e9bde687ca3e98679d541b21e8",
    "description": "Donation to the victims of the Christchurch terrorist attack - https://www.reddit.com/r/NavCoin/comments/b25or6/community_fund_proposal_is_live_10000_nav_to_the/",
    "requestedAmount": "10000.00",
    "notPaidYet": "10000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "Nh15kuGLpFyR6DsnRXc6ZyRcyQKrU8L4wp",
    "proposalDuration": 1209600,
    "votesYes": 2368,
    "votesNo": 10267,
    "votingCycle": 1,
    "status": "rejected",
    "state": 2
  },
  {
    "version": 2,
    "hash": "6bcb46a3a148c80297db4ca23b8637903a003321cf2c90fd51fdeead03397522",
    "blockHash": "8b66b4d603add5021fd079b6c51e245bb0666f9936c6593997c504912ae259b2",
    "description": "With this proposal the Community can decide, if the NavCoins which results from a bug, should be burned or not.\nMore information: https://collab.navcoin.org/content/perma?id=1055",
    "requestedAmount": "68333.00",
    "notPaidYet": "68333.00",
    "userPaidFee": "50.00",
    "paymentAddress": "bJj83uBV4WXQLqyCdH841bzjW84JwQexnK",
    "proposalDuration": 1209600,
    "votesYes": 4476,
    "votesNo": 10797,
    "votingCycle": 4,
    "status": "rejected",
    "state": 2
  },
  {
    "version": 2,
    "hash": "cbd05a71fb5aab36d06788ba6193a3dfe9cdf12237701c5c73977e6bd8687225",
    "blockHash": "21bcaa7f0d2ff787b5441e491ef5ca362a7a5250eab8cb774358e5acbf246275",
    "description": "A Treasure Hunt for 25000 NavCoin. A challenge where 25000 Nav will be hidden in the picture created on the domain 25000nav.com. Whoever finds the key to the coins may keep the Navcoins. Its not a lot however it should still peak a lot of interest. Once the proposal is approved I will finish the site then request for payment to fund the treasure hunt.",
    "requestedAmount": "28000.00",
    "notPaidYet": "28000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NQMkAM4qEAUJD6P8gHmzdE6w8M5s4hwxQS",
    "proposalDuration": 93780,
    "votesYes": 1334,
    "votesNo": 10703,
    "votingCycle": 5,
    "status": "rejected",
    "state": 2
  },
  {
    "version": 2,
    "hash": "7c76baa862e28b4bccadaca89e6317b486d0f73bd5bb89dbfe4a3234ab52712d",
    "blockHash": "1ba933126dd65b292a9fc4e3df5c1e115c850a4b4860b62e8b3fedb1b3eb9373",
    "description": "NavCoin Marketing Campaign Portuguese We will give more visibility to NavCoin with this proposal and we will activate the Portuguese community in 100%, we are intusiasmados to grow! https://collab.navcoin.org/content/perma?id=1067",
    "requestedAmount": "1748.00",
    "notPaidYet": "1223.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NiESAqMSZHP6Kp6unsRLMTyqfpo2fcxZjm",
    "proposalDuration": 2851200,
    "expiresOn":<PHONE_NUMBER>,
    "votesYes": 12252,
    "votesNo": 576,
    "votingCycle": 2,
    "status": "accepted",
    "state": 1,
    "stateChangedOnBlock": "182ee42e25684f41c041e134043459e9cd8caeb3f5e042a818bc58216b004154",
    "paymentRequests": [
      {
        "version": 2,
        "hash": "2cb9617d363551c7974756854ff556a8b2da29f94d57f49896e5261d38c00123",
        "blockHash": "bd7f57c3fe6993db03a59b3ba0ca80a665616c062ea57faf8f2c093d09a395aa",
        "description": "enchorse\\part-payment-proposal-http://twixar.me/s9VK",
        "requestedAmount": "525.00",
        "votesYes": 12461,
        "votesNo": 664,
        "votingCycle": 1,
        "status": "accepted",
        "state": 1,
        "stateChangedOnBlock": "2420b7c39ac6e7d8097b4dacb847031ee0cc5c9d3ad14bf15afb4adaac1ba29c",
        "paidOnBlock": "506903a534540d09131acfb5f387751d7b9284e8701367b3db84312142c753a7"
      }
    ]
  },
  {
    "version": 2,
    "hash": "bdc588af828557deb114f67c5dfa87e44e4f25b142ac091aa6d65ee653cbf44a",
    "blockHash": "3a9ab32e55732053f96419cf6b71bb89e64b3c937375d01a0d47518d76917ffd",
    "description": "This proposal is to support the monthly hosting costs for NavExplorer. https://collab.navcoin.org/s/navexplorer/custom_pages/container/view?id=11",
    "requestedAmount": "6000.00",
    "notPaidYet": "2800.02",
    "userPaidFee": "50.00",
    "paymentAddress": "NYApiLtWC6MNK6khxCLwd6RHmKjATq9rVN",
    "proposalDuration": 36806400,
    "expiresOn":<PHONE_NUMBER>,
    "votesYes": 11121,
    "votesNo": 7,
    "votingCycle": 6,
    "status": "accepted",
    "state": 1,
    "stateChangedOnBlock": "59e154ba5db2ac5d09364221efa826af5f77d179db7a69aa562ec3758c01bcd7",
    "paymentRequests": [
      {
        "version": 2,
        "hash": "68ab306392f1bba61cf4aecf42862a13647a280f843a6594706f8bc8bf016fe2",
        "blockHash": "dfbd760bc5cc5500981a617426e27a60a760f20e157d2fedeb72125ed8a06d73",
        "description": "December 2018 https://collab.navcoin.org/s/navexplorer/custom_pages/container/view?id=15",
        "requestedAmount": "762.03",
        "votesYes": 11957,
        "votesNo": 209,
        "votingCycle": 5,
        "status": "accepted",
        "state": 1,
        "stateChangedOnBlock": "ea1ac138143176ddccada8a089018c8a9d3d343c7639674b902d6615123344b4",
        "paidOnBlock": "b7035dca9e2607db50607afcc1e8cd22710e1e721ffd6baffce715d99ec6a861"
      },
      {
        "version": 2,
        "hash": "62d9bd63477614f878936cf3ab6df09931e636e4d6ab980011f675b153e6434f",
        "blockHash": "24c7d62f48be4fa3a0c57d691a112e682075e6f830c303702284b437be25289e",
        "description": "NavExplorer January 2010 https://collab.navcoin.org/s/navexplorer/custom_pages/container/view?id=17",
        "requestedAmount": "1012.62",
        "votesYes": 12194,
        "votesNo": 222,
        "votingCycle": 2,
        "status": "accepted",
        "state": 1,
        "stateChangedOnBlock": "5c015632e19ff8c69762c716c241ae834f27fa1f13dcff11929dac7ea57b5bee",
        "paidOnBlock": "ca95f64ba33891202ddd147cc40ca16ff1d33dfe578e313f6f7aafdb253e8c46"
      },
      {
        "version": 2,
        "hash": "10cd48de94c2f6114cd184d13d4a0f3555871ee9bbc3fde44e89b3984219fd15",
        "blockHash": "89a6f42371128bc94c405af8066a385520a306265ddeb657ab4c9bb9f5b131e2",
        "description": "NavExplorer February 2019 https://collab.navcoin.org/s/navexplorer/custom_pages/container/view?id=18",
        "requestedAmount": "839.41",
        "votesYes": 10798,
        "votesNo": 298,
        "votingCycle": 0,
        "status": "accepted",
        "state": 1,
        "stateChangedOnBlock": "fd1b4efff5c599dbf810896b1abd9a09f043f94548fa1a077813d8a920fe50a2",
        "paidOnBlock": "1b3e9630db785b2666d1cc3bedd1940cb69189097ed56fe589aea0ca02f7ebf4"
      },
      {
        "version": 2,
        "hash": "a5e2d4ac68709805ee105e004fdcde0fbbf8a127e10731d0e004e9fe739e9470",
        "blockHash": "4362961c4b56922b5948502a3eb7ec6db625ac763fb038ccb85dc1c02dec28d6",
        "description": "NavExplorer March 2019 https://collab.navcoin.org/s/navexplorer/custom_pages/container/view?id=21",
        "requestedAmount": "585.92",
        "votesYes": 12859,
        "votesNo": 514,
        "votingCycle": 1,
        "status": "accepted",
        "state": 1,
        "stateChangedOnBlock": "182ee42e25684f41c041e134043459e9cd8caeb3f5e042a818bc58216b004154",
        "paidOnBlock": "af8a8685e799a1969aabf46a4df7dd4b8393cff7d0736b26030ee6706c2ddaaf"
      },
      {
        "version": 2,
        "hash": "2b251890e6e772dacd8943da8717c80088c7180f25dce9ad992a6e6eb1fbf4c5",
        "blockHash": "cf630e6199a63960f4605e10ec72a8102a68111bc638c546c70cdc79d26d2e88",
        "description": "NavExplorer April 2019 https://collab.navcoin.org/s/navexplorer/custom_pages/container/view?id=23",
        "requestedAmount": "658.99",
        "votesYes": 0,
        "votesNo": 0,
        "votingCycle": 2,
        "status": "pending",
        "state": 0,
        "stateChangedOnBlock": "0000000000000000000000000000000000000000000000000000000000000000"
      }
    ]
  },
  {
    "version": 2,
    "hash": "2455135c51a2b3dc090c4ba21716e397fd23a0fde5430c6650c2753cc1816b58",
    "blockHash": "4fe6960ebbada97f2b62c9e541141126861b860773bff1b876536e5e01a03987",
    "description": "Translation of 10 articles in french - https://collab.navcoin.org/s/translations-10-articles-french/",
    "requestedAmount": "5000.00",
    "notPaidYet": "5000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NeC7jJqQ4sKAydK85uMs98LjXNss92yCC4",
    "proposalDuration": 1296000,
    "votesYes": 3808,
    "votesNo": 9045,
    "votingCycle": 3,
    "status": "rejected",
    "state": 2
  },
  {
    "version": 2,
    "hash": "e8940f6da7dce32539852adb802338aa9e1f4ec89b966b6971b0feff9d1e556f",
    "blockHash": "c0997767bb3fc410e298c503d5430bab26b3886b27bf3d5e243e27ed559b88a8",
    "description": "Translate NavPay into Romanian language",
    "requestedAmount": "900.00",
    "notPaidYet": "900.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NVHq79sADVMEGa2jX9sZDxLQmbFc931zBS",
    "proposalDuration": 7776000,
    "votesYes": 21,
    "votesNo": 16,
    "votingCycle": 2,
    "status": "pending",
    "state": 0
  },
  {
    "version": 2,
    "hash": "d1512d18491f9dec2dcd993ce5673b49081ea8ce105fe91b2a4b06ef27dc8371",
    "blockHash": "883d5324c0900015857fa9a38fa371ba7c0673f693e1b900c85c29fd9719ec60",
    "description": "Translation of NAVCOIN.ORG to Czech and Slovak language (Introducing Navcoin to new audiences pt. 1/2)",
    "requestedAmount": "5000.00",
    "notPaidYet": "5000.00",
    "userPaidFee": "50.00",
    "paymentAddress": "NRfmMwfErwewXPrBpwJqPFShzw3tBr3mKz",
    "proposalDuration": 15552000,
    "votesYes": 3685,
    "votesNo": 8851,
    "votingCycle": 2,
    "status": "rejected",
    "state": 2
  }
]

Seems it's caused by cfund db and coin db  not being in sync (Possibly caused by a wallet crash)
@aguycalled said he has a branch in the works for a fix.

im hoping my troubles are related.  here's the relevant part of log:
2019-05-17 11:59:55 UpdateTip: new best=2af9c6e70ad4ebad9b9c28f43090080a0462e072d95cfb0c5424f17857a153d8 height=2762321 version=0x7111e1ff log2_work=72.788964 tx=5803568 date='2019-01-05 06:36:32' progress=0.654045 cache=103.2MiB(362869tx)
2019-05-17 11:59:55 UpdateTip: new best=270d7e38c6367c05ff9a1078acac048d0d40a638ab57daf449143ed058dff219 height=2762322 version=0x7111e1ff log2_work=72.788965 tx=5803570 date='2019-01-05 06:37:04' progress=0.654046 cache=103.2MiB(362871tx)
2019-05-17 11:59:55 UpdateTip: new best=0dd790a1f9a2fc868a476f437fbe20c31f84699be9137dcac736368207a58222 height=2762323 version=0x7111e1ff log2_work=72.788965 tx=5803572 date='2019-01-05 06:37:52' progress=0.654047 cache=103.2MiB(362873tx)
2019-05-17 11:59:55 UpdateTip: new best=1ba5591ec4dc47c7fdf9c3ff7b49d7e9948607de2b0be27648e0ec0c0e4aef1d height=2762324 version=0x7111e1ff log2_work=72.788966 tx=5803574 date='2019-01-05 06:38:08' progress=0.654047 cache=103.2MiB(362875tx)
2019-05-17 11:59:55 UpdateTip: new best=d861941983abcf3620ec9a810e99b21d7fed83cb682047001dff58f84ddd8042 height=2762325 version=0x7111e1ff log2_work=72.788966 tx=5803576 date='2019-01-05 06:38:24' progress=0.654048 cache=103.2MiB(362877tx)
2019-05-17 11:59:55 UpdateTip: new best=6f0c83a1f66c3f82f544b2158396b40854d038499b20312db367ac523f6d0601 height=2762326 version=0x7111e1ff log2_work=72.788967 tx=5803578 date='2019-01-05 06:39:28' progress=0.654049 cache=103.2MiB(362879tx)
2019-05-17 11:59:56 init message: Rewinding blocks...
2019-05-17 12:00:19 init message: Verifying blocks...
`

..so it stopped on 2762326 and appears to have restarted itself?
let me know if/how i can be of further help.

@rocket-pig once @aguycalled has looked at the debug.log you sent him, he should be able to confirm if it's related to this issue, if it is, then it will be fixed on his next PR :+1:

i'd of course love to understand more of why it happened too if possible :)


feat: allow defining a python version list for GHA action (alt)

This is another way to implement the feature discussed in #601.
It hopefully addresses any shortcomings in the implementation except for the yaml list which is still not possible but has been replaced with a simple enough comma-separated list.
It now supports any python version supported by actions/setup-python@v3 with up-to 20 versions installed.
The python validation/helper script which is currently inlined in the action might benefit from being a standalone script allowing for proper testing. I can do this if maintainers want to pursue this further.
One thing discovered while working on this is that mixing actions/setup-python & wntrblm/nox actions might not be that safe.
e.g. let's say that for some reason that I need pypy-3.9-nightly because of a bug in pypy-3.9:
    # this breaks cpython3.9 testing (overridden by pypy-3.9-nightly)
    - uses: wntrblm/nox
    - uses: actions/setup-python@v3
      with:
        python-version: "pypy-3.9-nightly"

    # this is just no-op (pypy-3.9-nightly overridden by wntrblm/nox)
    - uses: actions/setup-python@v3
      with:
        python-version: "pypy-3.9-nightly"
    - uses: wntrblm/nox

    # we currently need to do this
    - uses: wntrblm/nox
    - uses: actions/setup-python@v3
      with:
        python-version: "pypy-3.9-nightly"
    - uses: actions/setup-python@v3
      with:
        python-version: "3.9"

    # with this PR
    - uses: wntrblm/nox
      with:
        python-versions: "3.7, 3.8, 3.9, 3.10, pypy-3.8, pypy-3.9-nightly"

closes #601

thanks for the review, I'm a bit short on time until this week-end so I will address most remarks then.
In the meantime, #606 is probably easier to review and included here (https://github.com/wntrblm/nox/pull/609#discussion_r862752916 is applicable to #606 so maybe we should start there ?)

Am I correct in thinking that the additional validation logic here is purely a result of avoiding the "['3.6', '3.7', '3.8'...]" syntax?
If so I don't think the increased complexity is worth it and I'd actually be happier with a string list syntax. Sorry that I've flip flopped on this but I didn't appreciate how much additional complexity would be required

The validation/helper logic is not only there to avoid the "['3.6', '3.7', '3.8'...]" syntax. That's only a small aspect of what's being achieved in this PR.
The main goal with this alternative to the implementation of #601 is for the wntrblm/nox action to be able to install any python version that can be installed with actions/python correctly. The list of python version that can be installed with the action in #601 is hardcoded meaning it will require some updates every now & then (e.g. when python 3.11 is released or python 3.7 EOL, ...).
The implementation here comes with a small increase in complexity but is in my opinion more usable and I feel that there will be less maintenance on the action in the long run.

The implementation here comes with a small increase in complexity but is in my opinion more usable and I feel that there will be less maintenance on the action in the long run.

So this one is intended to replace #601 ?

So this one is intended to replace https://github.com/wntrblm/nox/pull/601 ?

short answer: yes.
longer answer: I'm keeping #601 opened for now if maintainers think this added complexity is really too much to handle. #601 might be an acceptable middle ground.

Sorry for the long delay, been a bit of a busy period! This is looking really good and thanks @mayeut for all the effort you've put in so far. It would be good to get a couple other maintainers to weigh in with any thoughts/comments (@wntrblm/nox) but this looks good to me 👍🏻

LGTM

Thanks for the feedback. I rebased on main to fix the conflict.

Thanks @mayeut 🎉


Diagram and Push illustration changes

@netmilk: Please check out the files that were changed in this PR. Is this better?
Fixes #4

@netmilk: I hope you can fit this on your screen now.

Thank you for the info, it doesn't fit but let's deal with it later in a separate issue. I think we'll need a vertical version for mobile and a horizontal version for desktop.  Otherwise, the PR looks fine to me. :)


Is it possible to get route data for an activity using this library?

Describe the solution you'd like
I'm trying to retrieve the route data the user has taken while he/she was running so I can display the path on a map. Haven't find anything about it in the docs. Is this implemented?
Thanks

@krakz999 That's not implemented


fermyon-spin: 1.2.1 -> 2.1.0

Description of changes
I've updated this package, which is extremely out of date. I'm not 100% sure how to generate the correct sha hashes for any platforms except linux, but I tried it with nix store prefetch url. Can confirm this is now working on linux 64 bit

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I don’t think Spin 1.3.0 works to deploy apps any more since FC moved exclusively to using OCI for app distribution, so losing built in spin cloud deploy is ok.
I think as a follow up we’ll need to package the cloud plugin (fermyon/cloud-plugin) and potentially add a module to allow folks to install it easily.