Run service clients as non privileged pods

What this PR does / why we need it:
The Jobs being used to encapsulate HTTP / TCP / UDP clients that validate the functionality of Kubevirt's exposed Services
should not be run as privileged pods, or share the host's PID namespace - both of these security options require a particular SCC on Openshift, something which is not being provisioned.
The simplest way out is to provide an option to have both privileged / unprivileged pods and let the developers choose which to use according to their requirements.
In this case, the Jobs do not require to be run as privileged, hence, we can just the RenderPod function, which creates wraps the Job in an unprivileged pod.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

/assign @rmohr

Verified on kubevirt v0.36.1 running on openshift 4.7.0-0 .

@maiqueb I think the following two tests need their privileges:

2/740 Tests Failed. | expand_less
-- | --
Storage Starting a VirtualMachineInstance [rfe_id:2298][crit:medium][vendor:cnv-qe@redhat.com][level:component] With HostDisk and PVC initialization With smaller than requested PVCs [Serial][test_id:3108]Should not initialize an empty PVC with a disk.img when disk is too small even with toleration expand_more5s | Storage Starting a VirtualMachineInstance [rfe_id:2298][crit:medium][vendor:cnv-qe@redhat.com][level:component] With HostDisk and PVC initialization With smaller than requested PVCs [Serial][test_id:3108]Should not initialize an empty PVC with a disk.img when disk is too small even with toleration expand_more | 5s
Storage Starting a VirtualMachineInstance [rfe_id:2298][crit:medium][vendor:cnv-qe@redhat.com][level:component] With HostDisk and PVC initialization With smaller than requested PVCs [Serial][test_id:3108]Should not initialize an empty PVC with a disk.img when disk is too small even with toleration expand_more | 5s
Storage Starting a VirtualMachineInstance [rfe_id:2298][crit:medium][vendor:cnv-qe@redhat.com][level:component] With HostDisk and PVC initialization With smaller than requested PVCs [Serial][test_id:3109]Should initialize an empty PVC with a disk.img when disk is too small but within toleration expand_more | Storage Starting a VirtualMachineInstance [rfe_id:2298][crit:medium][vendor:cnv-qe@redhat.com][level:component] With HostDisk and PVC initialization With smaller than requested PVCs [Serial][test_id:3109]Should initialize an empty PVC with a disk.img when disk is too small but within toleration expand_more
Storage Starting a VirtualMachineInstance [rfe_id:2298][crit:medium][vendor:cnv-qe@redhat.com][level:component] With HostDisk and PVC initialization With smaller than requested PVCs [Serial][test_id:3109]Should initialize an empty PVC with a disk.img when disk is too small but within toleration expand_more

See https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/5075/pull-kubevirt-e2e-k8s-1.17/1363822144328306688

@maiqueb I think the following two tests need their privileges:

2/740 Tests Failed. | expand_less
-- | --
Storage Starting a VirtualMachineInstance [rfe_id:2298][crit:medium][vendor:cnv-qe@redhat.com][level:component] With HostDisk and PVC initialization With smaller than requested PVCs [Serial][test_id:3108]Should not initialize an empty PVC with a disk.img when disk is too small even with toleration expand_more5s | Storage Starting a VirtualMachineInstance [rfe_id:2298][crit:medium][vendor:cnv-qe@redhat.com][level:component] With HostDisk and PVC initialization With smaller than requested PVCs [Serial][test_id:3108]Should not initialize an empty PVC with a disk.img when disk is too small even with toleration expand_more | 5s
Storage Starting a VirtualMachineInstance [rfe_id:2298][crit:medium][vendor:cnv-qe@redhat.com][level:component] With HostDisk and PVC initialization With smaller than requested PVCs [Serial][test_id:3108]Should not initialize an empty PVC with a disk.img when disk is too small even with toleration expand_more | 5s
Storage Starting a VirtualMachineInstance [rfe_id:2298][crit:medium][vendor:cnv-qe@redhat.com][level:component] With HostDisk and PVC initialization With smaller than requested PVCs [Serial][test_id:3109]Should initialize an empty PVC with a disk.img when disk is too small but within toleration expand_more | Storage Starting a VirtualMachineInstance [rfe_id:2298][crit:medium][vendor:cnv-qe@redhat.com][level:component] With HostDisk and PVC initialization With smaller than requested PVCs [Serial][test_id:3109]Should initialize an empty PVC with a disk.img when disk is too small but within toleration expand_more
Storage Starting a VirtualMachineInstance [rfe_id:2298][crit:medium][vendor:cnv-qe@redhat.com][level:component] With HostDisk and PVC initialization With smaller than requested PVCs [Serial][test_id:3109]Should initialize an empty PVC with a disk.img when disk is too small but within toleration expand_more

See https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/5075/pull-kubevirt-e2e-k8s-1.17/1363822144328306688

Right, seems the container spec is immutable. Did not see that coming.

/retest

/cherry-pick v0.36.2

/cherrypick release-0.36

/cherry-pick v0.36.2

We have to pick the branch, not  the tag :)


Static Logger Binder

crash-2021-07-16_12.38.56-client.txt

Game crashes regardless of what mods installed, seemingly has a limit to how many mods can be installed before crashing

Well, in that case I'm just going to use Geyser on Velocity in the future till this issue gets fixed

Looks like a duplicate of https://github.com/GeyserMC/Geyser-Fabric/issues/22


Trailing assignments on next line are missing continuation indent in 0.43.0

Expected Behavior

I expect it to be indented
Observed Behavior

It is indenting to the same indent as the previous line (screenshot is before/after diff when running 0.43.0)

Steps to Reproduce

private val richTextSections =
  listOf(
    RichTextSection(
      chunks =
        // This gets indented back to align with the chunks name
        listOf(
          TextChunk(text = "test")
        )
    )
  )

Your Environment

Version of ktlint used: 0.43.0
Name and version (or code for custom task) of integration used (Gradle plugin, Maven plugin, command line, custom Gradle task): Spotless
Version of Gradle used (if applicable): N/A
Operating System and version: N/A
Link to your project (if it's a public repository): N/A

Actually it appears to affect everything in the expression after the assignment, not just the start of it

@ZacSweers thanks for the report. Are you able to run with the --verbose flag to confirm which rule is causing the issue?

I don't see any extra output with that flag
$ ./config/bin/ktlint -F --verbose /Users/zsweers/path/to/file.kt
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jetbrains.kotlin.com.intellij.util.ReflectionUtil (file:/Users/zsweers/dev/slack/restructure/slack-android-ng/config/bin/ktlint) to field java.lang.Throwable.backtrace
WARNING: Please consider reporting this to the maintainers of org.jetbrains.kotlin.com.intellij.util.ReflectionUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

@ZacSweers please run it w/o the -F option, then it should give the affected lines and the rule id

Ah ok, here you go
$ ./config/bin/ktlint --verbose path/to/file.kt
path/to/file.kt:67:1: Unexpected indentation (10) (should be 8) (indent)
path/to/file.kt:68:1: Unexpected indentation (12) (should be 10) (indent)
path/to/file.kt:69:1: Unexpected indentation (10) (should be 8) (indent)

This was explicitly implemented in #964. I have checked, and this is still the way that IntelliJ Ultimate formats the example. Personally, I would prefer to have the indented it as well ;-)

Wait so this is intended behavior? That can't be write, it's clearly wrong.

This was explicitly implemented in #964. I have checked, and this is still the way that IntelliJ Ultimate formats the example. Personally, I would prefer to have the indented it as well ;-)

Removing the "bug" label and add "won't fix".


Add survey api

What
In order to add the ability to take surveys in the android client we must first build out the api layer with the app
How
Add api, model and factory to prepare for surveys feature

Ooops. Yes I will add that!


ClickHouse <IP_ADDRESS> cannot start if /etc/localtime a is symlink.

Describe the bug
ClickHouse cannot start if /etc/localtime is a symlink.
How to reproduce

Build and install ClickHouse server version <IP_ADDRESS> on CentOS 7.
Run su -m -s /bin/sh clickhouse -c '/usr/bin/clickhouse-server --config-file=/etc/clickhouse-server/config.xml' (config is default)

Expected behavior
ClickHouse should start.
Error message and/or stacktrace
Logging trace to /var/log/clickhouse-server/clickhouse-server.log
Logging errors to /var/log/clickhouse-server/clickhouse-server.err.log
Logging trace to console
Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Exception: Could not determine local time zone: boost::filesystem::canonical: No such file or directory: "/etc/usr/share/zoneinfo/UTC" (version <IP_ADDRESS>)
Aborted

Additional context
/etc/localtime is a symlink on CentOS (and may be some other distros):
# ls -l /etc/localtime
lrwxrwxrwx 1 root root 25 Mar  5 17:36 /etc/localtime -> ../usr/share/zoneinfo/UTC
# strings /etc/localtime
TZif2
TZif2
UTC0

Also it looks like at least in this case time zone could be determined just reading /etc/localtime content. No need to look where symlink is pointing to.

https://github.com/yandex/ClickHouse/commit/4e1286e1e562d7ec3e7ddf51fb982a5b75359bd1
This commit didn't make it to 19.9, needs to be backported.

Done: https://github.com/yandex/ClickHouse/pull/5626

But I strongly recommend to upgrade to 19.11 instead.


Updates to zipkin-java 0.4.1, particularly docker images

Zipkin 0.4.1 obviates some duplication of configuration. It is also the
first version that's published as a docker image.
By switching to the published image of zipkin-java, we can be more
consistent, as spring-cloud-sleuth-zipkin-stream is derived from that,
not the scala query service.

cc @marcingrzejszczak suspect there's an opportunity in brewery too


Empty classes are not supported in the object mapper from org.springframework.cloud.stream.binding.BindingsLifecycleController

https://github.com/spring-cloud/spring-cloud-stream/blob/aea0e8f59110e1d3ae64affdcbdeff36a9640d60/core/spring-cloud-stream/src/main/java/org/springframework/cloud/stream/binding/BindingsLifecycleController.java#L60
Object binder should support empty classes
Proposed solution:
Solution on the particular object mapper instance it would be possible to add  objectMapper.setVisibility(PropertyAccessor.FIELD, Visibility.ANY);
Issue
Background of the issue: usage of 'bindings' endpoint for a 3.rd party spring cloud stream binder with an empty producer property as part of the configuration bean class inherited from a BinderSpecificPropertiesProvider throws an java.lang.IllegalArgumentException:
Exception stack:
Caused by: java.lang.IllegalArgumentException: No serializer found for class <......>ProducerProperties and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain: org.springframework.cloud.stream.binder.ExtendedProducerProperties["extension"]) (through reference chain: java.util.ArrayList[20]->org.springframework.cloud.stream.binder.AbstractMessageChannelBinder$1["extendedInfo"])
at com.fasterxml.jackson.databind.ObjectMapper._convert(ObjectMapper.java:4544)
at com.fasterxml.jackson.databind.ObjectMapper.convertValue(ObjectMapper.java:4475)
at org.springframework.cloud.stream.binding.BindingsLifecycleController.queryStates(BindingsLifecycleController.java:135)
at org.springframework.cloud.stream.endpoint.BindingsEndpoint.queryStates(BindingsEndpoint.java:52)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)
Limitations:
There is no access to the ProducerProperties class in question from a vendor binder.
Link to the binder class:
https://github.com/idealo/spring-cloud-stream-binder-sqs/blob/main/src/main/java/de/idealo/spring/stream/binder/sqs/properties/SqsProducerProperties.java

