docker run -e VAR='$APT_PORT_3142_TCP_ADDR` not expanded

I want to set my apt-cacher proxy automatically to a --linked container
docker run -rm -t -i -e 'http_proxy=http://$APT_PORT_3142_TCP_ADDR:${APT_PORT_3142_TCP_PORT}/' --link apt-cacher-run:apt debian bash

but at this point, everything is escaped.
is there an internal docker --link way to crack this egg?

@SvenDowideit i take it this is still an issue?

PR #12344 should solve this one

(sorry for the long comment and showing you the 'interesting' progress of this)
I actually do have a fix for this but I don't think we can merge the code changes - but I'd like to hear what others think.
Most of this is pretty much along the lines of what @tianon mentioned earlier.
When we get the env vars from a docker run command we stick them into the container and then later on we add the "link" env vars right before we actually start the container.  Changing the order in which this happens isn't too bad, and in fact, that's what I did.  And it works just fine after I then also do the $... substitutions.
However, there's a problem. From my testing, it appears that the -e vars are saved within any image that is created from that container, while the "link" env vars are not.  Not saving the "link" ones makes sense.  But my code changes will also not save the docker run -e vars too because they may need to have the "link" env vars values to work properly.  And this would be a breaking change, which is why I don't think we can accept this code change.
One variant of my code did a little bit of both. It saved the -e vars in the container (and therefore any resulting image) but didn't do the env var substitutions until right before any new container was started, and after the LINK vars were set.  Sounds promising.  It even worked when new containers from that image were run with new -e vars, they were merged appropriately.
However, there's a problem - again.  These -e vars are not really in the image, yet.  By that I mean, if someone created a Dockerfile using that image in the FROM, and then used ENV to change those previously defined -e vars it would look like it worked, but then any new container created from that new image would have those same (original) -e vars processed again and added to the new container - thus overriding anything done within the Dockerfile.  This is because the -e vars are pulled out into a new field and treated as 'special' and always processed right before a new container is started.  I did try to remove the vars from the -e list as they were mentioned in the ENV cmds, but things got really messy when I tried that due to how we merge config data - so I stopped.  The hole I as digging here started to really scare me beyond my comfort level at this point.
Anyway, the net of this is that I don't think we can support this w/o potentially breaking something or making some changes that will probably feel like hacks.
But, what do other people think?  @erikh @tiborvass

@duglin wauh! That's really nice that you tried so hard! I think you analyzed perfectly the situation.
However, I think @SvenDowideit's issue can be easily solved by:
Dockerfile:
FROM ubuntu:14.04
# ...
ENTRYPOINT ["/wrapper.sh"]

wrapper.sh:
#!/bin/sh
export http_proxy=http://$APT_PORT_3142_TCP_ADDR:${APT_PORT_3142_TCP_PORT}/
exec "$@"

I feel like the usecase is very narrow and can be circumvented like explained above, so I'd vote for closing this issue.

@tiborvass yep - I think that would probably do it for him.  I was just hoping to provide a native solution but given the way things are currently design I don't think its possible.

ok thanks for looking into it though @duglin ! I'm gonna close this to make us feel somewhat better about our open issues # :)


Failed to run upgrade safety validation

I am using openzeppelin-foundry-upgrades, openzeppelin contracts v5 and using the following code snippet in my setUp() function in foundry test.
 proxy = Upgrades.deployTransparentProxy(
      'Token.sol',
      tokenOwner,
      abi.encodeCall(Token.initialize, tokenOwner)
 );

foundry.toml
[profile.default]
src = "src"
out = "out"
libs = ["lib"]
ffi = true
ast = true
build_info = true
extra_output = ["storageLayout"]

OS: macOS Sonoma
I get the following error when running forge test. Compilation works, tests fail.

This looks like an installation issue with the npm package @openzeppelin/upgrades-core or its dependency solidity-ast.
You can try manually installing that package for your project by running the following command from your project root:
npm install @openzeppelin/upgrades-core@latest

Closing this as it looks like an installation issue. Feel free to reopen if you are still encountering the problem.

forge update worked for me and resolved this issue


Outline icon dynamically changes color

I found that in dark themes, the outline icon is still black making it look bad, i made a quick fix for this by changing the fill and stroke color of the svg to color-base-100.
Before-

After-

Hmm, this should already be a feature. It's a bug if it doesn't work. I have it set to equal the same color as header 6. (AKA the same color at the "Table of Contents" text. Could you send me the .html file so I can look over it?

Ah yeah you just changed it, is --h6-color not a global obsidian css variable? This probably has something to do with your theme rather than the plugin

I verified that it is in fact a css variable that is built-in to obsidian. So you should really fix this by adding a snippet that sets the --h6-color variable since this is a problem with your theme, not with the plugin.

I'm using the default theme, and for whatever reason --h6-color does not change with the theme. In fact, disabling the color property on headers (which is set to --h#-color) doesn't even change their color. I can't even find what those colors are set to other than inherit.
The actual property that controls header color is attached to the body element, which is color: var(--text-normal), which is in turn linked to var(--color-base-100).

Thanks for the info @zambony!
I'll go ahead and merge this since it's a small and easily reversible change. I'll look into it more when I am less busy. I also probably won't make a new release until I've looked into it more. Thank you for putting your time into this! It's very appreciated. @xXTgamerXx

You're welcome :).
Also, the --h6-color is set to inherit, and on the main document it inherits the color from some other variable from parent elements (the headings have colors), but for this icon there's no parent element that uses it, I'm guessing this is why it doesn't inherit the color but I'm not entirely sure if this is the reason for it.


fixed issue  https://github.com/TryGhost/Ghost-SDK/issues/150#issue-4…

Got some code for us? Awesome 🎊!
Please include a description of your change & check your PR against this list, thanks!
when a url with a trailing slash is passed to the admin api, it shows an error, to make it easy for user to debug it, displaying the url that was passed would be handful..
i added the url that was passed to the error message

[ ] There's a clear use-case for this code change
[ ] Commit message has a short title & references relevant issues
[ ] The build will pass (run yarn test and yarn lint)

More info can be found by clicking the "guidelines for contributing" link above.

Closing as the underlying issue has been resolved with a larger overhaul of error messages in 9d44031f9aa6383cde204ae13c4c2ca74edc8178


[Component request] Dialog

Some component of dialog will be made available ?

Issue #781

it's the dialog compoment is  compatible with firefox ?

@JdidouBrahim for support questions please use stackoverflow

@hebbet  Thank you  :)


Clear any other selection when you use the shortcut Ctrl+L to select the current line only without adding the currently already selected line.

Hi,
Thanks for this lovely editor.

Currently, when you want to select the current line ( i.e. line No.1) where your keyboard cursor is located, you press the shortcut Ctrl+L.
After you press the shortcut Ctrl+L, the keyboard cursor jumps to the next line automatically ( i.e. line No.2), and ( i.e. line No.1) currently selected.
Now, if I want to select ( i.e. line No.2) only when I press the keyboard shortcut Ctrl+L, it includes ( i.e. line No.1) also into the current selection.
So, sometimes I need to use the current settings, and other times I only need to select ( i.e. line No.2).
Is it possible to add an adjustment to the selected current line feature and add a new feature to enable selecting the current line only or select the current line with previously selected line(s)?
Thanks

This makes sense as Ctrl+L is running the command Expand Line Selection.  So since you already have a selection vscode is expanding that.  You could try just Esc and then Ctrl+C to select that current line.

By the way, you could achieve what you want with a macro extension like Multi-Command
{
  "key": "ctrl+l",
  "command": "expandLineSelection",
  "when": "!editorHasSelection"
},

// if there is a selection, cancel it first
{
  "key": "ctrl+l",      // whatever keybinding you want
  "command": "extension.multiCommand.execute",
  "args": {
    "sequence": [
      "cancelSelection",
      "editor.action.clipboardCopyAction"
      // "expandLineSelection",  // or this instead of above
    ]
  },
  "when": "editorHasSelection"
}

I've got an idea, and it may be good if you like it.
Press CTRL + L twice to clear other(s) already selected lines, or parts of code, and select the current line only.
So, if we imagine the scenario from the beginning, as follows:

Press CTRL + L once to select the current line, and the keyboard cursor jumped to the beginning of the next line, and the current line is already being selected.
Now, I want to select the new line only, so I press CTRL + L twice.
This way, I am still using the CTRL + L so the user does not need to remember any extra new shortcut related to line selection, and I've achieved the result.

@alexdima
Hi, any idea when this could be implemented?

@alexdima Hi, any idea when this could be implemented?

Any updates?
Any one may tell me how may I add this features myself to vscode?
Thanks


