Automated cherry pick of #6839: scheduler: fix memory over committed

Cherry pick of #6839 on release/3.1.
#6839: scheduler: fix memory over committed

Codecov Report

Merging #6842 into release/3.1 will decrease coverage by 0.37%.
The diff coverage is 9.77%.

@@               Coverage Diff               @@
##           release/3.1    #6842      +/-   ##
===============================================
- Coverage         7.48%    7.11%   -0.38%
===============================================
  Files              585      600      +15
  Lines            98953   105871    +6918
===============================================
+ Hits              7411     7529     +118
- Misses           90970    97768    +6798
- Partials           572      574       +2

Flag
Coverage Δ

#aFlag
7.11% <9.77%> (-0.38%)
:arrow_down:

Impacted Files
Coverage Δ

pkg/cloudcommon/policy/policy.go
1.58% <ø> (+<0.01%)
:arrow_up:

pkg/cloudcommon/policy/resources.go
0.00% <ø> (ø)

pkg/cloudprovider/objectstore.go
2.51% <0.00%> (-0.01%)
:arrow_down:

pkg/cloudprovider/securitygroup.go
0.00% <0.00%> (ø)

pkg/compute/guestdrivers/managedvirtual.go
0.00% <0.00%> (ø)

pkg/compute/models/buckets.go
1.24% <0.00%> (ø)

pkg/compute/models/cloudproviders.go
0.96% <0.00%> (-0.01%)
:arrow_down:

pkg/compute/models/disks.go
0.55% <0.00%> (-0.01%)
:arrow_down:

pkg/compute/models/guestdisks.go
0.58% <ø> (+0.01%)
:arrow_up:

pkg/compute/models/guestnetworks.go
0.21% <0.00%> (+<0.01%)
:arrow_up:

... and 44 more

Continue to review full report at Codecov.

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


Instance methods/class methods not working for waterline

Hey,
The custom instance and class method's are not working on Models for 0.9-RC. For example adding a
    chicken: function() {
        return this;
    }

to the model attributes array, then finding the model Model.find() the returned this does not have the method chicken. Model.chicken() also does not work (if I pull it outside of the attributes array).
Gist: https://gist.github.com/dubcanada/a72abb348f7d1ffc81a4

I think this is still be an issue in sails version 0.12
anyone with solution ?


Session renewal retry count for Consul versions not supporting Sessions

Add a simple retry mechanism for session renewal when using TTLs in case the version of Consul is < 0.5.0 or more generally does not support sessions to hold a TTL.
Before, if using an unsupported version of Consul, the session renew would hang not throwing any useful error to the user.
Signed-off-by: Alexandre Beslic<EMAIL_ADDRESS>

/cc @mavenugo

@mavenugo does that sound good to you? This is just to avoid the hang and provide with a better error message just in case users are trying to use Consul < 0.5.1 with libnetwork.

LGTM


Channel closed, sats not received

Hello,
I had a force-closed channel  at 26.10, sats still not back in the wallet
73b8b54c76d42d336b09632f8be9bb24555ffef737c89a44bfcc680b0964d431

can you post your logs?

I have the same issue
mutiny-logs.txt

Channel ID 7831ccfb19c81526bee8ae9d316f7c4aaea4ec8ee6b55c77d091441fff2d1e80
"Channel closed because user manually force-closed the channel"
Channel closed Nov 10th
I have tried to resync on chain wallet to no avail. Logs attached in above comment.

Channel ID 7831ccfb19c81526bee8ae9d316f7c4aaea4ec8ee6b55c77d091441fff2d1e80
"Channel closed because user manually force-closed the channel"
Channel closed Nov 10th
I have tried to resync on chain wallet to no avail. Logs attached in above comment.

Open up a separate issue.

here, logs
mutiny-logs.txt

Looks like the transaction was revoked. Have no idea why because your logs do not go back longer than a day or two. Can reach out to the LSP on your behalf.
tx: https://mempool.space/address/bc1qgxncp2ka5e4uuwwj5la5jvhx8m5xufcvnx7tfy7n88tuqrh4av8qrt0zus
What is your node id? it should be in the admin settings.


Inconsistent results

When reproducing the code, using the "Medt" network, you have not encountered the training and test results of the situation is very different

me too,why?

I don't know, in the test, there's still a lump in the upper left corner, and the test is very different from the training

The training and test results of  GLAS Dataset  are  bad

The train code
python train.py --train_dataset "./Medical-Transformer/dataset/war/train/" --val_dataset "./Medical-Transformer/dataset/war/validation/" --direc './Medical-Transformer/dataset/war/result/' --batch_size 1 --epoch 400 --save_freq 10 --modelname "MedT" --learning_rate 0.001 --imgsize 400 --gray "no"

We're about the same. It's not going to work

I leaved a PR, discussing image segmentation, check it out, maybe you'll find it useful

me too,why?

请问您是如何训练的呢？我下载代码后感觉运行不了

The train code python train.py --train_dataset "./Medical-Transformer/dataset/war/train/" --val_dataset "./Medical-Transformer/dataset/war/validation/" --direc './Medical-Transformer/dataset/war/result/' --batch_size 1 --epoch 400 --save_freq 10 --modelname "MedT" --learning_rate 0.001 --imgsize 400 --gray "no"

how did you fix your problem ?

When reproducing the code, using the "Medt" network, you have not encountered the training and test results of the situation is very different

Me too.I met the same issue as you.How did you solve it？

The issue is disappear after I delete model.eval () in the test.py file.I don't know why.

The issue is disappear after I delete model.eval() in the test.py file.I don't know why.


Dynamic form generation

This PR adds some very basic support for dynamic forms. There is a form builder function, which, when provided with JSON structures similar to those found already in Syndesis - for example;
{   clientSecret: {     description: '',     displayName: '',     type: 'string',     labelHint: ''   },   authorizationEndpoint: {     description: '',     displayName: '',     type: 'string',     labelHint: ''   } }
produce a static form, for example like the below screenshot.

The idea is that these form utility functions will work together similar to how Angular's FormBuilder class works, just less all the angular specific stuff. So when we move from PF3 to PF4, we might be able to leave much of the form builder still intact.
There is much work left to do, so I won't bother enumerating all of it here. Instead, for now, feel free to check out this work and provide any general feedback you may have in terms of high-level design patterns, directory structure, or naming contentions to enforce.

If we like the direction I'd vote for merging this work sooner rather than later just so we can have basic functionality to start fleshing out dependent bits like the create connection flow, editor etc.
@riccardo-forina WDYT?

Thank you @seanforyou23, nice progress!
I think this is an interesting approach, that now requires thinking about wiring the components for state management.
In the past I mentioned Formik as a potential candidate for form handling, and looking at this PR and how Formik works I still think it would be a nice fit.
I think we could try to achieve something like this:
<FormBuilder properties={properties}>
  ({ initialValues, validationSchema, getFields })
  <Formik
    initialValues={initialValues}
    validationSchema={validationSchema}
    onSubmit={values => {
      // same shape as initial values
      console.log(values);
    }}
  >
    {({ errors, touched, values }) => (
      <Form>
        {/*
          getFields will return the list of fields that should be rendered, based on the
          current values (so to resolve the field relationships), ordered as defined by
          the order property.
        */}
        {getFields(values).map((field) => (
          <Field
            name={field.name}
            component={field.component}
            key={field.name}
          />
          {errors[field.name] && touched[field.name] ? (

{errors[field.name]}

          ) : null}
        ))}
        <button type="submit">Submit</button>
      </Form>
    )}
  </Formik>
</FormBuilder>

Disclaimer: totally untested code, it might bring destruction in the multiverse if run
So, different from this PR there is the fact that formBuilder is a render prop component to allow composition, and field.component will refer to custom-made components that will use PF for rendering and will be Formik-aware (but still decoupled from it). Example component as by the doc:
const CustomInputComponent = ({
  field, // { name, value, onChange, onBlur }
  form: { touched, errors }, // also values, setXXXX, handleXXXX, dirty, isValid, status, etc.
  ...props
}) => (

    <input type="text" {...field} {...props} />
    {touched[field.name] &&
      errors[field.name] &&
{errors[field.name]}
}

);

