Channel that will never close?

Background
Hi. I closed down a few channels weeks ago, but some have been stuck at "closing" and some at "pending force close" for weeks now, maybe over a month.
here is the funding transaction for one of them https://blockstream.info/tx/aafb436d391dbf5f6eadfcbb062bc571c70b92bc3184478e2c84e13e75497073
And I guess I know why it does not close, the fee is 0.00000578 BTC or 0.29 USD. This is not getting picked up in the mempool, since it is never cleared out.
What can I do here, I have three channels, and they look to be potentially stuck in this state forever. There should be a way to somehow pump the fee so it can be closed.
Your environment

version of lnd

lncli version 0.11.0-beta commit=basedon-v0.11.0-beta-fresh-btcpay

which operating system (uname -a on *Nix)

Linux BTCPayServerVM 5.0.0-1028-azure #30~18.04.1-Ubuntu SMP Fri Dec 6 11:47:59 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

version of btcd, bitcoind, or other backend

Bitcoin Core RPC client version v0.20.1

Can you fill in the rest of the issue template including what backend, version, you're running, etc?
You can use the BumpFee command to use CPFP to increase the fee rate of the closing transaction.

Can you fill in the rest of the issue template including what backend, version, you're running, etc?
You can use the BumpFee command to use CPFP to increase the fee rate of the closing transaction.

Thanks for the quick response, updated the issue with environment details.
Still unsure how I can fix this with bump fee, for example this one

It has been "closing" for weeks now, the only transaction I know about is the funding transaction here:
https://blockstream.info/tx/aafb436d391dbf5f6eadfcbb062bc571c70b92bc3184478e2c84e13e75497073
That one is already confirmed, so can't bump the fee on that one.
Can I change it to a "force close"? then get a "closing transaction" txid, then bump the fee of the closing transaction?

The channel was force closed with a 6 sat/vByte TX: 7f87cc718a9a3d012d6288519a941d03f55bef5f17502173d73995bf861cc1de
Since that TX is time locked (you were the closing party), you can't CPFP it. There unfortunately is nothing you can do on your end other than wait for the mempool to clear below 6 sat/vByte. If you know who the remote peer is you can ask them to CPFP the TX.

The channel was force closed with a 6 sat/vByte TX: 7f87cc718a9a3d012d6288519a941d03f55bef5f17502173d73995bf861cc1de
Since that TX is time locked (you were the closing party), you can't CPFP it. There unfortunately is nothing you can do on your end other than wait for the mempool to clear below 6 sat/vByte. If you know who the remote peer is you can ask them to CPFP the TX.

That is what I was afraid of, in this case it is not that many sats and it might be cleared at some point. But, what if it was a larger amount of BTC and the mempool never got cleared and reached the transaction fee. There is a potential risk of getting BTC stuck forever. Practically losing your Bitcoin on lightning.

Yes, that is a potential problem in LN. The upcoming anchor commitment channel format (see https://lightning.engineering/posts/2020-04-30-lnd-v0.10/ for more information) is addressing exactly that problem.
Closing this as there's nothing more that can be done at this point other than waiting.


Publish stream with unknown length

Instead of serializing JSON data to a string, and then publishing, I am wanting to serialize to publish stream.
Problem is I do not know the length before hand, and do not want to calculate each value and key in the JSON document.
Is it ok to pass beginPublish() a length larger than what I send, and call endPublish prematurely?
Or would I have to send dummy data after?
My idea is something like this, just wondering if there is a right and a wrong way to do this.
bool success = false;
size_t docSize = document->capacity();

if (success = mqttClient.beginPublish(topic, docSize, deviceMqttSettings.retain))
{
	size_t size = serializeJson(document, mqttClient);

	while (docSize > size)
	{
		mqttClient.write((uint8_t)" ");
		size++;
	}

	success = mqttClient.endPublish();
}

size_t len = measureJson(doc);

Ahh thanks.
Did not know that function exists.


Update downshift to the latest version

Description
We are a major version behind on downshift. Update the downshift dependency to the latest version.
Since it is a major version upgrade, there may be some things to fix. I suggest reading over the release notes to see what has changed to ensure there is not a breaking change. Run regression tests on the components.
Please use the exact version. For example, ^7.3.2 🚫  |  7.3.2 ✅
downshift   6.1.12  →   7.3.2

Contribution Guide
If this is your first time contributing to UI Kit, please review the How to Contribute guide beforehand.

@nataliepina may I take this?

Yes, thank you 👍🏻


Mac M1: docker image not working

OSError: [Errno 28] No space left on device: '/home/jovyan/.local'

This method is not expected to work for mac M1 users, the docs will be updated shortly to include a note about this. Thanks for flagging!


Windows OS Option?

Would there be any possibility of using this on a Windows machine? If not, do you know of any similar projects like you have that are for Windows?
Thank you,
Rob

I'm wondering the same, if this could somehow be integrated with Git Bash, Mintty, Cygwin, or Msysgit2 or something like that.

VMWare into your favorite distro or Mac OS.  It might not be the best solution, but why not?  I can run YADR natively, but I still have boxes I work in tailored for specific tasks.  Although it's hard to ignore the fact that Windows is slowly creeping up to the lead for server distributions.  I guess all those young gamers have turned into MCSE.

As per noted in the README file, we can only support OSX at the moment.
All support towards Windows or Linux must come as contributions from the community as the maintainers only have OSX machines to test things out now.
If you find a clean way to support it, feel free to contribute back to us by opening a PR! :-) Thanks


[Bug][Sort] Data copy process is not used for MySQL node

What happened

Data copy process is not used
What you expected to happen
mysql to mysql
How to reproduce
no
Environment
No response
InLong version
master
InLong Component
InLong Manager
Are you willing to submit PR?

[ ] Yes, I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@gong @yunqingmoswu PTAL, thanks.

@linqianppb Can you please define what daata copy process is and describe more details in your description? Since your pic shows only the checkpoint process


[Docs] Make sure venv is py3 and export app

[X] Update docs to install a virtualenv for python3
[X] Export app before starting flask app

Codecov Report

Merging #6401 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #6401   +/-   ##
=======================================
  Coverage   77.31%   77.31%
=======================================
  Files          67       67
  Lines        9581     9581
=======================================
  Hits         7408     7408
  Misses       2173     2173

Continue to review full report at Codecov.

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

I wonder if all systems and linux distros have a python3 link in their path. That may not be the case moving forward as it becomes the default. python3 may also be unsupported versions of python (3.4, 3.5, ...). Maybe we should add a note or something there "Setup a python3.6 virtualenv"


ERR_UNKNOWN_FILE_EXTENSION: Unknown file extension ".vue"

The issue
When an external package is importing / exporting a file type that is known to vite (.vue), the build fails.
Stacktrace
[vite-ssg] An internal error occurred.
[vite-ssg] Please report an issue, if none already exists: https://github.com/antfu/vite-ssg/issues
(node:79140) UnhandledPromiseRejectionWarning: TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".vue" for<EMAIL_ADDRESS>    at new NodeError (internal/errors.js:322:7)
    at Loader.defaultGetFormat [as _getFormat] (internal/modules/esm/get_format.js:71:15)
    at Loader.getFormat (internal/modules/esm/loader.js:105:42)
    at Loader.getModuleJob (internal/modules/esm/loader.js:243:31)
    at async ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:78:21)
    at async Promise.all (index 0)
    at async link (internal/modules/esm/module_job.js:83:9)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:79140) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 436)
(node:79140) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

@alexgrozav  see https://github.com/antfu/vite-ssg/issues/161

Thank you for the help, @userquin. I'm running into a different issue now, if you can help me out with it #166


GH: auto label conflict PR

Description
I think this help
Checklist:

[x] Securely signed commits
[ ] Component(s) with PHPDoc blocks, only if necessary or adds value
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[x] Conforms to style guide

@ddevsr Thank you!

Sorry, this does not work.
We need to rework.

the place of the file is wrong.
if the PR is not updated, the check does not run.

The file must in workflows?

Yes.
See https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions#create-an-example-workflow

@kenjis I make PR to moving #7928

@ddevsr Thank you!


Workaround for missing animation on this.show() when module is alone in region

When you hide a module using this.hide() the function updateWrapperStates is called. This function basically checks if any module (wrapper) inside each region has it's style.position set to static (or blank). If no module (wrapper) is found, then the style.display is set to none and hereby hides the region.
The problem is that this prevents the animation when this.show() is later called.
I've added a new parameter to option in this.hide(): hiddenWrapperStyle that has to be set to static.
If you have a module that you later want to animate when showing, you have to explicitly hide the module using this parameter, like this:
var options = { hiddenWrapperStyle: 'static' };
this.hide(2000, callback, options);

Thanks for the report. It feels a bit like a hack/workaroud. I think it's better to solve the issue without the need for an extra flag.