Direct Method in module bug - preview11

I have taken the fresh Preview11 for a spin with python 3.5.3. There is no sample code to demonstrate a module client running in an edge environment that can receive a direct method call, so here is my test-code:
from datetime import datetime
from multiprocessing.connection import Client

import os, uuid, sys, asyncio, threading
from azure.iot.device.aio import IoTHubDeviceClient, IoTHubModuleClient
from azure.iot.device import Message, MethodResponse

import os, getpass

import imutils
import json
import socket
import time
import sys

import logging
logging.basicConfig(format='%(levelname)s:%(message)s', level=logging.DEBUG)

async def snapmain():
    logging.debug("Setup message receiver starting")

    module_client = IoTHubModuleClient.create_from_edge_environment()

    # connect the client.
    await module_client.connect()

    # define behavior for receiving an input message on input7
    async def input1_listener(module_client):
        while True:
            input_message = await module_client.receive_message_on_input("input7")  # blocking call
            logging.debug("the data in the message received on input7 was ")
            logging.debug(input_message.data)
            logging.debug("custom properties are")
            logging.debug(input_message.custom_properties)

    # Schedule tasks for Method Listener
    listeners = asyncio.gather(
        input1_listener(module_client)
    )

def main():
    try:
        # Basic configuration: configure the root logger, including 'azure.storage'
        logging.basicConfig(format='%(asctime)s %(name)-20s %(levelname)-5s %(message)s', level=logging.DEBUG)

        # If using Python 3.6 or below, use the following code instead of asyncio.run(snapmain()):
        loop = asyncio.get_event_loop()
        loop.create_task(snapmain())
        loop.run_forever()

    except KeyboardInterrupt:
        pass

if __name__ == "__main__":
    main()

The errors keeps coming like this:
azure.iot.device.common.transport_exceptions.ConnectionDroppedError: None
INFO:Connection State - Disconnected
INFO:Cleared all pending method requests due to disconnect
DEBUG:Sending CONNECT (u1, p1, wr0, wq0, wf0, c0, k60) client_id=b'Haven2/motion-detection'
DEBUG:Received CONNACK (1, 0)
INFO:connected with result code: 0
DEBUG:Starting _on_mqtt_connected in pipeline thread
INFO:_on_mqtt_connected called
DEBUG:PipelineRootStage: on_connected.  on_connected_handler=<function IoTHubPipeline.__init__.<locals>._on_connected at 0xb63f5ae0>
DEBUG:Starting _on_connected in callback thread
WARNING:Connection was unexpected
INFO:Connection State - Connected
INFO:disconnected with result code: 1
DEBUG:Starting _on_mqtt_disconnected in pipeline thread
ERROR:MQTTTransportStage: _on_mqtt_disconnect called: Out of memory.
DEBUG:PipelineRootStage: on_disconnected.  on_disconnected_handler=<function IoTHubPipeline.__init__.<locals>._on_disconnected at 0xb63f5b28>
DEBUG:Starting _on_disconnected in callback thread
WARNING:MQTTTransportStage: disconnection was unexpected
ERROR:Exception caught in background thread.  Unable to handle.
azure.iot.device.common.transport_exceptions.ProtocolClientError: Out of memory.

The above exception was the direct cause of the following exception:

azure.iot.device.common.transport_exceptions.ConnectionDroppedError: None
INFO:Connection State - Disconnected
INFO:Cleared all pending method requests due to disconnect

Thanks for the detailed log and sample. We'll start looking into this. To be clear, this is related to receiving input messages, not direct method requests, correct? I don't see any reference to .receive_method_request() in your sample.

You are right, same example used for my tests of direct methods. But very similar output... the below is for my tests of direct methods...
INFO:Cleared all pending method requests due to disconnect
DEBUG:Sending CONNECT (u1, p1, wr0, wq0, wf0, c0, k60) client_id=b'Haven2/motion-detection'
DEBUG:Received CONNACK (1, 0)
INFO:connected with result code: 0
DEBUG:Starting _on_mqtt_connected in pipeline thread
INFO:_on_mqtt_connected called
DEBUG:PipelineRootStage: on_connected.  on_connected_handler=<function IoTHubPipeline.__init__.<locals>._on_connected at 0xb6383ae0>
DEBUG:Starting _on_connected in callback thread
WARNING:Connection was unexpected
INFO:Connection State - Connected
INFO:disconnected with result code: 1
DEBUG:Starting _on_mqtt_disconnected in pipeline thread
ERROR:MQTTTransportStage: _on_mqtt_disconnect called: Out of memory.
DEBUG:PipelineRootStage: on_disconnected.  on_disconnected_handler=<function IoTHubPipeline.__init__.<locals>._on_disconnected at 0xb6383b28>
DEBUG:Starting _on_disconnected in callback thread
WARNING:MQTTTransportStage: disconnection was unexpected
ERROR:Exception caught in background thread.  Unable to handle.
azure.iot.device.common.transport_exceptions.ProtocolClientError: Out of memory.

The above exception was the direct cause of the following exception:

azure.iot.device.common.transport_exceptions.ConnectionDroppedError: None
INFO:Connection State - Disconnected
INFO:Cleared all pending method requests due to disconnect

Is this being adressed in the v12 preview? As I am not seeing a difference.

I am closing this issue, reverting to other methods that are less elegant but works. Was not able to find options to exposing direct methods in the newest release as of today.

@njbuch, thank you for your contribution to our open-sourced project! Please help us improve by filling out this 2-minute customer satisfaction survey


Gets 404 with [FromBody] IEnumerable, but not with [FromBody] List

I am getting a 404 with the same route and same input, just different type
This results in a 404:
 [FromBody] IEnumerable<int> foo
This does not:
[FromBody] List<int> foo
Setup:
docker image:  mono:<IP_ADDRESS>
dnx version: 1.0.0-rc1-update1
running on Kestrel behind nginx 1.9.9

