Minimal initial func.yaml

Summary
All fields on the Function struct should be set to omitempty
Exposition
When a user creates a new Function, their func.yaml should include only the values which are either required (language), have no default (created date/time stamp) or deviate from static defaults (`func create -l go -t cl.
With the current version of the functions core library, this would ideally look as such:
>  mkdir f && cd f && func create -l go
Created go function in [path]

> cat func.yaml
specVersion: 0.25.0
runtime: go
created: 2022-09-26T23:06:48.442316+09:00

Alternative Considered: The fully-populated Config File approach
A traditional "config file" style setup would be where the func.yaml is fully populated with all possible values (commented and showcasing static defaults), whereby the user can choose to uncomment a given setting.  However, this usage pattern is directly at odds with the usage pattern we are encouraging: CLI or direct API.  For example, we using our friend git as an example, only when configuration is changed using git config ... does the .git/config file change.  This is the opposite approach to, for example sshd, which upon installation provides a comprehensive config file available at /etc/ssh/sshd_config.  The reason for the difference is that the former has a CLI which provides for configuration, while the latter does not.  We have a CLI.
This is of course up for debate.  It might be nice to account for a user who prefers  a func.yaml-first approach.  That may very well happen in the future, but this minimal approach should probably still be the first step.  We currently have the worst of both worlds, were func.yaml is populated with an intimidating litany of uncommented zero values.
Caviat: It won't be that simple right now
Even if all fields are set to omitempty, the func.yaml will still include several more values.  This is a result of having not been strict in our usage of in-code static defaults early on, and requiring a few values we don't really need, so there are still a few fields which are written to every func.yaml despite not being actually deviations from the default.  The closest we can get at present would be:
specVersion: 0.25.0
name: f
runtime: go
healthEndpoints:
  liveness: /health/liveness
  readiness: /health/readiness
buildpacks:
- paketo-buildpacks/go-dist
- ghcr.io/boson-project/go-function-buildpack:tip
created: 2022-09-26T23:06:48.442316+09:00
invocation:
  format: http

Related
See forthcoming issues which request that we rely on the static defaults for buildpacks and health endpoints, only require a name upon deploy, and flatten the invocation struct (also relying on http as the static default)

/remove-lifecycle stale

That's great @manoelmarques .  It might be good to perform the omitempty change in in one PR and do the default buildpacks in another:
If I remember correctly, the buildpack defaults should be static defaults in the pack builder builders/buildpacks/builder.go.  Buildpacks specified in func.yaml (or a custom template) would become overrides. So if empty, the defaults in the buildpacks.Builder would take effect on build.
That means that, in the default case, the func.yaml would have no buildpacks specified.
I say the change to update to using in-code defaults maybe should be a separate PR because the buildpacks builder might need to be appreciably modified.

Hi @lkingland I added the flag and created a PR. However, during the CI, there were two errors when deploying to cluster. One caused by the Image and the other Registry. I removed the omitempty from those two and it all worked. Currently the PR passes CI. The errors are below:
Image:
=== RUN   TestBasicUpload
    cmd.go:83: /home/runner/work/func/func/func create -l node /tmp/TestBasicUpload3227201013/001/test-func-basic-upload29khr
    cmd.go:83: /home/runner/work/func/func/func deploy -p /tmp/TestBasicUpload3227201013/001/test-func-basic-upload29khr -r ttl.sh/knfunc2pqk62fp --remote --verbose
    cmd.go:127: Creating Pipeline resources
        Running Pipeline Task: Building function image on the cluster
        Running Pipeline Task: Deploying function to the cluster
        Error: failed to run pipeline: function pipeline run has failed with message:

        ⬆  Deploying function to the cluster
        deploy error: knative deployer failed to deploy the Knative Service: admission webhook "validation.webhook.serving.knative.dev" denied the request: validation failed: missing field(s): spec.template.spec.containers[0].image
        Error: knative deployer failed to deploy the Knative Service: admission webhook "validation.webhook.serving.knative.dev" denied the request: validation failed: missing field(s): spec.template.spec.containers[0].image

    cmd.go:128: exit status 1
    cmd.go:83: /home/runner/work/func/func/func invoke -p /tmp/TestBasicUpload3227201013/001/test-func-basic-upload29khr
    cmd.go:127: Error: services.serving.knative.dev "test-func-basic-upload29khr" not found

    cmd.go:128: exit status 1
    scenario_basic_test.go:41: assertion failed: expression is false: strings.Contains(result.Out, "first revision"): Func body does not contain 'first revision'
    cmd.go:83: /home/runner/work/func/func/func delete -p /tmp/TestBasicUpload3227201013/001/test-func-basic-upload29khr
    cmd.go:127:

   Removing Knative Service: test-func-basic-upload29khr

   Removing Knative Service 'test-func-basic-upload29khr' and all dependent resources
        Error: knative remover failed to delete the service: services.serving.knative.dev "test-func-basic-upload29khr" not found

    cmd.go:128: exit status 1
--- FAIL: TestBasicUpload (76.11s)

Registry, after removing omitempty from Image:
=== RUN   TestBasicGit
    gitserver.go:83: Initialized HTTP Func Git Server: Server URL = http://func-git.default.<IP_ADDRESS>.sslip.io/ Pod Name = func-git-00001-deployment-69ff558-r54wv
    cmd.go:83: kubectl exec func-git-00001-deployment-69ff558-r54wv -c user-container -- git-repo create test-func-basic-gitctx2s
    cmd.go:122: Initialized empty Git repository in /var/www/git/test-func-basic-gitctx2s.git/
        created
    cmd.go:83: /home/runner/work/func/func/func create -l node /tmp/TestBasicGit4213784320/001/test-func-basic-gitctx2s
    cmd.go:83: sh -c git init
    cmd.go:83: sh -c git branch -M main
    cmd.go:83: sh -c git add .
    cmd.go:83: sh -c git config user.name "John Smith"
    cmd.go:83: sh -c git config user.email<EMAIL_ADDRESS>    cmd.go:83: sh -c git commit -m "initial commit"
    cmd.go:83: sh -c git remote add origin http://func-git.default.<IP_ADDRESS>.sslip.io/test-func-basic-gitctx2s.git
    cmd.go:83: sh -c git push -u origin main
    cmd.go:83: /home/runner/work/func/func/func deploy -p /tmp/TestBasicGit4213784320/001/test-func-basic-gitctx2s -r ttl.sh/knfuncmhujvp0s --remote --verbose --git-url http://func-git.default.svc.cluster.local/test-func-basic-gitctx2s.git
    cmd.go:127: Creating Pipeline resources
        Running Pipeline Task: Fetching git repository with the function source code
        Running Pipeline Task: Building function image on the cluster
        Running Pipeline Task: Deploying function to the cluster
        Error: failed to run pipeline: function pipeline run has failed with message:

        Warning: function has current image 'ttl.sh/knfuncmhujvp0s/test-func-basic-gitctx2s:latest' which has a different registry than the currently configured registry 'image-registry.openshift-image-registry.svc:5000/default'. The new image tag will be 'image-registry.openshift-image-registry.svc:5000/default/test-func-basic-gitctx2s:latest'.  To use an explicit image, use --image.
        ⬆  Deploying function to the cluster
        Waiting for Knative Service to become ready
        deploy error: knative deployer failed to wait for the Knative Service to become ready: RevisionFailed: Revision "test-func-basic-gitctx2s-00001" failed with message: Unable to fetch image "image-registry.openshift-image-registry.svc:5000/default/test-func-basic-gitctx2s:latest": failed to resolve image to digest: Get "https://image-registry.openshift-image-registry.svc:5000/v2/": dial tcp: lookup image-registry.openshift-image-registry.svc on <IP_ADDRESS>:53: no such host.
        Error: knative deployer failed to wait for the Knative Service to become ready: RevisionFailed: Revision "test-func-basic-gitctx2s-00001" failed with message: Unable to fetch image "image-registry.openshift-image-registry.svc:5000/default/test-func-basic-gitctx2s:latest": failed to resolve image to digest: Get "https://image-registry.openshift-image-registry.svc:5000/v2/": dial tcp: lookup image-registry.openshift-image-registry.svc on <IP_ADDRESS>:53: no such host.

    cmd.go:128: exit status 1
    cmd.go:83: /home/runner/work/func/func/func invoke -p /tmp/TestBasicGit4213784320/001/test-func-basic-gitctx2s
    cmd.go:127: Error: failure invoking 'http://test-func-basic-gitctx2s.default.<IP_ADDRESS>.sslip.io/' (HTTP 404)

    cmd.go:128: exit status 1
    scenario_basic_test.go:99: assertion failed: expression is false: strings.Contains(result.Out, "first revision"): Func body does not contain 'first revision'
    cmd.go:83: /home/runner/work/func/func/func delete -p /tmp/TestBasicGit4213784320/001/test-func-basic-gitctx2s
    cmd.go:83: kubectl exec func-git-00001-deployment-69ff558-r54wv -c user-container -- git-repo delete test-func-basic-gitctx2s
    cmd.go:122: deleted
--- FAIL: TestBasicGit (55.92s)

I am happy with this being an "as many as we can" thing.
if you have time, please open an issue noting that for some reason these fields are required to exist (they should not be) for Image and Registry, and we can proceed with removing as many as possible 👍🏻


Translation with status "maschine translated" outdates after date refreshing

Describe the Bug

Translations with status "maschine translated" are "outdated" after refreshing the date of their source translation.
Steps to Reproduce

Set two languages (for example English and Arabic) directly hanging from German (root language) in the language tree of a region.
Create a German translation.
Create an Arabic translation by MT, and create an English translation manually (not by MT)
See in the page tree that the German and English traslations are up-to-date (✅) and the Arabic one maschine-translated (🤖)
Open the German translation and click the button "Mark this page as up-to-date"
Go back to the page tree, see the German and English translations are up-to-date but the Arabic one is marked as outdated (⚠)

Expected Behavior

The Arabic translation should be up-to-date too.
Actual Behavior

The Arabic translation is outdated.
Additional Information

👀 The cause seems to be the order in which the translations are refreshed: after this reproduction procedure the German translation (version 2) and the English one (version 1) have time stamp of 16:04:12, where as the Arabic one 16:03:38.
💡It is recommended to implement/review this issue with redis activated.

Traceback

@MizukiTemma seems like it should be like that because when we update the source language without ticking an automatic translation and updating it, the machine translated stays unchanged and therefore it outdates if the source translation was updated without ticking an automatic translation. Shouldn't it behave like that?

No, Mizuki is right bcs we are not talking about the update button in the top right hand corner but about the "mark page as up to date" button (further down in the settings of the page) which presumes that nothing was changed, all information is up to date and only should update the date on all pages that are marked as up to date (with a tick in the translation status).

@osmers Thank you for explaining 👍
@lunars97 Sorry, I have overlooked your question 😿 Yes, it about the button "Mark this page as up-to-date" in the side box "Actions"


Get rid of Linux Podman Machine requirement and instead run escalated privileged CLI command.

Is your feature request related to a problem? Please describe
Podman Machine is a requirement in order to run this extension which causes inconveniences for Linux users.
It requires us create a separate podman machine, use it, as well as make sure that it also has the correct image too.
There have been numerous cases where Podman Machine isn't detected (it is not officially supported and a hidden feature of PD) and requires PD to be restarted to "use" the podman machine.
Why this is possible now:

BIB does not require us to "pull" the image (can pass in directory) now
We already have functions to "generate" the podman CLI code that would be ran.

There are also other cases:

Much faster, runs local not on VM
Podman Machine on Linux isn't "officially" supported and there may be bugs
Does not align with bib / osbuild team with regards to their development / they do not test on podman machine
Issues arise with cumbersome steps for setup.

Describe the solution you'd like
Instead, our extension could use the exec command / process command of PD extension to run a privileged command (https://github.com/containers/podman-desktop/blob/main/packages/extension-api/src/extension-api.d.ts#L4114) and run the following example command:
sudo podman run \
  --name httpd-bootc-image-builder \
  --tty \
  --privileged \
  --security-opt label=type:unconfined_t \
  -v /home/testuser/bootc/test123:/output/ \
  -v $HOME/.local/share/containers/storage:/var/lib/containers/storage \
  --label bootc.image.builder=true \
  quay.io/centos-bootc/bootc-image-builder:latest-1720185748 \
  quay.io/bootc-extension/httpd:latest \
  --output \
  /output/ \
  --local \
  --type \
  raw \
  --target-arch \
  amd64

Note that this is running the SUDO command but uses $HOME/.local/share/containers/storage/. for the storage. This means that the user can use podman rootless like normal, but just for building, it will use SUDO.
Describe alternatives you've considered
No response
Additional context
No response

I agree with @cgwalters.  If we get podman-bootc into a state where it can run on Linux without a machine and get the bootc-extension to use podman-bootc, it's a huge win.
Requires some organization and good planning along with commitments to meet deadlines.

So, I have a pretty strong opinion that this project should not be implementing its own logic here in the medium/long term but should just be a GUI around a CLI (and maybe that CLI exposes a language API).
There's a lot of related threads on the podman-bootc CLI for this, see: containers/podman-bootc#9
I feel strongly enough about this that I think this issue should be closed as a duplicate of #166

@vrothberg @cgwalters
For this issue I'm referring to the building image fix / removing the podman machine requirement as Linux builds aren't working right now. Not with regards to running the resulting image in a VM.
From my understanding https://github.com/containers/podman-bootc helps (at the moment) with regards to spinning up the VM / using the resulting built image / and there is no other features implemented right now with regards to bib / building the image.
I agree that we should get this in medium/long-term, but this issue should focus on the short-term fix of linux builds.

I would prefer it as a wrapper around a cli too, but I think it would depend on the timeline? i.e. when would podman-bootc support windows and be the preferred approach enough so that pages like https://osbuild.org/docs/bootc/ would change? If that was in the pipe/'soonish' then we should just wait and focus on that, but if not we'll likely need to do something in the meantime.

@germag WDYT?

Another caveat too is how Podman Machine on Podman Desktop is by default root / rootful on macOS and Windows when creating the machine, but non-root on Linux (since it requires no podman machine). From the PR: https://github.com/containers/podman-bootc/pull/58 we will be hardcoding: /var/lib/containers/storage (https://github.com/containers/podman-bootc/pull/58/files#diff-b617e9b9c374b3eb34e1995a6010fadc91cfaa59baba743b40bec8163eec0ed0R158). But bootc-image-builder requires root to function due to filesystem requirements.
macOS & Windows:

Podman Desktop is started rootful
User builds or pulls bootc image within PD (root)
Uses this extension or podman-bootc (already root)
Passes fine since everything is root

But the current cycle for Linux is (or will be with podman-bootc):

Podman Desktop is started on Linux (non-root)
User builds or pulls bootc image within PD (non-root)
Build using this extension or podman-bootc (requires root)
Error: User unable to use the image that they built / pulled since it was built in non-root environment and saved to ~/.local/share/containers/storage
Now requires opening a podman machine / using podman-bootc
Rebuild / pull image
Build again
Error: Run into qemu issues (see https://github.com/osbuild/bootc-image-builder/issues/540)

What I'm proposing for Linux is as a short-term fix until we are at 100% feature parity with bib for podman-bootc is:

Podman Desktop is started on Linux (non-root)
User builds or pulls bootc image within PD (non-root)
Extension runs privileged podman CLI command with ~/.local/share/containers/storage passed in, which uses the non-root images they had built (requires root)
Passes

TLDR; Linux builds are failing at the moment, due to very old Podman versions on different machines (openSUSE tumbleweed, fedora 40, etc.) using flakey podman machine's and we should fix them with this solution until Linux support is better.

Another caveat too is how Podman Machine on Podman Desktop is by default root / rootful on macOS and Windows when creating the machine, but non-root on Linux (since it requires no podman machine). From the PR: https://github.com/containers/podman-bootc/pull/58 we will be hardcoding: /var/lib/containers/storage (https://github.com/containers/podman-bootc/pull/58/files#diff-b617e9b9c374b3eb34e1995a6010fadc91cfaa59baba743b40bec8163eec0ed0R158). But bootc-image-builder requires root to function due to filesystem requirements.
What the current workflow looks like:
macOS & Windows:

Podman Desktop is started rootful
User builds or pulls bootc image within PD (root)
Uses this extension or podman-bootc (already root)
Passes fine since everything is root

But the current cycle for Linux is:

Podman Desktop is started on Linux (non-root)
User builds or pulls bootc image within PD (non-root)
Build using this extension or podman-bootc (requires root)
Error: User unable to use the image that they built / pulled since it was built in non-root environment and saved to ~/.local/share/containers/storage
Now requires opening a podman machine / using podman-bootc
Rebuild / pull image
Build again
Error: Run into qemu issues (see https://github.com/osbuild/bootc-image-builder/issues/540)

What I'm proposing for Linux is as a short-term fix until we are at 100% feature parity with bib for podman-bootc is:

Podman Desktop is started on Linux (non-root)
User builds or pulls bootc image within PD (non-root)
Extension runs privileged podman CLI command with ~/.local/share/containers/storage passed in, which uses the non-root images they had built (requires root). We already have this code ready-to-go in: https://github.com/containers/podman-desktop/blob/main/packages/extension-api/src/extension-api.d.ts#L4114
Passes

TLDR; Linux builds are failing at the moment, due to very old Podman versions on different machines (openSUSE tumbleweed, fedora 40, etc.) using flakey podman machine's and we should fix them with this solution until Linux support is better.


Update ttrpc for metadata and namespace support

Codecov Report

Merging #3321 into master will increase coverage by 0.04%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #3321      +/-   ##
==========================================
+ Coverage   44.83%   44.87%   +0.04%
==========================================
  Files         112      113       +1
  Lines       12311    12320       +9
==========================================
+ Hits         5520     5529       +9
  Misses       5943     5943
  Partials      848      848

Flag
Coverage Δ

#linux
48.81% <100%> (+0.04%)
:arrow_up:

#windows
40.26% <100%> (+0.05%)
:arrow_up:

Impacted Files
Coverage Δ

namespaces/ttrpc.go
100% <100%> (ø)

namespaces/context.go
55.55% <100%> (ø)
:arrow_up:

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 faa5f55...fa6a9f0. Read the comment docs.

Codecov Report

Merging #3321 into master will increase coverage by 0.04%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #3321      +/-   ##
==========================================
+ Coverage   44.83%   44.87%   +0.04%
==========================================
  Files         112      113       +1
  Lines       12311    12320       +9
==========================================
+ Hits         5520     5529       +9
  Misses       5943     5943
  Partials      848      848

Flag
Coverage Δ

#linux
48.81% <100%> (+0.04%)
:arrow_up:

#windows
40.26% <100%> (+0.05%)
:arrow_up:

Impacted Files
Coverage Δ

namespaces/ttrpc.go
100% <100%> (ø)

namespaces/context.go
55.55% <100%> (ø)
:arrow_up:

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 faa5f55...fa6a9f0. Read the comment docs.


Add Azure Backup Center Command

Proposed name of the new command
azbackup
Description
Backup center
Category
Backup Center
Url
https://portal.azure.com/#view/Microsoft_Azure_DataProtection/BackupCenterMenuBlade/~/overview

Closed by: https://github.com/merill/cmd/pull/107


Having trouble with TurboStream frame replacement

Sorry if I'm missing something obvious, but I'm trying to do the following:

post a form's contents to a rails controller
controller does its work and returns turbo-streams
have the page update the frames automatically

Right now, I can submit the data fine, see the controller working fine and it sends the two turbo-streams back to the browser, but request.js is not updating the frames.  I do have window.Turbo defined.
Here's my stimulus controller where the call is made:
import { Controller } from "@hotwired/stimulus"
import { Turbo } from '@hotwired/turbo-rails'
import { post } from<EMAIL_ADDRESS>
export default class extends Controller {
  static targets = [ 'form' ]

  async submit() {
    // Collect up the form field values
    let dd = this.formTarget.querySelectorAll('input,select')
    let data = {}
    dd.forEach((d) => {
      data[d.getAttribute('name')] = d.value
    })

    const url = this.formTarget.getAttribute('action')
    const response = await post(url, { responseKind: "turbo-stream", body: JSON.stringify(data) })
    if (response.ok) console.log("ok")
  }
}

And here's the relevant controller action:
    def save_mapping
      map_params = params.select { |p| p.start_with?('mapping') }

      import_map = []
      map_params.each do |map|
        import_map << [map[0].split('_')[1].to_i, map[1]]
      end

      @import.update(import_map: import_map)

      # TODO: Validate map

      mapping_data
      render turbo_stream: [
        turbo_stream.replace('example', partial: 'example'),
        turbo_stream.replace('mapping_form', partial: 'mapping_form')
      ]
    end

I've tried adding the responseKind and not adding it.  I've also tried returning just one frame in my stream.  It looks like everything is getting to the server and back, so I'm wondering if I'm not doing something I need to do on the return.
And I just tested it with the latest turbo-rails (0.8.1) but I had tested it previous with 0.7.10.  On the stimulus side, I'm using stimulus-rails 0.6.0, but also tested with 0.4.2. Finally, I am using the latest request.js from August 10th, per skypack here.
Am I doing this wrong, or am I expecting it to do something it doesn't do?  Thanks!

Apologies - this was totally my error. Had a typo in the turbo-frame id on the html. Some days it just pays to stay in bed. Sheesh.


Trogdor: Add Task State filter to /coordinator/tasks endpoint

Also ensures that the /tasks/{taskId} endpoint returns a semantically-correct 404 status code. It would previously return 500 since the NotFoundException was not handled anywhere.
cc @cmccabe

Can you rebase this change?

Rebased

Retest this please

Looks good overall.  I left a comment about types.

It looks like there is a findbugs warning that needs to be fixed.  Also there is a null check that needs to be added.  LGTM after that is done

I merged this to trunk.  It looks like you were missing a suppression for an NPathComplexity warning in in checkstyle.xml.  Please run ./gradlew check -x test or similar in the future so that you see these warnings before Jenkins does.


Positional args are handled incorrectly when -- is present

Test program:
#include "cxxopts.hpp"
#include <iostream>

using namespace std;

int main(int argc, char *argv[])
{
    for (int i = 0; i < argc; ++i)
        cout << i << " " << argv[i] << "\n";

    cxxopts::Options options("posargmaster", "shows incorrect handling");
    options.add_options()
        ("dummy", "oh no", cxxopts::value<string>())
        ;

    options.parse(argc, argv);

    for (int i = 0; i < argc; ++i)
        cout << i << " " << argv[i] << "\n";

    return 0;
}

Example invocations and output:
$ ./a.out a b
0 ./a.out
1 a
2 b
0 ./a.out
1 a
2 b

$ ./a.out -- a b
0 ./a.out
1 --
2 a
3 b
0 ./a.out

It could be i am missing something, but this seems strange to me. Is this the intended behavior? If so, how should I access the positional arguments when -- is used?

The following works, but I assume this is not it's meant to be used:
options.parse_positional({"", "", "positional"});
options.parse(argc, argv);

for(const auto& s : options["positional"].as<vector<string>>() )
    cout << s << "\n";

The two empty string can also any string not also declared as an option.

To capture the positional arguments in options you need to call parse_positional. Your second example is the correct way to do it, although you probably shouldn't use empty strings as option names.
I never thought of the case where you might not declare a positional option, and yet still use --. That part of it is probably a bug. I should probably make it leave the arguments alone after the -- if there are no positional options declared.

I should probably make it leave the arguments alone after the -- if there are no positional options declared.

This makes sense to me. The reason I didn't originally use parse_positional() was because the readme says "Positional arguments can be optionally parsed into one or more options" (my emphasis). This made me expect that the rest were left alone, and that I could do e.g. int n = options.parse(argc, argv) and then argv[n] would be the first unparsed (IOW. the first positional) argument (or maybe int n = options.getFirstPositional() or something along those lines; you get the idea).
Anyway, in my specific case I desired all positional arguments in one container, and using parse_positional() I got what I wanted :-) Thank you for this nice library.

Yes that should be its behaviour. I will fix this when I next get a chance.


(FACT-596) Update selinux_config_policy fact

The newer version of selinux use the term "Loaded policy name"
in lieu of "Policy from config file".
This updated version matches on both for backard compatibility
reasons.
This should fix FACT-756 as well.

CLA signed by all contributors.

@peterhuene do you know if cfacter needs touchup to match this?

@frconil Thank you for your contribution!
PR Triage Notes:

@frconil can you add a unit test for this change?
@frconil can you retarget at the stable branch?
We will also need to verify if this is an issue for cfacter, and file a ticket if needed /cc @peterhuene @MikaelSmith

@joshcooper I've added the changes and test on the stable branch, should I open a new PR and refer this one?

@frconil yes, can you close in favor of a pull on stable (also including the spec changes)?
Thanks!

Oops! I see you did as #848. Thanks!
Closing this one in favor of that.


What's node  version must used?

Hi, i'm testing node 14 to 16 nothing to work!
failed to activate
><EMAIL_ADDRESS>start /www/wwwroot/apiwav3 > node . ><EMAIL_ADDRESS>start > node . ><EMAIL_ADDRESS>start > node . ><EMAIL_ADDRESS>start > node . ><EMAIL_ADDRESS>start /www/wwwroot/apiwav3 > node .

any one have this?

[image: image.png]
El dom, 5 mar 2023 a la(s) 09:38, mDestaFadilah notifications-github
escribió:

Hi, i'm testing node 14 to 16 nothing to work!
failed to activate> @.*** start /www/wwwroot/apiwav3 > node . > @.*** start > node . > @.*** start > node . > @.*** start > node . > @.*** start /www/wwwroot/apiwav3 > node .
any one have this?
—
Reply to this email directly, view it on GitHub
https://github.com/ookamiiixd/baileys-api/issues/158, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABMMTXL3BSWGWKECY72QZZLW2SQOHANCNFSM6AAAAAAVQGRO3M
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

hallo?

Sorry.
El dom, 5 mar 2023 a la(s) 20:27, mDestaFadilah @.***)
escribió:

hallo?
—
Reply to this email directly, view it on GitHub
https://github.com/ookamiiixd/baileys-api/issues/158#issuecomment-1455292326,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABMMTXKSLWVRXXSJ47TINM3W2U4QZANCNFSM6AAAAAAVQGRO3M
.
You are receiving this because you commented.Message ID:
@.***>

Sorry.
I forgot that in GitHub nobody (other than me) can see images.
In the "Github Ookamiiixd Baileys-API" main page we can read this:
Requirements

NodeJS version 14.5.0 or higher

Transcript: It is a requirement that you must have NodeJs v14.5.0 or
higher.
Sorry for these drawbacks.
El dom, 5 mar 2023 a la(s) 20:27, mDestaFadilah @.***)
escribió:

hallo?
—
Reply to this email directly, view it on GitHub
https://github.com/ookamiiixd/baileys-api/issues/158#issuecomment-1455292326,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABMMTXKSLWVRXXSJ47TINM3W2U4QZANCNFSM6AAAAAAVQGRO3M
.
You are receiving this because you commented.Message ID:
@.***>

nothing to work, as you see in my describe, do you success? what node version using?

Ok i will be validate, i'm success using node 16.13.2

Hi, mdestafadilah.
I have two customers with NodeJs-v16.15.1-x64 and an older version of Baileys (june- or july-2022), both running fine.
Now in my dev PC I am trying to install Baileys (march-03-2023) with NodeJs-v18.12.1-x64, but I am receiving errors referring to Prisma and SQLite.... and I'll be glad if you or someone can help me.
First errors (in this issue now in march-2023) were related to Git, but I have made it available.
Thanks.


Problem with updating multiple charts with this same version

I have a problem with your tool when I try to update multiple charts under /charts directory with this same version.
I have two charts:

nginx
currency-exchange

I bumped the version for both of them to 2.0.10
HCR tool updates version for one of them and return information for the second chart that version 2.0.10 already exists.
2022-03-1[7](https://github.com/luafanti/helm-chart-private2/runs/5584761897?check_suite_focus=true#step:6:7)T11:07:26.[8](https://github.com/luafanti/helm-chart-private2/runs/5584761897?check_suite_focus=true#step:6:8)5[9](https://github.com/luafanti/helm-chart-private2/runs/5584761897?check_suite_focus=true#step:6:9)335444Z	info	hcr/main.go:32	pages-branch: "gh-pages", charts-dir: "charts", pre-release: false, tag: "", remote: "origin", token: *****, dry-run: false, helm-config: sign: false, key: <empty>, keyring: <empty>, passphrase-file: <empty>
2022-03-17T11:07:26.859750165Z	info	git/client.go:120	/usr/bin/git ls-remote --heads origin
2022-03-17T11:07:27.289094528Z	info	hcr/releaser.go:173	found gh-pages github pages remote branch
2022-03-17T11:07:27.28912633Z	info	hcr/releaser.go:46	github pages remote branch exists
2022-03-17T11:07:27.289291138Z	info	helm/client.go:80	start package charts/currency-exchange chart
2022-03-17T11:07:27.292047377Z	info	helm/client.go:85	chart charts/currency-exchange packaged as currency-exchange-2.0.[10](https://github.com/luafanti/helm-chart-private2/runs/5584761897?check_suite_focus=true#step:6:10).tgz
2022-03-17T[11](https://github.com/luafanti/helm-chart-private2/runs/5584761897?check_suite_focus=true#step:6:11):07:27.2927378[12](https://github.com/luafanti/helm-chart-private2/runs/5584761897?check_suite_focus=true#step:6:12)Z	info	helm/client.go:90	chart currency-exchange loaded
2022-03-17T11:07:27.292771914Z	info	helm/client.go:80	start package charts/nginx chart
2022-03-17T11:07:27.296044979Z	info	helm/client.go:85	chart charts/nginx packaged as nginx-2.0.10.tgz
2022-03-17T11:07:27.296554105Z	info	helm/client.go:90	chart nginx loaded
2022-03-17T11:07:27.296576706Z	info	hcr/releaser.go:54	charts packaged
2022-03-17T11:07:27.29665491Z	info	git/client.go:120	/usr/bin/git remote update origin --prune
2022-03-17T11:07:27.562056801Z	info	git/client.go:120	/usr/bin/git worktree add /tmp/gh-pages492250291 origin/gh-pages
2022-03-17T11:07:27.568467524Z	info	hcr/releaser.go:153	added github pages gh-pages worktree to /tmp/gh-pages492250291
2022-03-17T11:07:27.568537028Z	info	git/client.go:120	/usr/bin/git remote get-url --push origin
2022-03-17T11:07:28.110477873Z	info	github/client.go:64	release currency-exchange-2.0.10 created
2022-03-17T11:07:28.654474521Z	warn	github/client.go:82	close currency-exchange-2.0.10.tgz asset file: close currency-exchange-2.0.10.tgz: file already closed
2022-03-17T11:07:28.654521823Z	info	github/client.go:71	asset currency-exchange-2.0.10.tgz uploaded
2022-03-17T11:07:28.655564376Z	info	helm/client.go:140	loaded /tmp/gh-pages492250291/index.yaml index file
2022-03-17T11:07:28.656926445Z	info	git/client.go:120	/usr/bin/git remote get-url --push origin
2022-03-17T11:07:28.773447624Z	info	hcr/releaser.go:115	nginx release 2.0.10 already exists, skipping
2022-03-17T11:07:28.773483026Z	info	hcr/releaser.go:72	released charts and updated index
2022-03-17T11:07:28.773540929Z	info	git/client.go:120	/usr/bin/git add index.yaml
2022-03-17T11:07:28.776506578Z	info	git/client.go:120	/usr/bin/git commit -m "update index.yaml"
2022-03-17T11:07:28.781504331Z	info	git/client.go:120	/usr/bin/git remote get-url --push origin
2022-03-17T11:07:29.417265009Z	info	hcr/releaser.go:82	index updated and pushed to github pages
2022-03-17T11:07:29.4173455[13](https://github.com/luafanti/helm-chart-private2/runs/5584761897?check_suite_focus=true#step:6:13)Z	info	git/client.go:120	/usr/bin/git worktree remove /tmp/gh-pages492250291 --force
2022-03-17T11:07:29.420231659Z	info	hcr/releaser.go:160	removed github pages gh-pages worktree /tmp/gh-pages492250291
[{"chart":"currency-exchange","tag":"2.0.10","version":"2.0.10"},{"chart":"nginx","tag":"2.0.10","version":"2.0.10"}]
2022-03-17T11:07:29.420283961Z	info	helm/client.go:71	removed generated chart currency-exchange-2.0.10.tgz
2022-03-17T11:07:29.4203[15](https://github.com/luafanti/helm-chart-private2/runs/5584761897?check_suite_focus=true#step:6:15)[36](https://github.com/luafanti/helm-chart-private2/runs/5584761897?check_suite_focus=true#step:6:36)3Z	info	helm/client.go:71	removed generated chart nginx-2.0.10.tgz

Could you help me with this problem? Maybe I missed some part of configuration?

I made workaround with the below snippet but will be great if you will resolve it and we are able to use your tool without any tricks :)
      - name: Package and release chart
        run: |
          git config user.email<EMAIL_ADDRESS>          git config user.name "gh-action"

          for p in charts/*/
          do
            path=${p%*/}
            dir=$(basename $p)
            version=$(yq eval '.version' $path/Chart.yaml)
            echo $path $dir $version
            ./hcr -charts-dir $path -token "${{ secrets.GITHUB_TOKEN }}" -tag $dir-$version
          done

Hi @luafanti, v0.0.4 version should fix the issue. Let me know if everything works as it should.

Thx @pete911 for a quick update. I need to clarify one thing
Right now If I bump the version for two charts under /charts directory they go with a single release that contains both charts.

I expect to have releases per chart, but maybe my assumption is wrong and if I want to achieve it I always need to iterate over all subdirectories in /charts. Pls let me know :)

Hi @luafanti, the idea was to use one repo for a project/app plus its helm chart. As far as I understand the release has to be tagged. I tag it with the chart version. The problem is when you have two or more charts with the same version, I am going to check and test if the same tag can be used for different releases. Also I am not sure how it is going to work if I have lets say chart A version 0.1, chart B version 0.2, update chart A to 0.2 - tag 0.2 already exists but points to older commit.
If you have any suggestions how to make this work (we could use flags as well) let me know and I can do the changes.


zen-kernels: 5.12.9 -> 5.12.14

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

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

[x] Fits CONTRIBUTING.md.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 129258 run on x86_64-linux 1

18 packages marked as broken and skipped:

linuxPackages_lqx.anbox
linuxPackages_lqx.ixgbevf
linuxPackages_lqx.mxu11x0
linuxPackages_lqx.ndiswrapper
linuxPackages_lqx.phc-intel
linuxPackages_lqx.r8125
linuxPackages_lqx.rtl8723bs
linuxPackages_lqx.sch_cake
linuxPackages_lqx.tbs
linuxPackages_zen.anbox
linuxPackages_zen.ixgbevf
linuxPackages_zen.mxu11x0
linuxPackages_zen.ndiswrapper
linuxPackages_zen.phc-intel
linuxPackages_zen.r8125
linuxPackages_zen.rtl8723bs
linuxPackages_zen.sch_cake
linuxPackages_zen.tbs

100 packages failed to build and are new build failures:

linuxPackages_lqx.acpi_call: log was empty
linuxPackages_lqx.akvcam: log was empty
linuxPackages_lqx.amdgpu-pro: log was empty
linuxPackages_lqx.apfs: log was empty
linuxPackages_lqx.asus-wmi-sensors: log was empty
linuxPackages_lqx.batman_adv: log was empty
linuxPackages_lqx.bbswitch: log was empty
linuxPackages_lqx.bcc: log was empty
linuxPackages_lqx.bpftrace: log was empty
linuxPackages_lqx.broadcom_sta: log was empty
linuxPackages_lqx.can-isotp: log was empty
linuxPackages_lqx.chipsec: log was empty
linuxPackages_lqx.cpupower: plain log  |  pretty log
linuxPackages_lqx.cryptodev: log was empty
linuxPackages_lqx.ddcci-driver: log was empty
linuxPackages_lqx.digimend: log was empty
linuxPackages_lqx.dpdk-kmods: log was empty
linuxPackages_lqx.ena: log was empty
linuxPackages_lqx.evdi: log was empty
linuxPackages_lqx.facetimehd: log was empty
linuxPackages_lqx.fwts-efi-runtime: log was empty
linuxPackages_lqx.gcadapter-oc-kmod: log was empty
linuxPackages_lqx.hid-nintendo: log was empty
linuxPackages_lqx.intel-speed-select: log was empty
linuxPackages_lqx.isgx: log was empty
linuxPackages_lqx.it87: log was empty
linuxPackages_lqx.jool: log was empty
linux_lqx: log was empty
(linuxPackages_lqx.kernel): log was empty
linuxPackages_lqx.lttng-modules: log was empty
linuxPackages_lqx.mba6x_bl: log was empty
linuxPackages_lqx.mbp2018-bridge-drv: log was empty
linuxPackages_lqx.mwprocapture: log was empty
linuxPackages_lqx.netatop: log was empty
linuxPackages_lqx.nvidia_x11: log was empty
linuxPackages_lqx.nvidia_x11_beta: log was empty
linuxPackages_lqx.nvidia_x11_legacy340: log was empty
linuxPackages_lqx.nvidia_x11_legacy390: log was empty
linuxPackages_lqx.nvidia_x11_vulkan_beta: log was empty
linuxPackages_lqx.nvidiabl: log was empty
linuxPackages_lqx.oci-seccomp-bpf-hook: log was empty
linuxPackages_lqx.openafs: log was empty
(linuxPackages_lqx.openafs_1_8): log was empty
linuxPackages_lqx.openafs_1_9: log was empty
linuxPackages_lqx.openrazer: log was empty
linuxPackages_lqx.perf: log was empty
linuxPackages_lqx.r8168: log was empty
linuxPackages_lqx.rtl8188eus-aircrack: log was empty
linuxPackages_lqx.rtl8192eu: log was empty
linuxPackages_lqx.rtl8812au: log was empty
linuxPackages_lqx.rtl8814au: log was empty
linuxPackages_lqx.rtl8821au: log was empty
linuxPackages_lqx.rtl8821ce: log was empty
linuxPackages_lqx.rtl8821cu: log was empty
linuxPackages_lqx.rtl88x2bu: log was empty
linuxPackages_lqx.rtl88xxau-aircrack: log was empty
linuxPackages_lqx.rtw88: log was empty
(linuxPackages_lqx.rtlwifi_new): log was empty
linuxPackages_lqx.sysdig: log was empty
linuxPackages_lqx.system76: log was empty
linuxPackages_lqx.system76-acpi: log was empty
linuxPackages_lqx.system76-io: log was empty
linuxPackages_lqx.systemtap: log was empty
linuxPackages_lqx.tp_smapi: log was empty
linuxPackages_lqx.tuxedo-keyboard: log was empty
linuxPackages_lqx.v4l2loopback: log was empty
linuxPackages_lqx.v86d: log was empty
linuxPackages_lqx.veikk-linux-driver: log was empty
linuxPackages_lqx.vendor-reset: log was empty
linuxPackages_lqx.vhba: log was empty
linuxPackages_lqx.virtualbox: log was empty
linuxPackages_lqx.virtualboxGuestAdditions: log was empty
linuxPackages_lqx.xpadneo: log was empty
linuxPackages_lqx.zenpower: log was empty
linuxPackages_lqx.zfs: log was empty
(linuxPackages_lqx.zfsStable: log was empty
,linuxPackages_lqx.zfsUnstable): log was empty
linuxPackages_zen.amdgpu-pro: log was empty
linuxPackages_zen.apfs: log was empty
linuxPackages_zen.asus-wmi-sensors: log was empty
linuxPackages_zen.gcadapter-oc-kmod: log was empty
linuxPackages_zen.hid-nintendo: log was empty
linuxPackages_zen.isgx: log was empty
linuxPackages_zen.it87: log was empty
linuxPackages_zen.jool: log was empty
linuxPackages_zen.lttng-modules: log was empty
linuxPackages_zen.mba6x_bl: log was empty
linuxPackages_zen.nvidia_x11: log was empty
linuxPackages_zen.nvidia_x11_beta: log was empty
linuxPackages_zen.nvidia_x11_legacy340: log was empty
linuxPackages_zen.nvidia_x11_vulkan_beta: log was empty
linuxPackages_zen.sysdig: log was empty
linuxPackages_zen.system76: log was empty
linuxPackages_zen.system76-acpi: log was empty
linuxPackages_zen.systemtap: log was empty
linuxPackages_zen.tp_smapi: log was empty
linuxPackages_zen.tuxedo-keyboard: log was empty
linuxPackages_zen.v86d: log was empty
linuxPackages_zen.veikk-linux-driver: log was empty
linuxPackages_zen.vendor-reset: log was empty

61 packages built:

linuxPackages_lqx.hyperv-daemons
linuxPackages_lqx.ply
linuxPackages_lqx.tmon
linuxPackages_lqx.turbostat
linuxPackages_lqx.usbip
linuxPackages_lqx.x86_energy_perf_policy
linuxPackages_zen.acpi_call
linuxPackages_zen.akvcam
linuxPackages_zen.batman_adv
linuxPackages_zen.bbswitch
linuxPackages_zen.bcc
linuxPackages_zen.bpftrace
linuxPackages_zen.broadcom_sta
linuxPackages_zen.can-isotp
linuxPackages_zen.chipsec
linuxPackages_zen.cpupower
linuxPackages_zen.cryptodev
linuxPackages_zen.ddcci-driver
linuxPackages_zen.digimend
linuxPackages_zen.dpdk-kmods
linuxPackages_zen.ena
linuxPackages_zen.evdi
linuxPackages_zen.facetimehd
linuxPackages_zen.fwts-efi-runtime
linuxPackages_zen.hyperv-daemons
linuxPackages_zen.intel-speed-select
linux_zen (linuxPackages_zen.kernel)
linuxPackages_zen.mbp2018-bridge-drv
linuxPackages_zen.mwprocapture
linuxPackages_zen.netatop
linuxPackages_zen.nvidia_x11_legacy390
linuxPackages_zen.nvidiabl
linuxPackages_zen.oci-seccomp-bpf-hook
linuxPackages_zen.openafs (linuxPackages_zen.openafs_1_8)
linuxPackages_zen.openafs_1_9
linuxPackages_zen.openrazer
linuxPackages_zen.perf
linuxPackages_zen.ply
linuxPackages_zen.r8168
linuxPackages_zen.rtl8188eus-aircrack
linuxPackages_zen.rtl8192eu
linuxPackages_zen.rtl8812au
linuxPackages_zen.rtl8814au
linuxPackages_zen.rtl8821au
linuxPackages_zen.rtl8821ce
linuxPackages_zen.rtl8821cu
linuxPackages_zen.rtl88x2bu
linuxPackages_zen.rtl88xxau-aircrack
linuxPackages_zen.rtw88 (linuxPackages_zen.rtlwifi_new)
linuxPackages_zen.system76-io
linuxPackages_zen.tmon
linuxPackages_zen.turbostat
linuxPackages_zen.usbip
linuxPackages_zen.v4l2loopback
linuxPackages_zen.vhba
linuxPackages_zen.virtualbox
linuxPackages_zen.virtualboxGuestAdditions
linuxPackages_zen.x86_energy_perf_policy
linuxPackages_zen.xpadneo
linuxPackages_zen.zenpower
linuxPackages_zen.zfs (linuxPackages_zen.zfsStable ,linuxPackages_zen.zfsUnstable)

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 129258 run on x86_64-linux 1

18 packages marked as broken and skipped:

linuxPackages_lqx.anbox
linuxPackages_lqx.ixgbevf
linuxPackages_lqx.mxu11x0
linuxPackages_lqx.ndiswrapper
linuxPackages_lqx.phc-intel
linuxPackages_lqx.r8125
linuxPackages_lqx.rtl8723bs
linuxPackages_lqx.sch_cake
linuxPackages_lqx.tbs
linuxPackages_zen.anbox
linuxPackages_zen.ixgbevf
linuxPackages_zen.mxu11x0
linuxPackages_zen.ndiswrapper
linuxPackages_zen.phc-intel
linuxPackages_zen.r8125
linuxPackages_zen.rtl8723bs
linuxPackages_zen.sch_cake
linuxPackages_zen.tbs

7 packages failed to build and are new build failures:

linuxPackages_lqx.amdgpu-pro: log was empty
linuxPackages_lqx.nvidia_x11_legacy340: log was empty
linuxPackages_lqx.nvidia_x11_vulkan_beta: log was empty
linuxPackages_zen.amdgpu-pro: log was empty
linuxPackages_zen.hid-nintendo: log was empty
linuxPackages_zen.nvidia_x11_legacy340: log was empty
linuxPackages_zen.nvidia_x11_vulkan_beta: log was empty

149 packages built:

linuxPackages_lqx.acpi_call
linuxPackages_lqx.akvcam
linuxPackages_lqx.apfs
linuxPackages_lqx.asus-wmi-sensors
linuxPackages_lqx.batman_adv
linuxPackages_lqx.bbswitch
linuxPackages_lqx.bcc
linuxPackages_lqx.bpftrace
linuxPackages_lqx.broadcom_sta
linuxPackages_lqx.can-isotp
linuxPackages_lqx.chipsec
linuxPackages_lqx.cpupower
linuxPackages_lqx.cryptodev
linuxPackages_lqx.ddcci-driver
linuxPackages_lqx.digimend
linuxPackages_lqx.dpdk-kmods
linuxPackages_lqx.ena
linuxPackages_lqx.evdi
linuxPackages_lqx.facetimehd
linuxPackages_lqx.fwts-efi-runtime
linuxPackages_lqx.gcadapter-oc-kmod
linuxPackages_lqx.hid-nintendo
linuxPackages_lqx.hyperv-daemons
linuxPackages_lqx.intel-speed-select
linuxPackages_lqx.isgx
linuxPackages_lqx.it87
linuxPackages_lqx.jool
linux_lqx (linuxPackages_lqx.kernel)
linuxPackages_lqx.lttng-modules
linuxPackages_lqx.mba6x_bl
linuxPackages_lqx.mbp2018-bridge-drv
linuxPackages_lqx.mwprocapture
linuxPackages_lqx.netatop
linuxPackages_lqx.nvidia_x11
linuxPackages_lqx.nvidia_x11_beta
linuxPackages_lqx.nvidia_x11_legacy390
linuxPackages_lqx.nvidiabl
linuxPackages_lqx.oci-seccomp-bpf-hook
linuxPackages_lqx.openafs (linuxPackages_lqx.openafs_1_8)
linuxPackages_lqx.openafs_1_9
linuxPackages_lqx.openrazer
linuxPackages_lqx.perf
linuxPackages_lqx.ply
linuxPackages_lqx.r8168
linuxPackages_lqx.rtl8188eus-aircrack
linuxPackages_lqx.rtl8192eu
linuxPackages_lqx.rtl8812au
linuxPackages_lqx.rtl8814au
linuxPackages_lqx.rtl8821au
linuxPackages_lqx.rtl8821ce
linuxPackages_lqx.rtl8821cu
linuxPackages_lqx.rtl88x2bu
linuxPackages_lqx.rtl88xxau-aircrack
linuxPackages_lqx.rtw88 (linuxPackages_lqx.rtlwifi_new)
linuxPackages_lqx.sysdig
linuxPackages_lqx.system76
linuxPackages_lqx.system76-acpi
linuxPackages_lqx.system76-io
linuxPackages_lqx.systemtap
linuxPackages_lqx.tmon
linuxPackages_lqx.tp_smapi
linuxPackages_lqx.turbostat
linuxPackages_lqx.tuxedo-keyboard
linuxPackages_lqx.usbip
linuxPackages_lqx.v4l2loopback
linuxPackages_lqx.v86d
linuxPackages_lqx.veikk-linux-driver
linuxPackages_lqx.vendor-reset
linuxPackages_lqx.vhba
linuxPackages_lqx.virtualbox
linuxPackages_lqx.virtualboxGuestAdditions
linuxPackages_lqx.x86_energy_perf_policy
linuxPackages_lqx.xpadneo
linuxPackages_lqx.zenpower
linuxPackages_lqx.zfs (linuxPackages_lqx.zfsStable ,linuxPackages_lqx.zfsUnstable)
linuxPackages_zen.acpi_call
linuxPackages_zen.akvcam
linuxPackages_zen.apfs
linuxPackages_zen.asus-wmi-sensors
linuxPackages_zen.batman_adv
linuxPackages_zen.bbswitch
linuxPackages_zen.bcc
linuxPackages_zen.bpftrace
linuxPackages_zen.broadcom_sta
linuxPackages_zen.can-isotp
linuxPackages_zen.chipsec
linuxPackages_zen.cpupower
linuxPackages_zen.cryptodev
linuxPackages_zen.ddcci-driver
linuxPackages_zen.digimend
linuxPackages_zen.dpdk-kmods
linuxPackages_zen.ena
linuxPackages_zen.evdi
linuxPackages_zen.facetimehd
linuxPackages_zen.fwts-efi-runtime
linuxPackages_zen.gcadapter-oc-kmod
linuxPackages_zen.hyperv-daemons
linuxPackages_zen.intel-speed-select
linuxPackages_zen.isgx
linuxPackages_zen.it87
linuxPackages_zen.jool
linux_zen (linuxPackages_zen.kernel)
linuxPackages_zen.lttng-modules
linuxPackages_zen.mba6x_bl
linuxPackages_zen.mbp2018-bridge-drv
linuxPackages_zen.mwprocapture
linuxPackages_zen.netatop
linuxPackages_zen.nvidia_x11
linuxPackages_zen.nvidia_x11_beta
linuxPackages_zen.nvidia_x11_legacy390
linuxPackages_zen.nvidiabl
linuxPackages_zen.oci-seccomp-bpf-hook
linuxPackages_zen.openafs (linuxPackages_zen.openafs_1_8)
linuxPackages_zen.openafs_1_9
linuxPackages_zen.openrazer
linuxPackages_zen.perf
linuxPackages_zen.ply
linuxPackages_zen.r8168
linuxPackages_zen.rtl8188eus-aircrack
linuxPackages_zen.rtl8192eu
linuxPackages_zen.rtl8812au
linuxPackages_zen.rtl8814au
linuxPackages_zen.rtl8821au
linuxPackages_zen.rtl8821ce
linuxPackages_zen.rtl8821cu
linuxPackages_zen.rtl88x2bu
linuxPackages_zen.rtl88xxau-aircrack
linuxPackages_zen.rtw88 (linuxPackages_zen.rtlwifi_new)
linuxPackages_zen.sysdig
linuxPackages_zen.system76
linuxPackages_zen.system76-acpi
linuxPackages_zen.system76-io
linuxPackages_zen.systemtap
linuxPackages_zen.tmon
linuxPackages_zen.tp_smapi
linuxPackages_zen.turbostat
linuxPackages_zen.tuxedo-keyboard
linuxPackages_zen.usbip
linuxPackages_zen.v4l2loopback
linuxPackages_zen.v86d
linuxPackages_zen.veikk-linux-driver
linuxPackages_zen.vendor-reset
linuxPackages_zen.vhba
linuxPackages_zen.virtualbox
linuxPackages_zen.virtualboxGuestAdditions
linuxPackages_zen.x86_energy_perf_policy
linuxPackages_zen.xpadneo
linuxPackages_zen.zenpower
linuxPackages_zen.zfs (linuxPackages_zen.zfsStable ,linuxPackages_zen.zfsUnstable)

Does the auto-backport not work on merged PRs?

Oh, there it goes. Probably didn't work because I deleted the branch before.


Wrap widgets according to minimum size and then stretch them to fill available width

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce
Wrap cannot contain Expanded widgets, so is there another way to have its children laid out according to their minimum required width, but then make them fill the space using spaceBetween to stretch only with respect to the specified spacing? Respective discussion on stackoverflow.
Expected results
|---item---| |--item--|
|--------item---------|
Actual results
|-item-|       |-item-|
|-item-|
Code sample
Wrap(
                alignment: WrapAlignment.start,
                spacing: controller.width / 16,
                runSpacing: 8,
                children: controller.productVariants.value.map((e) {
                  return SizedBox(
                    width: controller.width / 6,
                    child: Obx(() {
                      return SizedBox(
                        width: controller.width,
                        child: SelectableContainerWidget(
                          isDisable: !e.isAvailable,
                          groupValue: controller.selectedSize.value,
                          value: e,
                          child: Text(
                            e.attributes!.size.value,
                            style: labelWithoutBold(
                              color: e.isAvailable
                                  ? e == controller.selectedSize.value
                                      ? Colors.white
                                      : Colors.black
                                  : Colors.black,
                            ),
                          ),
                          callback: () {
                            if (controller.selectedSize.value == e) {
                              controller.selectedSize.value = VariantsItem();
                            } else {
                              controller.selectedSize.value = e;
                              debugPrint("${controller.selectedSize.value.id}");
                            }
                          },
                        ),
                      );
                    }),
                  );
                }).toList(),
              ),

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.13.0, on Microsoft Windows [Version 10.0.19045.3448], locale en-US)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.3.4)
[√] Android Studio (version 2022.2)
[√] Android Studio (version 2022.3)
[√] Android Studio (version 2023.1)
[√] IntelliJ IDEA Ultimate Edition (version 2023.2)
[√] Connected device (4 available)
[√] Network resources
• No issues found!
UPDATE
Found one useful plugin for achieving the above result but still fill Wrap should have capability to achieve required result

Hi @Sumit258000
If your 3rd item has a fixed size, you can try using IntrinsicWidth as below:
https://github.com/flutter/flutter/assets/104349824/8c72450d-28e7-4f4c-a1dc-f50ad6dc8ec4

Complete sample code
import 'package:flutter/material.dart';

void main() {
  runApp(
    MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: const NewWidget(),
    ),
  );
}

class NewWidget extends StatelessWidget {
  const NewWidget({
    super.key,
  });

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Wrap(
          direction: Axis.horizontal,
          alignment: WrapAlignment.center,
          spacing: 4,
          children: <Widget>[
            Container(width: 100, height: 100, color: Colors.amber),
            Container(width: 100, height: 100, color: Colors.green),
            IntrinsicWidth(child: Container(width: 400, height: 100, color: Colors.red))
          ],
        ),
      ),
    );
  }
}

In case it has a dynamic size by layout change, please consider using LayoutBuilder for such case.
If you still believe this could be a bug of framework, please provide a completed and minimal reproducible code sample that represents the problem.
Instead, if you think that the issue might depend on your implementation, please also see flutter's community for resources and ask questions like this.

Thanks for your message @huycozy. All children have same size as I am rendring elements directly from server also number of elements can be vary the only thing that I expect is there should be some properties which can stretch the last child.
Yes I tried with LayoutBuilder also still you can't achive the desired result. Please see stack overflow discussion. So the only possible solution is to write a custom RenderBox widget.

So, you are proposing the last child in Wrap can be stretched (optional), correct? If so, it would be suited with a new proposal. If this can be solved with an alternative option at custom RenderBox widget, please use it. But if you still think this should be added to framework, please file an proposal for it. Thanks.

Thanks for your time I am closing this issue and filed a proposal for the same.


Np aliases

Fix warnings about np.int and np.float aliases being deprecated. See Issue #238

Deleting to remove skipping aperture tests. np fixes will be done in a clean branch.


Add Plugin support

Implements https://github.com/PaulRBerg/prb-proxy/discussions/42.

And some questions:

I'm just thinking out loud, but this plugin functionality introduce a vulnerability whereby a malicious target contract can call any arbitrary plugin by calling the fallback function on the proxy itself, after the user has called the target contract via the normal execute pathway?

We will need to think deeply about security issues that might appear since this does a delegatecall. We should properly think about attack vectors once the plugin system is closer to finality.
Currently, there is no permission schema for plugins.
I don't understand the example you're explaining. I'm not sure this is an issue since the executed code should still be trusted (is this right?). Could you add more details?
Also, it's important to understand trusted and untrusted actors in the system.

May I have your permission to edit the git commit messages based on the feedback above? Or, alternatively, you could do it. The idea would be to git push with --force.

I tried rewriting, but feel free to push commits (rewrite history), I gave you permission.

Excuse my interjection here :)
Re:

I'm just thinking out loud, but this plugin functionality introduce a vulnerability whereby a malicious target contract can call any arbitrary plugin by calling the fallback function on the proxy itself, after the user has called the target contract via the normal execute pathway?

It might be worth having a plugin (or method) type which gets only invoked with a staticcall instead of delegatecall.

Open questions:

I still need additional information regarding the security issues. At the moment I don't see an attack vector.
@newts6 how would the static call be useful? Can you give an example?
Installing a plugin can possibly overwrite another plugin. Should we make sure the installedPluginMethods[methodList[i]] == 0 first? Could we add an additional argument to install(plugin, bool overwrite)?
Uninstalling a plugin can potentially disable a method from another plugin. Should I make sure the removed method is from the specified plugin before deleting?

2. @newts6, how would the static call be useful? Can you give an example?

Assurance of a reduced attack surface with non state changing calls would allow a more modular security policy for plugin installers. i.e. being way more relaxed with read only plugins.
Several use cases could benefit, first and foremost EIP1271 implementations ofc. But also I suppose most callbacks for ERC721/1155 safe transfers.

Replies

I'm not sure this is an issue since the executed code should still be trusted (is this right?). Could you add more details?

I think you're right - if you give permission to a target contract and you delegate-call to it, then if they are malicious they can do other things directly. They don't need to jump through hoops and use the plugin system.
Target contracts are indeed trusted actors under the current design of PRBProxy, and the plugin system you have implemented is orthogonal to that.

feel free to push commits (rewrite history), I gave you permission

Thank you! I pushed with --force to update the historical commit messages.
NOTE: you might have to delete your local feat/plugins to be able to fetch the latest changes.

Installing a plugin can possibly overwrite another plugin

Good catch, but I think that this is fine. Plugins should not normally not overlap, just like ERCs don't usually overlap.
The complexity of implementing an overwrite check and the maintenance cost does not seem worth it to me. Similarly with the bool overwrite proposal - the overhead is not worth it.
Also, this is a rectifiable scenario - in case a user accidentally overwrites a plugin, they can simply uninstall it, and then install a new one that doesn't have the overwritten methods.

Should I make sure the removed method is from the specified plugin before disabling it?

In a similar vein to the above, I would classify this as a rectifiable issue that can easily be patched manually by the user.
I would have been open to implementing these checks if we had a different access control schema that allowed third-parties to call the installPlugin and uninstallPlugin functions on behalf of the user - in that case, a user could easily be caught off-guard by an accidental overwrite triggered by someone else.
But since in our implementation, it is the user only who can install and uninstall plugins, they should be well aware of what they are installing.
Also worth mentioning that the "user" referred to above wouldn't actually be the end user, i.e. the owner of the proxy - but rather a frontend developer who would parse the proxy API on behalf of the actual end user.
Feedback
On top of what I left in the comments above.
1. Test Function Names
This is something that I learned in the meantime - a few Foundry contributors are working on a new Foundry-based linter for Solidity called scopelint, which will use a specific regex for linting test function names. See point 2 in General Test Guidance section of the Foundry Book for more detail; for now, what matters it that I have updated your test names to adhere to these best practices. I will also update the base branch staging to follow this format, and then I will do the rebase myself.
2. Name of execute directory.
I think that it is confusing to use the same directory name for the plugin execution tests. I have renamed it to run-plugin to make a clear distinction between the core execution function tests, and the plugin runs.
3. No testing trees
The tests still do not conform with the testing tree approach - there are no *.tree files.
But don't worry, I know I have asked for a lot already. Thank you for getting the ball rolling with the first suite of tests - I will refactor them to adhere to the system I have in place.
4. Install and Uninstall Tests should be separated
Different functions are always tested separately.

Also, @cleanunicorn, FYI - I have pushed a big commit to address all of the feedback left in the code review comments.
I am still due to refactor the tests to adhere to the testing tree approach - but once that's done, we can merge this in, after you review my feedback, too, of course.

Codecov Report
Base: 100.00% // Head: 97.26% // Decreases project coverage by -2.74% :warning:

Coverage data is based on head (980f8e2) compared to base (15d23fd).
Patch coverage: 93.33% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff             @@
##           staging      #53      +/-   ##
===========================================
- Coverage   100.00%   97.26%   -2.74%
===========================================
  Files            3        3
  Lines           43       73      +30
  Branches         9       16       +7
===========================================
+ Hits            43       71      +28
- Misses           0        1       +1
- Partials         0        1       +1

Impacted Files
Coverage Δ

src/PRBProxy.sol
96.42% <93.33%> (-3.58%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Codecov Report
Base: 100.00% // Head: 100.00% // No change to project coverage :thumbsup:

Coverage data is based on head (c928a6c) compared to base (483affa).
Patch coverage: 100.00% of modified lines in pull request are covered.

:exclamation: Current head c928a6c differs from pull request most recent head 23ac929. Consider uploading reports for the commit 23ac929 to get more accurate results

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff            @@
##           staging       #53   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            3         3
  Lines           43        73   +30
  Branches         9        16    +7
=========================================
+ Hits            43        73   +30

Impacted Files
Coverage Δ

src/PRBProxy.sol
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

After pushing a few commits these days, we are now almost ready to merge this PR.
@cleanunicorn, could you take a final look at the latest changes to confirm that you're happy with the aesthetic changes I made (e.g. rename IPlugin to IPRBProxyPlugin, and rename methodList to methods)?

Two final security-related points from my end.
Strange Loops
Is it possible to install the proxy itself as a plugin by running the following steps:

Create a (malicious?) plugin contract that returns the methodList method selector itself in its implementation of methodList, among other methods implemented in PRBProxy itself (e.g. transferOwnership).
Call installPlugin and pass the proxy's address. The proxy itself will get stored as the associated plugin for the methodList method and the other method selectors, because the call to methodList will trigger a call to the fallback function, which would call the malicious plugin from step 1, which would return its method list.

Now, the fun part: calling any method not defined in the proxy itself will lead to infinite recursion in the fallback function, triggering a stack overflow.
However, calling a method defined in the proxy would result in a successful transaction. The question is whether this can lead to any exploit.
I don't think it can because all essential functions are protected by owner != msg.sender checks. Calling these functions via the fallback function would mean jumping through hoops to achieve the same goal.
Therefore, adding an explicit check in the installPlugin function that would prevent the proxy itself from becoming a plugin doesn't seem helpful to me - the gas cost would increase, but no security value would be added.
Empty Data
When the calldata is empty, the receive function gets called.

The PR LGTM now. Test coverage is 100%:

There were many conflicts and frankly I was unsure what was the fix for several of them - to avoid the risk of deleting something accidentally, I have squashed all commits in one commit (was going to do this anyway, before merging), and rebased.
PR ready for your final review, @cleanunicorn!

Strange Loops
Is it possible to install the proxy itself as a plugin by running the following steps:

Create a (malicious?) plugin contract that returns the methodList method selector itself in its implementation of methodList, among other methods implemented in PRBProxy itself (e.g. transferOwnership).

It is possible for the plugin to try to overwrite transferOwnership, however the PRBProxy.transferOwnership will take precedence over the method defined in the plugin. If no method in the PRBProxy matches the one called, then the fallback method is activated. Thus, the proxy can't overwrite methods in PRBProxy.

Call installPlugin and pass the proxy's address. The proxy itself will get stored as the associated plugin for the methodList method and the other method selectors, because the call to methodList will trigger a call to the fallback function, which would call the malicious plugin from step 1, which would return its method list.

Now, the fun part: calling any method not defined in the proxy itself will lead to infinite recursion in the fallback function, triggering a stack overflow.
However, calling a method defined in the proxy would result in a successful transaction. The question is whether this can lead to any exploit.
I don't think it can because all essential functions are protected by owner != msg.sender checks. Calling these functions via the fallback function would mean jumping through hoops to achieve the same goal.
Therefore, adding an explicit check in the installPlugin function that would prevent the proxy itself from becoming a plugin doesn't seem helpful to me - the gas cost would increase, but no security value would be added.

Any method defined in PRBProxy is tried before any method in an installed proxy is called. This should protect from multiple attack vectors since it uses the security properties of PRBProxy.

Empty Data
When the calldata is empty, the receive function gets called.

This should be regarded as receiving ether. I believe we desire this behavior.

Thanks for the final review, @cleanunicorn! I agree with all the points you made.


Change handling of xcode silent options to params instead of hash lookup

Because in most cases that options passed in is actually a Configuration from gym or scan and we can't look up random values in it

LGTM! 🚀


turn simplify_bool into normalise.

There is more normalisation we should do before flattening, the natural place for this is in simplify bool.
The most pressing example is canonicalisation, which would make flattening faster in some cases, will help with cse, and removes the need to do it later in the transformation chain.

I agree, we should make a format what we consider "normalized" expressions.
Two things which would make sense to me are:

Constraints taking a "collection" of arguments (alldiff, sum,...) should have their arguments sorted
Convert numpy constants into Python constants. This will massively simplify our solver interfaces as solvers often do not accept numpy input


Update mixed-reality-capture-directx.md

Add info about the Screen Capture API and OutputSubtype property support that was released last year.

@lordpi : Thanks for your contribution! The author(s) have been notified to review your proposed change.


1st draft of Unity client documentation and source code

Issue: #385

[ ] Tick here to confirm that you have run RunCodeFormatter.ps1

Description:
1st draft of Unity client SDK documentation and source code.

@dgkanatsios,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla.microsoft.com.
It will cover your contributions to all Microsoft-managed open source projects.
Thanks,
Microsoft Pull Request Bot

Closed due to not running code formatter


feat(masthead-l1): implement v2.1 layout & styles for desktop

Related Ticket(s)

#9954
ADCMS-2911: [L1 Nav]: Implement design updates (Desktop/Tablet)

Description
Updates the L1 nav for desktop sizes
Changelog
Changed

updates masthead-l1 to v2.1 layout & styles

@andy-blum While we wait to sort out the branch merging issues in the feat/masthead-v2-dev branch (@jkaeser's PR). I wonder if we can just cherry-pick the commits for the node 18 updates so that we can at least get a deploy preview going for design QA purposes. Let me know what you think.

Replaced by #10339


only reset value on range input

Closes https://github.com/yoshuawuyts/choo/issues/475
I also noticed that the whole purpose of this line (which is to update range slider value based on state) no longer works in chrome.  So we have a regression since https://github.com/yoshuawuyts/nanomorph/pull/51. I don't have time to track that down this moment.

v4.0.4 patch not found 👀


Drill refactor

Review changes #200.
Original action does not allow for single, standard and HA configuration clusters - had to apply some changes to move this on. Now all clusters can be initialized but there are some issues with running drill example. Tested on drill version 1.13 and image-version 1.2.27.
Current state:

All clusters initialize
For init action with zookeeper first   (--initialization-actions gs://dataproc-initialization-actions/zookeeper/zookeeper.sh,gs://.../drill/drill.sh  ) Drill sample works only for single node configuration. For others there is an error:

Error: Failure in starting embedded Drillbit: java.net.BindException: Address already in use (state=,code=0)
java.sql.SQLException: Failure in starting embedded Drillbit: java.net.BindException: Address already in use
        at org.apache.drill.jdbc.impl.DrillConnectionImpl.<init>(DrillConnectionImpl.java:142)
        at org.apache.drill.jdbc.impl.DrillJdbc41Factory.newDrillConnection(DrillJdbc41Factory.java:72)
        at org.apache.drill.jdbc.impl.DrillFactory.newConnection(DrillFactory.java:69)
        at org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:144)
        at org.apache.drill.jdbc.Driver.connect(Driver.java:72)
        at sqlline.DatabaseConnection.connect(DatabaseConnection.java:167)
        at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:213)
        at sqlline.Commands.connect(Commands.java:1083)
        at sqlline.Commands.connect(Commands.java:1015)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36)
        at sqlline.SqlLine.dispatch(SqlLine.java:742)
        at sqlline.SqlLine.initArgs(SqlLine.java:528)
        at sqlline.SqlLine.begin(SqlLine.java:596)
        at sqlline.SqlLine.start(SqlLine.java:375)
        at sqlline.SqlLine.main(SqlLine.java:268)
Caused by: java.net.BindException: Address already in use
        at sun.nio.ch.Net.bind0(Native Method)
        at sun.nio.ch.Net.bind(Net.java:433)
        at sun.nio.ch.Net.bind(Net.java:425)
        at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
        at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
        at org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:279)
        at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
        at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:218)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
        at org.eclipse.jetty.server.Server.doStart(Server.java:337)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
        at org.apache.drill.exec.server.rest.WebServer.start(WebServer.java:169)
        at org.apache.drill.exec.server.Drillbit.run(Drillbit.java:193)
        at org.apache.drill.jdbc.impl.DrillConnectionImpl.<init>(DrillConnectionImpl.java:133)
        ... 18 more
apache drill 1.12.0
"what ever the mind of man can conceive and believe, drill can query"
0: jdbc:drill:zk=local> SELECT * FROM cp.`employee.json` LIMIT 3;
No current connection
0: jdbc:drill:zk=local> Mar 21, 2018 3:36:16 PM org.glassfish.jersey.server.ApplicationHandler initialize
INFO: Initiating Jersey application, version Jersey: 2.8 2014-04-29 01:25:26...
Error: Failure in starting embedded Drillbit: java.net.BindException: Address already in use (state=,code=0)

For init action without zookeeper, drill samples work on single and standard configuration. For HA there is an error:

java.sql.SQLException: Failure in starting embedded Drillbit: java.lang.IllegalArgumentException: java.net.UnknownHostException: adamstasiak-test-13013-drill-ha
        at org.apache.drill.jdbc.impl.DrillConnectionImpl.<init>(DrillConnectionImpl.java:142)
        at org.apache.drill.jdbc.impl.DrillJdbc41Factory.newDrillConnection(DrillJdbc41Factory.java:72)
        at org.apache.drill.jdbc.impl.DrillFactory.newConnection(DrillFactory.java:69)
        at org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:144)
        at org.apache.drill.jdbc.Driver.connect(Driver.java:72)
        at sqlline.DatabaseConnection.connect(DatabaseConnection.java:167)
        at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:213)
        at sqlline.Commands.connect(Commands.java:1083)
        at sqlline.Commands.connect(Commands.java:1015)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36)
        at sqlline.SqlLine.dispatch(SqlLine.java:742)
        at sqlline.SqlLine.initArgs(SqlLine.java:528)
        at sqlline.SqlLine.begin(SqlLine.java:596)
        at sqlline.SqlLine.start(SqlLine.java:375)
        at sqlline.SqlLine.main(SqlLine.java:268)
Caused by: java.lang.IllegalArgumentException: java.net.UnknownHostException: adamstasiak-test-13013-drill-ha
        at org.apache.hadoop.security.SecurityUtil.buildTokenService(SecurityUtil.java:378)
        at org.apache.hadoop.hdfs.NameNodeProxies.createNonHAProxy(NameNodeProxies.java:310)
        at org.apache.hadoop.hdfs.NameNodeProxies.createProxy(NameNodeProxies.java:176)
        at org.apache.hadoop.hdfs.DFSClient.<init>(DFSClient.java:678)
        at org.apache.hadoop.hdfs.DFSClient.<init>(DFSClient.java:619)
        at org.apache.hadoop.hdfs.DistributedFileSystem.initialize(DistributedFileSystem.java:149)
        at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2653)
        at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:92)
        at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2687)
        at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2669)
        at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:371)
        at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:170)
        at org.apache.drill.exec.store.dfs.DrillFileSystem.<init>(DrillFileSystem.java:91)
        at org.apache.drill.exec.store.dfs.DrillFileSystem.<init>(DrillFileSystem.java:87)
        at org.apache.drill.exec.store.sys.store.LocalPersistentStore.getFileSystem(LocalPersistentStore.java:110)
        at org.apache.drill.exec.store.sys.store.provider.LocalPersistentStoreProvider.<init>(LocalPersistentStoreProvider.java:53)
        at org.apache.drill.exec.server.Drillbit.<init>(Drillbit.java:145)
        at org.apache.drill.exec.server.Drillbit.<init>(Drillbit.java:108)
        at org.apache.drill.jdbc.impl.DrillConnectionImpl.<init>(DrillConnectionImpl.java:132)
        ... 18 more
Caused by: java.net.UnknownHostException: adamstasiak-test-13013-drill-ha
        ... 37 more
apache drill 1.12.0
"start your sql engine"
0: jdbc:drill:zk=local> SELECT * FROM cp.`employee.json` LIMIT 3;
No current connection
0: jdbc:drill:zk=local> Error: Failure in starting embedded Drillbit: java.lang.IllegalArgumentException: java.net.UnknownHostException: adamstasiak-test-13013-drill-ha (state=,code=0)

@karth295  What do you think about those changes and issues?

Address in use error means there is already daemon listening on whatever port the Drillbit wants. Consider just moving it to a different port (not sure the config changes involved there).
The UnknownHostException is happening because your hostname is misspelled -- it should end with something like -m-0, right?

java.sql.SQLException: Failure in starting embedded Drillbit: java.lang.IllegalArgumentException: java.net.UnknownHostException: adamstasiak-test-13013-drill-ha
is fixed now. Second issue fix in progress.

@karth295
I've found a problem with Address already in use can be solved with ./drillbit.sh stop  command fired first before you exactly call
SELECT * FROM cp.`employee.json` LIMIT 3;
EOF```.

With scenario like described above, all clusters passed basic validation described on README.

More complicated issue is that UI service is not reachable for all configurations. @karth295 Could you check UI service on your side - I would be grateful because I cannot exactly find a clear explanation for problems - for some configuration with / without zookeeper UI is running, for some not.

Possible cause of this can be problem with zookeeper:
```java.io.IOException: Failure to connect to the zookeeper cluster service within the allotted time of 10000 milliseconds.
        at org.apache.drill.exec.coord.zk.ZKClusterCoordinator.start(ZKClusterCoordinator.java:128) ~[drill-java-exec-1.13.0.jar:1.13.0]
        at org.apache.drill.exec.server.Drillbit.run(Drillbit.java:177) [drill-java-exec-1.13.0.jar:1.13.0]
        at org.apache.drill.exec.server.Drillbit.start(Drillbit.java:398) [drill-java-exec-1.13.0.jar:1.13.0]
        at org.apache.drill.exec.server.Drillbit.start(Drillbit.java:372) [drill-java-exec-1.13.0.jar:1.13.0]
        at org.apache.drill.exec.server.Drillbit.main(Drillbit.java:368) [drill-java-exec-1.13.0.jar:1.13.0]

that can be found inside drillbit.log.

The zookeeper init action only seems to work on standard clusters: https://github.com/GoogleCloudPlatform/dataproc-initialization-actions/blob/master/zookeeper/zookeeper.sh#L50, and we should probably document that in the README.
Master nodes in an HA cluster already run zookeeper, so the extra init action is not necessary. (Kafka is similar, and we document in the README that you only need to run the zookeeper init action on standard clusters iirc).
You could modify the Zookeeper init action to work on single node clusters, and then run Drill in pseudo-distributed mode (master and worker daemons on the same node). That would be similar to how we run the master and worker HDFS/YARN daemons on a single node clusters.
However, that seems like a lot of work and would further reduce the limited memory available on a small single node cluster. If there's a way to run Drill as a single daemon without Zookeeper, that would be my vote. And the same thing for all the other init actions that don't work on single node clusters yet: https://github.com/GoogleCloudPlatform/dataproc-initialization-actions#initialization-actions-on-single-node-clusters.

According to your suggestions I modified test plan - you can check results below:
For init action without Zookeeper passed as init script:

node
SQL
UI

single-m v10
OK
OK

single-m v11
OK
OK

single-m v12
OK
OK

ha-m-0  v10
OK
OK

ha-w-0   v10
OK
OK

ha-m-0  v11
OK
OK

ha-w-0   v11
OK
OK

ha-m-0  v12
OK
OK

ha-w-0   v12
OK
OK

For init action with Zookeeper fired first

node
SQL
UI

| standard-m   v10| OK | OK |
| standard-w-0 v10| OK | OK |
| standard-m   v11| OK | OK |
| standard-w-0 v11| OK | OK |
| standard-m   v12| OK | OK |
| standard-w-0 v12| OK | OK |

Did you intend to push a commit? Or did it work as is?
Also please update the README explaining that: a) you need to run the zookeeper init action on standard clusters, and b) how it works on single node clusters.

It was no need to modify existing init action (after my changes) so only thing I've changed was test script.
I will update README.

@karth295  Could you make clear one scenario?
I've tried to execute sqlline query on master node with zk specified as worker - and that's working ok. I was able to get some data from example database. Is it possible to get the same on worker node with zk specified as master? I am getting error - ```Error: Failure in connecting to Drill: org.apache.drill.exec.rpc.RpcException: Failure setting up ZK for client. (state=,code=0)

Another thing: I've noticed that Zookeeper does not start on Standard cluster (only one where I have to install manually by passing extra init action). If I check zkServer.sh status I get it is not running. After I start it, then status is still not running.
```JMX enabled by default
Using config: /usr/lib/zookeeper/bin/../conf/zoo.cfg
2018-04-25 20:40:04,383 [myid:] - INFO  [main:QuorumPeerConfig@103] - Reading configuration from: /usr/lib/zookeeper/bin/../conf/zoo.cfg
2018-04-25 20:40:04,403 [myid:] - WARN  [main:QuorumPeerConfig@296] - Non-optimial configuration, consider an odd number of servers.
2018-04-25 20:40:04,404 [myid:] - INFO  [main:QuorumPeerConfig@340] - Defaulting to majority quorums
2018-04-25 20:40:04,406 [myid:] - ERROR [main:QuorumPeerMain@85] - Invalid config, exiting abnormally
org.apache.zookeeper.server.quorum.QuorumPeerConfig$ConfigException: Error processing /usr/lib/zookeeper/bin/../conf/zoo.cfg
	at org.apache.zookeeper.server.quorum.QuorumPeerConfig.parse(QuorumPeerConfig.java:123)
	at org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:101)
	at org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)
Caused by: java.lang.IllegalArgumentException: serverid standard-m is not a number
	at org.apache.zookeeper.server.quorum.QuorumPeerConfig.parseProperties(QuorumPeerConfig.java:364)
	at org.apache.zookeeper.server.quorum.QuorumPeerConfig.parse(QuorumPeerConfig.java:119)
	... 2 more
Invalid config, exiting abnormally```

Did you face with this kind of problem?

It looks like the master has id 1, and the workers have ids starting at 2: https://github.com/GoogleCloudPlatform/dataproc-initialization-actions/blob/master/zookeeper/zookeeper.sh#L37
What commands were you running btw? (I've never really tried Drill before).

Actually found a reason of problem on standard configuration.
That's because zookeeper init action (for some reason) sets /var/lib/zookeeper/myid content file to
'''
standard-m
1
'''
instead of
'''
1
'''
I've tested connection from master to worker-0 node and opposite with command:
'''
sudo ./bin/sqlline -u jdbc:drill:zk=standard-w-0:2181 <<"EOF"
SELECT * FROM cp.employee.json LIMIT 3;
EOF
'''
and it ... succeeded :)
Need to look more inside zookeeper init action to complete drill refactor testing. Propably I will submit another PR for zookeeper to make this script running correctly on standard configuration.

With zookeeper changed by #263 all my tests passed.
Scenarios I've checked:
For zookeeper clusters:

sql-distributed with drill-localhost command and web UI check
sql-dristributed with drill-conf command (Opens the Drill shell using the connection string to ZooKeeper nodes specified in drill-override.conf in  /conf.) and web UI check

For single node:

drill embedded and web UI check

Fixed with last commit.

Fixed with chmod 777 /usr/lib/drill/log. Please check now. I was able to call ./drill-embedded inside usr/lib/drill/bin directory without error message (fired this on cluster via ssh connection).

SGTM -- removed instructions for changing log directories since you can just run drill as any user now.


Swift3

Small additions and updates to the package.

Removal of DynamicColor dependency
Add a Number Formatter (optional) for the value label
Adjust the default max value
Tweak the factor calculation (becomes apparent why it's needed when used with a Number Formatter)

Added a few more commits here:

The AutoRepeatHelper had some code commented out that seriously messed up the stepper. Put that code back in and fixed it for Swift 4.
Slight tweaks to a few function signatures to be more "swifty".


feat(v2): add edit link to blog posts

🚀 Feature
Just like we have the "Edit on GitHub" link for docs, we want the same for blog posts.
Have you read the Contributing Guidelines on issues?
Yes
Motivation
More convenient way to edit blog posts.

@fanny this issue might help you gain familiarity with the Docusaurus v2 plugins 😄

@fanny this issue might help you gain familiarity with the Docusaurus v2 plugins 😄

For sure, I'll take. Can you assign for me?


Make install-cli compatible with dash on Linux

The <<< redirection is not available on dash (/bin/sh)
on linux systems, which makes our script and instructions
broken.
Fixes #66

@blagojts I tested this out and it works.


newHeads subscription with goethereum throws error

blocksSubscriber, err := ethClient.SubscribeNewHead(context.Background(), blockHeaders)
if err != nil {
log.WithFields(log.Fields{"err": err}).Fatal("New heads subscription")
}

....

block, err := ethClient.BlockByHash(context.Background(), blockHead.Hash())
if err != nil {
log.WithFields(log.Fields{"err": err}).Error("BlockByHash")
continue
}

I always get the following error, I dont understand it should be campatible since its evm, why I still keep getting this error.

Hi @0x090909 visit the official page to initiate a chat with our support team on the live chat to report your errors for review and for further assistance via Official Support

Hi there!
This is the deprecated repo of the old "classic" Arbitrum tech stack, no longer maintained.
I'll close this issue now, but if you are still encountering issues, consider the following options:

For issues related to node running we now have a dedicated page in our dev docs for Troubleshooting errors, and we also provide support in the channel #noderunning in the official Discord server.
For issues related to the node's codebase, feel free to open new tickets in the Arbitrum Nitro repository.


where is the Layout of class which extends from MaterialNavigationDrawer

Hi, I'm a newbie in Android.
I have a little question.
I created a class which extends from MaterialNavigationDrawer to use like a base Activity in my entire application. Any subclass of this Base Activity will have a Navigation Drawer automatically.
Where is the layout of class MaterialNavigationDrawer, or Base Activity?

This library implements the base layout for the navigation drawer activity.


Unable to retrieve SAP S4/HANA On-Premise destination with Kubernetes

The user has a CAP application with Kubernetes. After updating to the latest version of the SAP Cloud SDK they got the following error:  Error during request to remote service: Failed to load destination. Caused by: Failed to add proxy authorization header - client credentials grant failed! Caused by: Could not fetch client credentials token for service of type \"connectivity\"/ Caused by: Invalid service credentials: Missing url.

if it worked before, this issue was most likely caused when the connectivity service was recreated in your k8s cluster, currently the connectivity service with the connectivity_proxy plan misses a few fields that it has in its CloudFoundry equivalent.
The current workaround is to edit the connectivity service binding that should be represented as a secret in your cluster and add the field manually, however just like this issue, this workaround will stop working every time the service and its service binding are recreated.
To fix it for now, check if the secret containing the connectivity service binding contains these 3 fields, and if not, add them to the secret:
onpremise_proxy_host: connectivity-proxy.
onpremise_proxy_port: , default is 20003
url: should have the same value as token_service_url
To edit the secret just use kubectl edit secret , be aware that you have to add the values encoded in base64, for that you can simply use echo "" | base64, or if you get the value of token_service_url already in its base64 encoded form, just copy it over.

Hello @tomfrenken
I have a similar issue in my app deployed to Kyma. However, my error is a bit different.
Please have a look at the error once and suggest me what could be wrong:
,"statusCode":502,"reason":{"message":"Error during request to remote service: \nFailed to load destination. Caused by: Failed to add proxy authorization header - client credentials grant failed! Caused by: Could not fetch client credentials token for service of type \"connectivity\". Caused by: Breaker is open","request":{"method":"GET","url":"/A_BusinessPartner?
Thanks,
Shubham


⚠ Bofrost.lu has degraded performance

In 56951bd, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1865 ms

Resolved: Bofrost.lu performance has improved in 51898af after 6 minutes.


Allow storing Sockets directly into SocketSelector

Subject of the issue
Please add the ability to store, loop through and get sockets directly into a socketselector.
right now we have to store our sockets into a vectors or list which shouldn't be necessary since socket selector already holds onto sockets in some sort of way.
I propose that..

a indexer be made available.
a getCount() or getLength() method be made available .
allow the user to set a max amount of sockets of a socketSelector

Your environment
Windows 7 Ultimate 64 bit
SFML 2.5.0
Visual Studio 2019 Community
No compiler flags I know of

I'm not convinced this is a good idea. While it may be suitable for your use case, it restricts a bunch of other different use cases, for example I couldn't have multiple vectors of sockets which all use one socket selector, I'd need to have multiple socket selectors?
Also how would you know the types of the socket, for example if I have a mixture of TCPListener, TCPSocket and UDPSocket in the selector, Am I expected to use runtime type information? Many people don't like that.

it doesn't restrict anything because it would be a optional feature.

The main problem I see is ownership. You say it's an optional feature, but sf::SocketSelector would then have 2 APIs:

one that stores sockets (the one you propose)
one that references sockets (the existing one)

addSocket() would still only reference the sockets, and there would need to be a weirdly named counterpart for storing sockets. How would you even store the non-copyable sockets without move-semantics (SFML is still C++03)? Manual memory management is definitely a bad API choice.
And the problem @JonnyPtn mentioned is still there: when iterating sockets, you would need to do some sort of RTTI (dynamic_cast, typeid or manual type identifiers), or you might just store statically typed pointers elsewhere.
With all those problems and the extra confusion a dual API would bring, I don't really see the benefits. You might even store socket references separately in a GC language due to extra type safety (no downcast needed).

I don't even remember why I posted this.
I just know that setting up the networking required a lot of code which I felt could be shorter.
i'm closing this due to me not using the library anymore. I don't really like the c++ language anyway.


Crash when unsubscribing / resubscribing

Firing unsubscribe sometime causes a lockup when the last subscription is removed from a device.
The DeviceEmptyHandler in SharpDX_DirectInput seems to be crashing when calling _activeDevices[e].Dispose()
        private void DeviceEmptyHandler(object sender, DeviceDescriptor e)
        {
            _logger.Log($"Device {e.DeviceHandle} instance {e.DeviceInstance} is empty, disposing...");
            _activeDevices[e].Dispose();
            _activeDevices.TryRemove(e, out _);
        }

This calls PollingDeviceHandlerBase's Dispose() method
        public override void Dispose()
        {
            _pollThread.Abort();
            _pollThread.Join();
            _pollThread = null;
        }

When running in Visual Studio, it always works, but sometimes, if not running in Visual Studio, it hangs on the line _pollthread.Join();

Fixed in 0.10.6


Add "reproducer" role ignore to the right place

As a pull request owner and reviewers, I checked that:

[X] no test can be made at that point

I added a Depends-On in another patch (#1506) and it works fine.

/lgtm


Add testing

Codebase is getting really quite large now and errors do arise and are left unnoticed for longer than ideal, it's time for gulag to get some tests.

tests for packet serialization added in https://github.com/osuAkatsuki/gulag/commit/3dc0f3ef939a68b8f99e38d8e7df2a505390baa7

this is being kickstarted in #201

score sub integration test is already covering 50% of the codebase alone, many more tests can be added but i don't think an issue as generic as this needs to remain open anymore


Provide a working example for .zshrc?

Type:

[x] Enhancement

Minimal zshrc (with less than 30 lines)
:rofl: looking for one
source ~/.zplug/init.zsh

#zplug "foo/bar", tag:baz
#zplug "...

if zplug check || zplug install; then
  zplug load --verbose
fi

What you want
A minimal friendly .zshrc file that is, at least as friendly as the fish shell (provides convenience to completions subcommand completion, history search such as within-line substring based search simply through up and down arrow keys, a sensible prompt etc.). I tried the example provided in the README.md, snippets in the FAQ, and some other people's .zshrc files that are mentioned in the project Wiki.
While it is ultimately up to each user's taste to come up with a .zshrc, providing a good ground to start would be great. It would include: a minimal script that checks and installs ZPlug along with a list of "default" plugins that are selected to provide a friendly welcome.

Thanks for your suggestion. I understood. Are there any good examples? Pull requests are welcome.

Couldn't find one that simply fits into the system; most assume something
specific to the user and breaks in other system.
On Sun, Apr 9, 2017, 06:47 BABAROT<EMAIL_ADDRESS>wrote:

Thanks for your suggestion. I understood. Are there any good examples?
Pull requests are welcome.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/zplug/zplug/issues/391#issuecomment-292778218, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADGKW9qccYmZa90zMy7lXh2MSASknP8Kks5ruLctgaJpZM4M2Lfl
.

--
Sent from Gmail Mobile.


Angular npm instalation

Hi!!
How can I do the npm installation for angular use? Have you posted anything on npmjs.com?
Thanks for your time :)

Try https://www.npmjs.com/package/ol-popup.

yes, but no work in angular 4

I've not worked with Angular, do you know what's required and/ or can you provide some details of what's not working/ any errors etc.