Yes, I agree. Have replaced it with PR https://github.com/MichMich/MagicMirror/pull/750 that hopefully should not be that hacky...


NVIDIA ROS2 projects documentation

This update provides ROS2 based projects on NVIDIA Jetson platform.

@clalancette I got this to the point where I think it is ready to merge. Can you do a quick second pass and smash that merge button?

@mergifyio backport galactic foxy


Scene graph

Just wonder, does anyone has the scene graph for all splits of the GQA Dataset?

No, the scene graphs of the test and dev sets are intentionally kept hidden so no one has access to them and they aren't being used for any baselines/models/features etc.
The only place where they have been used was in an experiment on page 15 of the original GQA paper https://arxiv.org/pdf/1902.09506.pdf where I measured performance over "perfect sight" (blue column) to evaluate the importance of visual vs semantic/reasoning aspects of the dataset in terms of impact on accuracy of current models.
Hope it helps!


[RemoteAST][build-break] Fix missing cassert include

What's in this pull request?

assert is undefined, causing the build to break (on at least Ubuntu 15.10) as of https://github.com/apple/swift/commit/093009b3ef9329e44d8d4b8b69e271ba5e3b80d2.
/cc @rjmccall
Resolved bug number: (SR-)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    OS X platform               | @swift-ci Please test OS X platform
    Linux platform              | @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

Fixed in https://github.com/apple/swift/commit/a8f9c8338bf7ba599b88a42e8c4e4df0f04ba1c0.


Initiate Spanish Localization Team

This issue is to initiate a new l10n Team
Please only use this template for submitting a new l10n team initiation requests.
See https://github.com/cncf/glossary/blob/main/LOCALIZATION.md for basic requirements for a new l10n team.

(1) The language and language code for l10n
Find localization's two-letter language code from ISO 639-1 standard.

Language name: Spanish
Language two-letter code: es

(2) List of volunteers
Name and GitHub Username for each l10n volunteer. Add [A] to make them approvers.

[A] Catherine Paganini (@CathPag)
[A] Rael Garcia (@raelga)
[A] Victor Morales (@electrocucaracha)
Rodolfo Martínez Vega (@ramrodo)
Miguel Garzon (@miguelangat)
Yngrid Coello (@yngrdyn)
Carol Valencia (@krol3)
Anyul Rivas Oropeza (@anyulled)
Jhonnatan Gil(@jthan24)

(Note) Next actions from maintainers

Create a new development branch for the l10n. (ex: dev-ko)
Update codeowners to add l10n contents approvers.
Add a new label for the language.

Awesome!

Hello @electrocucaracha
Thank you the initiation of Spanish localization team !
I'd like to inform you following progress.

Added a new label for the language.
lang/es https://github.com/cncf/glossary/issues/labels

Created a new development branch for the l10n.
https://github.com/cncf/glossary/tree/dev-es

Update permission to add l10n contents approvers.
Working on it (I will open a PR to do this, after a consensus among maintainers)

I will review #388 :)

Hi @electrocucaracha please add me to this initiative

Let's go! 🚀

Heeey dear friends! May I please be added to this initiative? Thanks in advance :)

Hi, for those interested in joining the Spanish localization team, please join the #glossary-localizations and #glossary-localization-spanish channels on the CNCF Slack


Anybody facing slow debugging?

Hello everyone.
I am facing slow debugging. It is bit slow and when try to click on button within app, it fires after 2-3 seconds. Sometimes takes 7-10 seconds. What is the problem? These following are my package dependencies.
"hermes-engine": "^0.1.1",
   "native-base": "^2.13.4",
   "react": "16.8.6",
   "react-native": "0.60.4",
   "react-native-gesture-handler": "^1.3.0",
   "react-native-reanimated": "^1.1.0",
   "react-native-sqlite-storage": "^3.3.11",
   "react-native-swipe-list-view": "^2.0.0",
   "react-navigation": "^3.11.1"

disable your hermes, then it will be faster, weird problem @ErHarinderSingh


Anchor point for AdvancedMarkerElement

I've made custom HTML cluster markers for my vector map, but they seem to default to 'anchoring' (i.e. positioning relative to the lat/long) at the bottom centre of the element. I'd instead like mine to anchor to the centre on both axes.
There's such a property on the standard marker, but at least according to the type definitions there doesn't seem to be one for AdvancedMarkerElement. Is this possible?
To illustrate, I've put a red background on the marker div, notice how the green dot moves closer to the actual location as you zoom in.
https://github.com/googlemaps/js-markerclusterer/assets/3835991/37db6d1f-1ccc-4f2c-a859-893c32b80e33

If you would like to upvote the priority of this issue, please comment below or react with :+1: so we can see what is popular when we triage.
@oeed Thank you for opening this issue. 🙏
Please check out these other resources that might help you get to a resolution in the meantime:

Check the issue tracker - bugs and feature requests for Google Maps Platform APIs and SDKs
Open a support case - Get 1:1 support in Cloud Console.
Discord - chat with other developers
StackOverflow - use the google-maps tag

This is an automated message, feel free to ignore.

You should translate you image, check how the renderer does it
https://github.com/googlemaps/js-markerclusterer/blob/main/src/renderer.ts#L133

Thank works perfectly, thanks for the suggestion!


React TypeScript - Annotations not rendering correctly.

Hi,
My annotations are set to:
annotation: {
  events: ["onClick"],
  annotations: [{
    drawTime: "afterDraw" as "afterDraw",
    type: "box" as "box",
    xMin: "2 Sep",
    xMax: "4 Sep",
    yMin: 0,
    yMax: 50,
    backgroundColor: "green",
    borderColor: "red",
    borderWidth: 1,
    onClick: function (e: any) {
    //do something...
    },
  },],
},

And I initialise the Bar chart using:
<Bar
  data={data}
  height={height}
  options={options}
  plugins={[ChartAnnodation]}
 />

Which Renders:

The issue:
I can't get the box annotation to fill the correct space, it simply fills all the space. I have tried different values for the min/max of both axis, but it makes no difference.
You will see that I have to set drawTime and type in a strange way, otherwise if I set them normally, I get the following type errors:

Types of property 'type' are incompatible.
Type 'string' is not assignable to type '"box"'.
Overload 2 of 2, '(props: LinearComponentProps, context?: any): Bar', gave the following error.

I am not sure what I am doing wrong, or why it it would be throwing type errors.
I am using:
"@types/chartjs-plugin-annotation": "^0.5.1",
"chartjs-plugin-annotation": "^0.5.7",
"chart.js": "^2.9.3",

Your values are incorrect it seems.

One of snippets from examples:
{
            drawTime: "beforeDatasetsDraw",
            type: "box",
            xScaleID: "x-axis-0",
            yScaleID: "y-axis-0",
            xMin: "February",
            xMax: "April",
            yMin: randomScalingFactor(),
            yMax: randomScalingFactor(),
            backgroundColor: "rgba(101, 33, 171, 0.5)",
            borderColor: "rgb(101, 33, 171)",
            borderWidth: 1,
            onClick: function(e) {
              console.log("Box", e.type, this);
            }
          }

I'd guess this is related to scale configuration (and/or the missing x/yScaleID)