Suggest trying your scenario with either Mono <IP_ADDRESS> (later versions don't get along w/ MVC action selection) or .NET Core.

Actually, we recommend using .NET Core only, Mono is not a fully supported configuration.

@dougbu do we know of any issues in this area, though? Or do you expect it to work?

Or do you expect it to work?

We know of issues w.r.t. action selection in every version after 4.0.5.x. Other dragons likely exist.
I do not expect any Mono version except 4.0.5.x to work. But I'm not sure of the exact scenarios that will or won't behave correctly.

@dougbu I assume we have a test for this scenario too?

we have a test for this scenario too?

We don't normally exhaustively test the underlying serializers.
In this case, no we don't have tests of opt-level collections that I could find. I wrote a few new JsonInputFormatter unit tests and didn't get any failures. Could add those or even extend the model binding integration tests to cover top-level collections. LMK

@dougbu can you try this out on .NET Core and .NET Framework quickly just to see if anything stands out? But yeah it'd be good to add some tests for top-level collections w/ formatters - that's a fairly common scenario.

Submitted #4500. Letting Travis test new scenarios w/ Mono 4.0.5.x.

Self-assigning since I seem to be working on this :smiley_cat:

Tests added in d9141d6


[joy] Add Drawer component

Early work-in-progress for adding a Drawer component in Joy UI. The first question we need to answer is whether we want to start re-using components (or rather to say composing components) in Joy UI. The Drawer component (I am not considering here the SwipeableDrawer, PersistentDrawer etc, which will likely be different components), is basically a modal that can receive an anchor to indicate where the Drawer should appear from.
If we decide to go with this route, we will need to revisit some things, especially around the ownerState propagating, slotProps callbacks etc. If we decide to not go with this route, we will likely have a lots of duplication in the code (consider the code that lives inside the Modal component at this moment.
TODOs:

[ ] extend the docs page, add playground
[ ]  extend the test suite
[ ]  list out the next related components we'll need to implement

The reason I don't want to build a component on top of another component is to avoid the issues we have seen in Material UI. This is what I meant by build a component on top of another component:
// Modal.tsx
export default

For the case of Drawer, we want to reuse the modal logic so why not create a hook useModal (we could just add it in Joy UI internally first and let Base UI take over later). Then reuse the useModal in both Modal and Drawer.
For the styles, export the styled component from the Modal and reuses in Drawer (this approach is already been using in other Joy UI components like Autocomplete).

I can try as a first step to isolate the useModal hook. My worry is that much of the Modal logic is happening in how elements are being rendered:
    <CloseModalContext.Provider value={onClose}>
      <Portal ref={handlePortalRef} container={container} disablePortal={disablePortal}>
        {/*
         * Marking an element with the role presentation indicates to assistive technology
         * that this element should be ignored; it exists to support the web application and
         * is not meant for humans to interact with directly.
         * https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/no-static-element-interactions.md
         */}
        <SlotRoot {...rootProps}>
          {!hideBackdrop ? <SlotBackdrop {...backdropProps} /> : null}
          <FocusTrap
            disableEnforceFocus={disableEnforceFocus}
            disableAutoFocus={disableAutoFocus}
            disableRestoreFocus={disableRestoreFocus}
            isEnabled={isTopModal}
            open={open}
          >
            {React.Children.only(children) &&
              React.cloneElement(children, {
                ...(children.props.tabIndex === undefined && {
                  tabIndex: -1,
                }),
              })}
          </FocusTrap>
        </SlotRoot>
      </Portal>
    </CloseModalContext.Provider>

If we ever need to do a fix on this logic, we will need to apply it in multiple places, while if we re-use the component it would live only in one place. Let me create the useModal hook first and see what can be abstracted.

@mnajdova For the structure, I think DrawerContent can be replaced with Drawer's content slot to simplify the implementation (remove unnecessary React context). I'd expect to use the Drawer like this:
<Drawer>
  <Typography>Title</Typography>
  …
</Drawer>

to customize the content use slotProps.content.

@mnajdova For the structure, I think DrawerContent can be replaced with the Drawer's content slot to simplify the implementation (remove unnecessary React context). I'd expect to use the Drawer like this:

I was considering this as well, I mainly created this component following the ModalDialog paradigm we have, but yeah, it makes sense to have it as slot too.

Should PermanentDrawer be excluded from this PR? It would reduce the size of the PR.

Yeah, let me extract these changes in a new branch. Btw, considering we will have more *Drawer components, should I rename the default one to TemporaryDrawer or keep Drawer for simplicity, considering this is (at least in my opinion), the componentI first have in mind when I think about a Drawer component. Maybe we can loop @samuelsycamore too on the name.

I decided to keep the PermanentDrawer as part of the initial effort - the docs would be basically empty without it - I feel this is basic requirement for the Drawer component - I just decided to extract it to a new component - for e.g. in Material UI it is defined by a prop on the Drawer.

Got your point, we can include another opinion from @samuelsycamore or @zanivan about the component. To be honest, I don't think we should follow Material UI on this, I feel that a TemporaryDrawer is the definition of a Drawer, and PermanentDrawer should not exist because using Flexbox or CSS Grid is a lot better to deal with the layout.
Some benchmark:

https://chakra-ui.com/docs/components/drawer/usage
https://ant.design/components/drawer
https://ui.shadcn.com/docs/components/sheet

Let me chime in: I think the default should be Drawer, and the default behavior should be similar to TemporaryDrawer because, as @siriwatknp described, this is the definition of a drawer, and it's what's more commonly seen. SwipableDrawer could be a good prop to be added, but I believe it's not exactly a must-have feature, and we could work around it with a way of doing this in a demo, and not properly a built-in prop.
However, I'd love to have something similar to the PermanentDrawer, mostly to be used as a sideBar or sideMenu—it indeed can be achieved in many ways, but it'd be great to have a similar component that provides some behaviors like collapsing, closing, etc.
That said, I believe it's out of the scope of a Drawer itself, since the main usage is to be a side navigation, that doesn't fit exactly with the concept of a drawer.

I scoped the PR to only add the Drawer component, I can open an issue for the permanent drawer variant (we could likely call it a sidebar, it's much more used than permanent drawer), but we can discuss this on the issue. I have the implementation already, so it would be moslty about how we want to name it and document it.

However, I'd love to have something similar to the PermanentDrawer, mostly to be used as a sideBar or sideMenu—it indeed can be achieved in many ways, but it'd be great to have a similar component that provides some behaviors like collapsing, closing, etc.

I have the same thought. The permanent drawer is a sidebar most of the time, which needs to be responsive, and integrated with other parts e.g Header, Main, Footer, and as @zanivan pointed out, collapsable at some point.
We should plan ahead for the Sidebar. I believe that the Sidebar should be in the system package which uses the zero-runtime engine that @brijeshb42 is working on. This could be a great opportunity for us to create layout components that are 100% server components.

@mnajdova
In https://github.com/mui/material-ui/pull/38169/commits/5c1eebc9cc7e3802468337c3c99d5b058cad2902, I did the same for the Root and Content slot by exporting the styled-components from the Modal. The reason to use the styled-components, not the slot component is to prevent theme.styleOverrides inheritance.
In https://github.com/mui/material-ui/pull/38169/commits/8768e6cf3392a634f933073822213fc3f6cbc889, I removed the variables that are 1-to-1 to the CSS properties and define the width, height variables for each size (we can discuss if those variables make sense or not)
In https://github.com/mui/material-ui/pull/38169/commits/bd816084dad210925ada9944ca453d901daf7fbc, I think the drawer should support multiple children. Furthermore, I think the getTransitionProps should not be in useModal. The API is too specific to Transition component, may be it should be separate into another hook.
The rest are demos and examples.

In https://github.com/mui/material-ui/commit/5c1eebc9cc7e3802468337c3c99d5b058cad2902, I did the same for the Root and Content slot by exporting the styled-components from the Modal. The reason to use the styled-components, not the slot component is to prevent theme.styleOverrides inheritance.

Nice, this pattern makes sense 👍

In https://github.com/mui/material-ui/commit/8768e6cf3392a634f933073822213fc3f6cbc889, I removed the variables that are 1-to-1 to the CSS properties and define the width, height variables for each size (we can discuss if those variables make sense or not)

Yep, I was thinking whether we should go with this route - the code I had was mostly copied from the modal dialog.

In https://github.com/mui/material-ui/commit/bd816084dad210925ada9944ca453d901daf7fbc, I think the drawer should support multiple children. Furthermore, I think the getTransitionProps should not be in useModal. The API is too specific to Transition component, may be it should be separate into another hook.

Makes total sense, we will likely change the way how transitions are handled in Base UI - this is kind of a legacy approach coming from Material UI.

There are some items that might be worth mentioning/discussing:

The variants and colors are not being applied to the playground demo
When switching modes, the iframe background sometimes appears and sometimes not

Light
Dark

It's impossible to dismiss the lg modal on mobile

I'm still getting up to speed on this, and you might already be aware of these things, so sorry about that.
Just to let you know, I've started refining the demos designs. Should I wait a bit more, or keep working on them?

Sorry for the delay. Here are some answers:

The variants and colors are not being applied to the playground demo

Fixed, I must have broken this when I was removing the DrawerContent component.

When switching modes, the iframe background sometimes appears and sometimes not

I simplified this demo, no need for iframe, it complicates things when exporting to sandbox too.

It's impossible to dismiss the lg modal on mobile

It's possible by clicking on some of the items. In practise, I wouldn't expect that someone would use large drawer on a mobile?

It's impossible to dismiss the lg modal on mobile

It's possible by clicking on some of the items. In practise, I wouldn't expect that someone would use large drawer on a mobile?

I added support for this by setting the width to min(100vw - 2.5rem, drawer-width). With this, the drawer's width will never exceed the viewport's width which is commonly used.

Thanks @siriwatknp , @mnajdova and
@zanivan for your hard and meticulous work!

Great work. I have a question. When will it be available via npm?
Thanks

Great work. I have a question. When will it be available via npm?

Likely later today with the latest release :)


Extend unreachable code analyzer with TERMINATE and FETCH

Cool - you could add STOP as well. Not the most used statement, but sometimes I use it in programs to skip the remaining parts, so it’s good to get a reminder to remove it again. :-)


only forward cookies for internal fetches -

closes #6604.
I'm not sure if we also need to handle the case where www.domain.com is requesting data from domain.com, or where the external origin sets a third party cookie?
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

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

Tests

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

Changesets

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

thank you!


Update run-analyzer-macos-linux.md

Adding a note to clarify that the report.html file is generated only when using the Python-based version of the client analyzer. I looked for the file but couldn't find. When I used the Python-based version of the client analyzer, I confirmed the file was generated.

Anything additional I need to do to finish the update on this article? thanks!

Anything additional I need to do to finish the update on this article? thanks!

Thanks @EdgarPMIA! What you added looks great. I actually find the original sentence a bit confusing :).
"The main HTML output file that contains the findings and guidance that the analyzer script run on the machine can produce"
If we updated it to this - does this make sense:
"The main HTML output file that contains the findings and guidance from running the client analyzer tool on the device. This file is only generated when running the Python-based version of the client analyzer tool. "

@siosulli Hi, yes, I think is perfect 👌

Great! I will make the update and go ahead merge. Thank you!