WDYT?

Thanks for the feedback, definitely helps. I'm looking into the Formik stuff, and also just getting familiar with the render prop pattern, that seems to be key in all of this. I'll send more comments as I get my head wrapped around all of this. Generally, sounds like a good direction though!

Related to #3


Scale HarmonicBalance to larger system sizes

To scale HarmonicBalance.jl for larger systems, we could consider utilizing more methods build in HomotopyContinuation.jl which can speed up the root finding depending on the specific system. For example, the monodromy method in combination with Newton descent could be an option. However, will have to do some testing benchmarking to see what works.

Use the Monodromy method to exploit now solutions and symmetries to find the solutions faster. We the new Method interface one has too write Monodromy<:HarmonicBalance struct which will encode all the necessary symmetry/infromation to pas to HC


Crash on PC wakeup (System.Net.Http.HttpRequestException)

Upon waking up the PC from sleep SyncTrayzor crashed (showing it's own crash info screen, overlayed with windows' "the program has crashed dialog"). The setup is very unremarkable on this PC.
Syncthing seem to still be alive after the crash.
SyncTrayzor Log: (first err at line 35) https://gist.github.com/anonymous/8194d418661cbb56a15f8c8ce4538502
SyncTrayzor v.1.1.18
Syncthing v.0.14.43
OS: Win10x64

Just my two cents.

No connection could be made because the target machine actively refused it <IP_ADDRESS>:8585

8585 is not the standard port number. My systems all use 8384. Is Synthing started by something other than SyncTrayzor?

The remote name could not be resolved: 'synctrayzor.antonymale.co.uk'

This makes me think the network is not ready yet. WiFi may have not had time to reconnect. I'm not sure how Windows handles stale TCP connections. Coming out of sleep will for sure make any existing connections invalid. A server will RST reset and close the connection if it doesn't get a response for more than ~60 seconds.
Windows does have messaging for system events like Sleep and Shutdown. You can listen for these events and do any cleanup.


Hyperlink By Page Number

Hi
My application generates a  16 page pdf report so is there any option which will allow me to create a hyperlink, for example, Page 7 and when the user clicks page 7 will be shown.

Hi @webmarts, step 1 is getting the jsPDF object created by html2pdf - there's info on how to do that here.
Then you can write your own function to add page numbers with hyperlinks to the jsPDF object. See this comment for documentation on the two hyperlink options in jsPDF (which include linking to PDF pages).


fix: prevent possible delay page scrolling marking touch listeners as passive

Lighthouse passive event listener audit fails (https://web.dev/uses-passive-event-listeners/?utm_source=lighthouse&utm_medium=lr#how-the-lighthouse-passive-event-listener-audit-fails)
Lighthouse flags event listeners that may delay page scrolling.
Improved scrolling performance by adding a passive flag to every event listener that Lighthouse identified.

Hi @alelapi , I'm wondering whey this issue was closed? I'm seeing a similar warning

hi @taktran , I actually closed the PR because doesn't fix the issue and I hadn't time to fix it, but the issue is still there, you are right.
Please open an issue if you want to track it


Is the current version is production ready ? Pl confirm

The ttlv package has good test coverage, and robust coverage of the edge cases in the spec.  This is the package which encodes and decodes ttlv, and marshals/unmarshals ttlv to go structs.  It is production ready.
The root package is incomplete and doesn't have great test coverage.  This was the package where we intended to create go structs mirroring all the objects in the spec, and create a kmip server (modeled after go's http server).  There is usable code in there, and we did create a working sample client and server executable from it as a proof of concept (the POC client is in the cmd/kmipclient package), and we confirmed interoperability with other KMIP clients and servers.  But we have not completed modeling all the KMIP spec's objects and operations.

thanks


Error creating firmware workspace with freeRTOS for esp32

Hardware description: ESP32-WROOM-32D
Installation type: micro_ros_setup
Version: foxy

Hello,
I'm following this tutorial on how to create a new firmware workstation with freeRTOS, but using esp32 instead. When i try to create the workspace in my microros workspace:
ros2 run micro_ros_setup create_firmware_ws.sh freertos esp32
i get the following error messages:
Creating firmware for freertos platform esp32 reading in sources list data from /etc/ros/rosdep/sources.list.d  ERROR: unable to process source [https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/osx-homebrew.yaml]: 	<urlopen error [Errno -3] Temporary failure in name resolution> (https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/osx-homebrew.yaml) ERROR: unable to process source [https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/base.yaml]: 	<urlopen error [Errno -3] Temporary failure in name resolution> (https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/base.yaml) ERROR: unable to process source [https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/python.yaml]: 	<urlopen error [Errno -3] Temporary failure in name resolution> (https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/python.yaml) ERROR: unable to process source [https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/ruby.yaml]: 	<urlopen error [Errno -3] Temporary failure in name resolution> (https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/ruby.yaml) ERROR: unable to process source [https://raw.githubusercontent.com/ros/rosdistro/master/releases/fuerte.yaml]: 	Failed to download target platform data for gbpdistro: 	<urlopen error [Errno -3] Temporary failure in name resolution> Query rosdistro index https://raw.githubusercontent.com/ros/rosdistro/master/index-v4.yaml ERROR: error loading sources list: 	<urlopen error <urlopen error [Errno -3] Temporary failure in name resolution> (https://raw.githubusercontent.com/ros/rosdistro/master/index-v4.yaml)>
I'm fairly new to this so it might be a mistake on my part.

Error fixed by creating new microros workspace


refactor sq.gr.moran, remove pysal depend

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Breaking change (change that would cause existing functionality to not work as before)
[x] New feature (non-breaking change which adds functionality)

Description
Re-implement Moran's I to remove libpysal dependency
How has this been tested?
not yet
Closes
TODO:

[ ] add row wise transform?
[ ] improve speed ?
[ ] change docs and reference

@michalk8 implementation is really trivial see wiki and original code https://github.com/pysal/esda/blob/642880e0b49913de07e5b7fafb3dd0b5855ed2ef/esda/moran.py#L234
unfortunately, it's slower than original, not sure why. one interpretation could be that numba vectorized dot product is still slower than np.dot and the gain in permutation is lost. do you see any major performance issues? otherwise could also revert to plain numpy.
anyway, this will allow us to remove pysal+esda from dependency. top 100 genes by pysal are consistent

thanks a lot @ivirshup ! so re performance, I calculated including joblib in both cases (their original implementation and mine with numba). It's slower nonetheless. I was wondering if there is some improvement I could do on the numba code itself, I think using joblib is necessary anyway to parallelize across genes.
re theislab/scanpy#1698 yeah thanks for pointing it out, so one option is to submit this PR directly there, and wrap scanpy.metrics here. Could also wrap your implementation of geary's C there if you agree.
would like to get feedback on this from @michalk8 @hspitzer : shall we move this to scanpy metrics module and wrap it as moran here?

re scanpy#1698 yeah thanks for pointing it out, so one option is to submit this PR directly there, and wrap scanpy.metrics here. Could also wrap your implementation of geary's C there if you agree.

Whatever works for you. I think it could also make sense to have the code live both places for a bit depending on how you feel about requiring newest scanpy/ release schedules.

adata = sq.datasets.visium_hne_adata()
sq.gr.spatial_neighbors(adata)
genes = adata[:, adata.var.highly_variable].var_names.values[0:100]

# numba
sq.gr.moran(adata, genes=genes, n_jobs=1)
# time 01:30
moran_numba = adata.uns["moranI"].copy()

# switch to master, pysal
sq.gr.moran(adata, genes=genes, n_jobs=1)
# time 00:18
moran_pysal = adata.uns["moranI"].copy()

g = sns.scatterplot(moran_pysal["I"], moran_numba["I"])
g.set_xlabel("pysal")
g.set_ylabel("numba")

re moving to scanpy, brief talk with @hspitzer and she is fine with moving it there, I think with the ratio of scanpy being core of squidpy it makes sense.
We would than wrap both this and geary's c in sq.gr.moran and sq.gr.gearysc for convenience to handle spatial neighbors. How does it sounds @ivirshup @michalk8 ?

We would than wrap both this and geary's c in sq.gr.moran and sq.gr.gearysc for convenience to handle spatial neighbors. How does it sounds @ivirshup @michalk8 ?

Sounds good to me. In terms of performance, 2 things come to mind:

look at the esda implementation
switch the joblib par. loops (perms/genes instead of genes/perms)
maybe try implementing the crucial parts in Cython? not sure if there would be a speed-up

this was addressed in #317


InlineEdit:true  cell width

Hi,
I used inlineEdit:true. the cells in which I used that their width is not dynamic.
If you see in the second image below:- it should be device thickness which is not shown properly. This column has inlineEdit:true.
Data is properly shown in which I didn't use inlineEdit:true. See the 1st  image. Its showing the data properly.

Hi @sahilkatia1, I'm not sure I follow but when inline edit is set to true it will actually render an input field which by default will have different styling, so in case you want it to look/behave differently you might have to add or adjust the css.


Add render test for login

This test also checks that the user will be redirected to the dashboard if already logged in

@dissto What if I utilize a different login page class? For instance, like the one mentioned here: https://blog.jpat.dev/filament-v3-how-to-fill-login-automatically-local-environment


fix(EU): Call location details

Just did a file comparison, and the file is now identical to the one with which I've tested, as mentioned in in #47. ✅

So how are we doing on this, and can I or anyone else do anything to help get this merged? Do you need more test pilots?

I will merge.  Hoping to hear if this causes issue or solves the issue.


Error when installing from a Git repo with no tags

I tried running bbin install io.github.nextjournal/garden-cli (which I had previously installed) and got the following error:
mk@mkair ~ [1]> bbin version
bbin 0.1.9

mk@mkair ~ [1]> bbin install io.github.nextjournal/garden-cli
{:coords
 #:git{:url "https://github.com/nextjournal/garden-cli.git",
       :tag "",
       :sha ""},
 :lib io.github.nextjournal/garden-cli}