@mgevantmakher I think this is a reasonable request. Are you open to making this change and sending a PR?

we will do a pr,  thank you

@mgevantmakher When do you think you can work on a PR?

Our plan is to do it not later than by mid march. This issue is not abandoned.

@mgevantmakher This is just an FYI — we have a release coming up on 3/26. Please let us know if you are still planning to work on a PR. Otherwise, we can look into this.

We had some delays, if you would look into it it would be awesome, otherwise we have to postpone it.
Thank you!

I don't get it. What is the value of an empty property class?

In particular use case there was no especial value for the user but the vendor of the binder choose to implement it this way.
It would be a an easy fix that enables 3. part binder usage.


Need to handle case: selectedIndexPath

First off all i have to say this is very nice popup view (Thank you!)
Because of we can use this popup for multiple selection functions in view.
Example: use 1 picker for all case ~
button 1 - handle selection Name
button 2 - handle selection Sex
button 3 - handle selection Locations
IF
we select option 2 for case of Button 1
then we touch on Button 2 -> selection check mark will be option 2 but we(user) did not do anything
Therefore, i think we should use 1 flag for this checking: should remember last selection or not.
Anyway, we can handle this issue by create multiple picker (but i think it is not good idea enough ~from my self)
:) Thank you! This is really nice popup view.
Sorry if i have some grammar problem.

Thanks, I think the picker should clear previous selections when show is called.
BTW, no worries about your grammar, I am not a native speaker either :P.

After thinking through this, I think the best way to solve the problem would be using multiple pickerViews for each field. And there're people asking for an option for getting previously selected items, I see this as a more common need. Therefore this feature would not be added.


Fuchsia

https://fuchsia.googlesource.com/docs/+/HEAD/book.md

https://fuchsia.googlesource.com/jiri


use hack/dev/kind/install.sh in install script for e2e

we don't need ot do our own in templates we can just reuse that script.
Signed-off-by: Chmouel Boudjnah<EMAIL_ADDRESS>Changes

Submitter Checklist