@kurkle @Veda-cmd tx
Does the x/yScaleID relate to the x/yAxisID?
I have updated the annotations to include the scaleIDs:
    events: ["onClick"],
    annotations: [
        {
            drawTime: "afterDatasetsDraw" as "afterDatasetsDraw",
            type: "box" as "box",
            xScaleID: "x-axis-0",
            yScaleID: "y-axis-0",
            xMin: "3 Sep",
            xMax: "5 Sep",
            yMin: 0,
            yMax: 50,
            backgroundColor: "green",
            borderColor: "red",
            borderWidth: 1,
            onClick: function (e: any) {
                // console.log("Box", e.type, this);
            },
        },
    ],
},```

At which point no annotations render.

I had a look at the documentation in regards to the Bar chart:

https://www.chartjs.org/docs/latest/charts/bar.html#general

And see that I need to add in a xAxisID and yAxisID, which I have done:

```const data = {
    labels: labels,
    datasets: [
        {
            xAxisID: "x-axis-0",
            yAxisID: "y-axis-0",
            data: values,
        },
    ],
};```

And updated my scales:

```scales: {
    yAxes: [
        {
            id: "y-axis-0",
        },
    ],
    xAxes: [
        {
            id: "x-axis-0",
        },
    ],
},```

And still no annotation is rendering.

No need to update the ids in scales.
There is one point which is mentioned in Box Annotations:

Box annotations are supported. If one of the axes is not specified, the box will take the entire chart dimension.

The 4 coordinates, xMin, xMax, yMin, yMax are optional. If not specified, the box is expanded out to the edges

Your axes or values seem incorrect. Please try some variations of values and see if it is rendering.

I can't spot any error in the values or config. Can you create a reproduce somewhere? It might be related on how the chart is initialized for react.

When I remove the xScaleID from my annotations, it renders the annotation and if I change the yMin/Max values, the annotation shifts up/down vertically.
So it seems to do with the xScaleID and it's xMin/Max values.
When I put it back, nothing renders. I have tried different date values, but no matter what combination I use it simply doesn't render.
I wanted to know, I format the xAxes ticks:
ticks: {
    callback: function (value: string, index: number, values: any) {
        const date = new Date(value);
        return `${date.getDate()} ${date.toLocaleString("default", {
            month: "short",
        })}`;
    },
},

And as per the screenshot the ticks are render as 7 Aug, 14 Aug etc. while the data labels are still in the full format, e.g. Mon Aug 10 2020 02:00:00 GMT+0200 (South Africa Standard Time)
Does the xMin/Max values work off the tick values or off the (data) labels? Could this be causing the issue?
@kurkle ok, I will create an example for this.

ah, the min/max for time scale work most reliably if specified as epoch, I do not remember if 2.9.3 parses the values using same method that it uses for data. That would be the 2nd option, use same format as in data.

ah ok, i have formatted the labels and ticks to use the same format. it's working now.
@kurkle tx for the help.


Bug record/replay may hang in SMP

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

pretty sure tests exist for record replay, but they are either not being run, or are not exercising a lot of code in ck.C
try some experiments with that in the context of coverage analysis to find out what needs to be done to improve measured coverage.

Record replay can be shown to hang on current master on netlrts-linux-x86_64-smp using simplearrayhello.
./charmrun ./hello 20 +p8 ++ppn 8 +record
.
.
.
./charmrun ./hello 20 +p8 ++ppn 8 +replay
Charmrun> scalable start enabled.
Charmrun> started all node programs in 1.378 seconds.
Charm++> Running in SMP mode: 1 processes, 8 worker threads (PEs) + 1 comm threads per process, 8 PEs total
Charm++> The comm. thread both sends and receives messages
Converse/Charm++ Commit ID: v6.9.0-383-g97572b27c
Warning> Randomization of virtual memory (ASLR) is turned on in the kernel, thread migration may not work! Run 'echo 0 > /proc/sys/kernel/randomize_va_space' as root to disable it, or try running with '+isomalloc_sync'.
Charm++> scheduler running in netpoll mode.
CharmLB> Load balancer assumes all CPUs are same.
Charm++> replay mode.
Charm++> Warning: disabling message integrity detection during replay (requires linking with -memory charmdebug)
Charm++> Running on 1 hosts (1 sockets x 6 cores x 2 PUs = 12-way SMP)
Charm++> cpu topology info is gathered in 0.000 seconds.
Running Hello on 8 processors for 20 elements
[0] Hello 0 created
[0] Hello 1 created
[0] Hello 2 created
[3] Hello 9 created
[6] Hello 16 created
[2] Hello 6 created
[5] Hello 14 created
[1] Hello 3 created
[5] Hello 15 created
[1] Hello 4 created
[6] Hello 17 created
[1] Hello 5 created
[4] Hello 12 created
[2] Hello 7 created
[7] Hello 18 created
[4] Hello 13 created
[7] Hello 19 created
[2] Hello 8 created
[3] Hello 10 created
[3] Hello 11 created
[0] Hi[17] from element 0
[0] CkMessageReplay> Message EP changed during replay org: [0 112 58 136] got: [0 80 58 59]
[0] CkMessageReplay> Message EP changed during replay org: [0 112 58 136] got: [0 80 58 59]

Unable to reproduce that bug on non-smp.  Appears to be a race condition of some sort as I have not found it on 4 PEs, but it is easily produced on 8.

I can reproduce this on the first try with this one-liner:
./build charm++ netlrts-linux-x86_64-smp --enable-replay -j12 -g3 && pushd netlrts-linux-x86_64-smp/tests/charm++/simplearrayhello/ && make -j12 OPTS="-g3" && while true; do ( rm -f *.log* && ./hello 20 ++ppn 8 +record && ./hello 20 ++ppn 8 +replay || break ); done
Unfortunately when I add TSan I can no longer reproduce it.
./build charm++ netlrts-linux-x86_64-smp --suffix=tsan --enable-replay -j12 -g3 -fsanitize=thread && pushd netlrts-linux-x86_64-smp-tsan/tests/charm++/simplearrayhello/ && make -j12 OPTS="-g3 -fsanitize=thread" && export TSAN_OPTIONS='log_path=tsan.log' && while true; do ( rm -f *.log* && ./hello 20 ++ppn 8 +record && ./hello 20 ++ppn 8 +replay || break ); done

The bug appears to originate in the record phase.  That is, when it is reproducible, it is typically from a recording from which the replay always fails in roughly the same way.  When it is not reproducible, the replay never fails. This implies that the non-determinism is in the recording, where we must have some sort of cross wiring or corruption in the message trace.
When extra debugging is enabled, you can see results like:
Hi[17] from element 0
[0] ProcessMessage message: 0 112 59 21 11 ep:136
[0] Queueing message: 0 112 59 136 because we wanted 0 112 58 136
[0] requeueing delayed message: 0 112 59 ep:136
[0] ProcessMessage message: 0 80 58 5 0 ep:59
CkMessageReplay> Message EP changed during replay org: [0 112 58 136] got: [0 80 58 59]
Where that sort of throwback Queueing and/or requeueing event always presages the hang and never occurs when there is no hang.  +recplay-xor or +recplay-crc don't seem to be useful at detecting corruption in this case.  But the Message EP emission is indicative of something going off the rails.

Reproducible in multicore too: ./build charm++ multicore-linux-x86_64 --enable-replay -j12 -g3 && pushd multicore-linux-x86_64/tests/charm++/simplearrayhello/ && make -j12 OPTS="-g3" && while true; do ( rm -f *.log* && ./hello 20 ++ppn 8 +record && ./hello 20 ++ppn 8 +replay || break ); done

The problem seems to be due to event ID ordering non-determinism.  That is, it isn't strictly a record bug, nor a replay bug, in the strictest sense.  It is a violation of the assumption that the original partial ordering of events will be reproduced globally if replayed in order.  What we see in practice is that is true for non-smp mode (so far), but is not reliable for SMP.
For example: in SMP mode we see this cascade of failure:
[0] Hi[17] from element 0
[0] ProcessMessage message: 0 112 59 21 11 ep:136
[0] Queueing message: 0 112 59 136 because we wanted 0 112 58 136
[0] requeueing delayed message: 0 112 59 ep:136
[0] ProcessMessage message: 0 80 58 5 0 ep:59
[0] CkMessageReplay> Message EP changed during replay org: [0 112 58 136] got: [0 80 58 59]
Where non-smp has:
[0] Hi[17] from element 0
[0] ProcessMessage message: 0 112 59 21 11 ep:136
[0] Executing message: 0 112 59
[0] getNext: 0 112 60
[0] Hi[18] from element 1
[0] ProcessMessage message: 0 112 60 21 11 ep:136
[0] Executing message: 0 112 60
Because in the recorded track the message was event ID 58, but in the replay the message we got was event ID 59.  The problem starts with an off by one error where event id enumeration disagrees between record and replay because the event ID assignment has some non-determinism.  Actual recorded message counts are identical across SMP vs non-SMP.  However there are large holes in the recorded event ID cardinality. That is, there are many incidents where the event id is incremented, but the incremented event does not appear in any recorded trajectory.  I expect that the non-determinism is in those events, such that one or more of them occur in an order that is independent of the message processing order.  That difference then impacts the event ID count and perturbs the replay by creating a mismatch.

#2408 fixes this issue by not incrementing envelopeEventID inside of initDone->sendTriggers. As that is reached by a non-deterministically set PE, and the rest of the queue processing is inaccessible to record/replay, incrementing with the envelope there perturbs the count non-deterministically.

Fixed by #2408


Crash on Server while trying to align and disassemble

READ CONTRIBUTING MD

Can I ask why this was closed? I'm having the same issue on my server, and I'd like to know if there is or was a fix for it? Thank you!

Edited both of your messages, not trying to be rude just please try and follow the guidelines. I recommend opening a new issue and following the instructions @Wolfofthenyght

Well, since my response is now gone, I'm not even sure of what I wrote that wasn't in line with your guidelines. It's fine, I'll just wait for an update and see if it's fixed.

Pretty much the entire thing, title was fine, message needed a bit more information and proper formatting, and the crash log was posted in the post and not externally like suggested.


chore: apply capitalization guidelines - iteration 7 (#12343)

SUMMARY
Apply capitalization guidelines defined in #12343.
@junlincc
TEST PLAN
Check if modified texts are following capitalization guidelines.
ADDITIONAL INFORMATION

[x] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

please specify all your changes in this PR, include screenshot and test plan, also for all your future PRs. @michael-s-molina 🙏

please specify all your changes in this PR, include screenshot and test plan, also for all your future PRs. @michael-s-molina 🙏

Codecov Report

Merging #12453 (605320c) into master (078a8a1) will decrease coverage by 3.50%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #12453      +/-   ##
==========================================
- Coverage   66.81%   63.31%   -3.51%
==========================================
  Files        1015      486     -529
  Lines       49544    29912   -19632
  Branches     5080        0    -5080
==========================================
- Hits        33102    18938   -14164
+ Misses      16312    10974    -5338
+ Partials      130        0     -130

Flag
Coverage Δ

cypress
?

javascript
?

python
63.31% <ø> (-0.77%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

superset/sql_validators/postgres.py
50.00% <0.00%> (-50.00%)
:arrow_down:

superset/views/database/views.py
62.50% <0.00%> (-25.07%)
:arrow_down:

superset/db_engine_specs/mysql.py
79.59% <0.00%> (-12.25%)
:arrow_down:

superset/db_engine_specs/sqlite.py
65.62% <0.00%> (-9.38%)
:arrow_down:

superset/db_engine_specs/presto.py
73.37% <0.00%> (-8.66%)
:arrow_down:

superset/databases/commands/create.py
83.67% <0.00%> (-8.17%)
:arrow_down:

superset/databases/commands/update.py
85.71% <0.00%> (-8.17%)
:arrow_down:

superset/sql_validators/base.py
93.33% <0.00%> (-6.67%)
:arrow_down:

superset/db_engine_specs/base.py
79.38% <0.00%> (-6.45%)
:arrow_down:

superset/views/database/forms.py
83.33% <0.00%> (-5.56%)
:arrow_down:

... and 531 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #12453 (605320c) into master (078a8a1) will decrease coverage by 3.50%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #12453      +/-   ##
==========================================
- Coverage   66.81%   63.31%   -3.51%
==========================================
  Files        1015      486     -529
  Lines       49544    29912   -19632
  Branches     5080        0    -5080
==========================================
- Hits        33102    18938   -14164
+ Misses      16312    10974    -5338
+ Partials      130        0     -130

Flag
Coverage Δ

cypress
?

javascript
?

python
63.31% <ø> (-0.77%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

superset/sql_validators/postgres.py
50.00% <0.00%> (-50.00%)
:arrow_down:

superset/views/database/views.py
62.50% <0.00%> (-25.07%)
:arrow_down:

superset/db_engine_specs/mysql.py
79.59% <0.00%> (-12.25%)
:arrow_down:

superset/db_engine_specs/sqlite.py
65.62% <0.00%> (-9.38%)
:arrow_down:

superset/db_engine_specs/presto.py
73.37% <0.00%> (-8.66%)
:arrow_down:

superset/databases/commands/create.py
83.67% <0.00%> (-8.17%)
:arrow_down:

superset/databases/commands/update.py
85.71% <0.00%> (-8.17%)
:arrow_down:

superset/sql_validators/base.py
93.33% <0.00%> (-6.67%)
:arrow_down:

superset/db_engine_specs/base.py
79.38% <0.00%> (-6.45%)
:arrow_down:

superset/views/database/forms.py
83.33% <0.00%> (-5.56%)
:arrow_down:

... and 531 more

Continue to review full report at Codecov.

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

looks good to me - please restart - I see random error in e2e which should be gone after next run I guess

looks good to me - please restart - I see random error in e2e which should be gone after next run I guess


Restricted element cause other elements to jump beneath

In the restricted demo, when dragging a restricted element (for example the "restricted bottom" element), to the left, the next element will jump up to take its place, even if the dragged element is still visible, causing the next element to become hidden/invisible to the user.
It's not very convenient to use.

@X-Ryl669, Do you have a use case other than your observation from the demo?


Species Abilities - add modifiers tab / edit description

Could we please add a modifiers tab to the Ability Item type, as some species abilities give bonuses / setbacks to dice rolls.
For example:

Also is there any way of editing the attached ability, other than deleting, creating a new Ability item & then adding back in?

Adding an XP field would be nice so it can be purchased similar to talents if the field value is greater than 0.


Update outdated note in README.md

The note was still referencing version 0.3.0. It has now been reworded to not be specific to any version.

Yes, I've also noticed that typo and changed it in v1.1.0 branch (link here if you want to see it and contribute with some ideas 😉), but I forgot to change it in the main branch. The new text looks more version-independent, thank you 😅

Ah, didn't see that branch. Expected the latest version to be worked on in the main branch. Thanks for letting me know. If I have some ideas I will check there first 🙂


Hello. I want to know how to use RLs into unity3d-mlagent.

I have read your project,but i do not know how to use in mlagent.please teach me,thanks.

follow the docs in official released ml-agents to build your custom training environment.
type python run.py -u to invoke the default PPO algorithm to interact with Unity Editor
press Start button in Unity Editor to establish a connection for your algorithm and environment.

ok,i will have a try,thank you

do you have wechat ,can i got it,it will communicate  with you more convenient

sorry, you could contact me by e-mail<EMAIL_ADDRESS>if you need more help.

ok，thank you

why my training has this problem,I use this command-"python run.py -u -a ppo -n run_with_unity" and start unity.

@strikeman1 Sorry, I totally have no idea about your problem encountered, there is no package named "naming" that is used in this repo. Maybe you could try pip install -e .[unity] and then start your training, or you could try the code in branch dev.
BTW, if you have any questions, plz reopen this issue or create a new one so as I could get it timely.

sry,I know,thx,I have a try

and I  want to ask you other question,this project use GPU? I have GPU installed,but it remain have this question


Add link in docs to this repo

Also, how can I submit a pr to the docs? typos and stuff...

I'll add the link. I didn't open source the docs because (from v1 experience) it's more trouble than it's worth. Let me know the errors and I'll update the docs.

I mostly wanted to fix typos I've found while reading.


test list gets screwed up when multiple tests have the same name but are in different describe blocks

Is this a bug report or a feature request?
bug
Version Info

Version of Majestic: v1.6.2
Version of Jest:
Version of Node:
Operating System:

Reproduction Repo
Create a unit test with two describe blocks and each describe block place the a test with the same name.
describe('block 1', () => {
  it('test name', () => {
    expect(true).toBeTruthy();
  })
}
describe('block 2', () => (
  it('test name', () => {
    expect(false).toBeTruthy();
  })
}

What you will see is the proper display of two describe blocks, each with one test in it, but both tests will show as passing, even though the second one fails.
I assume that you are using the test name as a unique key, which can't be assumed.

If I get to the other feature request of collapsing describe blocks, I will try to fix this.

Apparently when you mention an issue in a github comment, it assumes you are saying that you are fixing the issue with the PR. That is not the case. That PR does not fix this issue. I am looking into this issue to see if I can create a PR for a fix. Hopefully I will submit one today.

I fixed the PR. It now indicates that it will fix the FR, not this bug.

This has now been fixed and unfortunately included the PR of the collapsable UI branch.

hi!,
any reason why this wasn't merged yet?

@zeevrosental if you want a version that fixes this issue, you can build my fork. It is now up to date with the latest changes from the main fork and it includes  few extra enhancements that I will do separate PRs for if this original code is accepted.

Too bad this repo does not seems to be maintained anymore. I spent two hours thinking this was an isolation issue in my codebase ! To finally figure out that the output was different between the gui and the console :(


[MRG] ENH add baseline arg to read_epochs

Can you update an existing test?

updated

closes #2315

i'm experiencing some numerical accuracy problems (~.5%) comparing epochs baselined to epochs not baselined, saved to disk, read from disk and baselined.

Can you check to see if the accuracy differences come from different sets of time points being included?

@Eric89GXL the test passes for the two epochs.times are equivalent.

Travis is not happy

travis is all red.

@teonlamont what's the status here?

@Eric89GXL there's a slight difference in the baseline correction done from the saved file and one created from raw. :/

I would expect there to be some slight difference. assert_array_equal shouldn't pass but something like assert_allclose(..., rtol=1e-5, atol=1e-20) should. Does that one fail, too?

it failed on assert_array_almost_equal. failing on the assert_allclose
AssertionError:
Not equal to tolerance rtol=1e-05, atol=1e-20

(mismatch 100.0%)
 x: array([[[ -1.872922e-12,   5.578916e-14,   1.984500e-12, ...,
           5.841922e-12,   6.806278e-12,   6.806278e-12],
        [ -1.928711e-12,  -3.857422e-12,  -2.893066e-12, ...,...
 y: array([[[ -1.872922e-12,   5.578916e-14,   1.984500e-12, ...,
           5.841922e-12,   6.806278e-12,   6.806278e-12],
        [ -1.928711e-12,  -3.857422e-12,  -2.893066e-12, ...,...

Those specific numbers look pretty close, can you look into what actually
differs? You might be baseline correcting stimulus channels or something.

you're right, I wasn't picking the channels. I think there was a difference in the stim channel. this fixes the problem. pass locally, will see what travis has to say

instead of the argument, this now closes #2342 with using a method apply_baseline.

+1 for the assert_raises
then can you clean up the diff in what's new, squash to 1 commit and let's merge.
thanks @teonlamont

Great, will merge once the CIs are happy

Thanks @teonlamont


[doc,rstmgr] Declare rstmgr at D3

Fixes #22481

CHANGE AUTHORIZED: hw/ip_templates/rstmgr/data/rstmgr.hjson.tpl

@andreaskurth I made the suggested changes. Thanks.


resholve: add usable (overridden) python27

Description of changes
Minimum-viable-change to keep resholve (and all packages using resholve's Nix API) building after #201859.
I've also added an ~unrelated commit to clean up some old resholve aliases that just happen to be ripe for removal today.
Things done

Built on platform(s)

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

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] 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

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

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

[x] Fits CONTRIBUTING.md.

BTW, cross-compilation is not working:
$ nix build .#pkgsCross.aarch64-multiplatform.mons
error: Package ‘python-2.7.18’ in /nix/store/4ns3zd77y2wpmsrraakp6237388pxpvf-source/pkgs/development/interpreters/python/cpython/2.7/default.nix:329 is marked as insecure, refusing to evaluate.

       Known issues:
        - Python 2.7 has reached its end of life after 2020-01-01. See https://www.python.org/doc/sunset-python-2/.

       You can install it anyway by allowing this package, using the
       following methods:

       a) To temporarily allow all insecure packages, you can use an environment
          variable for a single invocation of the nix tools:

            $ export NIXPKGS_ALLOW_INSECURE=1

        Note: For `nix shell`, `nix build`, `nix develop` or any other Nix 2.4+
        (Flake) command, `--impure` must be passed in order to read this
        environment variable.

       b) for `nixos-rebuild` you can add ‘python-2.7.18’ to
          `nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
          like so:

            {
              nixpkgs.config.permittedInsecurePackages = [
                "python-2.7.18"
              ];
            }

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
          ‘python-2.7.18’ to `permittedInsecurePackages` in
          ~/.config/nixpkgs/config.nix, like so:

            {
              permittedInsecurePackages = [
                "python-2.7.18"
              ];
            }