Application hangs when right clicking text or clicking drop-downs

[x] This is not a troubleshooting question. Troubleshooting questions go here: http://www.mattermost.org/troubleshoot/.
[x] This doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
[x] I have read contributing guidelines.

Summary
The desktop application will hang if one selects text and right clicks. The context menu is always empty. Application restart required.
This desktop application was installed via the Snap package
Environment

Operating System: Ubuntu 21.10
Mattermost Desktop App version: 4.7.0
Mattermost Server version: 5.37.2

Steps to reproduce
Method 1: Select text -> Right click
Method 2: Click dropdown
Expected behavior
The application should not hang
Observed behavior
The application hangs

Possible fixes

@joseph-henry Do you see the same issue with Mattermost Desktop App version v5.0.2?

Unfortunately 5.0.2 via the snap store wont open. It installs but no window ever pops up. I've reverted back to 4.7.0 for the time being. If you push a new version to edge I can test that.

@joseph-henry Can you try with the app downloaded directly from https://github.com/mattermost/desktop/releases/tag/v5.0.2 and see if it reproduces?

Closing as inactive


Main composite selector problems

Found the following issues:
a) backspace when typing did not work
b) enter did not use typed text, had to select Create xxxxx first
c) no edit of what typed prior to hitting Build button

might need a workaround or alternative. Potentially an issue where React components in Atom do not receive key events normally. https://discuss.atom.io/t/onkeydown-react-event-does-not-fire-in-atom-package/59543


Subcommands not included in help

If an ArgParser has subcommands registered, these subcommands do not appear in the default help text. In addition, if an ArgParser only has subcommands registered, running the program with no arguments gives no output.
This is using the current version of kotlinx.cli bundled into Kotlin/Native.

Fixed in v0.2.1


Wrong uploader in "X will be encouraged by your appreciation" label

The picture being reviewed below has been uploaded by A1Cafel but the label mistakenly says GeographBot will be encouraged by your appreciation. The previous picture I reviewed was a picture uploaded by GeographBot, so it looks like a reset issue.

Hi! I am beginning to work on open-source projects. Can I give this issue a try? I am installing the project and I was looking for an issue to start working on.

Hi, @MaAnCoSa  any progress?

Hi! Sorry, I have been having trouble with my internet connection these past couple of days, but now that it is fixed, I am working on it.


Report of scannable water filtration machine

I made sure to prevent this in 2 locations, but there might be another one? This is based on component list, but they are not consistent.
Location will have to be found.

Can't do much without coordinates. Need to wait for another bug report.


bug: Unexpected input(s) 'pr_number' ?

Version
2.0.0
Current Behavior

Expected Behavior
Should no warnings.
Steps to Reproduce
Just like README.md
Additional Information
No response

@abcfy2 it appears that the README is erroneous in two places where it refers to the pr-number parameter for the action is incorrectly named pr_number in two of the YAML examples.
The correct parameter name, as in the first example, is pr-number. The README will be updated to show the corrected value:
- name: Post SARIF findings in the pull request
  if: github.event_name == 'pull_request'
  uses: sett-and-hive/sarif-to-comment-action@v1
  with:
    token: ${{ secrets.GITHUB_TOKEN }}
    repository: ${{ github.repository }}
    branch: ${{ github.head_ref }}
    pr-number: ${{ github.event.number }}
    sarif-file: scan/results/xss.sarif
    title: My security issue
    dry-run: false

Reproduced this issue by changing pr-number to pr_number in the action

Resolved in new version v2.0.1 now on the Marketplace


Ally color in allied menu

Sadly, my fix for the palyercolor in allied menu is not 100%. I noticed that if an AI's color was anything but black, it doesn't work. This is due to the text color having different IDs. For example, for black, it was 6 (not 5), and for blue, it was 2 (not 4). I will fix that bug in another pull request.

Can be closed with new release


Karpenter is not provisioning nodes and getting restarted

Description
karpenter-deploy.txt
HI Team
i have installed Karpenter Version v0.37.4 freshly on EKS Cluster and its not provisioning any nodes. Karpenter pods are also getting restarted frequently.
Version :
[root@ip-10-53-26-123 ~]# k get crd|grep -i karpenter
ec2nodeclasses.karpenter.k8s.aws                            2024-10-21T10:34:57Z
nodeclaims.karpenter.sh                                     2024-10-21T10:34:57Z
nodepools.karpenter.sh                                      2024-10-21T10:34:57Z
[root@ip-10-53-26-123 ~]# helm ls
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
karpenter       karpenter       1               2024-10-21 07:32:25.353351235 +0000 UTC deployed        ****        0.37.4
karpenter-crd   karpenter       1               2024-10-21 10:34:57.424417338 +0000 UTC deployed        karpenter-crd-0.37.4    0.37.4
[root@ip-10-53-26-123 ~]#
Kubernetes Version : 1.30
Logs as below :
    logs