Error building classpath. Library io.github.nextjournal/garden-cli has invalid tag:
----- Error --------------------------------------------------------------------
Type:     java.io.FileNotFoundException
Message:  /Users/mk/.clojure/.cpcache/A1A0BDF8D59CA7999543C1499C00A8D9.cp (No such file or directory)
Location: /opt/homebrew/bin/bbin:589:13

----- Context ------------------------------------------------------------------
585:                   {:coords {:bbin/url (str "file://" (get-in header [:coords :local/root]))}}
586:                   header)
587:         _ (pprint header' cli-opts)
588:         _ (when-not (#{::no-lib} lib)
589:             (deps/add-deps {:deps script-deps}))
                 ^--- /Users/mk/.clojure/.cpcache/A1A0BDF8D59CA7999543C1499C00A8D9.cp (No such file or directory)
590:         script-root (fs/canonicalize (or (get-in header [:coords :local/root])
591:                                          (local-lib-path script-deps))
592:                                      {:nofollow-links true})
593:         bin-config (load-bin-config script-root)
594:         script-name (or (:as cli-opts)

----- Stack trace --------------------------------------------------------------
clojure.java.io/fn--11617                       - <built-in>
clojure.java.io/fn--11569/G--11523--11576       - <built-in>
clojure.java.io/fn--11591                       - <built-in>
clojure.java.io/fn--11530/G--11519--11537       - <built-in>
clojure.java.io/reader                          - <built-in>
... (run with --debug to see elided elements)
babashka.bbin.cli/bbin                          - /opt/homebrew/bin/bbin:825:1
babashka.bbin.cli                               - /opt/homebrew/bin/bbin:831:3
clojure.core/apply                              - <built-in>
babashka.bbin.cli                               - /opt/homebrew/bin/bbin:835:3
babashka.bbin.cli                               - /opt/homebrew/bin/bbin:833:1

It works when passing the --latest-sha param.
For when a library does not have a tag, it might be worth considering installing the latest sha instead. Alternatively the error message could be improved.

Good suggestion. I'm planning to prioritize this next when I have some time.

@rads great to see this, thank you!

@mk: No problem. It's great to see people using bbin in the wild.


[🚀 for gh-pages]:  (POC) migrate 11ty to the 2.0.0 beta version

As an ESL architect, I want to have a development environment and site to be updated to the latest tools version.
There was an 11ty 2-nd version beta release announced: https://github.com/11ty/eleventy/releases/tag/v2.0.0-beta.1
Scope

[ ] investigate and share in bounds of ESL team 11ty 2nd version major updates and breaking changes
[ ] update 11ty to the 2nd version
[ ] provide required fixes and updates on site and test environments
[ ] test updated environments

:tada: This issue has been resolved in version 4.2.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[WIP] Bugfix: Hang in visual mode when using 'I' or 'A'

Issue: When in visual block mode, and using 'I' or 'A', libvim will hang. A repro is:
(from normal mode)
vimInput("<c-v>");
vimInput("I");
Defect: This codepath uses the op_insert method, which calls the blocking edit call. We need to refactor this to a non-blocking state.
Fix: Refactor this codepath to push a state_insert_operator state, and unroll into a non-blocking codepath.

This doesn't fully implement the functionality (I'd like to use the Visual -> I/A path to start to exercise multiple cursors), but it doesn't crash now


[WIP] Migrate clasp redeploy and clasp version to inquirer functionality

Fixes #57
If you do not specify an argument, we use inquirer to ask it.

[ ] npm run test succeeds.
[ ] npm run lint succeeds.
[ ] Appropriate changes to README are included in PR.

I am not good at English.
Sorry for any inconvenience.

Sorry, I signed it now.

The work is completed.
Please review this.


rename tables in djqs

Summary
closes #1143

Test Plan

[ ] PR has an associated issue: #
[ ] make check passes
[ ] make test shows 100% unit test coverage

Deployment Plan

Thanks @sadath-12! I'll review this soon and also pull it locally to try it out.

One original assumption was that it would call the core API to post changes rather than touching the metadata db, but it can now just make changes in the metadata database directly.

I'm hoping we can stick with this assumption and avoid having one of the services directly modify metadata for another service. It's nice that this enables sharing a single postgres db for the metadata but it's still worth allowing them to be separate postgres instances if someone wants to use it that way.

@sadath-12 take a look at #1168 when you have a chance. This removes the requirement to do this rename and greatly simplifies the query service. Now it only relies on a single query table (which does not conflict with the main service). Now, based on how you want to deploy it, it can share a database instance with the core service or run on an entirely separate one.
I know this PR was meant to unblock #1140 which is also achieved by the new PR. Let's revisit that one after this refactor is merged. It should be much easier to make the changes necessary to get a good multi-tenancy setup working for you.


Pre-requisites section does not incldue the shared-cf-blobstore bucket-

The pre-requisites section of the documentation does not include details about the creation of the shared-cf-blosh-blobstore- bucket(s). These buckets are not created by the paas-cf pipeline, so should be listed in the pre-requisites section.
Further to this, because S3 bucket names are globally unique, it is not possible for any other organisation outside of GDS to use the same bucket-name format, so it would be good to be able to parametrise the shared-cf-bosh-blobstore- part of the bucket name for different organisations to be able to use paas-cf without having to fork and change code.

I think this has already been resolved. Closing.


Implement yielding of calibration events, fixes #151

@kpfrang provided me with a 400 MB file containing Calibration events (Type 2028).
Those are just container objects with a single ArrayEvent inside.
I implemented yielding them in SimTelFile
The testfile ist 7.6 MB, most of it beiing telescope definitions. @kpfrang set, he could maube produce a smaller file on monday, so it might be good to wait until then.

This pull requests should be "squashed and merged" so the larger test file does not land in master

Let's run the tests and then squash and merge


Subgraphstack

Space efficient subgraph stack implementation.

Coverage decreased (-5.1%) to 78.505% when pulling 8ccc935ed74c2c2c5103a6c4d0cf631856a7e755 on 1yay1:subgraphstack into aaa21dcf6e8fc3e7103e63c07bdde379c23e598e on thm-mni-ii:master.


Useless error message related to SwiftUI and Closures.

Describe the bug
The following SwiftUI view does not compile:

    @Binding var selection: Item?
    @State var searchText = ""

    var body: some View {
        List(selection: $selection) {
        }
        .searchable(text: $searchText)           // (1)
        .onChange(of: searchText, perform: {     // (2)
            rebuildSectionsState()
        })
    }

    func rebuildSectionsState() {}

The errors shown are (Xcode marks the first “s” of both lines):

Type '()' cannot conform to 'Equatable'
Cannot convert value of type 'String' to expected argument type '()'

Steps To Reproduce
Steps to reproduce the behavior:

Create a new SwiftUI application
Paste the code shown above.
...

Expected behavior
A clear and concise description of what is wrong.

There is nothing wrong with “.searchable(text: $searchText)”
There is nothing wrong with “searchText” or anything related to a “String”
The actual error is not mentioned by the compiler: I forgot “_ in” in the closure.

Screenshots

Environment (please fill out the following information)

OS: macOS 12.6
Xcode Version/Tag/Branch: 14.0.1

Additional context
-/-

I think the compiler is correct here and it's due to how List.init is designed in SwiftUI because there is an overload of init that accepts () -> Content and because return type of a single-expression closure is allowed to default to Void you get Content inferred as Void which results in the errors you see.

I think the compiler is correct here and it's due to how List.init is designed in SwiftUI because there is an overload of init that accepts () -> Content and because return type of a single-expression closure is allowed to default to Void you get Content inferred as Void which results in the errors you see.

I reduced the test case.
The same happens if you use List(selection: $selection) { Text("") }.listStyle(.sidebar).searchable …. In that case, searchable is called on some View.

I think it's the same overload of initializer as before though even though there is something in the body.

I just had this situation happen to me, and it was very confusing. I'm so glad I came across this issue because I wouldn't have noticed the missing "_ in". I had already made my struct conform to Equatable, and I was trying a bunch of other things to try to fix it, but "_ in" fixed it immediately. So I agree that a more informative error message is warranted.

The error message can be more clear, I also missed "_ in" and encounter this. Fixed after reading this ticket. Thanks.


Flaky test: FunctionalTests.DotNetWatcherTests.RunsWithIterationEnvVariable

This build: https://dev.azure.com/dnceng/public/_build/results?buildId=97423
Ubuntu 16.04 x64 leg failed:
[xUnit.net 00:02:57.00]     Microsoft.DotNet.Watcher.Tools.FunctionalTests.DotNetWatcherTests.RunsWithIterationEnvVariable [FAIL]
  Failed   Microsoft.DotNet.Watcher.Tools.FunctionalTests.DotNetWatcherTests.RunsWithIterationEnvVariable
  Error Message:
   System.Threading.Tasks.TaskCanceledException : A task was canceled.
  Stack Trace:
     at Microsoft.DotNet.Watcher.Tools.FunctionalTests.AwaitableProcess.GetOutputLineAsync(String predicateName, Predicate`1 predicate, CancellationToken cancellationToken) in /_/src/Tools/dotnet-watch/test/AwaitableProcess.cs:line 114
     at Microsoft.DotNet.Watcher.Tools.FunctionalTests.AwaitableProcess.GetOutputLineAsync(String message, TimeSpan timeout) in /_/src/Tools/dotnet-watch/test/AwaitableProcess.cs:line 86
     at Microsoft.DotNet.Watcher.Tools.FunctionalTests.DotNetWatcherTests.RunsWithIterationEnvVariable() in /_/src/Tools/dotnet-watch/test/DotNetWatcherTests.cs:line 44
  --- End of stack trace from previous location where exception was thrown ---
  Standard Output Messages:
   The temporary test folder is /home/vsts/work/1/s/artifacts/bin/dotnet-watch.Tests/Release/netcoreapp3.0/tmp/vmdhkmop.hvk
   Copying project /home/vsts/work/1/s/artifacts/bin/dotnet-watch.Tests/Release/netcoreapp3.0/TestProjects/KitchenSink to /home/vsts/work/1/s/artifacts/bin/dotnet-watch.Tests/Release/netcoreapp3.0/tmp/vmdhkmop.hvk/KitchenSink
   Restoring msbuild project in KitchenSink
   Project directory: '/home/vsts/work/1/s/artifacts/bin/dotnet-watch.Tests/Release/netcoreapp3.0/tmp/vmdhkmop.hvk/KitchenSink'
   Started process 28809: /home/vsts/work/1/s/.dotnet/dotnet restore
     Restoring packages for /home/vsts/work/1/s/artifacts/bin/dotnet-watch.Tests/Release/netcoreapp3.0/tmp/vmdhkmop.hvk/KitchenSink/KitchenSink.csproj...
     Generating MSBuild file /home/vsts/work/1/s/artifacts/bin/dotnet-watch.Tests/Release/netcoreapp3.0/tmp/vmdhkmop.hvk/KitchenSink/.net/obj/KitchenSink.csproj.nuget.g.props.
     Generating MSBuild file /home/vsts/work/1/s/artifacts/bin/dotnet-watch.Tests/Release/netcoreapp3.0/tmp/vmdhkmop.hvk/KitchenSink/.net/obj/KitchenSink.csproj.nuget.g.targets.
     Restore completed in 178.73 ms for /home/vsts/work/1/s/artifacts/bin/dotnet-watch.Tests/Release/netcoreapp3.0/tmp/vmdhkmop.hvk/KitchenSink/KitchenSink.csproj.

It failed on a PR that changed only an MD file, so it clearly was not related to that.

Closing as dup of https://github.com/aspnet/AspNetCore-Internal/issues/1826 now that it failed on the internal CI as well.


Add winter/sports icons/sort hat-* icons

Loosely related to #1304.
ski/snowboard alts:

scarf alts:

This PR is merged to the lab branch. This PR does not match our PR template, which requires valid use cases. To move on we merged this PR to the lab branch, which will be moved to a separate repo in the future.


need to add a timeout to deal with letsencrypt being stuck "processing" an order

Describe the bug:
This bug is a consequence of letsencrypt/boulder#3427 — sometimes an order can remain stuck in the "processing" state indefinitely.  This seems to happen during certain kinds of let's encrypt outages. cert-manager will just wait forever for the order to be processed.
Expected behaviour:
cert-manager should give up on a "processing" order after a configurable amount of time and issue a new order (a reasonable default would be 4 hours, to retry 6 times a day).
Steps to reproduce the bug:
This is not easy to reproduce since it only seems to happen when let's encrypt experiences an outage that causes outstanding orders to get stuck in processing state indefinitely.
Anything else we need to know?:
Environment details::

cert-manager version: v0.5.0
Install method: helm

/kind bug

The upcoming v0.6 release will handle this slightly better, and give you a way to 'kick' things in these instances.
Notably, it'll still sit and wait, however you can delete the corresponding Order resource (which represents the acme order that is processing) in order to trigger a retry manually.
That said, we do need to timeout automatically if an order is failing and v0.6 currently does not implement this.
We should look at extending the acmeorders controller to support this 😄

Marking this as a feature as it's not something we've supported in the past and there are known workarounds!
/kind feature
/remove-kind bug

Thanks for looking into this!  I don't really agree that this is a feature request.  cert-manager's backend (let's encrypt) can misbehave, and cert-manager doesn't handle this case gracefully, so IMO it's a bug.  Having to manually poke things to make the system retry is not really an acceptable workaround, it implies that users have to babysit their orders themselves to spot which ones are stuck to manually re-create them.  That's not really a reasonable expectation given that the whole point of cert-manager is to automate the whole process away!

/remove-lifecycle stale

So we should now handle this better - in instances where a Challenge moves into a 'final state' (e.g. expired, invalid or similar) we will mark the challenge as failed and automatically trigger a retry after backing off.
In instances where the order is stuck in a 'processing' state, we won't automatically retry the challenge as, from our point of view, the challenge is still processing. This is effectively a non-spec compliant ACME server, and in this instance came about due to a bug with the Let's Encrypt server. I think requiring user action (i.e. delete the challenge resources) in such cases is probably the desired behaviour, as working around non-compliant ACME servers would be a never-ending game of cat and mouse.
For that reason, and given the improvements we've made already with failed order handling, I think we should probably close this issue? @tsuna

I think the client has to be written defensively. It's not reasonable IMO to expect operators to manually go and delete stuck orders.
My point is that if everyone said "oh we're not going to handle this case because that would only happen when the other side doesn't comply with the spec" we'd be having way way more brittle infrastructure in general.
That's just my opinion with my SRE hat on though :P I don't have a good sense as to how hard it is to implement in order to make the code more robust.

/remove-lifecycle stale

We aren't going to take any special action to handle cases like this - if you want to get things moving again if Let's Encrypt do ever have a similar problem, you can now delete your Order resources which will be consequently recreated and the order flow will continue.
We already handle 'expired' Orders, so if the Order becomes expired, we will now also recognise this. There is a certain onus on the ACME API to perform as per the spec, and if they report it is still 'processing', we can only assume that the Order is still processing.


[Bug] add default values to assertions check

Screenshots

Description

added default values to assertions because if one of values is undefined, the statement (undefined === 0) will equal to false

Signed-off-by: Jie Peng<EMAIL_ADDRESS>
PR checklist

[x] Ensure you have added or ran the appropriate tests for your PR.
[x] DCO signed

Hmm, note for the ongoing refactor work:
* Is there a way to simplify this check?

Updated this in the refactoring branch as well.
Currently NO


Pin 3rd-party actions to SHA1

Hi!
Following the GH Action Security Hardening guide we should use the commit SHA instead of the branch or tag for any third-party untrusted action.
This PR was submitted by a script.

LGTM, can be merged, token does not have permissions.

the Actions already changed, so no need to have this PR.

@eloycoto the following actions needs to be pinned to their commit SHA:

skjolber/maven-cache-github-action@v1
<EMAIL_ADDRESS>ishworkh/docker-image-artifact-upload@v1
yogeshlonkar/wait-for-jobs@v0


ci: downgrade libc to 0.2.127 for MSRV

Similar workaround as https://github.com/PyO3/pyo3/pull/2539, but for libc - hopefully this issue doesn't keep spreading!
See the error here:
https://github.com/PyO3/pyo3/runs/7753898046?check_suite_focus=true
and here, which is why I added this to the example directories as well:
https://github.com/PyO3/pyo3/runs/7754192650?check_suite_focus=true

I think this can probably be closed as that release has been yanked.
https://github.com/rust-lang/libc/issues/2866


feat: add keep_shutter_open logic

@tlambert03 for the MDAEvent keep_shutter_open what do you think about using a logic similar to the autoshutter?
This PR gives an example of that.
Briefly, the MDASequence has a shutter_plan which is a ShutterOpenAxes class that can be used to specify the axes where the shutter should be kept open.
As the AutoFocusPlan, ShutterOpenAxes has a should_keep_open method that return True if the specified axes have changed from the previous event.
So we can simply call shutter_plan.should_keep_open(event) before yielding the event to set the MDAEvent keep_shutter_open attribute to True or False.
if shutter_plan.should_keep_open(event):
    event = event.copy(update={"keep_shutter_open": True})

that confuses me too... What does "during this event" mean?  Aren't shutters almost always open during an event?  Remember, an event tends to be a single snap.  I think what you're trying to express is that the shutter should remain open even when this event is done.  For example, if someone wanted to keep it open throughout a z stack (most common thing to do) then they would want the shutter to remain open during many events (not just one).  I think you know that, but the wording is still unclear.

On Jul 17, 2023, at 4:02 PM, federico gasparoli @.***> wrote:
@fdrgsp commented on this pull request.
In src/useq/_mda_event.py https://github.com/pymmcore-plus/useq-schema/pull/97#discussion_r1265840438:

@@ -115,6 +115,8 @@ class MDAEvent(UseqModel):
The action to perform for this event.  By default, [useq.AcquireImage][].
Example of another action is [useq.HardwareAutofocus][] which could be used
to perform a hardware autofocus.

keep_shutter_open : bool

   Keep the shutter open between during this event. By default, `False`.

it's a mistake, it should be updated as:
If True, the shutter should be kept open during this event. By default, False.
—
Reply to this email directly, view it on GitHub https://github.com/pymmcore-plus/useq-schema/pull/97#discussion_r1265840438, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMI52KDHR4R4SGFHDJK77TXQWK6LANCNFSM6AAAAAA2NL3ZP4.
You are receiving this because you were mentioned.

i think i'm ok with this.  I'm a little hesitant to keep adding "plans" to the top level of the MDASequence schema.  Since this is rather similar to autofocus (with the primary difference being it doesn't add events, it modifies events...) I'd like to think for a moment about what the general patterns are and think about whether this can be done in a slightly more general way

that confuses me too... What does "during this event" mean? Aren't shutters almost always open during an event? Remember, an event tends to be a single snap. I think what you're trying to express is that the shutter should remain open even when this event is done. For example, if someone wanted to keep it open throughout a z stack (most common thing to do) then they would want the shutter to remain open during many events (not just one). I think you know that, but the wording is still unclear.
…

Yes I agree. I thought that every event should have a keep_shutter_open bool so that an engine will check if it has to set the shutter to the open state of the closed state.
for example, in case of our pymmcore_plus engine we could use the FullPMDAEngine and have something like:
def setup_event(self, event: MDAEvent) -> None:
        ...
        if self._use_autoshutter and event.keep_shutter_open:
            self._mmc.setAutoShutter(False)
            self._mmc.setShutterOpen(True)

        self._mmc.waitForSystem()

and then, at the end of a sequence we can reset the shutter to its original state (by original I mean the state when the sequence started).
def teardown_sequence(self, sequence: MDASequence) -> None:
        """Teardown state of system (hardware, etc.) after `sequence`."""
        if self._use_autoshutter:
            self._mmc.setAutoShutter(True)
            self._mmc.setShutterOpen(False)

i think i'm ok with this. I'm a little hesitant to keep adding "plans" to the top level of the MDASequence schema. Since this is rather similar to autofocus (with the primary difference being it doesn't add events, it modifies events...) I'd like to think for a moment about what the general patterns are and think about whether this can be done in a slightly more general way

Sure! I had the same feeling but I thought it could a starting point.

Yes I agree. I thought that every event should have a keep_shutter_open bool so that an engine will check if it has to set the shutter to the open state of the closed state.

yep. I agree with all of this, my point is just that the docs are confusing.  It's not what happens during the event, it's what happens after it.   The docs here should make it super clear to someone implementing the engine exactly what they are supposed to do.  I think we're in agreement about what keep_shutter_open means, but it needs to be made clearer.  I would say "If keep_shutter_open is True, the illumination shutter should be left open after the event has been executed, otherwise it should be closed."

having another look at this... i'm not sure we want to reuse the same logic from autofocus here.  Or, maybe we do but I'm not getting it yet...  Can you give me an example of how you'd express "keep the shutter open while moving z", in a multi-channel, z stack?  Particularly because this is more of a thing that persists across events (or rather,  an instruction for how to leave the state), it feels different.
Also shouldn't we be ensuring that we're only keeping the shutter open if the "keep open" axis is the fastest moving one?  For example, you can't keep the illumination shutter open if the channel is changing.  So there appear to be more limitations here than autofocus.  In general, does it ever make sense to have the kept-open axis be slower moving than channel?

i think it would be helpful to delete the test_keep_shutter_open file and make some clearer tests, without just reusing the autofocus file.  (not sure for the sake of removing duplication, but since I'm not sure it's the same thing)

Can you give me an example of how you'd express "keep the shutter open while moving z", in a multi-channel, z stack

So basically I was thinking that if you want to have the shutter open during a z stack, then you have to specify the "z" in the shutter_plan shutter_plan={"axes":("z",)}:
running this:
s = MDASequence(
    channels=["DAPI", "FITC"],
    stage_positions=[(0,0,10)],
    shutter_plan={"axes":("z",)},
    z_plan={"range": 1.0, "step": 0.5}
)

for e in s:
    print(f"INDEX:' {e.index}, SHUTTER_OPEN: {e.keep_shutter_open}")

results in this:
INDEX: {'p': 0, 'c': 0, 'z': 0} SHUTTER_OPEN: True
INDEX: {'p': 0, 'c': 0, 'z': 1} SHUTTER_OPEN: True
INDEX: {'p': 0, 'c': 0, 'z': 2} SHUTTER_OPEN: True
INDEX: {'p': 0, 'c': 1, 'z': 0} SHUTTER_OPEN: True
INDEX: {'p': 0, 'c': 1, 'z': 1} SHUTTER_OPEN: True
INDEX: {'p': 0, 'c': 1, 'z': 2} SHUTTER_OPEN: True

because the first axes changing is the "z" axes.
if you change the axis_order to tpgzc

s = MDASequence(
    axis_order="tpgzc",
    channels=["DAPI", "FITC"],
    stage_positions=[(0,0,10)],
    shutter_plan={"axes":("z",)},
    z_plan={"range": 1.0, "step": 0.5}
)

then you get
INDEX:' {'p': 0, 'c': 0, 'z': 0}, SHUTTER_OPEN: True
INDEX:' {'p': 0, 'c': 1, 'z': 0}, SHUTTER_OPEN: False
INDEX:' {'p': 0, 'c': 0, 'z': 1}, SHUTTER_OPEN: True
INDEX:' {'p': 0, 'c': 1, 'z': 1}, SHUTTER_OPEN: False
INDEX:' {'p': 0, 'c': 0, 'z': 2}, SHUTTER_OPEN: True
INDEX:' {'p': 0, 'c': 1, 'z': 2}, SHUTTER_OPEN: False

because the first axes changing is the channel one. So in this case, if you want to have the shutter always open you just have to set the  shutter_plan axes to both ("c", "z").
This is what I thought it could make sense :) but probably there is a different logic that works!

i think it would be helpful to delete the test_keep_shutter_open file and make some clearer tests, without just reusing the autofocus file. (not sure for the sake of removing duplication, but since I'm not sure it's the same thing)

I used the same logic of the autofocus test first to have something fast to use as tests :) but also because since we have an extra autofocus event, I wanted to make sure that the shutter_plan works also during the autofocus events.

yes, but practically speaking...
INDEX: {'p': 0, 'c': 0, 'z': 0} SHUTTER_OPEN: True
INDEX: {'p': 0, 'c': 0, 'z': 1} SHUTTER_OPEN: True
INDEX: {'p': 0, 'c': 0, 'z': 2} SHUTTER_OPEN: True   # <- shouldn't this be False?
INDEX: {'p': 0, 'c': 1, 'z': 0} SHUTTER_OPEN: True
INDEX: {'p': 0, 'c': 1, 'z': 1} SHUTTER_OPEN: True
INDEX: {'p': 0, 'c': 1, 'z': 2} SHUTTER_OPEN: True   # <- shouldn't this be False?

# shouldn't these ALL be false?
INDEX:' {'p': 0, 'c': 0, 'z': 0}, SHUTTER_OPEN: True
INDEX:' {'p': 0, 'c': 1, 'z': 0}, SHUTTER_OPEN: False
INDEX:' {'p': 0, 'c': 0, 'z': 1}, SHUTTER_OPEN: True
INDEX:' {'p': 0, 'c': 1, 'z': 1}, SHUTTER_OPEN: False
INDEX:' {'p': 0, 'c': 0, 'z': 2}, SHUTTER_OPEN: True
INDEX:' {'p': 0, 'c': 1, 'z': 2}, SHUTTER_OPEN: False

i think the point here is that, unlike autofocus events, leaving the shutter open  is intrinsically linked to the channel axis.  It doesn't ever make sense to leave the shutter open if the next image can't be acquired with that same "open shutter".  So, you're predicate here really needs awareness of whether the next event is using the same channel config as the current one


Roomba 966 with Firmware 2.4.13-199 not working

Roomba Model: Roomba 966
Roomba Software Version: 2.4.13-199

According to the iRobot-App there is no available software update. the adaptor should be working with 2.4.6-3, but somehow the recognition with the 2.4.13-199 does not seem to work.
Log outputs the following:

roomba.0
2023-08-07 10:43:15.048
info
State value to set for "roomba.0.states._connected" has to be type "string" but received type "boolean"

roomba.0
2023-08-07 10:43:15.005
info
State value to set for "roomba.0.states._connected" has to be type "string" but received type "boolean"

roomba.0
2023-08-07 10:43:14.939
warn
Secure Connection to Roomba failed!

roomba.0
2023-08-07 10:43:14.938
info
Roomba Connection closed.

roomba.0
2023-08-07 10:43:14.936
warn
Connection lost! Roomba offline.

roomba.0
2023-08-07 10:43:14.696
info
Connecting to Roomba (<IP_ADDRESS>)..

roomba.0
2023-08-07 10:43:14.693
warn
Canvas not installed! Thus, no map drawings are possible. Please see installation instructions on Github (https://github.com/iobroker-community-adapters/ioBroker.roomba#installation).

roomba.0
2023-08-07 10:43:14.643
info
starting. Version 1.1.4 in /opt/iobroker/node_modules/iobroker.roomba, node: v18.16.1, js-controller: 4.0.24

host.ioBroker
2023-08-07 10:43:11.969
info
instance system.adapter.roomba.0 started with pid 1496212

Password discovery also didn't work but I could do the manual way with the dorita980-script. The instance is running with a green indicator (connected to device or service) but in Objects -> Roomba.0.states._connected it still appears as "false"
I changed the Roomba.0.stated._connected to be a bool, since then the log looks cleaner, but doesn't help with connecting to the robot.

Please see #143


FB messenger notifications come in even if messages have been read on another device.

Expected Behavior
If i respond to or view messages on another device (like my phone).  I do not want to have them pop up as notifications when I return to my computer.  It becomes quite obnoxious.
Current Behavior
when I return to computer after being away for a while I often get a barrage of notifications from facebook (through franz).
Your Environment

Franz Version used: 5.0.0-beta.17
Operating System and version: window 10 x64

Facebook (Messenger) decides when to send and not to send notifications. Unfortunately this is nothing we have any influence on.


Update carbon-deployment version

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/954003975

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/954003975
Status: success


Fixed #30732 -- Added note for SameSite settings.

Added note for CSRF_COOKIE_SAMESITE and SESSION_COOKIE_SAMESITE
below the xframe_options_exempt of the clickjacking guide.

Please target your PR to master, commiters will handle backport if necessary.


support new git:sync command

dokku 0.23 comes with a git:sync command https://github.com/dokku/dokku/pull/4297
This replaces the dokku-clone plugin; a fix for https://github.com/dokku/ansible-dokku/issues/88 is already built in.
My suggestion would be to deprecate the dokku_clone ansible module and replace the dokku_git_sync module with one that uses the dokku internals (and update the corresponding  docs to no longer point to the commercial git_sync plugin).
@josegonzalez if you would like to do any of this, please go ahead.
I might have some time next weekend

I won’t have time to contribute to non-core projects for a bit as I’m wrapping up my commercial admin tool. Feel free to take this on.

I won’t have time to contribute to non-core projects for a bit as I’m wrapping up my commercial admin tool. Feel free to take this on.


Deprecation warning from redis-namespace gem about flushdb command

When running the tests there is the following deprecation warning which is displayed:
Passing 'flushdb' command to redis as is; administrative commands cannot be effectively namespaced and should be called on the redis connection directly; passthrough has been deprecated and will be removed in redis-namespace 2.0 (at /sidekiq-cron/test/integration/performance_test.rb:10:in `block (3 levels) in <top (required)>')

This one can be closed.


LivePaginatedTable may drop updates

Odd, the logic in LivePaginatedTable.update() scans either _deferredUpdates or this.state.body, but not both, when looking for whether this row update is for a pre-existing row (versus for a new row). This can result in duplicate rows. I don't think it ever happens for the kubectl "direct" watcher; it may for the CLI-based watcher, at least in theory.
Scenario 1:
This scenario should be fine:
pre-existing rows: r1, r2, r3
batch update with r3 then r4
Scenario 2:
This scenario should result in duplicate r3 rows
pre-existing rows: r1, r2, r3
batch update with r4 then r3
because first .update() will scan state.body for r4 and find nothing (good); but then it will scan deferredUpdates for r3 and find nothing (bad!)
The fix I think is simply to scan both?

We should also document that the way to add new rows to the view (from within the PaginatedTable UI hierarchy) is not to call setState({ body }), but to update props.response.body and trigger a render in some way.


Better grammar

I'm not an english expert, but..
Say hi or type help to show commands
or
Say hi or type help to show the commands
What you think?

Hi @leocavalcante
The demo version on github is outdated and is not the same used with Gulp.


systemd-shutdown hangs on containerd-shim when k3s-agent running

Environmental Info:
K3s Version: k3s version v1.18.6+k3s1 (6f56fa1d)
Node(s) CPU architecture, OS, and Version:  x86_64 Ubuntu 20.04.1
Linux nuc-linux3 5.4.0-48-generic #52-Ubuntu SMP Thu Sep 10 10:58:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Cluster Configuration: 1 master 2 workers
Describe the bug:
When shutting down or rebooting the node, the shutdown hangs for approximately 90 seconds.  The console message is
systemd-shutdown: waiting for process: containerd-shim

When researching the problem I landed on this issue: https://github.com/drud/ddev/issues/2538#issuecomment-705079079 where they said when they uninstalled k3s the problem went away.  I disabled and stopped k3s-agent.service and rebooted and the problem also went away for me.
I also tried re-enabling and starting k3s-agent.service and removing the docker.io package and running apt autoremove to remove containerd, runc, etc. but it still hangs on reboot at the same place.

Following https://github.com/containerd/containerd/issues/386#issuecomment-304837687 I changed the service configuration for k3s.agent and k3s-agent.service to KillMode=Mixed and that fixed the problem.   This is in the standard Docker configuration.
However, I also found https://github.com/rancher/k3s/issues/1965 where it looks like this behavior is as intended.  Is there a way to allow for upgrading k3s without disrupting workloads but at the same time not hang shutdowns/reboots for 90s?

I was thinking one way to do it is to use KillMode=mixed or KillMode=control-group by default for k3s{-agent}.service and when doing an upgrade, add a drop-in in /run/systemd/system/k3s{-agent}.service.d that temporarily sets KillMode=process before stopping the service, then removes the drop-in after the upgrade.

systemd has an explicit pre-shutdown hook, so perhaps you could invoke special logic with that. See:
/usr/lib/systemd/system/shutdown.target.wants

Bump still relevant

bump same issue

notice the issue with raspberry pi with display on

I faced this issue yesterday and ended up with the following solution.
<EMAIL_ADDRESS>:
[Unit]
Description=Kill cgroup procs on shutdown for %i
DefaultDependencies=false
Before=shutdown.target umount.target
[Service]
# Instanced units are not part of system.slice for some reason
# without this, the service isn't started at shutdown
Slice=system.slice
ExecStart=/bin/bash -c 'pids=$(cat /sys/fs/cgroup/unified/system.slice/%i/cgroup.procs); echo $pids | xargs -r kill;'
ExecStart=/bin/sleep 5
ExecStart=/bin/bash -c 'pids=$(cat /sys/fs/cgroup/unified/system.slice/%i/cgroup.procs); echo $pids | xargs -r kill -9;'
Type=oneshot
[Install]
WantedBy=shutdown.target

Enable the "service" for k3s-agent.service  (will also work for k3s on the master ):
sudo systemctl enable<EMAIL_ADDRESS>
# or, on the master:  sudo systemctl enable<EMAIL_ADDRESS>
I've written a long winding explanation here but in brief, what happens is that since killmode=process is used, all the container processes end up staying alive when k3s is brought down. Which is a good thing :tm:
However, during shutdown, systemd will signal all remaining processes and wait for DefaultTimeoutStopSec for them to die.
This is always 90s during the last shutdown phase with systemd v245.
It is a bug in systemd v245 shipped with ubuntu 20.04 and was fixed in september 2020
What I used to do was to set  DefaultTimeoutStopSec=5s in /etc/systemd/system.conf and it worked fine, but on ubuntu 20.04 it doesn't.
Since there's little chance this fix will make it back into 20.04, the above "service" will perform round of SIGTERM, wait 5s, then proceed with SIGKILL to finish k3s's process cleanup during shutdown.
The sleep can be tweaked to suit your services need (something matching terminationGracePeriod perhaps)
Hope it helps.

Awesome research!

@jraby your solution helped me to resolve the issue, however I ended up using the k3s-killall.sh according to the k3s docs
# source https://github.com/k3s-io/k3s/issues/2400#issuecomment-1013798094
# $ sudo systemctl enable<EMAIL_ADDRESS>[Unit]
Description=Kill cgroup procs on shutdown for %i
DefaultDependencies=false
Before=shutdown.target umount.target
[Service]
# Instanced units are not part of system.slice for some reason
# without this, the service isn't started at shutdown
Slice=system.slice
ExecStart=/bin/bash -c "/usr/local/bin/k3s-killall.sh"
Type=oneshot
[Install]
WantedBy=shutdown.target

This is on
Linux Mint 20.2
5.4.0-91-generic

the same problem exists on rke2 (no surprise, given it's roots are in k3s)

Yes, this is by design. Stopping the K3s (or RKE2) service does not stop running containers. This is to allow for nondisruptive upgrades of the main K3s/RKE2 components by simply replacing the binary and restarting the service.

would you accept a feature request to add a systemd unit like https://github.com/k3s-io/k3s/issues/2400#issuecomment-1018472343 which only triggers on shutdown?
This would both allow the intended behaviour of k3s/rke2 (seamless updates/restarts) and allow for a shutdown/reboot that's even quicker than RKE1.
here's my non-instanced version of that:
[Unit]
Description=Kill containerd-shims on shutdown
DefaultDependencies=false
Before=shutdown.target umount.target

[Service]
ExecStart=/bin/bash -c "/usr/local/bin/rke2-killall.sh"
Type=oneshot

[Install]
WantedBy=shutdown.target

That might be a good thing to add to the documentation, for folks that want it?

Confirming this behaviour to be present with:
root@k3s:~# k3s --version
k3s version v1.23.3+k3s1 (5fb370e5)
go version go1.17.5
root@k3s:~# uname -a
Linux k3s 5.4.0-100-generic #113-Ubuntu SMP Thu Feb 3 18:43:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

This is not version-specific behavior.  As described at https://github.com/k3s-io/k3s/issues/2400#issuecomment-1040795816 by design, pods are not stopped when the systemd service is stopped.

in releases prior to 1.23.7 it was enough to add KillMode=mixed to /etc/systemd/system/k3s.service , and when system shutdown executed, k3s killed containers and computer was turned off imediately
For some reason unknown to me since 1.23.8 ---> up to current one 1.24.4 when doing so, it takes 90s again to shutdown system with k3s (... which is default systemctl timeout TimeoutStopUSec=1min 30s ... ), so KillMode mixed is ignored and k3s waits until timeout has passed to kill them ....
what has changed?
[Service]
Type=notify
EnvironmentFile=-/etc/default/%N
EnvironmentFile=-/etc/sysconfig/%N
EnvironmentFile=-/etc/systemd/system/k3s.service.env
KillMode=mixed

Probably something related to the containerd version change? I'm not sure, since changing the KillMode isn't something we test or support. I would recommend adding another unit that runs on shutdown, as described above.

Probably something related to the containerd version change? I'm not sure, since changing the KillMode isn't something we test or support. I would recommend adding another unit that runs on shutdown, as described above.

Thanks I have implemented shutdown unit as described in @horihel .
My I vote for adding this to official documentation? I believe it could be pretty common scenario, since k3s is ideal for edge deployments, and usually edge deployments get much more shutdowns then restarts.

Here is a k3s version of https://github.com/k3s-io/k3s/issues/2400#issuecomment-1041165341:
[Unit]
Description=Kill containerd-shims on shutdown
DefaultDependencies=false
Before=shutdown.target umount.target

[Service]
ExecStart=/usr/local/bin/k3s-killall.sh
Type=oneshot

[Install]
WantedBy=shutdown.target

Put the file to /etc/systemd/system/shutdown-k3s.service and then enable the service using
systemctl enable shutdown-k3s.service

Also note that this service name shutdown-k3s shall not start with k3s-, otherwise the k3s-killall.sh script would try to stop it and cause problems.

I faced this issue yesterday and ended up with the following solution.
<EMAIL_ADDRESS>:
[Unit]
Description=Kill cgroup procs on shutdown for %i
DefaultDependencies=false
Before=shutdown.target umount.target
[Service]
# Instanced units are not part of system.slice for some reason
# without this, the service isn't started at shutdown
Slice=system.slice
ExecStart=/bin/bash -c 'pids=$(cat /sys/fs/cgroup/unified/system.slice/%i/cgroup.procs); echo $pids | xargs -r kill;'
ExecStart=/bin/sleep 5
ExecStart=/bin/bash -c 'pids=$(cat /sys/fs/cgroup/unified/system.slice/%i/cgroup.procs); echo $pids | xargs -r kill -9;'
Type=oneshot
[Install]
WantedBy=shutdown.target

Enable the "service" for k3s-agent.service (will also work for k3s on the master ):
sudo systemctl enable<EMAIL_ADDRESS>
# or, on the master:  sudo systemctl enable<EMAIL_ADDRESS>
I've written a long winding explanation here but in brief, what happens is that since killmode=process is used, all the container processes end up staying alive when k3s is brought down. Which is a good thing tm
However, during shutdown, systemd will signal all remaining processes and wait for DefaultTimeoutStopSec for them to die. This is always 90s during the last shutdown phase with systemd v245. It is a bug in systemd v245 shipped with ubuntu 20.04 and was fixed in september 2020
What I used to do was to set DefaultTimeoutStopSec=5s in /etc/systemd/system.conf and it worked fine, but on ubuntu 20.04 it doesn't.
Since there's little chance this fix will make it back into 20.04, the above "service" will perform round of SIGTERM, wait 5s, then proceed with SIGKILL to finish k3s's process cleanup during shutdown. The sleep can be tweaked to suit your services need (something matching terminationGracePeriod perhaps)
Hope it helps.

This will only work with unified cgroups though as for example I don't have /sys/fs/cgroup/unified/system.slice/ to begin with. :(

I could not get the systemd unit examples above to work (on Ubuntu 22.04). Instead the following achieved it for me:
[Unit]
Description=Kill containerd-shims on shutdown
Before=k3s.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStop=/usr/local/bin/k3s-killall.sh

[Install]
WantedBy=multi-user.target

Before needs to change to k3s-agent.service on agent nodes.

Yes, good catch. You will need to adapt the example for agent nodes. The server and agent use different service names.

Before needs to change to k3s-agent.service on agent nodes.

Unless of course one uses k3s ansible role which names them both as k3s.service. :)

Here is a k3s version of #2400 (comment):
[Unit]
Description=Kill containerd-shims on shutdown
DefaultDependencies=false
Before=shutdown.target umount.target

[Service]
ExecStart=/usr/local/bin/k3s-killall.sh
Type=oneshot

[Install]
WantedBy=shutdown.target

Put the file to /etc/systemd/system/shutdown-k3s.service and then enable the service using
systemctl enable shutdown-k3s.service

Also note that this service name shutdown-k3s shall not start with k3s-, otherwise the k3s-killall.sh script would try to stop it and cause problems.

Can confirm this also works if you get the message A stop job is running for libcontainer...
If you use the k3s ansible role you need to extract k3s-killall.sh from https://github.com/k3s-io/k3s/blob/d9f40d4f5b4776164322035499fabedea77f5f52/install.sh#L666-L743


application icon broken in ubuntu 18.04 alpha dash area

What version of electron-installer-debian are you using?
0.8.1
What version of node and npm are you using?
v6.12.0/3.5.2
What operating system are you using?
Ubuntu 18.04 alpha
Can you compile the example app successfully?
yes
What did you do? Please include the configuration you are using for electron-installer-debian.
{
	"name": "daisy-sequence",
	"src": "../release/release/daisy_sequence-linux-x64/",
	"dest": "../release/release/",
	"arch": "amd64",
	"icon": "image/icon.png",
	"categories": [
		"Utility"
	],
	"lintianOverrides": [
		"changelog-file-missing-in-native-package"
	]
}

What did you expect to happen?
The application icon is displayed correctly in the Dash area on the left side of the screen
What actually happened?
Application icon is not displayed correctly
** Other **
In Ubuntu 16.04 the application icon was displayed correctly.
In Ubuntu 18.04 application search (Alt + F2), icons are displayed correctly.
(To be honest, I think that this problem is a problem that Ubuntu changed its specifications)
screenshot

icon file

Given that Ubuntu 18.04 is still under development, we really don't know what's going on.
This is very likely an Ubuntu bug rather than a bug on our side. We'll have to keep an eye on this. I'll appreciate it if you can keep testing with future releases and keeps us updated

If this problem is a Ubuntu bug, we should report a bug before it is released.
Although I can report it, I am not an English speaker, so I'm not sure I can communicate correctly.

Because I can not make it in time for release unless I keep doing anything like this, will I write a bug report for Ubuntu launchpad?

You should see if the bug exists in Ubuntu 17.10 as well. If not, file a bug at Ubuntu's issue tracker.

I've been using Ubuntu 18.04 for 2 weeks now and I can't reproduce this in any way. I'm going to close this issue. @MichinariNukazawa if you still have problems , feel free to re-open the issue with more details, and maybe a log output

I reploduction now, in Ubuntu 18.04 release (clean installed release version).
Install log output:
sudo dpkg -i --debug=20 --log=log20.log lina-dicto-english_0.1.14_amd64.deb
log20.log

I took a quick look at your repository and the problem is not with this package, it's that you never assigned an icon to the window you create in electron.
If you change index.js#L14 to look like the following:
win = new BrowserWindow({
  width: 800,
  height: 600,
  icon: 'image/icon.png'
})

And just do npm run build you will already see that your program has an icon when running on Ubuntu 18.04. With the old code, if you just did npm run build or electron . your app never had an icon, so even when packaging it, you still don't have an icon.

I solved my application problem.
Thank you.


[AMORO-2819]Spark cannot execute the "alter table set identifier field" command on tables in Iceberg format in unified catalog

Why are the changes needed?

Close #2819 .
Brief change log

Fix the issue of creating a mixed format table using "create table like".

Shade out the Iceberg classes called by the Amorok Spark extension.

The cause:  UnifiedSessionCatalog is neither SparkCatalog nor SparkSessionCatalog of Iceberg， so it doesn't  match  catalogAndIdentifier, and can't get the physical plan

solution:

copy the iceberg ExtendedDataSourceV2Strategy and override  IcebergCatalogAndIdentifier as AmoroExtendedDataSourceV2Strategy
replace ExtendedDataSourceV2Strategy with  AmoroExtendedDataSourceV2Strategy in ArcticSparkExtensions

Tips:

ArcticSparkExtensions inject arctic extension and iceberg extension, so We don't need to configure the Iceberg extension in spark.sql.extensions in the future.

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before making a pull request

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

cc @baiyangtx   PTAL

This PR may cause conflict with https://github.com/apache/amoro/pull/2849.
I suggest that we can wait #2849 is merged

i reope