(use '--show-trace' to show detailed location information)

This is independent if my patch is applied or not. I am assuming there is something in the cross-compilation bootstrap depending on python27.

A more complete patch:
diff --git a/pkgs/development/misc/resholve/default.nix b/pkgs/development/misc/resholve/default.nix
index 771b85e177a..855e57c8592 100644
--- a/pkgs/development/misc/resholve/default.nix
+++ b/pkgs/development/misc/resholve/default.nix
@@ -1,16 +1,37 @@
-{ callPackage
-, deNeuteredPy27OnlyForResholve
+{ lib
+, pkgs
+, pkgsBuildBuild
+, pkgsBuildHost
+, pkgsBuildTarget
+, pkgsHostHost
+, pkgsTargetTarget
 , ...
 }:

 let
+  python27' = (pkgs.python27.overrideAttrs (old:
+    {
+      # Overriding `meta.knownVulnerabilities` here, see #201859 for why it exists
+      # In resholve case this will not be a security issue,
+      # since the code should always run inside nix sandbox (when enabled)
+      meta = old.meta // { knownVulnerabilities = [ ]; };
+    }
+  )).override {
+    self = python27';
+    # Need to override all targets, otherwise we break cross-compilation
+    pkgsBuildBuild = pkgsBuildBuild // { python27 = python27'; };
+    pkgsBuildHost = pkgsBuildHost // { python27 = python27'; };
+    pkgsBuildTarget = pkgsBuildTarget // { python27 = python27'; };
+    pkgsHostHost = pkgsHostHost // { python27 = python27'; };
+    pkgsTargetTarget = pkgsTargetTarget // { python27 = python27'; };
+  };
+  callPackage = lib.callPackageWith (pkgs // { python27 = python27'; });
   source = callPackage ./source.nix { };
-  deps = callPackage ./deps.nix { python27 = deNeuteredPy27OnlyForResholve; };
+  deps = callPackage ./deps.nix { };
 in
 rec {
   # resholve itself
   resholve = callPackage ./resholve.nix {
-    python27 = deNeuteredPy27OnlyForResholve;
     inherit (source) rSrc version;
     inherit (deps.oil) oildev;
     inherit resholve-utils;
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 86cde56da9c..e24d1e9130d 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -15868,10 +15868,6 @@ with pkgs;
     pythonAttr = "python2Full";
     x11Support = true;
   };
-  deNeuteredPy27OnlyForResholve = (python27.overrideAttrs(old: { meta = old.meta // { knownVulnerabilities = []; };})).override {
-    self = deNeuteredPy27OnlyForResholve;
-    pythonAttr = "deNeuteredPy27OnlyForResholve";
-  };
   python27Full = python27.override {
     self = python27Full;
     pythonAttr = "python27Full";

Working patch with cross-compilation:
diff --git a/pkgs/development/misc/resholve/default.nix b/pkgs/development/misc/resholve/default.nix
index 771b85e177a..76edf927769 100644
--- a/pkgs/development/misc/resholve/default.nix
+++ b/pkgs/development/misc/resholve/default.nix
@@ -1,16 +1,28 @@
-{ callPackage
-, deNeuteredPy27OnlyForResholve
+{ lib
+, pkgs
+, pkgsBuildHost
 , ...
 }:

 let
+  python27' = (pkgsBuildHost.python27.overrideAttrs (old:
+    {
+      # Overriding `meta.knownVulnerabilities` here, see #201859 for why it exists
+      # In resholve case this will not be a security issue,
+      # since the code should always run inside nix sandbox (when enabled)
+      meta = old.meta // { knownVulnerabilities = [ ]; };
+    }
+  )).override {
+    self = python27';
+    pkgsBuildHost = pkgsBuildHost // { python27 = python27'; };
+  };
+  callPackage = lib.callPackageWith (pkgs // { python27 = python27'; });
   source = callPackage ./source.nix { };
-  deps = callPackage ./deps.nix { python27 = deNeuteredPy27OnlyForResholve; };
+  deps = callPackage ./deps.nix { };
 in
 rec {
   # resholve itself
   resholve = callPackage ./resholve.nix {
-    python27 = deNeuteredPy27OnlyForResholve;
     inherit (source) rSrc version;
     inherit (deps.oil) oildev;
     inherit resholve-utils;
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 86cde56da9c..e24d1e9130d 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -15868,10 +15868,6 @@ with pkgs;
     pythonAttr = "python2Full";
     x11Support = true;
   };
-  deNeuteredPy27OnlyForResholve = (python27.overrideAttrs(old: { meta = old.meta // { knownVulnerabilities = []; };})).override {
-    self = deNeuteredPy27OnlyForResholve;
-    pythonAttr = "deNeuteredPy27OnlyForResholve";
-  };
   python27Full = python27.override {
     self = python27Full;
     pythonAttr = "python27Full";

@cole-h yes, sorry; meant to but was in a hurry to get it posted before leaving for dinner.

force-pushed; removed unwanted commit and square w/ 2nd patch by @thiagokokada

@thiagokokada marked ready for review

An alternative way to do this:
diff --git a/pkgs/development/misc/resholve/default.nix b/pkgs/development/misc/resholve/default.nix
index 55c0c7ad046..6b8e7199418 100644
--- a/pkgs/development/misc/resholve/default.nix
+++ b/pkgs/development/misc/resholve/default.nix
@@ -1,22 +1,19 @@
 { lib
-, pkgs
 , pkgsBuildHost
+, system
 , ...
 }:

 let
-  python27' = (pkgsBuildHost.python27.overrideAttrs (old:
-    {
-      # Overriding `meta.knownVulnerabilities` here, see #201859 for why it exists
-      # In resholve case this should not be a security issue,
-      # since the code will run inside nix sandbox (when enabled)
-      meta = old.meta // { knownVulnerabilities = [ ]; };
-    }
-  )).override {
-    self = python27';
-    pkgsBuildHost = pkgsBuildHost // { python27 = python27'; };
+  pkgs = import ../../../.. {
+    inherit system;
+    # Allow python27 with known security issues only for resholve,
+    # see issue #201859 for the reasoning
+    # In resholve case this should not be a security issue,
+    # since it will only be used during build, not runtime
+    config.permittedInsecurePackages = [ pkgsBuildHost.python27.name ];
   };
-  callPackage = lib.callPackageWith (pkgs // { python27 = python27'; });
+  callPackage = lib.callPackageWith pkgs;
   source = callPackage ./source.nix { };
   deps = callPackage ./deps.nix { };
 in

Not sure which one is better. This one does not override the package and explicitly add python27 to the permittedInsecurePackages allow list. We are re-evaluating nixpkgs though, but this shouldn't be a huge issue (some packages inside the bootstrap also does the same).

Force-push to adopt Thiago's more recent suggestion.
Realized after pushing that this approach probably makes https://github.com/NixOS/nixpkgs/pull/204023/commits/afce69f2ba553bbe548c4224ac037144dc4f63e9 not-technically-necessary, though it does better homogenize the python27 package with python3x. Want me to drop that commit?

Force-pushed to drop python27 overridability change in https://github.com/NixOS/nixpkgs/commit/afce69f2ba553bbe548c4224ac037144dc4f63e9.

What's the timeline for getting rid of this band-aid?

system is an alias, so this breaks eval without aliases enabled

system is an alias, so this breaks eval without aliases enabled

We can use stdenv.hostPlatform.system instead. Would this work?

Can someone explain the rationale behind this? In which sense would resholve not be affected by Python 2 vulnerabilities? It's also intended to be used outside of Nixpkgs and the Nix sandbox.

Can someone explain the rationale behind this? In which sense would resholve not be affected by Python 2 vulnerabilities? It's also intended to be used outside of Nixpkgs and the Nix sandbox.

The sandbox comment was a mistake, the point is not the sandbox at all. Resholve itself will never connect to internet for anything.
Also, this is only a build time dependency. It will not be included at runtime. If build time out-of-date dependencies are an issue, what about our derivations that depend on older versions of GCC? Heck, we probably depends on some older unsupported GCC for bootstrapping. Is this also an issue?

BTW, we use unsupported versions of compilers for a lots of things here in nixpkgs. I just recently discover we do the same for OpenJDK (we will use the openjdk13 to bootstrap openjdk14, same for openjdk15, and this continues until we get to a modern supported version). This was never an issue, and openjdk12 has way more known security issues then Python 2.7 ever had.
Not sure why Python 2 gets a different treatment. We are basically doing the same thing as we do with openjdk here, marking outdated versions as EOL and only allowing it for build purposes.

Not sure why Python 2 gets a different treatment. We are basically doing the same thing as we do with openjdk here, marking outdated versions as EOL and only allowing it for build purposes.

Resholve uses Python 2 at runtime.
And its readme explains how to use resholve outside of Nixpkgs. In that case, the Python 2 code could even be run on untrusted input.

I guess it would be okay to remove resholve as a top-level attribute and keep it for "bootstrapping" some command line scripts only. That's what OpenJDK does.

Looks like it broke msmtp (I'm on aarch64-darwin):
$ nix-env --install --attr nixpkgs.msmtp --dry-run
(dry run; not doing anything)
installing 'msmtp-1.8.22'
error: pyyaml-6.0 not supported for interpreter python2.7
(use '--show-trace' to show detailed location information)

Looks like it broke msmtp (I'm on aarch64-darwin):
$ nix-env --install --attr nixpkgs.msmtp --dry-run
(dry run; not doing anything)
installing 'msmtp-1.8.22'
error: pyyaml-6.0 not supported for interpreter python2.7
(use '--show-trace' to show detailed location information)

Not related to this PR.

Actual change that broke msmtp: https://github.com/NixOS/nixpkgs/pull/204405#issuecomment-1344655876.

Looks like it broke more packages, see also #205438

So nobody has an argument for this special treatment?

So nobody has an argument for this special treatment?

What do you mean? I did argue above.

So nobody has an argument for this special treatment?

What do you mean? I did argue above.

You argued for resholve as a build time dependency, but there's currently no indication that's the only way resholve is supposed to be used.

I feel like this is an anti-pattern, essentially this overrides what the user provided config to enable a certain scenario.
Python2 should really be getting phased out, not adding complexity to nixpkgs. I realize this is a personally maintained project from a contributor, but python2 well be soon 3 years EOL....
I guess I would like to see the python3 migration (or migration to another less-maintainer-and-downstream-burdensome language) be prioritized.

So nobody has an argument for this special treatment?

What do you mean? I did argue above.

You argued for resholve as a build time dependency, but there's currently no indication that's the only way resholve is supposed to be used.

IMO resholve.mkDerivation is the only real use of resholve, while the derivation itself is mostly used for debugging purposes. However @abathur may have more information about it.
If you feel really strong about it, we probably can remove the exposure of the derivation in all-packages.nix. This should take care of the issue.

I feel like this is an anti-pattern, essentially this overrides what the user provided config to enable a certain scenario.
Python2 should really be getting phased out, not adding complexity to nixpkgs. I realize this is a personally maintained project from a contributor, but python2 well be soon 3 years EOL....
I guess I would like to see the python3 migration (or migration to another less-maintainer-and-downstream-burdensome language) be prioritized.

I think it is fair to have this as a migration path, and give time to the maintainer to move it to Python 3. It is not a trivial task considering that oilshell (the project that resholve uses as a parser) is written in Python 2 with no plans to migrate to Python 3.

I think it is fair to have this as a migration path, and give time to the maintainer to move it to Python 3.

It's been three years.

I think it is fair to have this as a migration path, and give time to the maintainer to move it to Python 3.

It's been almost three years.

I talked with @abathur in private. oildev used to be much more unstable before, so trying to create a Python 3 API wrapping oildev own's Python 2 implementation would be very fragile.
Nowadays this looks much more promising thanks to the stabilization of the code and the amount of tests that increased in the recent years.
Still this is a lot of work, so we should give time to the maintainer to do it's job.


Background data fetch

[x] Ensure app is fetching new data in the background if desired
[x] Make sure to respect Wifi / cellular data preferences during background fetch
[x] Disable background sync when using "complex password" or when Tor is enabled

Implemented in cf2dd4d245a337375d204974dfb8f3c274e6ff2e & 5dc93bae6aadaa3b3d3bc7bd96cc7d9118f2eba7


versioned docs

With the 2.0 alpha --> beta --> stable journey going to take several months, we should have separate docs for 2.x and 1.x.
This should also be the right opportunity to get versioned docs in place.

@Gouthamve and I just hopped on a call and discussed a rough outline of things to do:

Move documentation

Best spot is likely each repository (prometheus docs move to prometheus/prometheus, alertmanager to prometheus/alertmanager, etc.). Has the nice side effect that people can read the docs locally, but will increase the amount of PRs and issues.
Use release branches like release-1.7 release-2.0 for versioned docs
Identify which parts are gonna stay in prometheus/docs (like glossary, faq, etc.) and which are specific docs for each project

Implementation

Maintain a list of all repos and branches we want to create docs for in prometheus/docs
check them out before compiling pages (probably with make, look into git sparse checkout to reduce amount of files to copy)
Write a nanoc filter/helper to change all links to have the right prefix
add dropdown or something to select the base version

Open/next questions

how to handle redirects

GH only supports html <meta> redirects, maybe enough if google supports it
other option is to host the page on digital ocean (because of cloud flare not a huge issue??)

nanoc 4 upgrade should come eventually, but is orthogonal
other optimizations to speed up the build process

Would the plan be to keep everything serving off prometheus.io?
There's something to be said for having the header and css on everything, rather than the standard github interfance.

Oh yes, totally, sorry if that was unclear. Everything will still be on prometheus.io, we just move the documentation in each repo and clone them during the docs build process. The directory structure right before calling nanoc build would be something like
content/
  docs/
    prometheus/
      1.7/ # cloned from prometheus/prometheus branch: release-1.7 directory: docs/
      2.0/ # cloned from prometheus/prometheus branch: release-2.0 directory: docs/
      2.1/ # cloned from prometheus/prometheus branch: release-2.1 directory: docs/
    alertmanager/
      0.8/ # cloned from prometheus/alertmanager branch: release-0.8 directory: docs/
      0.9/ # cloned from prometheus/alertmanager branch: release-0.9 directory: docs/

During the nanoc build process, we'll need to update the links with a nanoc/ruby filter.

That all sounds good to me.
As most repos don't use branches for releases, we should probably work off tags instead.

This was my first idea as well, but it would mean we could never fix/edit documentation once released, so actually it should be branches and not tags.
We'll start with prometheus and alertmanager, so we can postpone this discussion for now as both use release branches. From a prometheus/docs implementation, it doesn't matter whether the identifier is a git sha1, tag or branch name anyway, so it's something we can change on a per project basis.

See #851


corrections to formal spec

corrections, with notes at
https://github.com/input-output-hk/cardano-ledger-specs/pull/1330

@jmchapman @nfrisby let me know if there is anything missing/confusing/incorrect


tests/posix/common/ failing to build for riscv

Describe the bug
tests/posix/common/ failing to build for m2gl025_miv
To Reproduce
Steps to reproduce the behavior:

twister -p m2gl025_miv -T tests/posix/common -s portability.posix.common.static_stack
See error

Expected behavior
No build errors
Impact
main CI failing
Logs and console output
https://github.com/zephyrproject-rtos/zephyr/actions/runs/9510842407/job/26216040417#step:11:1441
Environment (please complete the following information):

OS: Ubuntu 22.04
Toolchain (e.g Zephyr SDK, ...): 0.16.8
Commit SHA or Version used: main after b98a60773b3f2a592b9a1dea4899ec26ca2ab4fb

Additional context
Introduced by https://github.com/zephyrproject-rtos/zephyr/actions/runs/9510842407/job/26216040417#step:11:1441

CC @fkokosinski @kgugala @tgorochowik
@mgielda @katsuster @edersondisouza @carlocaione @npitre

Fix is in #74282


Update max mage stats with void staff

Closes #4577
Swaps the max mage stats to 509 which is achieved with the void staff rather than the virtus wand.

Spellbound ring (I) is +13 over seers I, abyssal tome is +10 over virtus book, so max should be 532


feat: add controller interface and protocol wrappers

Signed-off-by: Tomisin Jenrola<EMAIL_ADDRESS>Title:
Created a controller interface and wrapper implementations.
Description:
There are restrictions on code that can be bound by gomobile. Hence, this change shows how we can create wrappers around each protocol's exported methods in Aries. A method from the Introduce protocol is included. The signatures of these wrapped methods are successfully parsed by gomobile. This can be tested by cloning this branch and running make bindings within the /cmd/aries-agent-mobile.
Closes #1923
Closes #1941
Part of #1958
Summary:

Relevant packages:

/cmd/aries-agent-mobile/api will contain interfaces that define agent operations.
/cmd/aries-agent-mobile/wrappers/command contains the implementation using the internal Aries framework.
/cmd/aries-agent-mobile/wrappers/rest contains the implementation that makes http requests to an external server.

Relevant Structs:

Aries: wrapped version of the actual Aries framework and a map of handler functions
AriesREST: contains a map of endpoints to delegate requests to
Introduce: wrapped introduce command
IntroduceREST: http client that is modelled after the introduce operation in /pkg/controller/rest/introduce

@ToJen

This can be tested by cloning this branch and running make bindings within the /cmd/aries-agent-mobile.

llorllale:~/dev/hyperledger/aries-framework-go/cmd/aries-agent-mobile$ make bindings
----------------------------------------
   gomobile: Creating Android bindings
----------------------------------------
gomobile bind -v -target=android -javapkg=com.hyperledger.aries -o=/home/llorllale/dev/hyperledger/aries-framework-go/cmd/aries-agent-mobile/build/android/aries-agent.aar github.com/hyperledger/aries-framework-go/cmd/aries-agent-mobile/ github.com/hyperledger/aries-framework-go/cmd/aries-agent-mobile/pkg/api github.com/hyperledger/aries-framework-go/cmd/aries-agent-mobile/pkg/wrappers github.com/hyperledger/aries-framework-go/cmd/aries-agent-mobile/pkg/wrappers/command github.com/hyperledger/aries-framework-go/cmd/aries-agent-mobile/pkg/wrappers/rest
gomobile: no Android NDK found in $ANDROID_HOME/ndk-bundle nor in $ANDROID_NDK_HOME
Makefile:72: recipe for target 'bindings-android' failed
make: *** [bindings-android] Error 1

Can the README be updated to describe how/where exactly to install the dependencies?

What we want to know are the following:

should there be only one library containing implementations for the local and remote agent?
how much latency would be experienced on a mobile app if the remote agent is written in go?

@llorllale
here's the update for the discussion. What I did was to test a simple GET request by

calling goFunction1 which is written in go and receives a URL and N, the number of times to call that URL
calling goFunction2 which is written in go and receives just a URL, i called this N times from objective-c
calling iOSFunction which is written in objective-c and takes a url and calls it N times

how much latency would be experienced on a mobile app if the remote agent is written in go?

N=10
res: [goFunction1] url:http://www.google.com N:10 seconds:4.579783
res: [goFunction2] url:http://www.google.com N:10 seconds:4.766893
res: [iOSFunction] url:http://www.google.com N:10 seconds:4.703360

N=50
res: [goFunction1] url:http://www.google.com N:50 seconds:25.057063
res: [goFunction2] url:http://www.google.com N:50 seconds:24.392210
res: [iOSFunction] url:http://www.google.com N:50 seconds:23.741404

There's barely any noticeable difference

should there be only one library containing implementations for the local and remote agent?

Based on the results, we should write the api, local agent and remote agent in golang and produce a single .framework file

I got make bindings-android to work on Ubuntu 18.04. Cannot confirm with bindings-ios.
I noted that make bindings-android takes a LONG time:
$ time make bindings-android
... lots and lots of stuff...
real    0m59.528s
user    2m49.010s
sys     0m20.962s

I also noted the "Command line tools" - you really do need to download the IDE package.


gulp can't find gulp-notice in ZSH

This tracker is for bug reports only.
Before opening an issue, please make sure you've checked the following:

For support requests, please use Stack Overflow (stackoverflow.com) or Gitter (see the README).

If the bug is in a plugin, open an issue on the plugin repository, not the gulp repository.

If you're getting a deprecated module warning, don't worry about it: we're aware of it and it's not an issue. To make it go away, update to Gulp 4.0.

If you're asking about the status of Gulp 4, please don't! You can see the remaining issues on the gulp4 label: https://github.com/gulpjs/gulp/issues?q=is%3Aissue+is%3Aopen+label%3Agulp4

What were you expecting to happen?
Gulp to run under ZSH
What actually happened?
gulp fails with "zsh: command not found: gulp-notice". this would indicate a problem with ZSH, it's not, it's GULP
Please post a sample of your gulpfile (preferably reduced to just the bit that's not working)
It's not the gulpfile, it's gulp itself, I don't use gulp-notice
gulp.task(function () {});

What version of gulp are you using?
gulp 4.0.0
What versions of npm and node are you using?
npm: 6.9.0 // node: 10.16.0

gulp does not use gulp-notice internally and does not install it. That is potentially an issue with a zsh plugin, or user configuration


workaround for 5.15.1 regression

@JamesMBallard please review/merge
The issue is that whenever showCallout is called, precalculateWidthAndHeight is called. precalculateWidthAndHeight gets the grid layout's width and figures out how big the frame should be (depending on the content, accessory button, icon, etc). However, for some reason, the timing order has changed at 5.15.1, and the grid layout's width isn't updated until after precalculateWidthAndHeight executes, which means that the first time precalculate runs, it is calculating based on the wrong dimensions. This causes the frame to display incorrectly, usually too small. The previous fix fixed the sample because it just set the initial width as something large enough that it happened to display as desired. However, the test app tests many different scenarios, getting way larger and way smaller, modifying leader width, etc. This turned up more issues, and the previous fix was not viable. This new workaround just calls precalculate once the width changes, which ensures it is recalculated again if the width changes after we expected it to.
This fix fixes the sample and the tests cases in the test app. There is no noticeable performance difference.
FYI - Previously, I attempted to decouple this from our API and test app to send to Qt, but couldn't get it to reproduce outside of the environment.

Do we need to let the release team know about this change? Will this change any test screenshots?

Do we need to let the release team know about this change? Will this change any test screenshots?

@JamesMBallard it's possible it won't be an exact pixel match to what it was updated to with the last change, so yes, good to let them know.

@JamesMBallard it's possible it won't be an exact pixel match to what it was updated to with the last change, so yes, good to let them know.


Bad handling of path parameters in a Linux environment

Under Msbuild.groovy we have the code
        ['OutDir', 'OutputPath', 'BaseIntermediateOutputPath', 'IntermediateOutputPath', 'PublishDir'].each {
            if (cmdParameters[it] && !cmdParameters[it].endsWith('\\')) {
                cmdParameters[it] += '\\'
            }
        }

which doesn't look right on a Unix environment.
I have a case similar to the documented help:

// overrides project OutputPath
destinationDir = 'build/msbuild/bin'
// overrides project IntermediaryOutputPath
intermediateDir = 'build/msbuild/obj'

These paths will be modified to contain a '' in the end, causing the output to be copied to the wrong directory with the wrong name, e.g. (file 'bin\some_lib.dll' will be placed under build/ instead of build/bin/some_lib.dll)

I have this problem as well. What is the intention behind adding \\ to the output paths?

as far as I remember this was required because msbuild tasks on windows didn't append the separator automatically.
One would have to check if mono msbuild also requires this, and either add the proper sep for mono, or not add it at all.
Any idea which case it is ?


Make delete of raw coding data optional by property delete_col_raw_coding

Proposal to make deletion of raw "coding" after extraction of main values to "codingcodes" optional (default set to true so it should not break/bloat existing usage) to be able to analyze codes from FHIR extensions in FHIR datatype coding, too.

Thanks, @Mandalka . Please add your details to the list of contributors in README, if you like.


All stacks might not be deleting when running ./bin/delete-all.sh

No longer relevant: https://github.com/stelligent/dromedary/issues/32


Failed to setup kind cluster for ipv4-only

Describe the version
version about:
spiderpool: 0.0.10
Describe the bug
Failed to setup kind cluster for ipv4-only
Copy-paste the output the test failure.
 Child_process exited with error code 2

::set-output name=exit_error::Final attempt failed. Child_process exited with error code 2

Upload the zip file generated from that test failure.
None

Copy-paste the link of the CI build where that test failure has happen.
https://github.com/spidernet-io/spiderpool/runs/7982298023?check_suite_focus=true
Include any output from logs that you think may be relevant (to ease GitHub searches).

failed calling webhook "spiderippool.spiderpool.spidernet.io":

add init pod for default ippool
https://github.com/spidernet-io/spiderpool/pull/671
@Icarus9913  please add spiderpool-init code
and remove charts/spiderpool/templates/cluster-default-ippool.yam

# go run ./main.go
{"level":"INFO","ts":"2022-09-03T14:41:49.875+0800","caller":"cmd/config.go:44","msg":"PoolV4Name=testv4 "}
{"level":"INFO","ts":"2022-09-03T14:41:49.875+0800","caller":"cmd/config.go:47","msg":"PoolV4Subnet=<IP_ADDRESS>/16 "}
{"level":"INFO","ts":"2022-09-03T14:41:49.875+0800","caller":"cmd/config.go:55","msg":"PoolV4Gateway=<IP_ADDRESS> "}
{"level":"INFO","ts":"2022-09-03T14:41:49.875+0800","caller":"cmd/config.go:63","msg":"PoolV4IPRanges=[<IP_ADDRESS>-<IP_ADDRESS>] "}
{"level":"INFO","ts":"2022-09-03T14:41:49.875+0800","caller":"cmd/config.go:73","msg":" converted PoolV4IPRanges=[<IP_ADDRESS>-<IP_ADDRESS>] "}
{"level":"INFO","ts":"2022-09-03T14:41:49.875+0800","caller":"cmd/config.go:78","msg":"PoolV6Name=testv6 "}
{"level":"INFO","ts":"2022-09-03T14:41:49.875+0800","caller":"cmd/config.go:81","msg":"PoolV6Subnet=fc00::/64 "}
{"level":"INFO","ts":"2022-09-03T14:41:49.875+0800","caller":"cmd/config.go:89","msg":"PoolV6Gateway=fc00::1 "}
{"level":"INFO","ts":"2022-09-03T14:41:49.875+0800","caller":"cmd/config.go:97","msg":"PoolV6IPRanges=[fc00::100-fc00::200] "}
{"level":"INFO","ts":"2022-09-03T14:41:49.876+0800","caller":"cmd/config.go:107","msg":" converted PoolV6IPRanges=[fc00::100-fc00::200] "}
{"level":"INFO","ts":"2022-09-03T14:41:50.135+0800","caller":"cmd/k8s.go:81","msg":"endpoints: &Endpoints{ObjectMeta:{spiderpool-controller  kube-system  1076dae2-4cd3-4724-9e00-6804cef5ad5d 277286 0 2022-09-01 17:54:31 +0800 CST <nil> <nil> map[app.kubernetes.io/component:spiderpool-controller app.kubernetes.io/instance:spiderpool app.kubernetes.io/managed-by:Helm app.kubernetes.io/name:spiderpool app.kubernetes.io/version:v0.1.1 helm.sh/chart:spiderpool-v0.1.1] map[endpoints.kubernetes.io/last-change-trigger-time:2022-09-03T04:28:47Z] [] []  [{kube-controller-manager Update v1 2022-09-03 12:28:37 +0800 CST FieldsV1 {\"f:metadata\":{\"f:annotations\":{\".\":{},\"f:endpoints.kubernetes.io/last-change-trigger-time\":{}},\"f:labels\":{\".\":{},\"f:app.kubernetes.io/component\":{},\"f:app.kubernetes.io/instance\":{},\"f:app.kubernetes.io/managed-by\":{},\"f:app.kubernetes.io/name\":{},\"f:app.kubernetes.io/version\":{},\"f:helm.sh/chart\":{}}},\"f:subsets\":{}} }]},Subsets:[]EndpointSubset{EndpointSubset{Addresses:[]EndpointAddress{EndpointAddress{IP:<IP_ADDRESS>,TargetRef:&ObjectReference{Kind:Pod,Namespace:kube-system,Name:spiderpool-controller-6b595bfdfd-pttbb,UID:c10a9302-e39e-4356-a963-17c0f44a64cd,APIVersion:,ResourceVersion:,FieldPath:,},Hostname:,NodeName:*spider-worker,},EndpointAddress{IP:<IP_ADDRESS>,TargetRef:&ObjectReference{Kind:Pod,Namespace:kube-system,Name:spiderpool-controller-6b595bfdfd-qx65k,UID:0fa641ce-7abc-4940-81ac-abd464126cc0,APIVersion:,ResourceVersion:,FieldPath:,},Hostname:,NodeName:*spider-control-plane,},},NotReadyAddresses:[]EndpointAddress{},Ports:[]EndpointPort{EndpointPort{Name:http,Port:5720,Protocol:TCP,AppProtocol:nil,},EndpointPort{Name:webhook,Port:5722,Protocol:TCP,AppProtocol:nil,},},},},} "}
{"level":"INFO","ts":"2022-09-03T14:41:50.135+0800","caller":"cmd/root.go:36","msg":"spider controller is ready"}
{"level":"INFO","ts":"2022-09-03T14:41:50.135+0800","caller":"cmd/root.go:90","msg":"Ipv4 ippool will be created "}
{"level":"INFO","ts":"2022-09-03T14:41:50.135+0800","caller":"cmd/root.go:102","msg":"try to create ippool: &{TypeMeta:{Kind: APIVersion:} ObjectMeta:{Name:testv4 GenerateName: Namespace: SelfLink: UID: ResourceVersion: Generation:0 CreationTimestamp:0001-01-01 00:00:00 +0000 UTC DeletionTimestamp:<nil> DeletionGracePeriodSeconds:<nil> Labels:map[] Annotations:map[] OwnerReferences:[] Finalizers:[] ZZZ_DeprecatedClusterName: ManagedFields:[]} Spec:{IPVersion:<nil> Subnet:<IP_ADDRESS>/16 IPs:[<IP_ADDRESS>-<IP_ADDRESS>] Disable:<nil> ExcludeIPs:[] Gateway:0x20cd258 Vlan:<nil> Routes:[] PodAffinity:nil NamesapceAffinity:nil NodeAffinity:nil} Status:{AllocatedIPs:map[] TotalIPCount:<nil> AllocatedIPCount:<nil>}} "}
{"level":"INFO","ts":"2022-09-03T14:41:50.194+0800","caller":"cmd/root.go:63","msg":"succeeded to crate ippool testv4 "}
{"level":"INFO","ts":"2022-09-03T14:41:50.194+0800","caller":"cmd/root.go:112","msg":"Ipv6 ippool will be created "}
{"level":"INFO","ts":"2022-09-03T14:41:50.194+0800","caller":"cmd/root.go:124","msg":"try to create ippool: &{TypeMeta:{Kind: APIVersion:} ObjectMeta:{Name:testv6 GenerateName: Namespace: SelfLink: UID: ResourceVersion: Generation:0 CreationTimestamp:0001-01-01 00:00:00 +0000 UTC DeletionTimestamp:<nil> DeletionGracePeriodSeconds:<nil> Labels:map[] Annotations:map[] OwnerReferences:[] Finalizers:[] ZZZ_DeprecatedClusterName: ManagedFields:[]} Spec:{IPVersion:<nil> Subnet:fc00::/64 IPs:[fc00::100-fc00::200] Disable:<nil> ExcludeIPs:[] Gateway:0x20cd2a0 Vlan:<nil> Routes:[] PodAffinity:nil NamesapceAffinity:nil NodeAffinity:nil} Status:{AllocatedIPs:map[] TotalIPCount:<nil> AllocatedIPCount:<nil>}} "}
{"level":"INFO","ts":"2022-09-03T14:41:50.274+0800","caller":"cmd/root.go:63","msg":"succeeded to crate ippool testv6 "}
{"level":"INFO","ts":"2022-09-03T14:41:50.274+0800","caller":"cmd/root.go:132","msg":"finish initialization"}

fix @https://github.com/spidernet-io/spiderpool/pull/678