[root@ip-10-53-26-123 ~]# k logs -f karpenter-56f6b956fb-7f8tt
{"level":"INFO","time":"2024-10-22T05:32:13.673Z","logger":"controller.controller-runtime.metrics","message":"Starting metrics server","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:32:13.674Z","logger":"controller.controller-runtime.metrics","message":"Serving metrics server","commit":"0ebc224","bindAddress":":8000","secure":false}
{"level":"INFO","time":"2024-10-22T05:32:13.674Z","logger":"controller","message":"starting server","commit":"0ebc224","name":"health probe","addr":"[::]:8081"}
{"level":"INFO","time":"2024-10-22T05:32:13.776Z","logger":"controller","message":"attempting to acquire leader lease karpenter/karpenter-leader-election...","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:32:24.112Z","logger":"controller","message":"successfully acquired lease karpenter/karpenter-leader-election","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:32:24.113Z","logger":"controller","message":"Starting controller","commit":"0ebc224","controller":"provisioner"}
{"level":"INFO","time":"2024-10-22T05:32:24.113Z","logger":"controller","message":"Starting controller","commit":"0ebc224","controller":"eviction-queue"}
{"level":"INFO","time":"2024-10-22T05:32:24.113Z","logger":"controller","message":"Starting controller","commit":"0ebc224","controller":"disruption.queue"}
{"level":"INFO","time":"2024-10-22T05:32:24.113Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"provisioner.trigger.pod","controllerGroup":"","controllerKind":"Pod","source":"kind source: *v1.Pod"}
{"level":"INFO","time":"2024-10-22T05:32:24.114Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"provisioner.trigger.pod","controllerGroup":"","controllerKind":"Pod"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"provisioner.trigger.pod","controllerGroup":"","controllerKind":"Pod","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.114Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"provisioner.trigger.node","controllerGroup":"","controllerKind":"Node","source":"kind source: *v1.Node"}
{"level":"INFO","time":"2024-10-22T05:32:24.117Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"provisioner.trigger.node","controllerGroup":"","controllerKind":"Node"}
{"level":"INFO","time":"2024-10-22T05:32:24.117Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"provisioner.trigger.node","controllerGroup":"","controllerKind":"Node","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.114Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodepool.hash","controllerGroup":"karpenter.sh","controllerKind":"NodePool","source":"kind source: *v1beta1.NodePool"}
{"level":"INFO","time":"2024-10-22T05:32:24.117Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"nodepool.hash","controllerGroup":"karpenter.sh","controllerKind":"NodePool"}
{"level":"INFO","time":"2024-10-22T05:32:24.113Z","logger":"controller","message":"Starting controller","commit":"0ebc224","controller":"disruption"}
{"level":"INFO","time":"2024-10-22T05:32:24.114Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"state.daemonset","controllerGroup":"apps","controllerKind":"DaemonSet","source":"kind source: *v1.DaemonSet"}
{"level":"INFO","time":"2024-10-22T05:32:24.120Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"state.daemonset","controllerGroup":"apps","controllerKind":"DaemonSet"}
{"level":"INFO","time":"2024-10-22T05:32:24.114Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"state.nodepool","controllerGroup":"karpenter.sh","controllerKind":"NodePool","source":"kind source: *v1beta1.NodePool"}
{"level":"INFO","time":"2024-10-22T05:32:24.114Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"state.node","controllerGroup":"","controllerKind":"Node","source":"kind source: *v1.Node"}
{"level":"INFO","time":"2024-10-22T05:32:24.114Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"state.pod","controllerGroup":"","controllerKind":"Pod","source":"kind source: *v1.Pod"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"node.termination","controllerGroup":"","controllerKind":"Node","source":"kind source: *v1.Node"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"metrics.nodepool","controllerGroup":"karpenter.sh","controllerKind":"NodePool","source":"kind source: *v1beta1.NodePool"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"state.nodeclaim","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","source":"kind source: *v1beta1.NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodepool.counter","controllerGroup":"karpenter.sh","controllerKind":"NodePool","source":"kind source: *v1beta1.NodePool"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting controller","commit":"0ebc224","controller":"metrics.node"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"metrics.pod","controllerGroup":"","controllerKind":"Pod","source":"kind source: *v1.Pod"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","source":"kind source: *v1beta1.NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclaim.consistency","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","source":"kind source: *v1beta1.NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","source":"kind source: *v1beta1.NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"lease.garbagecollection","controllerGroup":"coordination.k8s.io","controllerKind":"Lease","source":"kind source: *v1.Lease"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting controller","commit":"0ebc224","controller":"nodeclaim.garbagecollection"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclaim.disruption","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","source":"kind source: *v1beta1.NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclass.status","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass","source":"kind source: *v1beta1.EC2NodeClass"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting controller","commit":"0ebc224","controller":"nodeclaim.garbagecollection"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclass.hash","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass","source":"kind source: *v1beta1.EC2NodeClass"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting controller","commit":"0ebc224","controller":"providers.pricing"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclass.termination","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass","source":"kind source: *v1beta1.EC2NodeClass"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclaim.tagging","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","source":"kind source: *v1beta1.NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting controller","commit":"0ebc224","controller":"interruption"}
{"level":"INFO","time":"2024-10-22T05:32:24.115Z","logger":"controller","message":"Starting controller","commit":"0ebc224","controller":"providers.instancetype"}
{"level":"INFO","time":"2024-10-22T05:32:24.121Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"state.nodepool","controllerGroup":"karpenter.sh","controllerKind":"NodePool"}
{"level":"INFO","time":"2024-10-22T05:32:24.123Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"state.node","controllerGroup":"","controllerKind":"Node"}
{"level":"INFO","time":"2024-10-22T05:32:24.123Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"state.pod","controllerGroup":"","controllerKind":"Pod"}
{"level":"INFO","time":"2024-10-22T05:32:24.123Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"node.termination","controllerGroup":"","controllerKind":"Node"}
{"level":"INFO","time":"2024-10-22T05:32:24.124Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"metrics.nodepool","controllerGroup":"karpenter.sh","controllerKind":"NodePool"}
{"level":"INFO","time":"2024-10-22T05:32:24.124Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"state.nodeclaim","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.124Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodepool.counter","controllerGroup":"karpenter.sh","controllerKind":"NodePool","source":"kind source: *v1beta1.NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.124Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodepool.counter","controllerGroup":"karpenter.sh","controllerKind":"NodePool","source":"kind source: *v1.Node"}
{"level":"INFO","time":"2024-10-22T05:32:24.124Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"nodepool.counter","controllerGroup":"karpenter.sh","controllerKind":"NodePool"}
{"level":"INFO","time":"2024-10-22T05:32:24.124Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"metrics.pod","controllerGroup":"","controllerKind":"Pod"}
{"level":"INFO","time":"2024-10-22T05:32:24.124Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","source":"kind source: *v1.Node"}
{"level":"INFO","time":"2024-10-22T05:32:24.124Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.125Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclaim.consistency","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","source":"kind source: *v1.Node"}
{"level":"INFO","time":"2024-10-22T05:32:24.125Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"nodeclaim.consistency","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.125Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","source":"kind source: *v1.Node"}
{"level":"INFO","time":"2024-10-22T05:32:24.125Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.125Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"lease.garbagecollection","controllerGroup":"coordination.k8s.io","controllerKind":"Lease"}
{"level":"INFO","time":"2024-10-22T05:32:24.125Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclaim.disruption","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","source":"kind source: *unstructured.Unstructured"}
{"level":"INFO","time":"2024-10-22T05:32:24.125Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclaim.disruption","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","source":"kind source: *v1beta1.NodePool"}
{"level":"INFO","time":"2024-10-22T05:32:24.126Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclaim.disruption","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","source":"kind source: *v1.Pod"}
{"level":"INFO","time":"2024-10-22T05:32:24.126Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"nodeclaim.disruption","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.126Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"nodeclass.status","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass"}
{"level":"INFO","time":"2024-10-22T05:32:24.127Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"nodeclass.hash","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass"}
{"level":"INFO","time":"2024-10-22T05:32:24.127Z","logger":"controller","message":"Starting EventSource","commit":"0ebc224","controller":"nodeclass.termination","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass","source":"kind source: *v1beta1.NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.128Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"nodeclass.termination","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass"}
{"level":"INFO","time":"2024-10-22T05:32:24.128Z","logger":"controller","message":"Starting Controller","commit":"0ebc224","controller":"nodeclaim.tagging","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:32:24.218Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"nodepool.hash","controllerGroup":"karpenter.sh","controllerKind":"NodePool","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.229Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"state.daemonset","controllerGroup":"apps","controllerKind":"DaemonSet","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.229Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","worker count":100}
{"level":"INFO","time":"2024-10-22T05:32:24.230Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"metrics.nodepool","controllerGroup":"karpenter.sh","controllerKind":"NodePool","worker count":1}
{"level":"INFO","time":"2024-10-22T05:32:24.230Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"nodeclaim.tagging","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","worker count":1}
{"level":"INFO","time":"2024-10-22T05:32:24.230Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"lease.garbagecollection","controllerGroup":"coordination.k8s.io","controllerKind":"Lease","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.230Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","worker count":1000}
{"level":"INFO","time":"2024-10-22T05:32:24.233Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"state.nodepool","controllerGroup":"karpenter.sh","controllerKind":"NodePool","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.233Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"nodeclaim.consistency","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.233Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"state.node","controllerGroup":"","controllerKind":"Node","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.234Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"state.pod","controllerGroup":"","controllerKind":"Pod","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.234Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"node.termination","controllerGroup":"","controllerKind":"Node","worker count":100}
{"level":"INFO","time":"2024-10-22T05:32:24.234Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"nodeclaim.disruption","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.234Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"state.nodeclaim","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.235Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"nodepool.counter","controllerGroup":"karpenter.sh","controllerKind":"NodePool","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.235Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"metrics.pod","controllerGroup":"","controllerKind":"Pod","worker count":1}
{"level":"INFO","time":"2024-10-22T05:32:24.236Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"nodeclass.termination","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.241Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"nodeclass.hash","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.242Z","logger":"controller","message":"Starting workers","commit":"0ebc224","controller":"nodeclass.status","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass","worker count":10}
{"level":"INFO","time":"2024-10-22T05:32:24.400Z","logger":"controller","message":"discovered ssm parameter","commit":"0ebc224","controller":"nodeclass.status","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass","EC2NodeClass":{"name":"default"},"namespace":"","name":"default","reconcileID":"712920ca-b741-462a-8dd6-6f2f68c89b84","parameter":"/aws/service/eks/optimized-ami/1.30/amazon-linux-2/recommended/image_id","value":"ami-0e557fbb334a8523a"}
{"level":"INFO","time":"2024-10-22T05:32:24.421Z","logger":"controller","message":"discovered ssm parameter","commit":"0ebc224","controller":"nodeclass.status","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass","EC2NodeClass":{"name":"default"},"namespace":"","name":"default","reconcileID":"712920ca-b741-462a-8dd6-6f2f68c89b84","parameter":"/aws/service/eks/optimized-ami/1.30/amazon-linux-2-gpu/recommended/image_id","value":"ami-00e0039d47b330830"}
{"level":"INFO","time":"2024-10-22T05:32:24.435Z","logger":"controller","message":"discovered ssm parameter","commit":"0ebc224","controller":"nodeclass.status","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass","EC2NodeClass":{"name":"default"},"namespace":"","name":"default","reconcileID":"712920ca-b741-462a-8dd6-6f2f68c89b84","parameter":"/aws/service/eks/optimized-ami/1.30/amazon-linux-2-arm64/recommended/image_id","value":"ami-0255d1302f214fe9c"}
{"level":"INFO","time":"2024-10-22T05:34:23.058Z","logger":"controller","message":"Stopping and waiting for non leader election runnables","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Stopping and waiting for leader election runnables","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Stopping controller","commit":"0ebc224","controller":"eviction-queue"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Stopping controller","commit":"0ebc224","controller":"disruption.queue"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Stopping controller","commit":"0ebc224","controller":"metrics.node"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Stopping controller","commit":"0ebc224","controller":"nodeclaim.garbagecollection"}
{"level":"ERROR","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Reconciler error","commit":"0ebc224","controller":"providers.pricing","error":"updating pricing, retreiving on-demand pricing data, RequestCanceled: request context canceled\ncaused by: context canceled; RequestCanceled: request context canceled\ncaused by: context canceled"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Stopping controller","commit":"0ebc224","controller":"providers.pricing"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Stopping controller","commit":"0ebc224","controller":"providers.instancetype"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"nodeclass.status","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"nodeclass.hash","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Stopping controller","commit":"0ebc224","controller":"nodeclaim.garbagecollection"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"nodeclass.termination","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"metrics.pod","controllerGroup":"","controllerKind":"Pod"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"nodepool.counter","controllerGroup":"karpenter.sh","controllerKind":"NodePool"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"state.nodeclaim","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"nodeclaim.disruption","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:34:23.059Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"node.termination","controllerGroup":"","controllerKind":"Node"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"state.pod","controllerGroup":"","controllerKind":"Pod"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"state.node","controllerGroup":"","controllerKind":"Node"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"nodeclaim.consistency","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"state.nodepool","controllerGroup":"karpenter.sh","controllerKind":"NodePool"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"lease.garbagecollection","controllerGroup":"coordination.k8s.io","controllerKind":"Lease"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"nodeclaim.tagging","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"metrics.nodepool","controllerGroup":"karpenter.sh","controllerKind":"NodePool"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"state.daemonset","controllerGroup":"apps","controllerKind":"DaemonSet"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"nodepool.hash","controllerGroup":"karpenter.sh","controllerKind":"NodePool"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"provisioner.trigger.node","controllerGroup":"","controllerKind":"Node"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"Shutdown signal received, waiting for all workers to finish","commit":"0ebc224","controller":"provisioner.trigger.pod","controllerGroup":"","controllerKind":"Pod"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"metrics.pod","controllerGroup":"","controllerKind":"Pod"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"nodepool.counter","controllerGroup":"karpenter.sh","controllerKind":"NodePool"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"state.nodeclaim","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"state.pod","controllerGroup":"","controllerKind":"Pod"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"state.node","controllerGroup":"","controllerKind":"Node"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"state.nodepool","controllerGroup":"karpenter.sh","controllerKind":"NodePool"}
{"level":"INFO","time":"2024-10-22T05:34:23.060Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"nodeclaim.consistency","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:34:23.061Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"provisioner.trigger.node","controllerGroup":"","controllerKind":"Node"}
{"level":"INFO","time":"2024-10-22T05:34:23.061Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"nodepool.hash","controllerGroup":"karpenter.sh","controllerKind":"NodePool"}
{"level":"INFO","time":"2024-10-22T05:34:23.061Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"provisioner.trigger.pod","controllerGroup":"","controllerKind":"Pod"}
{"level":"ERROR","time":"2024-10-22T05:34:23.062Z","logger":"controller","message":"Reconciler error","commit":"0ebc224","controller":"interruption","error":"getting messages from queue, receiving sqs messages, RequestCanceled: request context canceled\ncaused by: context canceled"}
{"level":"INFO","time":"2024-10-22T05:34:23.062Z","logger":"controller","message":"Stopping controller","commit":"0ebc224","controller":"interruption"}
{"level":"INFO","time":"2024-10-22T05:34:23.097Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"nodeclaim.tagging","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:34:23.097Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"nodeclass.termination","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass"}
{"level":"INFO","time":"2024-10-22T05:34:23.097Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"nodeclass.hash","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass"}
{"level":"INFO","time":"2024-10-22T05:34:23.097Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"nodeclass.status","controllerGroup":"karpenter.k8s.aws","controllerKind":"EC2NodeClass"}
{"level":"INFO","time":"2024-10-22T05:34:23.097Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"nodeclaim.disruption","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:34:23.097Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"lease.garbagecollection","controllerGroup":"coordination.k8s.io","controllerKind":"Lease"}
{"level":"INFO","time":"2024-10-22T05:34:23.098Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:34:23.098Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim"}
{"level":"INFO","time":"2024-10-22T05:34:23.098Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"metrics.nodepool","controllerGroup":"karpenter.sh","controllerKind":"NodePool"}
{"level":"INFO","time":"2024-10-22T05:34:23.098Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"node.termination","controllerGroup":"","controllerKind":"Node"}
{"level":"INFO","time":"2024-10-22T05:34:23.098Z","logger":"controller","message":"All workers finished","commit":"0ebc224","controller":"state.daemonset","controllerGroup":"apps","controllerKind":"DaemonSet"}
{"level":"ERROR","time":"2024-10-22T05:34:23.350Z","logger":"controller","message":"Reconciler error","commit":"0ebc224","controller":"disruption","error":"disrupting via "expiration", determining candidates, tracking PodDisruptionBudgets, Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
{"level":"INFO","time":"2024-10-22T05:34:23.350Z","logger":"controller","message":"Stopping controller","commit":"0ebc224","controller":"disruption"}
{"level":"INFO","time":"2024-10-22T05:34:23.500Z","logger":"controller","message":"found provisionable pod(s)","commit":"0ebc224","controller":"provisioner","Pods":"monitoring/inflate-prod-6f99db8776-j2ths, monitoring/kube-prometheus-stack-operator-594865b5df-2ftfh","duration":"1m58.378708934s"}
{"level":"INFO","time":"2024-10-22T05:34:23.500Z","logger":"controller","message":"computed new nodeclaim(s) to fit pod(s)","commit":"0ebc224","controller":"provisioner","nodeclaims":2,"pods":2}
{"level":"INFO","time":"2024-10-22T05:34:23.500Z","logger":"controller","message":"Stopping controller","commit":"0ebc224","controller":"provisioner"}
{"level":"INFO","time":"2024-10-22T05:34:23.500Z","logger":"controller","message":"Stopping and waiting for caches","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:34:23.501Z","logger":"controller","message":"k8s.io/client-go@v0.30.1/tools/cache/reflector.go:232: watch of *v1beta1.NodePool ended with: an error on the server ("unable to decode an event from the watch stream: context canceled") has prevented the request from succeeding","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:34:23.501Z","logger":"controller","message":"k8s.io/client-go@v0.30.1/tools/cache/reflector.go:232: watch of *v1.Pod ended with: an error on the server ("unable to decode an event from the watch stream: context canceled") has prevented the request from succeeding","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:34:23.501Z","logger":"controller","message":"k8s.io/client-go@v0.30.1/tools/cache/reflector.go:232: watch of *v1.NodePool ended with: an error on theserver ("unable to decode an event from the watch stream: context canceled") has prevented the request from succeeding","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:34:23.501Z","logger":"controller","message":"k8s.io/client-go@v0.30.1/tools/cache/reflector.go:232: watch of *v1.Node ended with: an error on the server ("unable to decode an event from the watch stream: context canceled") has prevented the request from succeeding","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:34:23.501Z","logger":"controller","message":"k8s.io/client-go@v0.30.1/tools/cache/reflector.go:232: watch of *v1beta1.NodeClaim ended with: an error on the server ("unable to decode an event from the watch stream: context canceled") has prevented the request from succeeding","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:34:23.503Z","logger":"controller","message":"Stopping and waiting for webhooks","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:34:23.503Z","logger":"controller","message":"Stopping and waiting for HTTP servers","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:34:23.503Z","logger":"controller","message":"shutting down server","commit":"0ebc224","name":"health probe","addr":"[::]:8081"}
{"level":"INFO","time":"2024-10-22T05:34:23.503Z","logger":"controller.controller-runtime.metrics","message":"Shutting down metrics server with timeout of 1 minute","commit":"0ebc224"}
{"level":"INFO","time":"2024-10-22T05:34:23.503Z","logger":"controller","message":"Wait completed, proceeding to shutdown the manager","commit":"0ebc224"}
{"level":"ERROR","time":"2024-10-22T05:34:23.514Z","logger":"controller","message":"error received after stop sequence was engaged","commit":"0ebc224","error":"leader election lost"}
[root@ip-10-53-26-123 ~]#

This is working fine after enabling access to pricing Api.


Compute system_challenge_offset correctly

Just to provide a description: self.num_challenge() takes self.num_challenge, which are the user challenges, and then adds some challenges that are always part of the halo2 system:
[
  [theta],
  [beta, gamma],
  [alpha],
]

However in the edge case that your advice columns only use n phases but you have a challenge in phase n+1, then theta shares the same phase/index as the last user challenge, looking like:
[
  [my_challenge, theta],
  [beta, gamma],
  [alpha],
]

This means the previous calculation of the system challenge offset based on excluding the last 3 entries of self.num_challenge() is incorrect. Instead it should sum all the user challenges in self.num_challenge (note the lack of parenthesis).


Switch from mission-control ➡ just

https://github.com/casey/just

i think the website documentation still needs updating to reflect this change

i think the website documentation still needs updating to reflect this change

Thanks, fixed: https://github.com/srid/srid/commit/88abda3d4abf0381d1665e60c0efa6293c74d1a9


neomutt: 20231221 -> 20240425

Description of changes

Release notes: https://github.com/neomutt/neomutt/releases/tag/20240416
Refactor to use finalAttrs instead of rec
Refactor to use lib. in meta directly rather than with lib;
Introduce disabledTests to skip failing tests
Remove indeterminate article from meta.description

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] 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

[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/)
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.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/3854

Thanks everyone for the helpful review comments and getting this merged, much appreciated 🙂

This version has severe heap-use-after-free :/.

@SuperSandro2000 How did you test it?

I forward that question to @afh @nim65s , I just reviewed the changes.

Heap-use-after free isn't something I had on the agenda for testing neomutt, @RaitoBezarius. Would you be willing to share some details from which some test notes for future update could be created?

Mind sharing more details about ASAN and commands used? That would be helpful and much appreciated, @RaitoBezarius 🙂

https://github.com/RaitoBezarius/nixos-home/blob/master/emails/neomutt.nix#L11-L20
I just ran neomutt, that's it, it crashed instantly at startup, no action needed to be done (as per the stacktrace).

Thanks for sharing, @RaitoBezarius, I'll give this a spin and report back here.


Add support for php 8.x

This pull request resolves https://github.com/Strategery-Inc/Magento2-InfiniteScroll/issues/70

Closed in favor to https://github.com/Strategery-Inc/Magento2-InfiniteScroll/pull/72, because I hadn't permissions to merge to the master branch


cloudbank: Explicitly specify what nodepools users should go to

Otherwise, they still end up on the old 'user' nodepool, and it can not be decomissioned. With this, they will end up on the equivalent 'new' nodepool, and then I can get rid of the old one.
I have also had to adjust the CPU limit, as at some point I suppose we switched from 8 CPU nodes to 4 but did not adjust this.

This also ensures users don't end up accidentally on one of the large nodepools, which would cost a lot more!

Self-merging as there aren't any other engineers around until end of year.


Documentation Setup

Currently the documentation is built upon my fork of this repository.
To build it upon the main branch,

Go to ReadTheDocs
Sign up -> Community
Sign up using Github (Make sure to sign in with the asascience-open account
This is important to give access to the repository
Import project
Enter project name and branch name
Finish -> Build version

Successfully setup!

To add a new example in the documentation, make sure the notebook / python file is in docs/examples folder.
In docs/notebooks.rst , Add a new line at the end -  examples/sample.ipynb.
Make sure that the notebook has a #heading so that it is rendered as the title for the example notebook

Can you take down your version? Currently i cannot publish it because the name is taken

Sorry. I've deleted my project I think it should work now

All set thank you!


sender:BQ:create_table:error Error: Already Exists:

Hi there,
When I clone and run your demo repository from scratch, I get this error:
demo_streamer2bigquery [master●] DEBUG=* node streamer.js
i started
  streamer:google_client:log   authorized +0ms
  scheduler:log   added new sender for key:logs:demo_app:v2:random_address +5ms
  sender:BQ:create_dataset:error Error: Already Exists: Dataset seismic-spot-114600:development_demo_app_v2
___Stack trace #1___
Error: Already Exists: Dataset my_dataset:development_demo_app_v2
    at Request._callback (/Users/scaryguy/arge/redis_to_bq/demo_streamer2bigquery/node_modules/bigquery-streamer/node_modules/googleapis/lib/transporters.js:83:15)
    at Request.self.callback (/Users/scaryguy/arge/redis_to_bq/demo_streamer2bigquery/node_modules/bigquery-streamer/node_modules/googleapis/node_modules/request/request.js:373:22)
    at emitTwo (events.js:87:13)
    at Request.emit (events.js:172:7)
    at Request.<anonymous> (/Users/scaryguy/arge/redis_to_bq/demo_streamer2bigquery/node_modules/bigquery-streamer/node_modules/googleapis/node_modules/request/request.js:1318:14)
    at emitOne (events.js:82:20)
    at Request.emit (events.js:169:7)
    at IncomingMessage.<anonymous> (/Users/scaryguy/arge/redis_to_bq/demo_streamer2bigquery/node_modules/bigquery-streamer/node_modules/googleapis/node_modules/request/request.js:1266:12)
    at emitNone (events.js:72:20)
    at IncomingMessage.emit (events.js:166:7)
    at endReadableNT (_stream_readable.js:905:12)
    at nextTickCallbackWith2Args (node.js:437:9)
    at process._tickCallback (node.js:351:17) +2s

But I don't have mentioned table. It is created after I run streamer.js. So what could be wrong?
Thanks

Seems like bigquery-streamer is pretty old. Do you have any working demos with V3 of bigquery-streamer?


Roll Flutter Engine from 7bf865774d06 to 86c55dde6963 (2 revisions)

https://github.com/flutter/engine/compare/7bf865774d06...86c55dde6963
2024-05-14<EMAIL_ADDRESS>Refactor Semantics in preparation for ARC migration (flutter/engine#52729)
2024-05-14<EMAIL_ADDRESS>Rolls in buildroot with stack protection flag (flutter/engine#52774)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC bdero@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


IMqttNetLogger called with plaintext password

Upon connecting to the MQTT broker, the Verbose method of the implementation of the IMqttNetLogger interface is called with a MqttConnectPacket object in the parameters array. This object includes the password in plaintext.

Hi,
thank you for your suggestion. I will think about it and modify the logger. I assume I will add a setting for this which defaults to removal of the password. Because in some cases this value might be interesting while debugging etc.
Best regards
Christian

This will be added in the next version 3.0.0.


Native Editor - Modify variable explorer to have new look

Here's the toolbar icon (need icon from design team)

Also need to change behavior so that it only shows up when that button is depressed (it's sticky)

additional-icons.zip

May as well fix the other icons in the interactive panel too.

Actually icon is already there. Already submitted the new image. Just need to use it


Simple append text just disappears

The following simple button make the text appear for a split second before removed again:
```button
name Javascript
type append text
action Javascript-text
templater true
```
^button-js

I'm using Obsidian 1.0.3 (, Templater 1.16.0) , and Buttons 0.4.19.  If I remove the templater true line, it adds the text, but I would like to actually use templater stuff in the added text.
Have I done something strange, or is this a bug?

This happens for me as well when using templater=true

And now that workaround doesn't work either. It replaces all the text in my note with the output of the template.


The top-right logout button sometimes disappears for small screen size

The browser is: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0, screen is: 1366*768
The top-right widgets should always show up in any screen size.

@seriouszyx @Nekotoxin


chore: go-demo-6 to 1.0.379

chore: Promote go-demo-6 to version 1.0.379

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Problem with http://ashleydw.github.io/lightbox/

Hi,
When going to http://ashleydw.github.io/lightbox/ there is a banner warning message saying : "This site is sending too much trafic to rawgit.com. Please contact its owner  and ask them to use cdn.rawgit.com instead, which has no trafic limit."

Thanks, I've removed all traces of rawgithub infacour of cdnjs.com


German translation improvement

Hi,
awsome Tool, and thanks for publishing it under an open licence for everyone to see the code and compile.
In the newest release there are some German translations that could be improved:
Exit -> Beenden (The current used word Ausfahrt is the word for Highway exit)
Folders -> Ordner
Cancel -> Abbrechen (Stornieren is more used for canceling a Hotel booking, not to cancel a IT interaction)
refresh -> Aktualisieren
All in all cosmetic issues, but i think this tool deserves it :)

Thanks, the feedback helps a lot!

Fixed in v1.2.1 release


Bootstrap buffer doesn't provide speedup

In both your test and in a more complex one, I get better performance when setting the size of the bootstrap buffer to 0 bytes:
BenchmarkComplexMarshalJSONNative         100000             17252 ns/op  76.80 MB/s
BenchmarkMarshalJSONNative       1000000              2364 ns/op          41.87MB/s

With bootstrap size set to 0:
BenchmarkComplexMarshalJSONNative         100000             16767 ns/op  79.02 MB/s
BenchmarkMarshalJSONNative       1000000              2104 ns/op          47.04 MB/s

The difference is pretty consistent on my machine. How does it look on yours? I would expect the slowdown to come from zeroing the array and in some cases copying the slice into a bigger one.
I have tried setting the size to both lower and higher values, and lower gives speedup, while higher gives slowdown. '0' was the fastest value.

If bootstrap is removed, Truncate should probably be changed to:

On sync.Pool: We don't have a multi-go-routine benchmark right now -- I'd like to add one before getting too "into" it -- in a real world web server, that is processing requests in multiple go-routines, today there is zero locking from ffjson -- reusing the Buffer might be worth it, but i'd like to be able to test it more realistically before adding usage of sync.Pool.

I tried a few approaches for buffering, but the only way I found worked was if it was the only major speedup would be if the byte buffer was re-used. The problem of course is that we are returning the byte array to the json encoder/the user.
The caller can still do the buffering like this:
var buffers = sync.Pool{New: func() interface{} { return &fflib.Buffer{} }}

func handle() {
	var b = buffers.Get().(*fflib.Buffer)
	err := record.MarshalJSONBuf(b)
	json := b.Bytes()
	// Finish working with the bytes, so the buffer is no longer needed.
	b.Reset()
	buffers.Put(b)
}

This works fine if the bootstrap is removed and the truncate function is modified as described above.
I can send you a PR, if you'd like to see it.

Merged in #101 and #102


Migrate database and update handlers for new user profile design

connect #393

Update database schema

rename user to auth in all tables
create record table user with username and email

Rename AuthInfo to ProviderInfo
Rename UserInfo to AuthInfo
Remove Username and Email in UserInfo
Remove user:query, user:update and user:link
Remove user discovery funcs
Refactor TxDatabase to Transactional and TxDatabase

All handler request and response signature are unchanged.
============
Update:

Treat pq citext as normal string

I found I couldn't signup with email or username with the new database schema because the column type is incompatible, citext vs text.
And then I found https://github.com/SkygearIO/skygear-server/issues/41.
Since username and email are now stored in a normal record table, which means these columns are no longer special column to skygear. Then they need to handle schema migration, but citext does not exist in skygear record, which leads to the conflict.

I think the concept case insensitive comparison is not compatible to the new user profile design, so needs some discussion first.

Many thanks @Steven-Chan!

Seems lacking test case

@cheungpat updated

@cheungpat updated

@cheungpat updated

@cheungpat  I just found if a user sign up with username, the email would be empty instead of null, which makes the second empty email sign up request violate the unique constraint. 😢


Update to verify the module against https://github.com/dev-sec/linux-baseline

We have multiple options, one option is to use test-kitchen as we use this for Chef and Ansible.

I'm for test-kitchen - I would like the same/similar setup everywhere, this would make it easy for us and contributors I think
From my POV this tools are more or less established for this purpose independently of the automation stack itself, so..

@artem-sidorenko Could you help me with this somewhere in the next weeks? I suggest we switch to the new PDK infrastructure first (#107) before we implement this ...


Clarify the meaning of the build queue metrics: waiting vs blocked vs buildable vs left

Describe your use-case which is not covered by existing documentation.
Want to monitor the build queue and understand if some builds are stuck...

left: count of task that have gone through the build queue and left the build queue.
buildable:h.m.Queue#getBuildableItems()
blocked: Difference h.h.q.QueueListener#onEnterBlocked - h.m.q.QueueListener#onLeaveBlocked
waiting: items that are in the queue but not blockedh.m.Queue#getUnblockedItems()

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.
No response

Fixed by https://github.com/jenkinsci/opentelemetry-plugin/pull/401
See https://github.com/jenkinsci/opentelemetry-plugin/blob/master/docs/monitoring-metrics.md


Update remaining quantity with quotation uploads

Fixes https://github.com/LSFLK/MedicinesforLK/issues/525

Fixes https://github.com/LSFLK/MedicinesforLK/issues/539


Got the error randomly "one of the commands exited with non-zero exit code" when conda activate snakemake

Snakemake version
5.30.1
Describe the bug
When I use command line "conda deactivate", I can run trim_galore successfully.
When I  "conda activate snakemake
snakemake  -j100 --cores 10 -prk --rerun-incomplete",
it will show errors: "one of the commands exited with non-zero exit code; note that snakemake uses bash strict mode!
/usr/bin/bash: /path/to/venv/bin/activate: No such file or directory"
Adding "set +u; source /path/to/venv/bin/activate; set -u" in the rule can not solve this problem.
It is very strange that sometimes it can run successfully when conda activate snakemake.
I don't know how to change the code to solve the problem as the error showed randomly.
Logs
When it got errors, the log file of  trim_galore showed that cutadapt is simply too old!
Minimal example
rule all:
input:
expand('s02.qc_trim/{exp}/{cell}_R1_val_1.fq.gz', zip,
exp=samples.exp, cell=samples.cell),
expand('s02.qc_trim/{exp}/{cell}_R2_val_2.fq.gz', zip,
exp=samples.exp, cell=samples.cell)
rule trim_galore:
input:
R1='s01.fastq/{exp}/{cell}_R1.fq.gz',
R2='s01.fastq/{exp}/{cell}_R2.fq.gz'
output:
"s02.qc_trim/{exp}/{cell}_R1_val_1.fq.gz",
"s02.qc_trim/{exp}/{cell}_R1.fq.gz_trimming_report.txt",
"s02.qc_trim/{exp}/{cell}_R2_val_2.fq.gz",
"s02.qc_trim/{exp}/{cell}_R2.fq.gz_trimming_report.txt"
log:
'log/trim_galore/{exp}/{cell}.log',
shell:
''' trim_galore
-a CTGTCTCTTATACACATCTCCGAGCCCACGAGACNNNNNNNNATCTCGTATGCCGTCTTCTGCTTG
--cores 4
--paired
-o ./s02.qc_trim/{wildcards.exp}
{input.R1}
{input.R2}
2> {log}
'''

from what I understand, the problem is related to activating the conda env in the rule - if so, this is probably the same as #770


Azure ACR ResolveAsync missing required header (InvalidResponse)

What happened in your code base?
Hi, I am trying to do a copy between ACR and local registry:2 container.

Unhandled exception: System.Net.Http.HttpIOException: HEAD https://redacted.azurecr.io/v2/my-ns/some-ui/manifests/v2.3.2: missing required header  (InvalidResponse)
at OrasProject.Oras.Registry.Remote.HttpResponseMessageExtensions.GenerateDescriptorAsync(HttpResponseMessage response, Reference reference, CancellationToken cancellationToken)
at OrasProject.Oras.Registry.Remote.ManifestStore.ResolveAsync(String reference, CancellationToken cancellationToken)
at OrasProject.Oras.Registry.Remote.Repository.ResolveAsync(String reference, CancellationToken cancellationToken)
at OrasProject.Oras.Extensions.CopyAsync(ITarget src, String srcRef, ITarget dst, String dstRef, CancellationToken cancellationToken)

trying to curl the failing request uri does return the expected Docker-Content-Digest header.
Tried debugging and apparently, the response.Contents.Headers does not have the header:

but response.Headers does have it :

What did you expect to happen?
I expected the reference to be resolved instead of an exception being thrown.
How can we reproduce it?
When ResolveAsync is executed it throws the exception.
var sourceRegistryClient = new HttpClientWithBasicAuth(...);
var image = "my-registry.azurecr.io/ns/image:v2.3.2"
 var sourceRepository = new Repository(
                    image,
                    sourceRegistryClient);
await sourceRepository.ResolveAsync(image, cancellationToken);

What is the version or commit of the ORAS .NET library?
0.2.0 from nuget
What are your OS and Runtime environments?
Fedora 40 and .NET 8.0
Are you willing to submit PRs to fix it?

[X] Yes, I am willing to fix it.

This appears to be fixed on main branch. I've just cloned the repo, built from source code and tried the same test and it passed.
Is there a chance we can bump the nuget.org version of this package?

Hi @leonardochaia , good catch!

Is there a chance we can bump the nuget.org version of this package?

Yeah we can release a patch version v0.2.1 on the main branch.

Hi @Wwwsylvia , thank you that would be very appreciated :+1:

Hi @leonardochaia , [v0.2.1](https://www.nuget.org/packages/OrasProject.Oras/0.2.1) is now available on NuGet! 🙂

Thanks @Wwwsylvia , I think we can close this one :1st_place_medal:


⚠ Bofrost.es has degraded performance

In fd65204, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1654 ms

Resolved: Bofrost.es performance has improved in c8ce497 after 6 minutes.


Migration guide does not say how to configure filename pattern

I'm migrating from Mocha, which doesn't care about filenames. Jest seems to require a specific .test.js suffix, even if I explicitly tell it where my test files are:
jest test/*.js

No tests found

but neither the migration guide, nor migration tool (https://github.com/skovhus/jest-codemods/issues/55) help to solve this problem.

See http://facebook.github.io/jest/docs/en/cli.html#content and http://facebook.github.io/jest/docs/en/configuration.html#testmatch-array-string