[ ] ♽  Run make test lint before submitting a PR (ie: with pre-commit, no need to waste CPU cycle on CI
[ ] 📖 If you are adding a user facing feature or make a change of the behavior, please verify that you have documented it
[ ] 🧪 100% coverage is not a target but most of the time we would rather have a unit test if you make a code change.
[ ] 🎁 If that's something that is possible to do please ensure to check if we can add a e2e test.
[ ] 🔎 If there is a flakiness in the CI tests then don't necessary ignore it, better get the flakyness fixed before merging or if that's not possible there is a good reason to bypass it. (token rate limitation may be a good reason to skip).

seems to work now, had to push to main because not sure why action doesn't pickup pr changes,


fix: issue where couldn't annotate with CurrencyComparableValue

What I did
It was pointed out there may be some issues with CurrencyValueComparable when used in Pydantic models.
I was able to reproduce a serialization issue when the type the annotated field.
How I did it
Implement a custom serializer in the type that treats it like a normal int
How to verify it

Checklist

[ ] All changes are completed
[ ] New test cases have been added
[ ] Documentation has been updated

Sounds like the pydantic issue is going to take a while. Can we get a model or field serializer on BaseContractLog that handles the original situation?
This is what I tested that works, but it's probably not really what we want:
    @model_serializer
    def ser_model(self) -> dict[str, Any]:
        def ser_arg(v):
            if isinstance(v, int):
                return int(v)
            return v

        return {
            "event_name": self.event_name,
            "contract_address": self.contract_address,
            "event_arguments": {k: ser_arg(v) for k, v in self.event_arguments.items()},
        }

Bet you have a better idea.

I was having issues with bytes types (even HexBytes) when using mode="json" is the model_dump(). No matter what I did (e.g. make them hex-strings), I still get invalid codec issues... which is very annoying because it's like wtf is the point of a serializer if I can't handle that, but I am guessing dict[str, Any] is just too open-ended for the Pydantic framework. UGh, so annoying... In any case, this PR fixes like 5 bugs.

@mikeshultz  let me know if this resolves your issue

@mikeshultz let me know if this resolves your issue

Looks good. Thanks for getting the temporary fix in.


Add files via upload

https://www.rutgersprep.org/
https://www.rutgersprep.org/academics/upper-school

@ma33r Pull request merged. Thank you!


DictionaryForNode out of memory

when searchWithXPathQuery for "//p"，there is a lot of "//p" caused out of memory。 when I update hpple for latest，it also happens. Could give any help? this is the html file caused crashed
crash.txt

Hi, I just want to help you. When I download crash.txt, I do not find any p tag. Could you check it again?


ioSender way to translate?

I translated the .csv file and submit it to you?

Why do you mention the "translation.txt" file again? Submit the translated .csv file to you, and then you use it to generate the translation.txt file? The program ends up reading the translation.txt file? Is that what you mean?


Chatterino2 on Fedora - floating point exception while connecting(?) to chat

Describe the bug

When joining a chat, program generates floating point exception
To reproduce

Join the chat and wait for a message
Screenshots

Chatterino version

2.2.2
Operating system

Fedora 33
Additional information

backtrace from crashed thread
0: std::__detail::_Map_base<chatterino::ColorType, std::pair<chatterino::ColorType const, std::shared_ptr<QColor> >, std::allocator<std::pair<chatterino::ColorType const, std::shared_ptr<QColor> > >, std::__detail::_Select1st, std::equal_to<chatterino::ColorType>, std::hash<chatterino::ColorType>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true>, true>::at(chatterino::ColorType const&)
1: chatterino::ColorProvider::color(chatterino::ColorType) const
2: chatterino::SharedMessageBuilder::parseHighlights()
3: chatterino::TwitchMessageBuilder::build()
4: chatterino::Outcome chatterino::TwitchChannel::loadRecentMessages()::{lambda(auto:1)#1}::operator()<chatterino::NetworkResult>(chatterino::NetworkResult) const
5: std::_Function_handler<chatterino::Outcome (chatterino::NetworkResult), chatterino::TwitchChannel::loadRecentMessages()::{lambda(auto:1)#1}>::_M_invoke(std::_Any_data const&, chatterino::NetworkResult&&) [clone .lto_priv.0]
6: QtConcurrent::StoredFunctorCall0<void, chatterino::loadUncached(std::shared_ptr<chatterino::NetworkData> const&)::{lambda()#1}::operator()()::{lambda()#3}::operator()()::{lambda()#2}>::runFunctor()
7: non-virtual thunk to QtConcurrent::RunFunctionTask<void>::run()

Pretty much identical to https://github.com/Chatterino/chatterino2/issues/2355, with the difference that the reporter compiled Chatterino themselves (notably with -flto).
How did you install Chatterino on your system? Compiled yourself, AppImage, distro package manager?

installed via dnf

It's an issue with fedora's package of chatterino, install from source or use the appimage instead.

@ilyazzz
well its a workaround - ty for that.
its stated on the offical webpage we should use dnf install chatterino2 on Fedora.
you should remove it from there or fix it - as currently i would flag it as broken.

you should remove it from there or fix it - as currently i would flag it as broken.

If it actually is a problem with the Fedora package (which it seems to be when a source-install works fine), that would be the task for the package maintainer, not the upstream developers.
Have you reported this issue on the Fedora bug tracker already?

i get you.
still its on YOUR documentation as the way to go.
no i didnt report it yet.
you know your maintainer?

I was referring to the "fix it" part.
Not sure what you mean by "our" maintainer but the Fedora package maintainer is listed on the official Fedora package page.

@fourtf could you also add a link to https://flathub.org/apps/details/com.chatterino.chatterino on that page?

It is fixed with 2.3.1 on Fedora 34

It is fixed with 2.3.1 on Fedora 34

If reoccurs, feel free to comment below and reopen :+1:


[lit-next] Add reactive controller -> hooks adapter to labs

Some subset of reactive controllers will depend only on the generic ReactiveControllerHost interface and not specifics of that host being a LitElement. These types of controllers can probably be wrapped into React hooks, making them a lower-level primitive for code sharing across frameworks and web components.
To make a hook wrapper we need to create and store a controller instance with useState, trigger the controller lifecycle via the built-in React hooks, and possibly allow mapping any OOP (property/method) APIs on the controller to hook function arguments and return values for more idiomatic hooks.

cc @Westbrook and @benjamind if you have any ideas for a type of controller to make sure works with this pattern, let us know!

cc @Westbrook and @benjamind if you have any ideas for a type of controller to make sure works with this pattern, let us know!

Following along here. Just thought I should note one thing you'll need to watch out for in the React wrapper: concurrent mode. It's not safe to mutate objects used in React components, especially in concurrent mode, as multiple versions of a component tree may be active at a time. I think either immutable state will need to somehow be stored in useState rather than as instance properties on the controller class, or perhaps something with useMutableSource, though I haven't looked too deeply into that myself. Looks like it might require some kind of deep clone, however, which would probably be expensive.

Following along here. Just thought I should note one thing you'll need to watch out for in the React wrapper: concurrent mode. It's not safe to mutate objects used in React components, especially in concurrent mode, as multiple versions of a component tree may be active at a time. I think either immutable state will need to somehow be stored in useState rather than as instance properties on the controller class, or perhaps something with useMutableSource, though I haven't looked too deeply into that myself. Looks like it might require some kind of deep clone, however, which would probably be expensive.

Thanks for the pointer to useMutableSource!
Snapshotting looks like a complication, but maybe tractable much of the time. Most controllers will be simple class instances: just instance properties + a prototype. Cloning/snapshotting those will not inherently be more expensive than any other object. I suspect that most complications in snapshotting are going to be around libraries the controllers wrap, ie if you use a spring library it has to have cloneable spring state (though I suspect it's not worth worrying about in some cases because tearing either isn't noticeable, or the tearing behavior is arguably more correct).
It seems like the most general approach is going to involve letting the hook wrapper call customize the behavior: map arguments to ctor arguments or instance calls, map the instance to a return value, and potentially get a snapshot or something even more general than that that would let the author bring their own strategy - iow, not bake in useMutableSource support directly.

Thanks for the pointer to useMutableSource!
Snapshotting looks like a complication, but maybe tractable much of the time. Most controllers will be simple class instances: just instance properties + a prototype. Cloning/snapshotting those will not inherently be more expensive than any other object. I suspect that most complications in snapshotting are going to be around libraries the controllers wrap, ie if you use a spring library it has to have cloneable spring state (though I suspect it's not worth worrying about in some cases because tearing either isn't noticeable, or the tearing behavior is arguably more correct).
It seems like the most general approach is going to involve letting the hook wrapper call customize the behavior: map arguments to ctor arguments or instance calls, map the instance to a return value, and potentially get a snapshot or something even more general than that that would let the author bring their own strategy - iow, not bake in useMutableSource support directly.


UPDATE README AND UPLOAD MISTRAL AND LLAMA3 NIM notebooks

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

It looks like 99% of the code can be reused, can we use this way https://saturncloud.io/blog/how-to-import-jupyter-notebooks-to-another-jupyter-notebook/ to avoid having too much duplication?
Please align the filename format.

Please explain a bit the purpose of having an NGC_API_KEY if the image is pulled from ECR.
Please check if we can use boto3 instead of calling subprocess for aws cli

Please explain a bit the purpose of having an NGC_API_KEY if the image is pulled from ECR.
completed
Please check if we can use boto3 instead of calling subprocess for aws cli
we need the subprocess for cli to tag and push the image to ecr so we aren't able to use boto3

It looks like 99% of the code can be reused, can we use this way https://saturncloud.io/blog/how-to-import-jupyter-notebooks-to-another-jupyter-notebook/ to avoid having too much duplication?
Please align the filename format.
completed


order of observations

I've been testing AdlerPlanetoid on the RSP and I have noticed that the observations returned by construct_from_SQL and construct_from_RSP are not in time order. Also the two methods return observations in different orders. Not sure what they are ordered by (if anything).
This is probably an RSP/DP0.3 issue, but logging here to avoid any gotchas later on.

Curious and moderately concerning. Thanks for bringing this up.
For consistency at the very least, I should implement something that sorts the retrieved data table on time of observation, before the dataclass attributes are populated. Then we can at least be sure everything is in date order.


Add asdf installer

asdf is a popular tool that helps a bit with the management of the languages (which brew doesn't give us a good solution for it, at least in MacOS)
Would be nice to have an asdf plugin for managing Deno

There already seems to be one https://github.com/johnlayton/valdastreet

Found this one as well. https://github.com/asdf-community/asdf-deno

The above @johnlayton's plugin seems to be official one now. https://github.com/asdf-vm/asdf-plugins/pull/104


Enhancement:  Extend the teams app list to retrieve Teams info based on teamName

The command currently lists apps from the Microsoft Teams app catalog or apps installed in the specified team with an option to pass teamId in which case the command lists apps installed in the specified Microsoft Teams team.
Extend this to pass teamName as well, passing either teamId or teamName but not both.
If we find multiple items matching the teamName, return an error with the list of matching items and their IDs to disambiguate.

Good idea @rabwill 💡
Rather than using displayName, shall we use teamName instead?
I say this as we are using teamName in the spec for https://github.com/pnp/cli-microsoft365/issues/1804 so this keeps the options consistent.

Good suggestion both @rabwill and @garrytrinder. We should use teamName to align with other commands and to make it clear that the name refers to a team rather than the app.

@garrytrinder @waldekmastykarz spec update to teamName. Good catch ☺👏🏾

Hi @garrytrinder @garrytrinder @waldekmastykarz
Can I take this up?

All yours @nanddeepn thanks for the help 👍🏻


cmd/go: deprecate the -i flag

go build, go install, and go test accept the -i flag. From go help build:

The -i flag installs the packages that are dependencies of the target.

For example, if you run go build -i example.com/a, and example.com/x imports example.com/y, go build installs the file $GOPATH/pkg/$GOOS_$GOARCH/example.com/y.a.
This was useful for speeding up builds before Go 1.10, since previously installed packages didn't need to be recompiled. go build re-used packages installed in $GOPATH/pkg.
Go 1.10 introduced the build cache, so the $GOPATH/pkg directory is largely obsolete. Compiled packages are now stored in $GOCACHE. The -i flag merely copies files out of the build cache, so there's no longer any performance advantage.
The -i can cause errors when a target directory is not writable, as in #37962. In that issue, VSCode installed tools with -i, which caused errors when $GOROOT/pkg was not writable (common when Go is installed system-wide with an installer). Something caused runtime/cgo to be recompiled (perhaps a new clang version or flag), but it couldn't be written to $GOROOT/pkg/darwin_amd64/runtime/cgo.a.
Because of these problems, we should consider deprecating and eventually removing the -i flag.

cc @bcmills @matloob @rsc

Are there any objections to doing this? I see plenty of emoji in favor and nothing else.

My only potential objection is breaking people who learned to use go build -i years ago, and perhaps introduced the flag in build or CI scripts. So the eventual removal of support for -i should come with a clear deprecation warning in the release changelog at least one or two releases before then.

@mvdan, yes, deprecate and remove means it will have a release of printing a warning that -i is going away followed by the actual removal in the next release.

Based on the discussion above, this seems like a likely accept.
To be clear, Go 1.16 would warn that the flag should not be used (but still complete successfully), and Go 1.17 would remove the flag.

No change in consensus, so accepted.

It just occurred to me that sometimes I still used go test -i -v ./... to see what packages were being built in advance of running tests.
I guess I can move to go test -run=- -v ./... nowadays, but I thought I'd point that out as a reasonable use case.

@mvdan, is there a way to use the -c flag to get the information you want?
(Perhaps go test -c -v -o /dev/null ./...?)

Doesn't seem like I can use -c with many packages at once, which makes sense.
For clarity, what I liked about go test -i -v ./... is that I could see the stream of packages being built. This is useful if go test ./... suddenly seems to take a long time to start running tests, for example after someone adds a large cgo dependency like go-sqlite3. Seeing the stream of packages being built, one would see the progress stuck at that package for more than ten seconds, which is a pretty clear signal.
But maybe there are better ways to inspect what's being a bottleneck in a Go build :) There's go list -test -deps ./..., but that simply lists packages, it doesn't perform a build or tell me what packages are the slowest to build.
go list -test -export -v ./... is pretty close, though; -export means building the packages, -test pulls in test deps, and -v prints packages as they are being built.


Support for use as a javascript module

After having tried and failed, but it would be helpful if I could use buildinginstructions.js files as a javascript modules with an "import" command. I'm willing to admit maybe it's my lack of technical understanding and this is already possible so any pointers would also be helpful.

Nope. You are right. three.js has also moved in that direction now, so it is something that should be done.
It will also allow for pruning of three.js, so that the JS files can become smaller (and faster).


Unable to send message using MessageSender and user-assigned managed identity

Query/Question
How can I use the user-assigned managed identity to connect to the service bus queue/topic?
Environment:
I've used the following packages in a .NET 3.1 console application to test it out

Microsoft.Azure.ServiceBus v5.1.3
Microsoft.Azure.Services.AppAuthentication v1.6.1
Running on Windows 10 with Visual Studio Professional 2019 v16.9.2

Azure setup

Created a service bus namespace and queue
Created a user-assigned managed identity and client-id is debd8176-910a-4cc1-887e-fc89ac72e8a6. The user-assigned managed identity is being added to the service bus namespace identity
Gave Azure Service Bus Data Owner of the service bus namespace to the user-assigned managed identity

Local Dev environment

Created a system environment variable AzureServicesAuthConnectionString and set the value RunAs=App;AppId=debd8176-910a-4cc1-887e-fc89ac72e8a6

Code Sample
using System;
using System.Text;
using Microsoft.Azure.ServiceBus;
using Microsoft.Azure.ServiceBus.Core;
using Microsoft.Azure.ServiceBus.Primitives;

namespace UATester
{
    class Program
    {
        static void Main(string[] args)
        {
            string _connectionString = "sb://sbtest.servicebus.windows.net/";
            string _queueName = "test-queue";

            var tokenProvider = TokenProvider.CreateManagedIdentityTokenProvider();
            MessageSender _sender = new MessageSender(_connectionString, _queueName, tokenProvider);

            Message _message = new Message(Encoding.UTF8.GetBytes(Guid.NewGuid().ToString()));
            _sender.SendAsync(_message).GetAwaiter().GetResult();
            _sender.CloseAsync().GetAwaiter().GetResult();

            Console.WriteLine("Message Sent...");
        }
    }
}

Error details
While running the code, I'm getting the following error message
Microsoft.Azure.Services.AppAuthentication.AzureServiceTokenProviderException: 'Parameters: Connection String: RunAs=App;AppId=debd8176-910a-4cc1-887e-fc89ac72e8a6, Resource: https://servicebus.azure.net/, Authority: . Exception Message: Tried to get token using Managed Service Identity. Access token could not be acquired. Failed after 5 retries. MSI ResponseCode: NotFound, Response: <?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
                "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

  <title>404 - Not Found</title>

404 - Not Found

'

Can you please help me to find out why I cannot connect to the service bus queue locally using a user-assigned managed identity?

//cc: @shankarsama

Thank you for your feedback.  Tagging and routing to the team best able to assist.

Hi Team,
Please let me know if you have any updates on this. I'm looking for help on how to debug the code locally while using user-assigned managed identity to connect to service bus queue.
Any help is really appreciated.
Thanks
Subhendu

Hey @subhendu-de
Please note, a newer package Azure.Messaging.ServiceBus is available as of November 2020. While the older package Microsoft.Azure.ServiceBus will continue to receive critical bug fixes, we strongly encourage you to upgrade. Read the migration guide at https://aka.ms/azsdk/net/migrate/sb for more details.
In the newer Azure.Messaging.ServiceBus, you can pass in the credential objects from the Azure.Identity package. We have a code snippet that shows how you can use your user assigned managed identity too.
@DorothySun216,
Can you provide input on whether user-assigned managed identity is supported in the Microsoft.Azure.ServiceBus package?


stop publishing .asc.${checksums} to Central repository

Expected Behavior
.asc files are published to Maven Central without .asc.${checksum}
Current Behavior
for example: https://repo1.maven.org/maven2/org/junit/jupiter/junit-jupiter/5.8.2/
junit-jupiter-5.8.2-javadoc.jar.asc.md5
junit-jupiter-5.8.2-javadoc.jar.asc.sha1
junit-jupiter-5.8.2-javadoc.jar.asc.sha256
junit-jupiter-5.8.2-javadoc.jar.asc.sha512
and same for each .ascfile
Context
currently, for each artifact published to Central repository, there are many additional files published: checksums and signature
see for example: https://repo1.maven.org/maven2/org/junit/jupiter/junit-jupiter/5.8.2/
most of the files that I see follow expected Maven2 repository layout: https://maven.apache.org/repository/layout.html perfect
there is only one series of checksum files that I'm surprised of: each .asc file is currently complemented by checksum files .asc.md5+.asc.sha1+.asc.sha256+.asc.sha512
These files are not a Central requirement: see for example https://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/3.4.1/
Is there a deliberate choice to add checksums for .asc files? Are these checksums found useful for something that I did not imagine?
I'd personally would think that these files should not be published.
Steps to Reproduce
publish a release to Maven Central
Your Environment

I agree it makes no sense to have checksums for PGP signatures.
Do you have an official reference that mentions which files need checksums and which do not?
https://central.sonatype.org/publish/requirements/ does not seem to clarify the requirements regarding the checksums.

in fact, there is no reference for "what not to do" :)
but the reference is https://maven.apache.org/repository/layout.html for the layout

@hboutemy , I am afraid you are slightly off here.
Maven is the tool, and Sonatype OSSRH (aka Central) is the repository that hosts artifacts. It is up to the repository to define rules and policies.
The tool should just obey the rules.
For instance, Maven as a tool can't really declare policies "who can publish artifacts under org.postgresql:postgresql coordinates". On the other hand, Central can declare rules like "every artifact must come with PGP signature in a form or .asc file, and the public key must exist on one of the ... keyservers".
That is why the Maven repository layout has absolutely no power here.

Apparently, Central requires PGP signatures: https://central.sonatype.org/publish/requirements/#sign-files-with-gpgpgp

All files deployed need to be signed with GPG/PGP and a .asc file containing the signature must be included for each file.

It has nothing to do with Maven, and there are repositories that do not really require PGP signatures when publishing artifacts.
That is why I believe, Gradle should not change the behavior at random, and Central repository should clarify exact requirements so everybody can follow.

Here's a real-life example where Cental artifacts miss PGP signatures:
https://repo.maven.apache.org/maven2/org/ow2/asm/asm/7.1/
The missing .asc files are caused by the fact that asm is published via synchronization from ow2 Nexus instance which does not really have .asc requirements.
https://gitlab.ow2.org/asm/asm/-/issues/317878

you're right, you're just ignoring the fact that the Maven tool and its central repository existed before the repository was externalized from Maven and its rules written with best efforts. I know that I point to Maven site, but the general repository layout has been defined by Maven (and works because it's quite extensible given classifiers and extensions are not predefined).
The way the rules are defined does not block additional unnecessary files that don't break the rules: for example
.asc.${checksum}, or .${checksum}.${checksum} (= something that happens at Maven build tool level for reasons beyond this discussion).
it's only today that we're reading back the requirements more in-depth and finding some undocumented parts, when trying to fully abstract from its Maven origins: reading your feedback, I'm just discovering an obvious missing part in https://central.sonatype.org/publish/requirements/ = there is nothing written about checksums (lol!)
thinking at it, I know the reason: because .md5 and .sha1 were part of Maven2 repository layout requirement, then obvious in a Maven context
and it was "obvious" when writing

All files deployed need to be signed with GPG/PGP and a .asc file containing the signature must be included for each file

that the .asc signature was not a "normal" file that was required to follow rules (= have checksums and a .asc signature file)
You're right that it should be documented: let's do it, open an OSSRH or MVNCENTRAL Jira issue and improve
Back to the Gradle publication plugin: just looking at an example https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.4.1/ shows that .asc files don't require checksums in real world
FYI, when looking for an example, I looked at Ant artifacts and found that the .asc.${checksum} files were also provided: https://repo.maven.apache.org/maven2/org/apache/ant/ant/1.10.9/ . Gradle is not the only tool suffering from the direct reading of the incomplete rules :)

https://central.sonatype.org/publish/requirements/ = there is nothing written about checksums (lol!)

Exactly. Central needs to publish the requirements in the first place.

https://issues.sonatype.org/browse/NEXUS-8213
It might be the case that Central behaviour regarding checksums for signatures has changed in 2013...

Thanks for the report. It's not breaking anyone, so it's unlikely to be fixed in a timely fashion unless someone from the community provides a fix.

For reference, here's the relevant code that publishes checksums: https://github.com/gradle/gradle/blob/8e0e8e442c411c212f305ac87a1df8c5b4bcc370/subprojects/maven/src/main/java/org/gradle/api/publish/maven/internal/publisher/AbstractMavenPublisher.java#L238-L244
I guess the hardest issue is to figure out how to make checksum publishing configurable.
I can easily imagine there might be maven repositories that require checksums for all the files, so issue is to design a proper configuration for the set of generated and published checksums.
For instance, someone might want to skip md5.

It's not breaking anyone, so it's unlikely to be fixed

It does multiply the number of files in the repository which causes issue when adding sigstore signatures.
For instance, if you add sigstore signature for all the files, you add .asc and .sha... for all of them, so avoiding checksums for .asc is a clever way to keep the number of published files sane.

I agree it makes no sense to have checksums for PGP signatures.

I'm not convinced by that. Checksums exist to validate downloaded files have not been corrupted during transport which also applies to signature files. If a signature file got corrupted during transport, verifying the signature of the corresponding artifact would yield a misleading error message, would it not?

do you really have much transport corruption with https?

I've made a project that demonstrates this.
https://github.com/aSemy/examples-gradle-signing-bugged
signing-bug.zip

https://central.sonatype.org/publish/requirements/ = there is nothing written about checksums (lol!)

Exactly. Central needs to publish the requirements in the first place.
https://issues.sonatype.org/browse/NEXUS-8213
It might be the case that Central behaviour regarding checksums for signatures has changed in 2013...

The documentation says checksums aren't required for *.asc files, nor vice-versa.

Notice that .asc files don't need any additional checksum file, nor checksum files don't need
.asc signature file.

I wonder what happends if the main artifact is named like test.asc where asc stands for Android System Command.
Would Central attempt to parse that test.asc as a PGP signature? Would it require the file to have test.asc.asc PGP signature?
Have anyone tried that?

any updates on this, kind of annoying to be honest


fix crash in js_typed_array_slice caused by memory overlap

Use memmove instead of memcpy for safe.
Fixes: https://github.com/quickjs-ng/quickjs/issues/378

Cn you add a test please?

Ok, I added the test in test_builtin.js.

Cn you add a test please?

Ok, I added the test in test_builtin.js.

Excellent!


refactor: Delete seed phrase API

Current dependencies on/for this PR:

main

PR #2558   👈

This comment was auto-generated by Graphite.


Ensure mailchip and google analytics is installed and works correctly

All works, just needs reassurance it continuously works


Update LICENSE

Hi there!
Noticing your license is missing some details. This PR seeks to add the "When" and "who.

Thanks, this should probably go to the dev branch, not to master.


Add rb-allocator

This PR adds a wrapper around the Rust system allocator which reports memory usage back to the Ruby GC. This means that Ruby will have an accurate representation of Rust's memory usage, and thus know when to GC.
This crate exports, one type, RbAllocator, which implements the GlobalAlloc trait. It is a simple wrapper over the system allocator which reports memory usage to Ruby using rb_gc_adjust_memory_usage.
cc: @macournoyer @dylanahsmith

IIRC, Windows does not have support for atomic.h, so not sure if rb_gc_adjust_memory_usage would work. Going to disable on Windows unless someone has a better idea!

It looks like Ruby actually exports malloc, free, etc functions as part of its API, I wonder if you could take this idea to the next level and wrap Ruby's actual allocator.

Ruby is really just wrapping the system allocator too.  That seems like the simpler solution, so perhaps that would result in some sort of incompatibility.  Was this not done to avoid raising a NoMemoryError when allocation fails?

Ruby is really just wrapping the system allocator too. That seems like the simpler solution, so perhaps that would result in some sort of incompatibility. Was this not done to avoid raising a NoMemoryError when allocation fails?

I was thinking of (but didn't actually put it in my last comment 🤷) cases where Ruby's been built with jemalloc, there's a Ruby configure script flag for this.

A concern with invoking the ruby GC through the rust allocator is that it would add a lot of places where the GC could be invoked, which could result in issues from implicit aliasing that the rust compiler isn't aware of.
The GC being invoked means that the mark function for ruby data objects will be called, which could result in internal collections (e.g. Vec) being iterated.  Semantically, this is a read-only borrow reference, except it isn't made explicitly, so the rust borrow checker won't check for conflicts.  For instance, if a rust allocation is made while doing a mutable iteration over one of these collections, then doing a GC in this rust allocation hook would result in this usage being unsafe.
There is also the concern of making sure any ruby objects data being referenced is done with that ruby object being rooted.  E.g. if there is a reference to a string's bytes, then there needs to also be another reference to the ruby object that owns it that will be marked.
These reentrancy concerns are already concerns to be aware of when making calls to MRI C functions, but doing so for rust allocations makes it even more implicit.
An alternative would be to accumulate a memory usage delta in the impl GlobalAlloc for RbAllocator trait functions without calling rb_gc_adjust_memory_usage and expose a separate function on RbAllocator to manually call rb_gc_adjust_memory_usage with the accumulated delta if it isn't 0.  It would be nice to get this feature for free without users of the library having to think about it, but doing so by making it hard to write memory safe code seems counter to the reason why users would want to choose to write their ruby extension in rust.  It would still be easier to use in rust code expected to allocate/free memory compared to trying to calculate the delta and use rb_gc_adjust_memory_usage directly.

The GC being invoked means that the mark function for ruby data objects will be called, which could result in internal collections (e.g. Vec) being iterated. Semantically, this is a read-only borrow reference, except it isn't made explicitly, so the rust borrow checker won't check for conflicts. For instance, if a rust allocation is made while doing a mutable iteration over one of these collections, then doing a GC in this rust allocation hook would result in this usage being unsafe.

I think if I'm understanding correctly, then this is an example of what you're talking about, written using Magnus:
use std::cell::RefCell;

use magnus::{
    define_class, function, gc, method, DataTypeFunctions, Error, Module, Object, TypedData, Value,
};

#[derive(TypedData)]
#[magnus(class = "Vec", mark)]
struct RbVec(RefCell<Vec<Value>>);

impl DataTypeFunctions for RbVec {
    fn mark(&self) {
        // this will panic (in the middle of the garbage collector!) if
        // somewhere else has a `borrow_mut` still live.
        // `try_borrow` is of no use as we *must* mark the contents of the
        // vec, otherwise it could be GC'd
        gc::mark_slice(&self.0.borrow())
    }
}

impl RbVec {
    fn new() -> Self {
        Self(RefCell::new(Vec::new()))
    }

    fn push(&self, value: Value) {
        // This will allocate if the Vec needs to be resized, if allocation
        // triggers GC then `<RbVec as DataTypeFunctions>::mark` will be called
        // with the RefCell still mutably borrowed.
        self.0.borrow_mut().push(value)
    }
}

#[magnus::init]
fn init() -> Result<(), Error> {
    let class = define_class("Vec", Default::default())?;
    class.define_singleton_method("new", function!(RbVec::new, 0));
    class.define_method("push", method!(RbVec::push, 1));
    Ok(())
}

With Magnus once a Rust value is wrapped in a Ruby object Ruby will own that value. Magnus will only ever give you back a non-mutable reference, so you have to wrap the value in a type like RefCef to get mutability. In this case RefCef is doing the borrow checking at runtime, and could panic in the middle of GC. Panicking across FFI boundaries is undefined behaviour, so I'm going to adjust Magnus to catch the panic and abort for any case where code panics in the mark function.
Sorry @ianks for hijacking this thread with this diversion into Magnus stuff. Hopefully it's at least a useful illustration.
Thanks @dylanahsmith for outlining this edge case and helping me catch something I missed.

Yes, that example is a useful more concrete example of the problem, which illustrates how easily the problem can occur.

So if I'm understanding this correctly, maybe we can trigger dont_gc_on at the beginning of the allocation, so that ruby will not attempt to GC during the allocation.
Obviously this isn't ideal, as it will not give ruby the chance to free up memory when rust allocates, but that's how things would work without this patch. However, ruby would have an accurate depiction of memory usage so it could free objects whenever an allocation is triggered outside of Rust.
Does this seam reasonable?

I don't think dont_gc_on is part of Ruby's public API. There's rb_gc_disable, but if you follow through the code that ends up finishing up the mark & sweep phases of the GC if they are being done incrementally, and that'll end up triggering exactly the thing you'd be trying to prevent.
I experimented with this using the code above, and it does trigger the error, really easily.

I then tried with rb_gc_adjust_memory_usage, and I just can't get it to cause the problem.
Looking at the code for rb_gc_adjust_memory_usage again, rb_gc_adjust_memory_usage calls objspace_malloc_increase that calls objspace_malloc_increase_body which can start GC, but it only does so when the type argument is MEMOP_TYPE_MALLOC. rb_gc_adjust_memory_usage passes MEMOP_TYPE_REALLOC for type, so it won't trigger GC.
So, as far as I can tell, your original version with rb_gc_adjust_memory_usage is actually ok.

It might be worth also wrapping the alloc_zeroed and realloc functions of GlobalAlloc. By default the trait implements them in terms of alloc and dealloc, but it's possible allocators are providing their own optimised implementation. By not implementing them in your wrapper you'd be skipping those potential optimisations.

I then tried with rb_gc_adjust_memory_usage, and I just can't get it to cause the problem.
Looking at the code for rb_gc_adjust_memory_usage again, rb_gc_adjust_memory_usage calls objspace_malloc_increase that calls objspace_malloc_increase_body which can start GC, but it only does so when the type argument is MEMOP_TYPE_MALLOC. rb_gc_adjust_memory_usage passes MEMOP_TYPE_REALLOC for type, so it won't trigger GC.
So, as far as I can tell, your original version with rb_gc_adjust_memory_usage is actually ok.

After digging through the code myself, I had a similar hunch. I’ll try to confirm this is the expected behavior.

It might be worth also wrapping the alloc_zeroed and realloc functions of GlobalAlloc. By default the trait implements them in terms of alloc and dealloc, but it's possible allocators are providing their own optimised implementation. By not implementing them in your wrapper you'd be skipping those potential optimisations.

Good call.


CEM-15500 WebUI modify and extend Status Field in CR

Add rediness probe to WebUI container
Skip WebUI related test cases in HA test suite because of being strong coupled with Keystone
Add readiness and liveness probe to WebUI's Redis
Add Service statuses to WebUI CR
Add new lines at the end of files
Fix pod statuses initialization
Change slice to map of ServiceStatuses

recheck ha


Add possibility to configure Request Statistics columns

Is your feature request related to a problem? Please describe.
Add possibility to configure Request Statistics columns
Now it is not configurable
label | samples | avg [ms] | min [ms] | max [ms] | P90 [ms] | P95 [ms] | P99 [ms] | requests/s | mbps | error rate |
Will be nice to have a possibility to configure user needed columns
For example if I'm interesting only in 90 % line I would like to see
label | samples | avg [ms] | min [ms] | max [ms] | P90 [ms] |
And download those table as csv or image
Thank you

Hi @yobshans
I like the idea - the current layout will be default though and also default for anonymous users (when a report is shared).

Nice, thank you

@yobshans shall this be defined globally or per project/scenario ?
From my point of view, it should be defined on scenario or project level.

I agree with you. Should be define on scenario level.
Like Thresholds or Label Filter Settings

I have it ready (yet tests need to be updated) - implemented like this - the settings are per project and per user. But now I realized that the top metrics setting is not per user and only per scenario :/, that feels weird.

Merged

Great. Thank you


fit square in triangle java added

Related Issue
Describe the changes you've made
Java code for fit square in triangle added!
Describe if there is any unusual behavior of your code(Write NA if there isn't)
NA
Language used for coding
Java
Checklist:

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have documented the code.
[x] New and existing unit tests pass locally with my changes.

Thank You for the pull request. Can you add comments to your code for making it beginner friendly ?

Sure, I will do


k3s fails to start on Raspberry Pi

Kairos version:
NAME="openSUSE Leap"
VERSION="15.5"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.5"
PRETTY_NAME="openSUSE Leap 15.5"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.5"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap"
LOGO="distributor-logo-Leap"
KAIROS_NAME="kairos-opensuse-leap-arm-rpi"
KAIROS_VERSION="v2.3.0-k3sv1.27.3+k3s1"
KAIROS_ID="kairos"
KAIROS_ID_LIKE="kairos-opensuse-leap-arm-rpi"
KAIROS_VERSION_ID="v2.3.0-k3sv1.27.3+k3s1"
KAIROS_PRETTY_NAME="kairos-opensuse-leap-arm-rpi v2.3.0-k3sv1.27.3+k3s1"
KAIROS_BUG_REPORT_URL="https://github.com/kairos-io/kairos/issues/new/choose"
KAIROS_HOME_URL="https://github.com/kairos-io/provider-kairos"
KAIROS_IMAGE_REPO="quay.io/kairos/kairos-opensuse-leap-arm-rpi"
KAIROS_IMAGE_LABEL="latest"
KAIROS_GITHUB_REPO="kairos-io/provider-kairos"
KAIROS_VARIANT="kairos"
CPU architecture, OS, and Version:
Linux yak-001 5.14.21-150500.53-default #1 SMP PREEMPT_DYNAMIC Wed May 10 07:56:26 UTC 2023 (b630043) aarch64 aarch64 aarch64 GNU/Linux
Describe the bug
K3s fails to start on Raspberry PI (have tried on Ubuntu and OpenSUSE based images). Due to an error writing to /var/lib/rancher/k3s/data
To Reproduce

Install an extracted or custom created Raspberry Pi image on to a SD card
Enable k3s in a cloud-init file
Power on the Raspberry Pi

Expected behavior
K3s should start successfully
Logs
sudo systemctl status k3s shows the service is stuck in the activating state, continually in an auto-restart loop:
● k3s.service - Lightweight Kubernetes
     Loaded: loaded (/etc/systemd/system/k3s.service; enabled; vendor preset: disabled)
    Drop-In: /etc/systemd/system/k3s.service.d
             └─override.conf
     Active: activating (auto-restart) (Result: exit-code) since Tue 2023-07-11 02:25:08 UTC; 776ms ago
       Docs: https://k3s.io
    Process: 2096 ExecStartPre=/bin/sh -xc ! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service (code=exited, status=0/SUCCESS)
    Process: 2098 ExecStartPre=/sbin/modprobe br_netfilter (code=exited, status=0/SUCCESS)
    Process: 2099 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)
    Process: 2100 ExecStart=/usr/bin/k3s server (code=exited, status=1/FAILURE)
   Main PID: 2100 (code=exited, status=1/FAILURE)

sudo journalctl -u k3s shows a failure loop due to being unable to extract data into var/lib/rancher/k3s/data:
systemd[1]: Starting Lightweight Kubernetes...
sh[3096]: + /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service
sh[3097]: Failed to get unit file state for nm-cloud-setup.service: No such file or directory
k3s[3100]: time="2023-07-11T02:34:23Z" level=info msg="Acquiring lock file /var/lib/rancher/k3s/data/.lock"
k3s[3100]: time="2023-07-11T02:34:23Z" level=info msg="Preparing data dir /var/lib/rancher/k3s/data/8147fdcc81517672a3573345f56cc1fc8eb>
k3s[3100]: time="2023-07-11T02:34:23Z" level=info msg="error extracting tarball into /var/lib/rancher/k3s/data/8147fdcc81517672a3573345>
k3s[3100]: time="2023-07-11T02:34:24Z" level=fatal msg="extracting data: error writing to /var/lib/rancher/k3s/data/8147fdcc81517672a35>
systemd[1]: k3s.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: k3s.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Lightweight Kubernetes.
systemd[1]: k3s.service: Scheduled restart job, restart counter is at 139.
systemd[1]: Stopped Lightweight Kubernetes.
systemd[1]: Starting Lightweight Kubernetes...

Note: I tried this previously in Kairos 2.2.1 images for both openSUSE and Ubuntu. I wanted to try it on the latest release today before filing to make sure it wasn't already addressed.

More information on this specific image. This was created following the instructions under Installation > RaspberryPi > Customizing the Disk Image.  However, after running into this issue previously to the same affect I doubled many of the disk size related parameters in an attempt to fix it. The command run to make the image was:
docker run -v /path/to/dir:/HERE \
        -v /var/run/docker.sock:/var/run/docker.sock \
        --privileged -i --rm \
        --entrypoint=/build-arm-image.sh quay.io/kairos/osbuilder-tools:latest \
        --use-lvm \
        --model rpi64 \
        --state-partition-size 12400 \
        --recovery-partition-size 4200 \
        --size 30400 \
        --images-size 4000 \
        --local \
        --config /HERE/cloud-config.yaml \
        --docker-image quay.io/kairos/kairos-opensuse-leap-arm-rpi:v2.3.0-k3sv1.27.3-k3s1 /HERE/yak-001.img```

I think the issue might be related to the size of the persistent partition:
lsblk -o NAME,SIZE,LABEL
NAME                   SIZE LABEL
loop0                    2G COS_ACTIVE
mmcblk0               29.2G
├─mmcblk0p1             96M COS_GRUB
├─mmcblk0p2            6.1G COS_STATE
├─mmcblk0p3            4.2G
│ ├─KairosVG-oem        64M COS_OEM
│ └─KairosVG-recovery  4.1G COS_RECOVERY
└─mmcblk0p4             64M COS_PERSISTENT

The issue is caused because there's a failure resizing persistent https://github.com/kairos-io/kairos/issues/1448#issuecomment-1632497108

Until this is fixed, you can run the command manually (annoying but only needs to be done once)

In GRUB add rd.break=initqueue
when you drop in the rescue shell run: sgdisk -g -d=4 -n=4:21635072:+0 -c=4:Linux filesystem -t=4:8300 /dev/mmcblk0

keep in mind the start from sector will depend on the values of the image, so validate before
and you might want to run the command with -P to dry run before running it without

restart

On next boot you should see something like
lsblk -o NAME,SIZE,LABEL
NAME                   SIZE LABEL
loop0                    2G COS_ACTIVE
mmcblk0               29.2G
├─mmcblk0p1             96M COS_GRUB
├─mmcblk0p2            6.1G COS_STATE
├─mmcblk0p3            4.2G
│ ├─KairosVG-oem        64M COS_OEM
│ └─KairosVG-recovery  4.1G COS_RECOVERY
└─mmcblk0p4           18.9G COS_PERSISTENT

Forgot to mention you also need to resize the fs:
resize2fs /dev/disk/by-label/COS_PERSISTENT
resize2fs 1.46.4 (18-Aug-2021)
Filesystem at /dev/disk/by-label/COS_PERSISTENT is mounted on /usr/local; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 152
The filesystem on /dev/disk/by-label/COS_PERSISTENT is now 19795436 (1k) blocks long.

And starting K3s after this, should work
systemctl start k3s
systemctl status k3s
● k3s.service - Lightweight Kubernetes
     Loaded: loaded (/etc/systemd/system/k3s.service; disabled; vendor preset: disabled)
     Active: active (running) since Thu 2023-07-13 07:54:31 UTC; 4s ago

This card is blocked because if we drop support for RPI3 we will switch to GPT as partitioning layout (see rationale in: https://github.com/kairos-io/osbuilder/pull/68#issuecomment-1635834382 ).
See poll in : https://github.com/kairos-io/kairos/discussions/1608

Blocked by this: https://github.com/kairos-io/kairos/issues/1636

@mauromorales this should now be fixed on master with model rpi4, if ther reason was not enough space under persistent.

fantastic! Let's move under review and I'll test

Let's not forget to document the manual expansion of rpi3

There is already an issue for that: https://github.com/kairos-io/kairos/issues/1637 . @mauromorales please close this as soon as you test this and it works.

blocked by https://github.com/kairos-io/kairos/issues/1725

With the latest changes, the space is there but I still encounter this issue when trying to start k3s:
systemctl is-enabled --quiet nm-cloud-setup.service
Failed to get unit file state for nm-cloud-setup.service: No such file or directory

this was related to not having network on the rpi ... so I will add an alert on the docs

One more bug preventing this from working: https://github.com/kairos-io/kairos/issues/1831

I am having the same issue.
Is there a workaround for this yet?

I am having the same issue with the latest Ubuntu image running on a RPI4.
Is there a workaround for this yet?

Automatic expansion of the last partition of Rasbperry Pi 4 is fixed in v2.4.1. Creating images for rpi3 has its own ticket: https://github.com/kairos-io/kairos/issues/1816.
We can close this now.

Hey @jimmykarily, sure here is more information:

Used Raspberry: RPI 4(8GB)
The image used: kairos-standard-ubuntu-arm64-rpi4-v2.4.1-k3sv1.27.3+k3s1.img
The journal:

systemd[1]: Starting k3s.service - Lightweight Kubernetes...
sh[1745]: + /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service
systemctl[1746]: Failed to get unit file state for nm-cloud-setup.service: No such file or directory
k3s[1749]: time="2023-10-10T11:09:17Z" level=info msg="Acquiring lock file /var/lib/rancher/k3s/data/.lock"
k3s[1749]: time="2023-10-10T11:09:17Z" level=info msg="Preparing data dir /var/lib/rancher/k3s/data/8147fdcc81517672a3573345f56cc1fc8eb0b1135e84cd4dbc06eb673620d610"
k3s[1749]: time="2023-10-10T11:09:19Z" level=info msg="error extracting tarball into /var/lib/rancher/k3s/data/8147fdcc81517672a3573345f56cc1fc8eb0b1135e84cd4dbc06eb673620d610-tmp after 5 files, 1 dirs, 1.873067111s: error writing to /var/lib/rancher/k3s/data/8147fdcc81517672a3573345f56cc1fc8eb0b1135e84cd4dbc06eb673620d610-tmp/bin/k3s: write /var/lib/rancher/k3s/data/8147fdcc81517672a3573345f56cc1fc8eb0b1135e84cd4dbc06eb673620d610-tmp/bin/k3s: no space left on device"
k3s[1749]: time="2023-10-10T11:09:20Z" level=fatal msg="extracting data: error writing to /var/lib/rancher/k3s/data/8147fdcc81517672a3573345f56cc1fc8eb0b1135e84cd4dbc06eb673620d610-tmp/bin/k3s: write /var/lib/rancher/k3s/data/8147fdcc81517672a3573345f56cc1fc8eb0b1135e84cd4dbc06eb673620d610-tmp/bin/k3s: no space left on device"
systemd[1]: k3s.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: k3s.service: Failed with result 'exit-code'.
systemd[1]: Failed to start k3s.service - Lightweight Kubernetes.
systemd[1]: k3s.service: Consumed 1.957s CPU time.

lsblk:

root@localhost:~# lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0  2.6G  1 loop /
mmcblk0     179:0    0 29.7G  0 disk
|-mmcblk0p1 179:1    0   96M  0 part
|-mmcblk0p2 179:2    0  7.9G  0 part /run/initramfs/cos-state
|-mmcblk0p3 179:3    0  5.3G  0 part
|-mmcblk0p4 179:4    0   64M  0 part /oem
`-mmcblk0p5 179:5    0 16.4G  0 part /var/lib/wicked
                                     /var/lib/snapd
                                     /var/lib/rancher
                                     /var/lib/longhorn
                                     /var/lib/kubelet
                                     /var/lib/extensions
                                     /var/lib/dbus
                                     /var/lib/containerd
                                     /var/lib/cni
                                     /etc/ssl/certs
                                     /var/lib/ca-certificates
                                     /etc/zfs
                                     /etc/systemd
                                     /etc/sysconfig
                                     /etc/ssh
                                     /var/snap
                                     /etc/runlevels
                                     /etc/rancher
                                     /etc/modprobe.d
                                     /var/log
                                     /usr/libexec
                                     /etc/kubernetes
                                     /etc/iscsi
                                     /etc/cni
                                     /snap
                                     /root
                                     /opt
                                     /home
                                     /usr/local

df -h:

root@localhost:~# df -h
Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              3.9G     0  3.9G   0% /dev/shm
tmpfs                              1.6G  9.9M  1.6G   1% /run
tmpfs                              5.0M     0  5.0M   0% /run/lock
/dev/loop0                         2.6G  2.6G     0 100% /
/dev/disk/by-label/COS_OEM          55M   15K   51M   1% /oem
tmpfs                              2.0G  492K  2.0G   1% /run/overlay
/dev/disk/by-label/COS_PERSISTENT   55M   34M   17M  67% /usr/local
overlay                            2.0G  492K  2.0G   1% /var
overlay                            2.0G  492K  2.0G   1% /etc
overlay                            2.0G  492K  2.0G   1% /srv
tmpfs                              3.9G     0  3.9G   0% /tmp
/dev/mmcblk0p2                     7.7G  5.2G  2.2G  71% /run/initramfs/cos-state
tmpfs                              786M  4.0K  786M   1% /run/user/0

fdisk -l

root@localhost:~# fdisk -l
Disk /dev/loop0: 2.64 GiB,<PHONE_NUMBER> bytes, 5529600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mmcblk0: 29.72 GiB,<PHONE_NUMBER>4 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 7A3E8686-3DD9-9647-902C-A40A44CBF3E3

Device            Start      End  Sectors  Size Type
/dev/mmcblk0p1     8192   204799   196608   96M Microsoft basic data
/dev/mmcblk0p2<PHONE_NUMBER>3599 16588800  7.9G Linux filesystem
/dev/mmcblk0p3 16793600 27852799 11059200  5.3G Linux filesystem
/dev/mmcblk0p4 27852800 27983871   131072   64M Linux filesystem
/dev/mmcblk0p5 27983872 62333918 34350047 16.4G Linux filesystem

Hmm, the partitions seems expanded:
mmcblk0p5 179:5    0 16.4G  0

but the filesystem not (?):
/dev/disk/by-label/COS_PERSISTENT   55M   34M   17M  67% /usr/local

Does this still occurs after a reboot? I remember we needed to run partprobe in some cases to the new partition to be read. Though it's the filesystem that doesn't seem to expand but worths checking.

Sadly the reboot did not help.
I am not so familiar with partitions and volumes, but I noticed that  the COS_PERSISTENT has the same size on my RPI as it has when I mount the SD card in my Laptop
On RPI:
root@localhost:~# df -h
Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              3.9G     0  3.9G   0% /dev/shm
tmpfs                              1.6G  9.9M  1.6G   1% /run
tmpfs                              5.0M     0  5.0M   0% /run/lock
/dev/loop0                         2.6G  2.6G     0 100% /
/dev/disk/by-label/COS_OEM          55M   15K   51M   1% /oem
tmpfs                              2.0G  476K  2.0G   1% /run/overlay
/dev/disk/by-label/COS_PERSISTENT   55M  8.7M   42M  18% /usr/local
overlay                            2.0G  476K  2.0G   1% /var
overlay                            2.0G  476K  2.0G   1% /etc
overlay                            2.0G  476K  2.0G   1% /srv
tmpfs                              3.9G     0  3.9G   0% /tmp
/dev/mmcblk0p2                     7.7G  5.2G  2.2G  71% /run/initramfs/cos-state
tmpfs                              786M  4.0K  786M   1% /run/user/0

On my Laptop:
❯ df -h
Filesystem        Size  Used Avail Use% Mounted on
/dev/sdb2         7.7G  5.2G  2.2G  71% /run/media/mordax/COS_STATE
/dev/sdb3         5.2G  2.6G  2.3G  54% /run/media/mordax/COS_RECOVERY
/dev/sdb1          95M  8.5M   87M   9% /run/media/mordax/COS_GRUB
/dev/sdb4          55M   15K   51M   1% /run/media/mordax/COS_OEM
/dev/sdb5          55M  8.7M   42M  18% /run/media/mordax/COS_PERSISTENT

It should be the same on any machine, what you see is ok. The question is why didn't the filesystem expand. Are you sure you are installing v2.4.1? I can't reproduce this. On my rpi4 (64Gb sdcard):
kairos@localhost:~> lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0     7:0    0    2G  1 loop /
mmcblk0 179:0    0 59.7G  0 disk
├─mmcblk0p1
│       179:1    0   96M  0 part
├─mmcblk0p2
│       179:2    0  6.1G  0 part /run/initramfs/cos-state
├─mmcblk0p3
│       179:3    0  4.1G  0 part
├─mmcblk0p4
│       179:4    0   64M  0 part /oem
└─mmcblk0p5
        179:5    0 49.4G  0 part /usr/local/.state/usr-share-pki-trust.bind/anchors
                                 /usr/share/pki/trust/anchors
                                 /usr/share/pki/trust
                                 /var/lib/wicked
                                 /var/lib/snapd
                                 /var/lib/rancher
                                 /var/lib/longhorn
                                 /var/lib/kubelet
                                 /var/lib/extensions
                                 /var/lib/dbus
                                 /var/lib/containerd
                                 /var/lib/cni
                                 /var/lib/ca-certificates
                                 /etc/zfs
                                 /etc/systemd
                                 /etc/sysconfig
                                 /etc/ssh
                                 /var/snap
                                 /etc/runlevels
                                 /etc/rancher
                                 /etc/modprobe.d
                                 /var/log
                                 /usr/libexec
                                 /etc/kubernetes
                                 /etc/iscsi
                                 /etc/cni
                                 /root
                                 /opt
                                 /home
                                 /usr/local

kairos@localhost:~> df -h
Filesystem                         Size  Used Avail Use% Mounted on
devtmpfs                           4.0M     0  4.0M   0% /dev
tmpfs                              3.9G  8.0K  3.9G   1% /dev/shm
tmpfs                              1.6G   26M  1.6G   2% /run
tmpfs                              4.0M     0  4.0M   0% /sys/fs/cgroup
/dev/disk/by-label/COS_ACTIVE      2.0G  1.8G  110M  95% /
/dev/disk/by-label/COS_OEM          55M   15K   51M   1% /oem
tmpfs                              2.0G   12M  2.0G   1% /run/overlay
/dev/disk/by-label/COS_PERSISTENT   47G  951M   43G   3% /usr/local
overlay                            2.0G   12M  2.0G   1% /var
overlay                            2.0G   12M  2.0G   1% /etc
overlay                            2.0G   12M  2.0G   1% /srv
tmpfs                              3.9G  4.0K  3.9G   1% /tmp
/dev/mmcblk0p2                     5.9G  3.5G  2.2G  63% /run/initramfs/cos-state
shm                                 64M     0   64M   0% /run/k3s/containerd/io.containerd.grpc.v1.cri/sandboxes/3c3c2a41ba103b7a6428671c705e1e19734c751417196611422e9761ccf7af0a/shm
shm                                 64M     0   64M   0% /run/k3s/containerd/io.containerd.grpc.v1.cri/sandboxes/e5d3b6c77ea50b78c500a6e621e0af923acecdf8fcd8f414f2e99bc468b1e51d/shm
shm                                 64M     0   64M   0% /run/k3s/containerd/io.containerd.grpc.v1.cri/sandboxes/2865850d67bc8bcc10b30810262d5a6350e4629ee85a8180c21141f0f05315c8/shm
shm                                 64M     0   64M   0% /run/k3s/containerd/io.containerd.grpc.v1.cri/sandboxes/e6cd7b7f868cef127345e13a911cbcfd630b09697f3b336ea9ce5a165d44c6d2/shm
shm                                 64M     0   64M   0% /run/k3s/containerd/io.containerd.grpc.v1.cri/sandboxes/dd67a77b2ccc6841d74adc0520e5805aaa6db45b65bfb30e65c8e4110538128e/shm

My COS_PERSISTENT is the full size of the partition. I didn't even have to reboot or anything. My kairos config is as simple as it gets:
#cloud-config

users:
  - name: kairos
    passwd: kairos

k3s:
  enabled: true

The tool we use to expand the filesystem depends on the filesystem type: https://github.com/kairos-io/kairos-agent/blob/40289af471124e9f3bb58965b9206b80bc01f144/pkg/partitioner/disk.go#L410-L450
I'm using defaults and it works. @mordax7 are you setting the filesystem to something non-default in your kairos config maybe? I'm suspecting that if you do, we are trying to use a tool that is not there or doesn't work for some other reason.

The image that I have used:

The command I used to flash the SD card:
xzcat kairos-standard-ubuntu-arm64-rpi4-v2.4.1-k3sv1.27.3+k3s1.img.xz | sudo dd of=/dev/sda oflag=sync status=progress bs=10MB
The cloud-config that I have used:

The file-system type of the mounts:

Which RPI Model I use:

My image was
kairos-standard-opensuse-leap-arm64-rpi4-v2.4.1-k3sv1.26.6+k3s1.img

(only the k3s version is different)
My config and the rpi model are the same as yours. My /dev/disk/by-label/COS_PERSISTENT is also ext4.
The process I used to burn the image was the same. I don't see how we could get different results.
You should add rd.debug rd.immucore.debug to the kernel boot line (by hitting e when the grub menu is presented and appending these to the linux line). You'd need a serial cable and a tool like minicom to be able to store the boot logs to a file. I'm not sure if they are accessible after boot with journalctl.
I usually do sudo minicom -b 115200 -o -D /dev/ttyUSB0  2>&1 | tee out and then check the out file.
There should be some error in the logs that will help.

I found some immocore logs in journalctl, It seems like a file system permission problem:
journalctl.txt
I tried multiple SD cards and writing the image to the SD card with multiple different tools, nothing helped.

I have exactly the same issue with kairos-core-ubuntu-22-lts-arm64-rpi4-v2.4.1.img image. I followed the guide:
root@ubuntu:/home/ubuntu# export IMAGE=quay.io/kairos/core-ubuntu-22-lts-arm-rpi-img:v2.4.1
root@ubuntu:/home/ubuntu# docker run -ti --rm -v $PWD:/image quay.io/luet/base util unpack "$IMAGE" /image

then wrote the image using RPI Imager, and after booting my RPI 4 I have:
root@localhost:/home/kairos# df -h
Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              1.9G     0  1.9G   0% /dev/shm
tmpfs                              767M  9.9M  757M   2% /run
tmpfs                              5.0M     0  5.0M   0% /run/lock
/dev/loop0                         2.6G  2.2G  322M  88% /
/dev/disk/by-label/COS_OEM          55M   15K   51M   1% /oem
tmpfs                              959M  480K  958M   1% /run/overlay
/dev/disk/by-label/COS_PERSISTENT   55M  7.1M   44M  15% /usr/local
overlay                            959M  480K  958M   1% /var
overlay                            959M  480K  958M   1% /etc
overlay                            959M  480K  958M   1% /srv
/dev/sda2                          7.7G  4.4G  3.0G  60% /run/initramfs/cos-state
tmpfs                              1.9G     0  1.9G   0% /tmp

/dev/disk-by-label/COS_PERSISTENT is tiny.

I tested it with a 64GB SD card(all SanDisk), did not help. Maybe it has something to do with the type of SD cards?

I'm using a USB Flash drive 64G.

I came across this thread a short while ago after having experienced the same issue (with K3S not running due to no space on the disk) with kairos-alpine-arm-rpi-img:v2.4.1-k3sv1.27.3-k3s1.
I have since installed kairos-opensuse-leap-arm-rpi-img:v2.4.1-k3sv1.27.3-k3s1 and the filesystem has been expanded successfully.  I would prefer to use the Alpine version though.
/dev/disk/by-label/COS_PERSISTENT  214G  218M  203G   1% /usr/local
By the way, when I run kairos --version, it returns version: 2.4.0, compiled with: go1.20.8. I was expecting it to say 2.4.1 ?

Could be that alpine is missing a required binary on the initramfs needed to expand.

By the way, when I run kairos --version, it returns version: 2.4.0, compiled with: go1.20.8. I was expecting it to say 2.4.1 ?

This is expected as you are checking the version of kairos-agent.
For the Kairos version you need to check /etc/os-release
Kairos-agent and Kairos have different release cadence, currently they are kind of matched in version numbers due to coincidence, but you could have different versions altogether depending on their release cadence, so it could report version 2.2.12 of the agent in the Kairos version 2.1 for example :)

@mordax7 I just realized you used ubuntu, the original reporter was using opensuse. I can reproduce this on Ubuntu. I see these on immucore boot logs:
1902 ^[[1;51r^[[50;1H[   74.744911] immucore[451]: time="2023-08-18T18:15:37Z" level=debug msg="Using label COS_PERSISTENT for layout expansion"^M^[[1;50r^[[50;1H
1903 ^[[1;51r^[[50;1H[   74.768531] immucore[451]: time="2023-08-18T18:15:37Z" level=debug msg="Output of udevadm settle: "^M^[[1;50r^[[50;1H
1904 ^[[1;51r^[[50;1H[   74.788476] immucore[451]: time="2023-08-18T18:15:37Z" level=debug msg="Got device /dev/mmcblk0 for label COS_PERSISTENT"^M^[[1;50r^[[50;1H
1905 ^[[1;51r^[[50;1H[   74.812510] immucore[451]: time="2023-08-18T18:15:37Z" level=warning msg="Not enough unpartitioned space in disk to operate"^M^[[1;50r^[[50;1H
1906 ^[[1;51r^[[50;1H[   74.836583] immucore[451]: time="2023-08-18T18:15:37Z" level=info msg="Done executing stage 'rootfs.after'\n"^M^[[1;50r^[[50;1H

There is still something off. As is this fix didn't work: https://github.com/mudler/yip/pull/110/files
Now at least I can debug.

Fix finding, the partition expansions seems to happen twice:

00_rootfs.yaml
11_persistent.yaml/oem/11_persistent.yaml

This is wrong. Also in immucore debug logs, I see the following warning 3 times:
Not enough unpartitioned space in disk to operate

That said, the first time we try to expand the partition, it should succeed expanding the filesystem as well, otherwise some error should show up (I can't find any).
Also, I don't see why it would Ubuntu behave differently from Opensuse. We rely on output from lsblk to detect partition device names so it could be that some lsblk output is different between the 2 OSes (e.g. due to different versions of it).

FYI found the same on alpine pure testing. Part is expanded (as show via lsblk) but filesystem is not (as shown by df) and no errors on the logs.
vda    253:0    0   176G  0 disk
├─vda1 253:1    0     1M  0 part
├─vda2 253:2    0    64M  0 part /oem
├─vda3 253:3    0   2.3G  0 part
├─vda4 253:4    0   4.2G  0 part /run/initramfs/cos-state
└─vda5 253:5    0 169.4G  0 part /var/lib/wicked

kairos-i0n7:~$ df -h
Filesystem                         Size  Used Avail Use% Mounted on
/dev/disk/by-label/COS_ACTIVE      1.1G  599M  421M  59% /
/dev/disk/by-label/COS_OEM          55M   50K   51M   1% /oem
/dev/disk/by-label/COS_PERSISTENT   69G  3.8M   66G   1% /usr/local

According to this: https://github.com/mudler/yip/blob/master/pkg/plugins/layout.go#L507 if there is an error it should return it and the stage would show it...I think?
Maybe we would need to add even more logging to layout yip plugin...

this is what I got from a extended debug enabled yip:
[[90m2023-10-16T13:52:58Z[[0m [[33mDBG[[0m Output from running e2fsck e2fsck 1.4
7.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
COS_PERSISTENT: 15/4521984 files (0.0% non-contiguous), 428763/18063872 blocks

[[90m2023-10-16T13:52:58Z[[0m [[33mDBG[[0m Output from running resize2fs resize2
fs 1.47.0 (5-Feb-2023)
The filesystem is already 18063872 (4k) blocks long.  Nothing to do!

[[90m2023-10-16T13:52:58Z[[0m [[33mDBG[[0m Trying to reread the partition table
of /dev/vda (try number 1)
[[90m2023-10-16T13:52:58Z[[0m [[33mDBG[[0m output of partprobe:
[[90m2023-10-16T13:52:58Z[[0m [[33mDBG[[0m Output of sync:

Looks like the partition table is not properly re-read or something and resize2fs thinks that its already maxed out?

expansion migth be fixed after https://github.com/mudler/yip/pull/116 gets in and down into immucore

Did someone find a workaround which can be used in the cloud-config in the meantime?
Because after the RPI booted I ssh'ed and used the resize2fs /dev/mmcblk0p5 as described here to manually resize the the partition. Which does resize the partition. But I do not know if the cloud-config actually managed to configure k3s, I think I am missing all the k3s configuration, but I am not 100% sure. Is there a way for me to verify that my cloud-config actually configures something?
One example, i want to use KubeVIP as described here. In theory, the IP I configured  under eip, should be a network interface on the controller node and k3s should have that IP configured, but it is not. Any ideas?

@mordax7 to see if k3s was configured I think you should start by directly looking into the k3s service: systemctl status k3s and journalctl -u k3s. If the service is started correctly but you still can't tell if all your options were applied, you should look in how the k3s service is started (flags and such). A specific option you are missing might help us point you to more exact debugging steps.

This is going to be fixed with v2.4.2 except for Alpine for which we have created a separate issue: https://github.com/kairos-io/kairos/issues/1995
I will close this and track the Alpine fix on the new issue.


Questions about the reproduction of the TGIF-QA

We used the same data as in git and used the officially provided training weights, also evaluated using gpt3.5, but only achieved an accuracy of 47.9/3.1 (vs. 70.0) on the TGIF-QA task.BTW, on the other three QA tasks, were able to obtain metrics similar to those in the paper. What could be the cause of this?

The following questions are relevant, perhaps you can refer to them.
issue 36
issue 34
issue 28 from Video-ChatGPT

We used the same data as in git and used the officially provided training weights, also evaluated using gpt3.5, but only achieved an accuracy of 47.9/3.1 (vs. 70.0) on the TGIF-QA task.BTW, on the other three QA tasks, were able to obtain metrics similar to those in the paper. What could be the cause of this?

Have you succeed? I met the same problem. I've checked other issues but the problem remains.
The results are very close in other datasets, but significantly lower in TGIF-QA dataset (59.8/3.4)

We used the same data as in git and used the officially provided training weights, also evaluated using gpt3.5, but only achieved an accuracy of 47.9/3.1 (vs. 70.0) on the TGIF-QA task.BTW, on the other three QA tasks, were able to obtain metrics similar to those in the paper. What could be the cause of this?

Have you succeed? I met the same problem. I've checked other issues but the problem remains. The results are very close in other datasets, but significantly lower in TGIF-QA dataset (59.8/3.4)

@LinB203 Could you provide a TGIF-QA results JSON to help us locate the problems?
Besides, we've also found that different gpt-3.5 versions will yield significantly different results.
gpt-3.5-turbo-1106 performs like human evaluators, but gpt-3.5-turbo-0613 and gpt-3.5-turbo-0301 will regard many wrong answers as correct ones. (resulting ~8% higher accuracy)

We used the same data as in git and used the officially provided training weights, also evaluated using gpt3.5, but only achieved an accuracy of 47.9/3.1 (vs. 70.0) on the TGIF-QA task.BTW, on the other three QA tasks, were able to obtain metrics similar to those in the paper. What could be the cause of this?

Have you succeed? I met the same problem. I've checked other issues but the problem remains. The results are very close in other datasets, but significantly lower in TGIF-QA dataset (59.8/3.4)

@LinB203 Could you provide a TGIF-QA results JSON to help us locate the problems?
Besides, we've also found that different gpt-3.5 versions will yield significantly different results.
gpt-3.5-turbo-1106 performs like human evaluators, but gpt-3.5-turbo-0613 and gpt-3.5-turbo-0301 will regard many wrong answers as correct ones. (resulting ~8% higher accuracy)

Sure, hope this helpful. https://drive.google.com/file/d/1ArNLI3jF3u6QS1XujiP3O_Q0kEmHjvm_/view?usp=sharing

I found a serious issue here.
You seems to only evaluate on only a subset  of TGIF-QA test (specifically, FrameQA). Specifically, the TGIF-QA data you provided in the Baidu drive has 25751 annotations (same as the TGIF official repo). But the result file in your Google Drive has only 13691 samples. And 13691 is the extact number of FrameQA-test samples.
I did not notice any explanation in your paper or code. Is there anything that I have missed?

We used the same data as in git and used the officially provided training weights, also evaluated using gpt3.5, but only achieved an accuracy of 47.9/3.1 (vs. 70.0) on the TGIF-QA task.BTW, on the other three QA tasks, were able to obtain metrics similar to those in the paper. What could be the cause of this?

Have you succeed? I met the same problem. I've checked other issues but the problem remains. The results are very close in other datasets, but significantly lower in TGIF-QA dataset (59.8/3.4)

@LinB203 Could you provide a TGIF-QA results JSON to help us locate the problems?
Besides, we've also found that different gpt-3.5 versions will yield significantly different results.
gpt-3.5-turbo-1106 performs like human evaluators, but gpt-3.5-turbo-0613 and gpt-3.5-turbo-0301 will regard many wrong answers as correct ones. (resulting ~8% higher accuracy)

Sure, hope this helpful. https://drive.google.com/file/d/1ArNLI3jF3u6QS1XujiP3O_Q0kEmHjvm_/view?usp=sharing

I found a serious issue here.
You seems to only evaluate on only a subset of TGIF-QA test (specifically, FrameQA). Specifically, the TGIF-QA data you provided in the Baidu drive has 25751 annotations (same as the TGIF official repo). But the result file in your Google Drive has only 13691 samples. And 13691 is the extact number of FrameQA-test samples.
I did not notice any explanation in your paper or code. Is there anything that I have missed?

We follow the Video-ChatGPT, who uses Test_frameqa_question. mbzuai-oryx/Video-ChatGPT#65 (comment)

Thank you for your kindness!

We used the same data as in git and used the officially provided training weights, also evaluated using gpt3.5, but only achieved an accuracy of 47.9/3.1 (vs. 70.0) on the TGIF-QA task.BTW, on the other three QA tasks, were able to obtain metrics similar to those in the paper. What could be the cause of this?

Hello, could you please share your reproduced accuracy and score on MSRVTT to us? This dataset is too large so reproducing it costs a lot. Would love to know the result!


Updating search params?

Is there a preferred way of updating search params when using this library? I'd like to update search params based on a user's page in a table, filter options, etc.

The docs say to use router.push on this page https://next-typesafe-url.dev/en/usage/routing.
I have done it myself like this:
import { useRouter } from "next/navigation";

export function Component() {
  const [searchQuery, setSearchQuery] = useState("");
  const router = useRouter();

  async function handleChange(e: React.ChangeEvent<HTMLInputElement>) {
    e.preventDefault();

    // TODO: Check if we still need to encode the search query with next-typesafe-url
    const encodedSearchQuery = encodeURIComponent(e.target.value);
    setSearchQuery(encodedSearchQuery);

    router.push(
      $path({
        route: "/path",
        searchParams: { query: encodedSearchQuery },
      },
    );
  }

  return (
    <form>
      <input
        type="text"
        value={searchQuery}
        onChange={handleChange}
      />
    </form>
  );
}

However, in my example, I have not yet determined if we still need to use encodeURIComponent...
I did not see any mention on the docs about the encoding of the URL parameters.


Fix/evm 451

Checking again with the (long) list of things in EVM-451, I think currently there is two main things missing from the PR:

RpcRequest: remove unused getters/setters and handle invalid json
RpcService: Unit Tests (mainly for  the argument conversions I think)

FYI: something weird happened in this PR during a merge of dev_evm into this branch. The GitHub UI here does not show all the changes. Reviewing should either be done outside or we have to fix and force-push this branch.
Other then that, I think the last remaining issue here is:

RpcService: Unit Tests (mainly for the argument conversions I think)

I suggest putting that into a new ticket and proceed with merging. This PR is already getting quite old.

Added a fix for the missing 0x prefix on the "to" address here , see EVM-596.

Meh, now with dev_evm merged in some of the changes in this branch make some tests in EthServiceTest fail. Need to update.


Feat: E2E Docker Support

Issue number
Relevant issue number

Resolves #

Please check the following

[ ] Do the tests still pass? (see Run the Tests)
[ ] Is the code formatted properly? (see Linting (Formatting))
For New Features:

[ ] Have tests been added to cover any new features or fixes?
[ ] Has the documentation been updated accordingly?

Please describe additional details for testing this change

Closing as this isn't actively worked on


Remove unneeded parameter

Codecov Report

Merging #244 (d25702f) into main (c9b13aa) will decrease coverage by 0.41%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #244      +/-   ##
==========================================
- Coverage   89.59%   89.18%   -0.42%
==========================================
  Files          87       87
  Lines        6008     6008
==========================================
- Hits         5383     5358      -25
- Misses        625      650      +25

Impacted Files
Coverage Δ

...crosoft.VisualStudio.Composition/ExportProvider.cs
96.39% <ø> (ø)

...timeExportProviderFactory+RuntimeExportProvider.cs
97.71% <100.00%> (ø)

....Composition.AppDomainTests/OpenGenericExport`1.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...mposition.AppDomainTests/ExternalExportOnMember.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...mposition.AppDomainTests/ExternalExportWithLazy.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...osition.AppDomainTests2/CustomMetadataAttribute.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...dTypeReceiver/PartThatImportsLazyOfEmbeddedType.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...rtThatLazyImportsExportWithMetadataOfCustomType.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...atLazyImportsExportWithTypeMetadataViaTMetadata.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...tLazyImportsExportWithTypeMetadataViaDictionary.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 2 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 c9b13aa...d25702f. Read the comment docs.


co sage intacct info text update

Summary by CodeRabbit

New Features

Enhanced user guidance by adding a message that instructs users to enter unique integration credentials for specific brand configurations.


IMPROVEMENT: Improve Database Structure

Currently, all the relations are stored in one set of technical skills technicalHardSkills. This is not good as only this set of skills needs to be queried. For example, if you want to check skills associated with a programming language, you must query the technicalHardSkills and find instances of that programming language.

Instead of using objects in the array of skills, we should use the unique slugs. Then we can use the slug to find the associated sub-skill. There will be no check to see if the slug is actually valid therefore enums could be used. Because we are no longer storing the reference to the object itself, the performance will be slower as we are doing a linear search; to address this, we can use hash maps/dictionaries to keep the same constant time performance.

#366


Floodfill

Awsome :)
riggiding<EMAIL_ADDRESS>escreveu no dia sexta, 28/02/2020 à(s)
18:04:

Merged #61 https://github.com/Photonsters/PhotonFileValidator/pull/61
into master.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Photonsters/PhotonFileValidator/pull/61?email_source=notifications&email_token=ACUR56UEVNQGHTTH6RQK7BLRFFG4HA5CNFSM4K5WQ3Z2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOW7BGWGI#event-3082971929,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACUR56XZCY2CM2IQKJO4OC3RFFG4HANCNFSM4K5WQ3ZQ
.

--
Com os melhores cumprimentos,
Vinicius Silva


[Bug] MD List add status

Device information

Tachiyomi version: r339
Android version: 10
Device: redmi 8

Steps to reproduce

open manga not from mangadex
add to dex tracker

Expected behavior
tracker status as reading
Actual behavior
tracker status as unfollowed

Addressed with https://github.com/jobobby04/TachiyomiSY/commit/5dace4fd7448da1d8e9c837ea4e8fc25278f8518


Why font color overlaps and changed in iTerm2 on Mac

Just as shown in pictures above, the small triangle looks so uncomfortable, and similar problem also appears in Terminal.app, with just same configuration.
iTerm version: Build 2.1.1
Oh my zsh and the themes are latest.

What version of OS X are you running? Is that the agnoster theme?

Mac OS 10.10.5
The agnoster theme

This looks like you're running in to the effects of "minimum contrast enforcement". This is a terminal emulator feature that ensures text is readable by adjusting foreground colors that are too similar to the background color of the window (in Terminal's case) or the character cell (in iTerm's case, I think). Powerline themes make that right-pointing segment shape by drawing a special right-pointing triangle character with a foreground color that is the same as the previous segment's background color.
You can see it in action by adjusting the background color. In Terminal, take a look at the "Window" tab under the Profile, select the Background Color & Effects, and adjust the color and opacity slider. You'll see the green triangle pop in and out of a brightened mode when you have a dark background that's like the green color.
In iTerm2, you can adjust this feature with the "Minimum contrast" slider in the Colors section of your profile. Terminal.app doesn't seem to have any way to turn it off or control it. You may just have to fiddle with your background color until you get one that doesn't trigger it.

Wow, that just work fine!
I spent a lot of time trying to find which option controls this behavior, but got nothing.
So I recommend to add your notification to the wiki page to remind others about this thing.
And thanks very much for your reply.


Disable jdk14 build+test, and enable jdk15 build+test

This is being done because we've passed the last release for jdk14,
and we need start testing 15 in preparation for the September release.
Most JDK15 builds are already active, but there are a few platforms
(windows 32bit and XL variants) that needed to be added, based on the
fact that jdk14 was creating builds for them.
Signed-off-by: Adam Farley<EMAIL_ADDRESS>

run tests

run tests

Ah, George's test shows I'm missing a vital comma.
Searching for more commas now.

run tests

run tests

add to whitelist

one last observation, we should probably remove 14 from the PR tester too (https://github.com/AdoptOpenJDK/openjdk-build/blob/master/pipelines/build/prTester/pr_test_pipeline.groovy#L133)

Thanks @sxa
@gdams - Sure. See here: https://github.com/AdoptOpenJDK/openjdk-build/pull/1993