Mastodon for iPhone (The native app)

GitHub Issue
App Store
App Store Market Tools
WTF

App ID:<PHONE_NUMBER>
Web
Forums
Patreon

Description

Mastodon is the largest decentralized social network on the internet. Instead of a single website, it’s a network of millions of users in independent communities that can all interact with one another, seamlessly. No matter what you’re into, you can meet passionate people posting about it on Mastodon!
Join a community and create your profile. Find and and follow fascinating folks and read their posts in an ad-free, chronological timeline. Express yourself with custom emoji, images, GIFs, videos, and audio in 500-character posts. Reply to threads and reblog posts from anyone to share great stuff. Find new accounts to follow and trending hashtags to expand your network.
Mastodon is built with a focus on privacy and safety. Decide whether your posts are shared with your followers, just the people you mention, or the whole world. Content warnings let you hide posts containing sensitive or triggering material until you're ready to engage with them. Each community has its own guidelines and moderators to keep its members safe, and robust blocking and reporting tools help prevent abuse.
More features:

Dark Mode: Read posts in light, dark, or true black mode
Polls: Ask followers for their opinion and tally the votes
Explore: Trending hashtags and accounts are a tap away
Notifications: Get notified about new follows, replies, and reblogs
Sharing: Post directly to Mastodon from any share sheet in any app
-Cuteness: Our mascot is an adorable elephant, and you'll see them pop up from time to time
Mastodon is a registered nonprofit and development is supported directly by your donations. There’s no advertising, no monetization, and no venture capital, and we plan to keep it that way.

Developer Contact

Mastodon
GitHub Repository

Embed

Keyboard Shortcuts

GitHub Issue
Gist
Keys Wiki

Updated as of release version 1.4.1. - 05182022-123850
Please note that the list below includes view-dependent commands.

Action
Command

Previous
K

Next
J

Back
H

Open
L

Open Author’s Profile
P

Open Reblogger’s Profile
⌥P

Reply to Post
⌥ ⇧ N

Toggle Reblog on Post
R

Toggle Favorite on Post
F

Toggle Content Warning
O

Preview Image
I

Switch to Home
⌘ 1

Switch to Search
⌘ 2

Switch to Notifications
⌘ 3

Switch to Profile
⌘ 4

Compose New Post
⌘ N

Show Favorites
⌘ F

Open Settings
⌘ ,

Previous Section
⌘ ⇧ [

Next Section
⌘ ⇧ ]

Discard Post
⌘ W

Publish Post
⌘ ⏎

Add Attachment - Browse
⌥ ⌘ B

Add Attachment - Photo Library
⌥ ⌘ P

Add Attachment - Take Phoro
⌥ ⌘ C

Toggle Poll
⇧ ⌘ P

Toggle Content Warning
⇧ ⌘ C

Select Visibility - Public
⌘ 1

Select Visibility - Followers Only
⌘ 2

Select Visibility - Only people I mention
⌘ 3

Paste
⌘ V

Paste and Match Style
⌥ ⇧ ⌘ V

Select All
⌘ A

Data
App Store Tools
Name = Mastodon for iPhone and iPad
Artist = Mastodon
Store URL = https://apps.apple.com/us/app/mastodon-for-iphone-and-ipad/id1571998974?uo=4
Store ID =<PHONE_NUMBER>
Download Size = 47.1 MB
Price = 0
Currency Code = USD
Formatted Price = Free
Release Date = Jul 30, 2021 at 02:00
Category = Social Networking
Description = Mastodon is the largest decentralized social network on the internet. Instead of a single website, it’s a network of millions of users in independent communities that can all interact with one another, seamlessly. No matter what you’re into, you can meet passionate people posting about it on Mastodon!
Join a community and create your profile. Find and and follow fascinating folks and read their posts in an ad-free, chronological timeline. Express yourself with custom emoji, images, GIFs, videos, and audio in 500-character posts. Reply to threads and reblog posts from anyone to share great stuff. Find new accounts to follow and trending hashtags to expand your network.
Mastodon is built with a focus on privacy and safety. Decide whether your posts are shared with your followers, just the people you mention, or the whole world. Content warnings let you hide posts containing sensitive or triggering material until you're ready to engage with them. Each community has its own guidelines and moderators to keep its members safe, and robust blocking and reporting tools help prevent abuse.
More features:
• Dark Mode: Read posts in light, dark, or true black mode
• Polls: Ask followers for their opinion and tally the votes
• Explore: Trending hashtags and accounts are a tap away
• Notifications: Get notified about new follows, replies, and reblogs
• Sharing: Post directly to Mastodon from any share sheet in any app
• Cuteness: Our mascot is an adorable elephant, and you'll see them pop up from time to time
Mastodon is a registered nonprofit and development is supported directly by your donations. There’s no advertising, no monetization, and no venture capital, and we plan to keep it that way.
Rating = 4.53597
of Ratings = 556
Rating (This Version) = 4.53597
of Ratings (This Version) = 556
Version = 1.4.2
Last Updated = May 23, 2022 at 17:46
Release Notes = - You no longer need an extendable thumb to make a new post. Button moved to the bottom!

You can navigate back by using pan gestures from the middle of posts now

New report dialog

Pull to refresh on hashtag screen

You can see "followers you follow" for profiles on the "For you" tab

You can finally browse who favourited and reblogged a post now

"Get started" has been renamed to "Sign up" on the start screen

"Search servers" prompt has been changed to "Search servers or enter URL" on the server pick screen

The app is no longer in Finnish on Swedish devices (sorry about that)

Other various fixes and improvements

Content Rating = 17+

Minimum OS Version = 14.0

Is Universal = Yes

Supports Game Center = No

Supported Devices = iPhone5s-iPhone5s

iPadAir-iPadAir

iPadAirCellular-iPadAirCellular

iPadMiniRetina-iPadMiniRetina

iPadMiniRetinaCellular-iPadMiniRetinaCellular

iPhone6-iPhone6

iPhone6Plus-iPhone6Plus

iPadAir2-iPadAir2

iPadAir2Cellular-iPadAir2Cellular

iPadMini3-iPadMini3

iPadMini3Cellular-iPadMini3Cellular

iPodTouchSixthGen-iPodTouchSixthGen

iPhone6s-iPhone6s

iPhone6sPlus-iPhone6sPlus

iPadMini4-iPadMini4

iPadMini4Cellular-iPadMini4Cellular

iPadPro-iPadPro

iPadProCellular-iPadProCellular

iPadPro97-iPadPro97

iPadPro97Cellular-iPadPro97Cellular

iPhoneSE-iPhoneSE

iPhone7-iPhone7

iPhone7Plus-iPhone7Plus

iPad611-iPad611

iPad612-iPad612

iPad71-iPad71

iPad72-iPad72

iPad73-iPad73

iPad74-iPad74

iPhone8-iPhone8

iPhone8Plus-iPhone8Plus

iPhoneX-iPhoneX

iPad75-iPad75

iPad76-iPad76

iPhoneXS-iPhoneXS

iPhoneXSMax-iPhoneXSMax

iPhoneXR-iPhoneXR

iPad812-iPad812

iPad834-iPad834

iPad856-iPad856

iPad878-iPad878

iPadMini5-iPadMini5

iPadMini5Cellular-iPadMini5Cellular

iPadAir3-iPadAir3

iPadAir3Cellular-iPadAir3Cellular

iPodTouchSeventhGen-iPodTouchSeventhGen

iPhone11-iPhone11

iPhone11Pro-iPhone11Pro

iPadSeventhGen-iPadSeventhGen

iPadSeventhGenCellular-iPadSeventhGenCellular

iPhone11ProMax-iPhone11ProMax

iPhoneSESecondGen-iPhoneSESecondGen

iPadProSecondGen-iPadProSecondGen

iPadProSecondGenCellular-iPadProSecondGenCellular

iPadProFourthGen-iPadProFourthGen

iPadProFourthGenCellular-iPadProFourthGenCellular

iPhone12Mini-iPhone12Mini

iPhone12-iPhone12

iPhone12Pro-iPhone12Pro

iPhone12ProMax-iPhone12ProMax

iPadAir4-iPadAir4

iPadAir4Cellular-iPadAir4Cellular

iPadEighthGen-iPadEighthGen

iPadEighthGenCellular-iPadEighthGenCellular

iPadProThirdGen-iPadProThirdGen

iPadProThirdGenCellular-iPadProThirdGenCellular

iPadProFifthGen-iPadProFifthGen

iPadProFifthGenCellular-iPadProFifthGenCellular

iPhone13Pro-iPhone13Pro

iPhone13ProMax-iPhone13ProMax

iPhone13Mini-iPhone13Mini

iPhone13-iPhone13

iPadMiniSixthGen-iPadMiniSixthGen

iPadMiniSixthGenCellular-iPadMiniSixthGenCellular

iPadNinthGen-iPadNinthGen

iPadNinthGenCellular-iPadNinthGenCellular

iPhoneSEThirdGen-iPhoneSEThirdGen

iPadAirFifthGen-iPadAirFifthGen

iPadAirFifthGenCellular-iPadAirFifthGenCellular

Supported Languages

AR - EU - CA - NL - EN - FI - FR - GD - GL - DE - IT - JA - KU - RU - ZH - ES - SV - TH - ZH - TR - VI

Local

Other Platforms

Description
A demonstration of the highly-considered onboarding feature coming in the official Mastodon app for iOS.
Learn more: https://joinmastodon.org/apps
Support the project and gain early access to the beta!: https://patreon.com/mastodon
A demonstration of the highly-considered onboarding feature coming in the official Mastodon app for iOS.

Learn more: https://joinmastodon.org/apps

Support the project and gain early access to the beta!: https://patreon.com/mastodon

noticed the icon has changed since you made this list. its now purple


Chrome Bug: Failed to read the 'selectionEnd' property from 'HTMLInputElement'

Hello together.
When I want to submit the survey I get the error:
build.js:1 Uncaught DOMException: Failed to read the 'selectionEnd' property from 'HTMLInputElement': The input element's type ('button') does not support selection.
    at i (chrome-extension://bpggmmljdiliancllaapiggllnkbjocb/content/build.js:1:29031)
    at i.showButton (chrome-extension://bpggmmljdiliancllaapiggllnkbjocb/content/build.js:2:2895)
    at chrome-extension://bpggmmljdiliancllaapiggllnkbjocb/content/build.js:2:1628

But that just happens with chrome explorer. I Use the Version: 55.0.2883.87
I implement the surver tool with your angular 2 distribution.

@Aventrue I just checked the code and find out that we do not has selectionStart or even 'selection' in the source and compiled JavaScript.
Do you use any another library or could you try to find any code that deal with to the selectionStart attribute or a setSelectionRage method?
The google tells that somewhere in your code or in a library, you are using, there is a code that tries to get/set selection from the button html element and it fails, since the button type doesn't support selectionStart/End attributes and a setSelectionRage method.
Thank you,
Andrew


Updating Export Grouping Button

Ticket Link
Ticket
List of squashed commits

Add new option to export grouping
Makes button looks more like dropdown

Test Checklist

[X] Unit Tests Passed:
[X] Jasmine Tests Passed:
[X] General Visual Inspection:

Personally I am 51/49, leaning just barely toward the smaller caret merely
for the sake of its compactness.
I also think I see the caret more commonly.
On Thu, Jul 20, 2023 at 1:28 PM Jordan Wong @.***>
wrote:

@.**** commented on this pull request.
In src/main/resources/templates/fragments/selected-grouping.html
https://urldefense.com/v3/__https://github.com/uhawaii-system-its-ti-iam/uh-groupings-ui/pull/837*discussion_r1270095743__;Iw!!PvDODwlR4mBZyAb0!V9MiTFno0NeL8fk4ckh0jSNu6eo5CoXyHOXPtfN-230-iHu6S9Xy20XweBkOZ2h32AYbLjKeNUd0tSjL6t9FpeuOrA$
:

           <button type="button" class="btn btn-primary btn-dropdown-split"

                   ng-disabled="!paginatingComplete || groupingMembers.length === 0"

                   ng-click="exportGroupToCsv(groupingMembers, 'members')">

               Export Members

           </button>

       <button type="button" class="btn btn-primary dropdown-toggle-split dropdown-toggle" data-toggle="dropdown"

               aria-label="More export options" aria-haspopup="true" aria-expanded="false"

               ng-disabled="!paginatingComplete || (groupingMembers.length === 0 && groupingExclude.length === 0)">

       <button type="button" class="form-control" data-toggle="dropdown"

               aria-haspopup="true" aria-expanded="false"

               ng-disabled="!paginatingComplete || (groupingMembers.length === 0 && groupingBasis.length === 0 && groupingInclude.length === 0 && groupingExclude.length === 0)">

           Export Grouping

I like the new design of the dropdown button but I also think adding a
caret/chevron would make the design even better because it tells the user
that this is a dropdown. Here are some designs with a caret or a chevron:
Caret:
[image: image]
https://urldefense.com/v3/__https://user-images.githubusercontent.com/42422209/255034425-9eaeb31e-3581-4827-973a-b43167836b87.png__;!!PvDODwlR4mBZyAb0!V9MiTFno0NeL8fk4ckh0jSNu6eo5CoXyHOXPtfN-230-iHu6S9Xy20XweBkOZ2h32AYbLjKeNUd0tSjL6t8W3iPaIQ$
I used this code after the "Export Grouping" text:
Chevron:
[image: image]
https://urldefense.com/v3/__https://user-images.githubusercontent.com/42422209/255035181-a71b2e32-136d-4c72-9fa0-d1aced3fdd65.png__;!!PvDODwlR4mBZyAb0!V9MiTFno0NeL8fk4ckh0jSNu6eo5CoXyHOXPtfN-230-iHu6S9Xy20XweBkOZ2h32AYbLjKeNUd0tSjL6t9nsv-3_w$
I used this code after the "Export Grouping" text:
Let me know what you think.
—
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/uhawaii-system-its-ti-iam/uh-groupings-ui/pull/837*pullrequestreview-1540274771__;Iw!!PvDODwlR4mBZyAb0!V9MiTFno0NeL8fk4ckh0jSNu6eo5CoXyHOXPtfN-230-iHu6S9Xy20XweBkOZ2h32AYbLjKeNUd0tSjL6t_0aohP-w$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ACX2CMBAQW5AE6PQHVKTBVDXRG5IFANCNFSM6AAAAAA2QQORBQ__;!!PvDODwlR4mBZyAb0!V9MiTFno0NeL8fk4ckh0jSNu6eo5CoXyHOXPtfN-230-iHu6S9Xy20XweBkOZ2h32AYbLjKeNUd0tSjL6t-o9ufmIg$
.
You are receiving this because your review was requested.Message ID:
<uhawaii-system-its-ti-iam/uh-groupings-ui/pull/837/review/1540274771@
github.com>


Improve reliability of Run-JS-Functional-Tests-BrowserBot-yaml

Additionally, explore separating monolithic job into separate jobs to speed up re-running of overall test (similar to E2E_BF-Streaming-DL-ASE_Test) which allows for the tests job to be run individually in the event of failures.
Supporting this would mean that the current process of creating a brand new Resource Group with new resources would need to be changed.

@BruceHaley, please verify if this is still needed. If not, please close it.


Allow running Inspektor Gadget in custom namespaces

Allow running Inspektor Gadget in custom namespaces
closes #2205
TODO

[ ] traceloop + advice doesnt work in other namespaces. Support? Error out on different namespace usage?
[ ] Right places?
[x] Found all references to the gadget namespace
[x] When having multiple instances of Inspektor Gadget deployed in different namespaces:

[x] Have different catalog contexts? See https://github.com/inspektor-gadget/inspektor-gadget/issues/2102 Wait for that Issue or not?

We will ignore that Issue for now. Future of the catalog is not known

[x] How to handle undeploy? We have the Clusterrole which is shared between all "instances" of Inspektor Gadget in different namespaces
[x] Make sure entrypoint.sh (or Go equivalent in Use distroless as base image #2207) supports several deployments in parallel. See comment

[ ] Should we use a templating engine for reading deploy.yaml?
Creating ServiceAccount/gadget...
Creating ClusterRole/gadget-cluster-role...
Creating ClusterRoleBinding/gadget-cluster-role-binding...
Creating Role/gadget-role...
Creating RoleBinding/gadget-role-binding...
Creating DaemonSet/gadget...
Creating CustomResourceDefinition/traces.gadget.kinvolk.io...
Waiting for gadget pod(s) to be ready...
1/1 gadget pod(s) ready
Retrieving Gadget Catalog...
gadgetNamespace: foobar
Inspektor Gadget successfully deployed

➭ go run ./cmd/kubectl-gadget/... trace tcp --gadget-namespace foobar
K8S.NODE        K8S.NAMESPACE  K8S.POD        K8S.CONTAINER  T PID     COMM    IP SRC                    DST
minikube-docker default        test-pod       test-pod       C 889154  wget    4  p/default/test-pod:395 r/<IP_ADDRESS>:80
minikube-docker default        test-pod       test-pod       X 889154  wget    4  p/default/test-pod:395 r/<IP_ADDRESS>:80
minikube-docker default        test-pod       test-pod       C 889154  wget    4  p/default/test-pod:434 r/<IP_ADDRESS>:443
^C%

➭ go run ./cmd/kubectl-gadget/... undeploy --gadget-namespace foobar
Removing traces...
Removing CRD...
Removing cluster role binding...
Removing cluster role...
Removing namespace...
Waiting for namespace to be removed...
Inspektor Gadget successfully removed

TODO:

[ ] Make sure entrypoint.sh (or Go equivalent in #2207) supports several deployments in parallel. See comment.

How to handle undeploy? We have the Clusterrole which is shared between all "instances" of Inspektor Gadget in different namespaces

I would rather have undeploy only targeting one namespace. Otherwise, this is OK to have, at first, undeploy to remove everything and having people dealing with undeploying by hand if they use specific namespace.

What about adding another flag to undeploy: --only-namespace. This would remove everything inside the specified namespace. So Role, Bindings, DaemonSet... The ClusterRole will still be there. We ofc have to document if one wishes to use multiple namespaces concurrently.
Then its their Job to "keep the ClusterRole alive"

Should we just add a new template parameter to the deploy.yaml?

If you refer helm stuff, yes it would make our life easier but it would mean having more feature in helm rather than with kubectl gadget deploy.

I meant more of a templating engine (like Jinja2) where we can put something like {{namespace}} in the yaml and have it populated automatically when we read it in golang.
That seems to be the best choice imo.

[ ]  Make sure entrypoint.sh (or Go equivalent in Use distroless as base image #2207) supports several deployments in parallel. See comment.

Seems like it will be fun :D
Added to the TODO

What about adding another flag to undeploy: --only-namespace.

Maybe --skip-clusterrole (and --skip-crd for the time being) instead? Sounds more specific.

Should we use a templating engine for reading deploy.yaml? (Using something like {{namespace}} inside the yaml and search/replace the corresponding places in golang)

Yeah, the standard go pkg text/template should be good for that.

Have different catalog contexts? See https://github.com/inspektor-gadget/inspektor-gadget/issues/2102 Wait for that Issue or not?

I think we should ignore that for now as we're not yet completely sure how to handle the catalog post-CG.

After thinking about the implementation of undeploy a bit I came up with the following Issue:
Lets say Person 1 deploys into namespace gadget-1 and Person 2 deploys into namespace gadget-2.
And assume Person 1 and Person 2 don't know each other at all. Just a coincidence that the want to debug the same cluster.
If we now have a mechanism which remove the single ClusterRole Person 1 could totally interfere with Person 2 or vice versa.
Suggestion: Every namespace creates its own ClusterRole? So every namespace only has its own objects to manage

Suggestion: Every namespace creates its own ClusterRole? So every namespace only has its own objects to manage

Alternatively, could we delete the gadget-cluster-role ClusterRole and use the view ClusterRole instead? The view ClusterRole is defined by Kubernetes so it should be present by default. It should have most of what we need already.
If you choose this solution, we would have to solve the following:

Do we still need to use the ClusterRoleBindings?
Can we use the security.openshift.io securitycontextconstraints securitycontextconstraints? It might be possible via another ClusterRole in OpenShift or with a ClusterRole aggregation

Suggestion: Every namespace creates its own ClusterRole? So every namespace only has its own objects to manage

Alternatively, could we delete the gadget-cluster-role ClusterRole and use the view ClusterRole instead? The view ClusterRole is defined by Kubernetes so it should be present by default. It should have most of what we need already.

In my minikube Cluster the role view can't list nodes:
➭ kubectl describe clusterrole view
Name:         view
Labels:       kubernetes.io/bootstrapping=rbac-defaults
              rbac.authorization.k8s.io/aggregate-to-edit=true
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources                                    Non-Resource URLs  Resource Names  Verbs
  ---------                                    -----------------  --------------  -----
  bindings                                     []                 []              [get list watch]
  configmaps                                   []                 []              [get list watch]
  endpoints                                    []                 []              [get list watch]
  events                                       []                 []              [get list watch]
  limitranges                                  []                 []              [get list watch]
  namespaces/status                            []                 []              [get list watch]
  namespaces                                   []                 []              [get list watch]
  persistentvolumeclaims/status                []                 []              [get list watch]
  persistentvolumeclaims                       []                 []              [get list watch]
  pods/log                                     []                 []              [get list watch]
  pods/status                                  []                 []              [get list watch]
  pods                                         []                 []              [get list watch]
  replicationcontrollers/scale                 []                 []              [get list watch]
  replicationcontrollers/status                []                 []              [get list watch]
  replicationcontrollers                       []                 []              [get list watch]
  resourcequotas/status                        []                 []              [get list watch]
  resourcequotas                               []                 []              [get list watch]
  serviceaccounts                              []                 []              [get list watch]
  services/status                              []                 []              [get list watch]
  services                                     []                 []              [get list watch]
  controllerrevisions.apps                     []                 []              [get list watch]
  daemonsets.apps/status                       []                 []              [get list watch]
  daemonsets.apps                              []                 []              [get list watch]
  deployments.apps/scale                       []                 []              [get list watch]
  deployments.apps/status                      []                 []              [get list watch]
  deployments.apps                             []                 []              [get list watch]
  replicasets.apps/scale                       []                 []              [get list watch]
  replicasets.apps/status                      []                 []              [get list watch]
  replicasets.apps                             []                 []              [get list watch]
  statefulsets.apps/scale                      []                 []              [get list watch]
  statefulsets.apps/status                     []                 []              [get list watch]
  statefulsets.apps                            []                 []              [get list watch]
  horizontalpodautoscalers.autoscaling/status  []                 []              [get list watch]
  horizontalpodautoscalers.autoscaling         []                 []              [get list watch]
  cronjobs.batch/status                        []                 []              [get list watch]
  cronjobs.batch                               []                 []              [get list watch]
  jobs.batch/status                            []                 []              [get list watch]
  jobs.batch                                   []                 []              [get list watch]
  endpointslices.discovery.k8s.io              []                 []              [get list watch]
  daemonsets.extensions/status                 []                 []              [get list watch]
  daemonsets.extensions                        []                 []              [get list watch]
  deployments.extensions/scale                 []                 []              [get list watch]
  deployments.extensions/status                []                 []              [get list watch]
  deployments.extensions                       []                 []              [get list watch]
  ingresses.extensions/status                  []                 []              [get list watch]
  ingresses.extensions                         []                 []              [get list watch]
  networkpolicies.extensions                   []                 []              [get list watch]
  replicasets.extensions/scale                 []                 []              [get list watch]
  replicasets.extensions/status                []                 []              [get list watch]
  replicasets.extensions                       []                 []              [get list watch]
  replicationcontrollers.extensions/scale      []                 []              [get list watch]
  ingresses.networking.k8s.io/status           []                 []              [get list watch]
  ingresses.networking.k8s.io                  []                 []              [get list watch]
  networkpolicies.networking.k8s.io            []                 []              [get list watch]
  poddisruptionbudgets.policy/status           []                 []              [get list watch]
  poddisruptionbudgets.policy                  []                 []              [get list watch]

Together with @mqasimsarfraz we looked at how prometheus does it:
The helm file is located at https://github.com/prometheus-community/helm-charts/blob/main/charts/kube-prometheus-stack/templates/prometheus/clusterrole.yaml
One can see that they prefixed their name with {{ template "kube-prometheus-stack.fullname" . }}- so they are different for "different installations":
→ helm install foo prometheus-community/kube-prometheus-stack
...
→ helm install bar prometheus-community/kube-prometheus-stack
...
→ kubectl get clusterrole
NAME                                                                   CREATED AT
admin                                                                  2023-11-10T09:27:15Z
bar-grafana-clusterrole                                                2023-11-10T10:49:59Z
bar-kube-prometheus-stack-operator                                     2023-11-10T10:49:59Z
bar-kube-prometheus-stack-prometheus                                   2023-11-10T10:49:59Z
bar-kube-state-metrics                                                 2023-11-10T10:49:59Z
...
foo-grafana-clusterrole                                                2023-11-10T10:46:21Z
foo-kube-prometheus-stack-operator                                     2023-11-10T10:46:21Z
foo-kube-prometheus-stack-prometheus                                   2023-11-10T10:46:21Z
foo-kube-state-metrics                                                 2023-11-10T10:46:21Z

I implemented it (for now) with 1 ClusterRole + ClusterRoleBinding per namespace:
➭ go run ./cmd/kubectl-gadget/... deploy --gadget-namespace foobar --image ghcr.io/inspektor-gadget/inspektor-gadget
Creating Namespace/foobar...
Creating ServiceAccount/gadget...
Creating ClusterRole/foobar-gadget-cluster-role...
Creating ClusterRoleBinding/foobar-gadget-cluster-role-binding...
Creating Role/gadget-role...
Creating RoleBinding/gadget-role-binding...
Creating DaemonSet/gadget...
Creating CustomResourceDefinition/traces.gadget.kinvolk.io...
Waiting for gadget pod(s) to be ready...
0/1 gadget pod(s) ready
0/1 gadget pod(s) ready
1/1 gadget pod(s) ready
Retrieving Gadget Catalog...
Inspektor Gadget successfully deployed

➭ go run ./cmd/kubectl-gadget/... trace tcp --gadget-namespace foobar
K8S.NODE             K8S.NAMESPACE        K8S.POD             K8S.CONTAINER       T PID        COMM       IP SRC                       DST
minikube-docker      default              test-pod            test-pod            C 547854     wget       4  p/default/test-pod:55262  r/<IP_ADDRESS>:80
minikube-docker      default              test-pod            test-pod            X 547854     wget       4  p/default/test-pod:55262  r/<IP_ADDRESS>:80
minikube-docker      default              test-pod            test-pod            C 547854     wget       4  p/default/test-pod:49284  r/<IP_ADDRESS>:443
^C%

➭ go run ./cmd/kubectl-gadget/... undeploy
Removing traces...
Removing CRD...
Removing cluster role binding...
Removing cluster role...
Inspektor Gadget successfully removed

➭ go run ./cmd/kubectl-gadget/... trace tcp --gadget-namespace foobar
K8S.NODE             K8S.NAMESPACE        K8S.POD             K8S.CONTAINER       T PID        COMM       IP SRC                       DST
minikube-docker      default              test-pod            test-pod            C 554064     wget       4  p/default/test-pod:40502  r/<IP_ADDRESS>:80
minikube-docker      default              test-pod            test-pod            X 554064     wget       4  p/default/test-pod:40502  r/<IP_ADDRESS>:80
minikube-docker      default              test-pod            test-pod            C 554064     wget       4  p/default/test-pod:43658  r/<IP_ADDRESS>:443
^C%

{18:33}~/codes/inspektor-gadget-3:burak/multiple_ns ✗ ➭ go run ./cmd/kubectl-gadget/... undeploy --gadget-namespace foobar
Removing traces...
Removing CRD...
Removing cluster role binding...
Removing cluster role...
Removing namespace...
Waiting for namespace to be removed...
Inspektor Gadget successfully removed

➭ go run ./cmd/kubectl-gadget/... trace tcp --gadget-namespace foobar
K8S.NODE             K8S.NAMESPACE        K8S.POD             K8S.CONTAINER       T PID        COMM       IP SRC                       DST
Error: running gadget: getting target nodes: get gadget pods: no gadget pods found. Is Inspektor Gadget deployed?
exit status 1

This is just a quick push to show how the current status is. If you want to look at the code either wait or review NOT commit-wise
Changes:

Daemonsets are launched in custom namespaces
Daemonset now has an additional env variable: GADGET_NAMESPACE
ContainerCollection map now has a prefix with the namespace
gadgettracermanager socket now has a prefix with the namespace
gadgettracermanager is now renamed to gadgettracermanager-
oci and nri hooks also have a prefix

In general everything resource which lives in the global k8s scope or the host node got a prefix/suffix except for the CRD.
Here a --skip-cdr was added to undeploy
As you can probably see, there are many comments which says // PoC or so. This is mostly the place where I read the original file and modify it so it contains a prefix or suffix.
Should we use the templating lib as proposed in https://github.com/inspektor-gadget/inspektor-gadget/pull/2208#issuecomment-1802815671 ?

This is just a quick push to show how the current status is. If you want to look at the code either wait or review NOT commit-wise
Changes:

Daemonsets are launched in custom namespaces
Daemonset now has an additional env variable: GADGET_NAMESPACE
ContainerCollection map now has a prefix with the namespace
gadgettracermanager socket now has a prefix with the namespace
gadgettracermanager is now renamed to gadgettracermanager-
oci and nri hooks also have a prefix

In general everything resource which lives in the global k8s scope or the host node got a prefix/suffix except for the CRD.
Here a --skip-cdr was added to undeploy
As you can probably see, there are many comments which says // PoC or so. This is mostly the place where I read the original file and modify it so it contains a prefix or suffix. Should we use the templating lib as proposed in #2208 (comment) ?

Now all commits are hopefully split into smaller and logical chunks

We should find a better way to handle the creation and removal of several namespaces. Rather than having a set of binaries for each namespace, we should make these binaries "multiple namespace aware" as much as possible. The real removal should occur when we remove the last running namespace.
I will also need to test the code.

The general problem is for having multi namespace aware executables is the same as the reason for --skip-crd: Which deploy/undeploy is responsible for creating the executables/deleting them.
With simple checks like seeing if there are any gadget pods or other Inspektor Gadget namespaces currently running is not enough. That situation will always have the TOCTOU problem. There is (currently) no guarantee after checking, e.g. existence of gadget pods, that the situation will stay the same.
This multiple executables problam just circumvents this problem.
Another one is having different version of Inspektor Gadget deployed. We would then need to support every version combination in parallel. Or limit the usage of versions to the one who first deployed the binaries.
I am also not a huge fan of multiple binaries, so any solutions (or problems for any implementation) are very welcome :)

That situation will always have the TOCTOU problem. There is (currently) no guarantee after checking, e.g. existence of gadget pods, that the situation will stay the same.

Any way to use a flock (or whatsoever locking k8s may offer like this or that) on a node (or several) to mitigate the TOCTOU problem? So, we take the lock each time we want to deploy/undeploy and we can in this case, have only one binary and a reference counter.

Nice. Such locking would ofc mitigate the race condition.
Now the only question is about version compatibility

Now the only question is about version compatibility

What is the use case for having several versions? Having one already installed and wanting to test a newer one? In this case, I would just point to test it another cluster, potentially a local one (e.g. minikube).

I actually don't know it supporting this makes sense. Thats the question.

We should think about keeping things simple and avoid adding extra complexity as much as possible.

This can also be said for the multiple and differently name binaries. The programs doesn't have to know about the existence of other "IG instances" deployed and do not need to synchronize with each other.
On the other hand if we support multiple "IG instances" with "single" binaries this removes the complexity with the multiple binaries

The first 2 commits (running IG in a custom namespace) is now its own PR https://github.com/inspektor-gadget/inspektor-gadget/pull/2250
This PR (#2208) was mainly discussing the parallel deployment so this PR will focus on that

What is the use case for having several versions?
Having one already installed and wanting to test a newer one?

I think the important use case here is for two users to deploy different versions of Inspektor Gadget, not for the same user to deploy different versions.
I don't see any other option to the "multiple binaries" solution.

After https://github.com/inspektor-gadget/inspektor-gadget/pull/2250 was merged, this PR is now rebased on top of those changes.
The current strategy is still to have multiple binaries (like gadgettracermanager etc. This is done so multiple users can use Inspektor Gadget at the same time with different versions in different namespaces. Not every user might now every other one.
Tests that I have done:

Multiple deployments in different namespaces (up to 3)
Deploying and Undeploying doesn't affect any other namespace
Tested the helm chart

In all cases, thank you for dealing with my comments.

Thank you for the constant reviews and fruitful discussions. which made the code better and clearer :)

I'm wondering about skip-crds thing. It seems difficult to use for me. Can't we use the same approach as with the hooks and have a different crd for each IG instance?

In the first versions of this PR traceloop etc were not supported. And I thought that CRDs will be removed soon :tm:
But with the current state I think there is no reason not to add a prefix to the CRDs

Also, is it feasible to add some tests to this feature? Ideally, two running the integration tests on two instances of IG running at the same time.

Good idea. I'll look into it

The latest modification since I lastly viewed are here: https://github.com/inspektor-gadget/inspektor-gadget/compare/440b5961ee598c02d0c18f41ca7a030ef4e5b456..099fca2fcd3464f861265c7a3264e2575b051807 ? Just to be sure I did not miss anything in the code.

You didn't miss anything. I had to work on other stuff. Will update this PR today or tomorrow

Since the final issue with this PR revolves around the CRD, I'll put this on hold until https://github.com/inspektor-gadget/inspektor-gadget/pull/2561 merges or any outcome of the PR is known


Explore updated built-in color themes

Our built-in themes (e.g. Dark+, Light+) are, as you might expect, among the most popular themes used by VS Code users. However, as the years have gone on, the themes are starting to feel dated. I think it's worth exploring how we could refresh them to ensure VS Code continues to feel modern and fresh as well as solving for known contrast/usability issues along the way.
Examples
These quick sketches show what Dark+ and Light+ could look like if only the workbench theme colors were updated. They do not change the syntax highlighting, however that could make sense as a next step.

Next steps
There are at least two clear options to move forward. I'm sure there are other approaches, but two obvious paths include:

Gradually update the existing themes over a series of releases.
Release a net new set of themes but keep the old themes as a "legacy" option. New installs would get the new themes automatically. Existing installs could be prompted to switch to the new theme or keep the legacy theme if they perfer.

Feedback and thoughts welcome 🙏

In my personal color theme, I painted the sidebar in the same color as the editor area so it would not attract the attention of peripheral vision while editing the code

I hope with GTK4, vscode on ubuntu can bend all 4 sides of the window. Currently the vscode window is still 4 square corners on ubuntu 22.

Here are some updates after talking with the team. Feedback welcome.
Rolling out the new themes
This is likely to take place over two phases:

Add "Experimental" themes to VS Code to gather feedback on the new themes
When ready, the new themes will be set as the default, replacing Dark+ and Light+. If you are currently using either the Dark+ or Light+ theme, you'll get a notification telling you that we've updated them. This notification will let you switch back to the old one if you'd prefer. It's likely that we will move the old themes to the marketplace rather than keep them in the product. This means you can install the themes as an extension pack.

So what do they look like?
Here are a few options that we're looking at:
Dark
Dark editor, everything else lighter:

Dark sidebar, everything else lighter:

Light editor, everything else darker:

Entire workbench normalized to one darker color:

Light
Grey sidebar, everything else white:

White editor, everything else grey:

Entire workbench normalized to white:

Yet another option: everything around the editor is painted in its color, the rest is darker

I throw my hat in for these 2:

Dark theme: Light editor, everything else darker
Light theme: White editor, everything else grey

They're the logical choice since we perceive lighter things to be close by and thus be the most important elements on screen.

Dark theme: Light editor, everything else darker
Light theme: White editor, everything else grey

👍 that's is basically what I went with to start. Here's a quick look at how it looks just touring around the basic UI:
https://user-images.githubusercontent.com/25163139/204674428-024a2a9f-880c-46eb-9659-2d19d16b3e2c.mp4
I'll get this landed in Insiders in the next week or so so you can give it a spin 🙏

The new themes are now merged via https://github.com/microsoft/vscode/pull/167104.
Please feel free to file new issues as you try them out so I can better track them individually 🙏

Nice work! 👍🏻
I'm not so experienced with themes in VS Code. How can we try it out?

Hi, i found a small issue. If i choose update built-in theme (Dark+ V2) the theme choice gets automatically reset to the the old Dark+ version. Same thing happens if i choose any other theme
Version: 1.75.0-insider
Commit: b92894493e6f971a3c71912d823e699d3a05d643
Date: 2022-12-08T05:37:36.940Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 22.2.0
Sandboxed: Yes
https://user-images.githubusercontent.com/65836795/206389533-485b9ecc-922f-4409-8045-0a94efc6873b.mov

Hi, i found a small issue. If i choose the updated built-in theme (Dark+ V2), the theme choice gets automatically reset to the the old Dark+ version. Same thing happens if i choose any other theme.
Version: 1.75.0-insider Commit: b928944 Date: 2022-12-08T05:37:36.940Z Electron: 19.1.8 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: <IP_ADDRESS>-electron.0 OS: Darwin arm64 22.2.0 Sandboxed: Yes
Screen.Recording.2022-12-08.at.09.48.12.mov

I can confirm that the same things happens for me with Insiders.

@nickolasoverlay @nonameolsson I see the same behavior now too after updating to today's Insiders. I believe this is an issue with the quick pick that isn't specific to themes. https://github.com/microsoft/vscode/issues/168425

@daviddossett Thanks for the tip! I also found another issue related to Default Light+ Experimental specifically.
The issue is related to the contrast of cursor inside integrated-terminal. In my specific case, cursor has a block shape (caused by Vim extension)

It would be better if we reduce saturation for code colors IMO.

The blue code color in updated light theme feels wield. It has a higher saturation than other colors of the theme.
We should lower its saturation IMO.

Tried new the Dark theme in 1.75. In my opinion, it is much darker than the previous theme, very close to #000000 and should be called "black theme", not "dark". Comparing with GitHub, for example, old dark theme is like "dark" and new dark theme is like "dark high contrast". I prefer to stay on old theme

I'm on the other side - the new themes are great! You can consider adding their more subdued variations in the future (e.g. a slightly lighter dark mode) but the current options are great and I use them every day :)

https://github.com/microsoft/vscode/issues/173475
Please inspect this bug when working with terminals under V2 themes.

@daviddossett would you prefer feedback on the new themes via separate issues, or in this thread?
A minor bit of feedback:
With Light+ v2, it's much harder to tell which tab in the sidebar is selected. Compare the two screenshots:

v1
v2

In the "old" theme, the whole icon foreground colour changes, so it's easy to see what tab is active at a glance. With the v2 theme, only the chip to the left indicates the selection, which is hard to see, especially when using a fullscreen or left-aligned window, as it blends in with the bezel of the screen.

would you prefer feedback on the new themes via separate issues, or in this thread?

Ideally in new issues. But I continue to monitor this one as I tweak the themes based on the feedback.
The active items are actually a darker/lighter color than the inactive items, but I agree that it could be more obvious. I'll see what I can do here and will push up some changes 👍

Thoughts on adding translucency and blurring to the sidebar and the tab bar?

@quackerex this is something we've talked about to inherit some nice Fluent design bits, but I believe it isn't possible with an electron-based app at the moment.

I wonder why the remote icon in the left-bottom corner is blue while the other areas are all white or black. It always attracts my eyes.

@zeyugao this is mostly to encourage usage of remote development. But we could consider making it less prominent if others have the same feedback. cc @bamurtaugh for remote context.

Yes, would definitely be interested in the broad remote indicator feedback here! As it's already a small and potentially unfamiliar button, the goal of a more prominent color is as @daviddossett mentions (attracting attention is a good thing from this perspective 😄).

Just wanted to chime in and say I just tried the new theme and I think it's really good; I made the switch from Material Theme and the contrast is generally a lot better in Dark+ V2, while it also doesn't look outdated like legacy Dark+.
The only thing I would say I don't like the high contrast when it comes to things like Git diff markers (I'm not sure what they're called?) — this is how they look (when you add a new line to a source-controlled file) in legacy Dark+:

And this is what it looks like in Dark+ V2 — it's too bright in my opinion, a slightly dimmer color would be more suitable:

Thanks for the find @aradalvand. I'll take a pass at these to make them less prominent 👍

Personal opinion: This blue border on focus is a bit distracting. And the right border is somehow hidden.

@mrcaidev it's easy to disable and AFAIK enabled for accessibility. You can disable it by adding this to your settings.json:
"workbench.colorCustomizations": {
    "focusBorder": "#ff000000",
    "list.focusAndSelectionOutline": "#ff000000",
}

One of the reasons I've really settled on VSCode as my editor is because the default Dark+ theme does not have a lot of high contrast.
The new V2 theme seems more like a hybrid between the Dark High Contrast and existing Dark+, and within seconds of having either of those themes open, my eyes begin to hurt and I can feel a headache forming. It's also a lot harder to read filenames that have problems - the contrast between the yellow and the black almost render my glasses useless, I'm curious if anyone else with an astigmatism is having similar problems.
Does moving the current Dark+ Theme to the marketplace mean it will eventually stop being maintained or not be updated as frequently? If so, would it be possible to call this theme "Dark+ Mid Contrast" or something instead?

@akpircher I don't see a reason why someone couldn't just keep using the old Dark+. I don't think they're going to remove it or anything.

@xamir82 they say pretty explicitly above that the experimental V2 will, once it's not experimental anymore, replace the Dark+ default and the current Dark+ will be moved to the marketplace.
Hence my questions about maintenance.

I think "Dark sidebar, everything else lighter" is the best choice, because it has just enough contrast, not too dark.
And it gives a better experience than the current "Dark+ V2" (it's too black)

On big difference keeping me from switching to Light+ V2 is the difference I see in my tabs. I currently depend on only the blue line at the top to indicate unsaved changes. On Light+ V2, the active tab has a blue line at the top, making me paranoid I've accidentally made an unintended change, or haven't hit save...

Hey folks, closing this issue now that we've shipped the themes as the new defaults in the stable release as Dark Modern and Light Modern 🚀
Please file individual issues for any feedback/bugs you see going forward. I've noted the issues in this thread, as well as other existing issues, and will be making another round of updates in the upcoming release(s). Thank you for the great feedback and ideas thus far!

@daviddossett Will syntax highlighting colors be updated too?

I would like to see a bit of work there 😺
For one, I think all of the colours get set to the same luminance, so that they come from the same palette.

@daviddossett what color theme do you use?

@daviddossett ooc what color theme + font do you use?

Dark Modern, default fonts. Light Modern of Light High Contrast if I'm working outside 😉 Also a fan of the GitHub themes.

If you want to keep the remote host button colors consistent.
  "workbench.colorCustomizations": {
    "statusBarItem.remoteBackground": "#181818"
  },


Issue 4 Implements the temporary collector.

The dirty table collector is now a temporary table, which allows it to be invisible when performing a "show tables;" command. The inserts in the table are also faster
A separate SnifferRepository was created instead of a repository inside the FixtureManager
The possibility to restart and stop a given Sniffer. This is necessary if the session with the DB is interrupted, e.g. when the Migrations class is used inside a test
It is possible to switch between temporary and main mode. In main mode, the dirty table is real

Let's discuss this @pakacuda before it gets merged into next.

Let's discuss this @pakacuda before it gets merged into next.


 In terminal window?
"$ markdown-toc -h <default: 3> -t bear [--no-write] "Bear Note Title"

It doesn't appear to work at all for me either. I tried all the commands listed for bear and always receive:
zsh: no matches found: [--no-write]
Not sure what I am doing wrong exactly.

[--no write] is a optional flag, you can do something like
markdown-toc -t bear "My Note Title"

Hi there @alexander-lee
I get the following error:
Traceback (most recent call last):
File "/usr/local/bin/markdown-toc", line 4, in
markdowntoc.main()
File "/usr/local/lib/python3.9/site-packages/markdowntoc/markdowntoc.py", line 295, in main
md_text_toc_pairs, identifiers = create_table_of_contents_bear()
File "/usr/local/lib/python3.9/site-packages/markdowntoc/markdowntoc.py", line 199, in create_table_of_contents_bear
notes = get_notes_from_bear()
File "/usr/local/lib/python3.9/site-packages/markdowntoc/markdowntoc.py", line 64, in get_notes_from_bear
return list(filter(lambda note: match_title_uuid_tag(note), notes))
File "/usr/local/lib/python3.9/site-packages/markdowntoc/markdowntoc.py", line 64, in
return list(filter(lambda note: match_title_uuid_tag(note), notes))
File "/usr/local/lib/python3.9/site-packages/markdowntoc/markdowntoc.py", line 58, in match_title_uuid_tag
note_tags = get_tags_in_note(note['ZTEXT'])
File "/usr/local/lib/python3.9/site-packages/markdowntoc/markdowntoc.py", line 75, in get_tags_in_note
lines_iter = iter(md_text.splitlines())
AttributeError: 'NoneType' object has no attribute 'splitlines'

Hmm which note are you using? What it looks like is that the note seems to empty?

I am using bear notes if that was what you were asking, I suspect not. Do I need to be in the folder where the notes are located possibly?

I am using bear notes if that was what you were asking, I suspect not. Do I need to be in the folder where the notes are located possibly?

@Mundeep-BBC try markdown-toc -h 3 -t bear "temp"
Or you can use the UUID (Right-click>Copy note's identifier) markdown-toc -h 3 -t bear "8F8B6D20-2177-47AD-9A3F-3ACC28492FC3-425-00018E359FE3B976"


npm run test 之后报错

$ npm run test

<EMAIL_ADDRESS>test D:\react-lz-editor-master
echo "Error: no test specified" && exit 1

"Error: no test specified"
npm ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\Program Files (x86)\node.exe" "C:\Users\Administrator\App                           Data\Roaming\npm\node_modules\npm\bin\npm-cli.js" "run" "test"
npm ERR! node v6.9.2
npm ERR! npm  v4.0.5
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>test: echo "Error: no test specified" && exit 1
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>test script 'echo "Error: no test s                           pecified" && exit 1'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the react-lz-editor packa                           ge,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     echo "Error: no test specified" && exit 1
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs react-lz-editor
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls react-lz-editor
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     D:\react-lz-editor-master\npm-debug.log

抱歉，暂时还没有实现测试脚本，您可以 clone 代码后，依次执行
npm install
npm run dev
查看运行效果。


Pending QuickSend Correct Fee TEST

Previously, fees were miscalculated before scan. FIXED
Whoohoo! This branch buffs the with_assertions module to make sure everything is right from the initial record, even before scanning the broadcast.
Previous incarnations of this branch failed. As recently as Wednesday, the following tests failed:
--- STDERR:              libtonode-tests::chain_generics chain_generics::propose_and_broadcast_40_000_to_transparent ---
thread 'chain_generics::propose_and_broadcast_40_000_to_transparent' panicked at /home/cupress/ZINGO/libs/pending/zingo-testutils/src/assertions.rs:32:9:
assertion left == right failed
left: 55000
right: 15000
--- STDERR:              libtonode-tests::chain_generics chain_generics::send_shield_cycle ---
thread 'chain_generics::send_shield_cycle' panicked at /home/cupress/ZINGO/libs/pending/zingo-testutils/src/assertions.rs:32:9:
assertion left == right failed
left: 124000
right: 20000
However, merging todayz dev fixed this!

@fluidvanadium should you click "Update Branch"?

I clicked update branch.


Closes: #1

Updated validations.py python script.# Please enter the commit message for your changes. Lines starting
Fixed the behavior of validate_user function in validations.py.
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

it was useful laba


runtime: some tests fails on Windows with CGO_ENABLED=0

What version of Go are you using (go version)?
go version go1.18 windows/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
OS: Windows 11
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\henry\AppData\Local\go-build
set GOENV=C:\Users\henry\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\henry\go\pkg\mod
set GONOPROXY=github.com/henryas
set GONOSUMDB=github.com/henryas
set GOOS=windows
set GOPATH=C:\Users\henry\go
set GOPRIVATE=github.com/henryas
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Users\henry\Programs\Go\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Users\henry\Programs\Go\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.18
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -fmessage-length=0 -fdebug-prefix-map=C:\Users\henry\AppData\Local\Temp\go-build230480319=/tmp/go-build -gno-record-gcc-switches
What did you do?
I tried to build go1.18 from source, by running all.bat. CGO_ENABLED is set to 0 (false).
What did you expect to see?
It should build and pass the tests.
What did you see instead?
It builds fine but fails the tests. Here are the failed tests:
--- FAIL: TestVectoredHandlerDontCrashOnLibrary (0.24s)
signal_windows_test.go:37: failed to build go library: exit status 1
go: no Go source files
--- FAIL: TestLibraryCtrlHandler (0.06s)
signal_windows_test.go:161: failed to build go library: exit status 1
go: no Go source files
FAIL
FAIL    runtime 83.530s

@gopherbot Please open backport issues
These tests will fail if run with CGO_ENABLED=0.  The fix is trivial and test-only.  We may as well backport it.


Broken link - How-much-do-parallel-jobs-cost

The Buy Self-hosted parallel jobs link under the 'How-much-do-parallel-jobs-cost' section is broken.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 43d1ea36-caf8-c3f6-95f3-2d40ead86f5a
Version Independent ID: 46755386-7c55-bd3a-7984-30687a4e94f3
Content: Configure and pay for parallel jobs - Azure DevOps
Content Source: docs/pipelines/licensing/concurrent-jobs.md
Product: devops
Technology: devops-cicd-licensing
GitHub Login: @steved0x
Microsoft Alias: jukullam

Not sure what it's supposed to link to.

It should go to here (later down on the same page)
https://docs.microsoft.com/en-us/azure/devops/pipelines/licensing/concurrent-jobs?view=azure-devops&tabs=self-hosted#how-do-i-buy-more-parallel-jobs
I'll get that updated. Although starting with Azure DevOps Server 2019 customers don't have to pay for self hosted parallel jobs.


anomaly-benchmarking: added generate-datasets

Here is the working implementation of the ODD paper. I made one minor change from the paper -- this script creates ten replicate datasets instead of 40. Special thanks to @charleslparker, for his resource deletion in the clean-data example.
Of note, I was running into some problems with queueing up too many datasets at once. This was "solved" by using create-and-wait-dataset even though I don't need to rely on that resource to continue.  It would be nice to not have to worry about parallelization when writing a whizzml script.

@akashenfelter when you say you were running into problems with queued datasets, was it executing in the server? if so, it'd be a bug in our server side and i'd like to investigate (if it's in the client side, that's a limitation of the client repl and cannot be solve, but the script should not use create-and-wait, since it's really meant to run on the server).

(which means that, no matter what, we should remove those create-and-wait from this script)

I got the error Error computing primitive operation 'create'. Error handling resource (You don't have enough credits available). Talking with @petersen-poul, he says that happens if you exceed the parallelization. I'm not sure it's a bug, as such. I can see why we wouldn't want an arbitrarily long queue.

But I would also welcome being able to create as many datasets as I want, and let the server figure out how to make them. :)

the server should already being figuring out how to parallelize your
tasks without problems.  the "you don't have enough credits available"
error might be related to the size of your jobs, not the level of
parallelism.  what are your subscription's parameters? (you didn't tell
me if you got the errors through the REPL or in an execution, but i'm
guessing the latter).  if your subscription parameters are fine, then
there's a bug in our server.

With further investigation, the queueing problem was when trying to run the script in the java repl, not as an execution. Everything is fine when run directly as packaged. I'm removing the -and-wait-.

Got it! If I didn't comment inline above, I've made the suggested change.  Rebased and ready to go.

Ah, thanks. Then I will have to carefully remove the predicted value one.

maybe one thing you can do to make that easier is to give it a different
name in the batch prediction request (by default, we use the same name
as the objective)... e.g. something like "predicted species"

That's what I came up with! That made it very easy to add to the "all_but" list.


add the interfaces doc of ipam.

Signed-off-by: hyzhou.zhy<EMAIL_ADDRESS>

Works for me, ipam use the discorver apis and ipam plugin must implement those discorver apis to get plugin work.

@Hyzhou @BSWANG Currently the discover calls are not proxied to the remote ipam plugin.
This is why they are not documented in ipam.md.

I am going to close this PR given the interface being added are in fact intentionally not exposed to the remote ipam driver as explained in the comment above.


symbol lookup error

Version: Jetpack 4.4
Device: AGX Xavier
Branch: 20.03
Getting an error after running the cppapi/build setup when trying to convert my model.onnx to model.plan
/retinanet-examples/extras/cppapi/build$ ./export model.onnx model.plan
./export: symbol lookup error: ./export: undefined symbol: _ZN9retinanet6EngineC1EPKcmmNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEfiRKSt6vectorIS9_IfSaIfEESaISB_EEbfiRKS9_IS8_SaIS8_EES8_S8_bm

Can you try the main branch with JP 4.6? For the first time the main branch has TRT8 which is compatible with recent container and JP4.6


[carbon] Add support for Coorest CC02 in CM & RA

KIP-37 passed with 178k KLIMA voting ‘for’ and 99.52% in favor.
Motivation
KlimaDAO seeks to offer a diverse array of carbon credits to its users. This goal can be advanced by adopting new digital carbon assets that undergo review and satisfy requirements around additionality, co-benefits, monitoring, reporting, and verification (MRV), and industry acceptance.
Coorest’s goal is to expand into partner ecosystems like KlimaDAO with their blockchain-native carbon credit token to gain more adoption for their assets.
Initial review, corroborated by discussions with advisors and among the community on the RFC, found that Coorest’s CCO2 digital carbon assets satisfied minimum requirements across the aforementioned factors.
Proposal
Add support for CCO2 tokens within KlimaDAO’s Retirement Aggregator.
KlimaDAO’s Retirement Aggregator serves as base layer digital carbon infrastructure and provides an interface for selecting digital carbon assets for retirement, as well as handling routing between disparate liquidity pools for any required trading to complete retirements. CCO2 support will allow users to retire their CCO2 tokens and create a retirement certificate via KlimaDAO’s infrastructure, as well as via Coorest’s in-house certificate generating mechanism.
Add support for CCO2 tokens on Carbonmark.
Carbonmark is the Universal Carbon Marketplace – an open-source, publicly available carbon credit market for every organization in the world seeking to acquire, trade, or retire carbon credits. Adding CCO2 listing, trading, buying and retiring support on Carbonmark will grant exposure to this asset for our various partners integrating with Carbonmark. Importantly, it will allow CCO2 to be accessed by digital carbon market participants via the Carbonmark interface, providing the same great user experience for both digitized (a.k.a. bridged) legacy credits and digitally-native credits like CCO2.

General reference links:
Coorest Docs: https://coorest.gitbook.io/coorest-dapp-manual/
CCO2 Token: https://polygonscan.com/token/0x82b37070e43c1ba0ea9e2283285b674ef7f1d4e2
Coorest Contract for creating PoCC: https://polygonscan.com/address/0x363ae9b7dbf55c0956a74c3be4ed0996d277a8be
An important note: CCO2 tokens represent 1kg of carbon, and not the 1 tonne other currently supported tokens represent.
Contracts
Retirement Aggregator

Need to be able to quote/discover a price. Currently tokens supported all have a KLIMA paired AMM liquidity pool to swap against. Does such a pool for CCO2 exist currently, and if so, what DEX is it using?
Gather the required information needed to correctly mint and produce a PoCC.
Any amounts quoted to or provided to the RA should use the native token amounts and decimals for CCO2.
There is mention of a retirement fee for CCO2. This should be included in any quote provided.

Carbonmark

CCO2 tokens are already abstracted and fungible with each other, and there may not be a way to list some generated from a specific batch. Need to research the docs a bit more, but if this is the case, we will need to add support for both the contract and API to handle only having essentially one fungible CCO2 project listed.
Work and price tokens in the native amounts, without worrying about converting between tonnes and kg.

Subgraphs
Polygon Digital Carbon

Add support for CCO2 tokens, and current holders.
Add details for NFTrees?Along with metadata on how many tokens are generated per annum for said NFTree?
Add support for all Coorest PoCC minting and related data.

This ticket and the information contained has been moved to a milestone epic in the klimadao-solidity repo
https://github.com/KlimaDAO/klimadao-solidity/milestone/1
All additional tasks for this workstream will be managed there.


CMake package registry breaks workspace isolation

We recently ran into issues with packages that leverage the CMake package registry feature. This feature does not seem to be compatible with build tools like catkin, colcon, etc.. Should catkin automatically be passing the CMake disable flags?
  -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON
  -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON

I don't know enough about the CMake package registry to make a suggestion here. It sounds reasonable to me though.
Even with these flags embedded by default the user should be able to pass different values if desired.
Would you like to create a pull request for the proposed change? Probably not only to catkin but also catkin_tools.
Just for reference the parallel ticket on colcon: colcon/colcon-cmake#91

This is a really subtle, but problematic issue with CMake, especially on Windows. I've experienced unexpected and highly undesirable behaviour from CMake's "magic" use of it's package registry where it's basically used a recently built version of a library in an unrelated workspace.
The way I see it, colcon's philosophy is to create a self-contained workspace which is at odds with the CMake package registry. It would be reasonable to disable the package regsitry by default an option to turn restore the default "magic" behaviour.
To avoid the issue though, you can use --cmake-args, --catkin-cmake-args and --ament-cmake-args to pass through the options you list above. Probably best to use either default.yaml or a mixin.


Performance related backports

https://hibernate.atlassian.net/browse/HHH-13494
https://hibernate.atlassian.net/browse/HHH-13495
https://hibernate.atlassian.net/browse/HHH-13527
https://hibernate.atlassian.net/browse/HHH-13531
https://hibernate.atlassian.net/browse/HHH-13534
https://hibernate.atlassian.net/browse/HHH-13544
https://hibernate.atlassian.net/browse/HHH-13512

updated it to incorporate review changes to https://github.com/hibernate/hibernate-orm/pull/2976

Now also including backport of https://hibernate.atlassian.net/browse/HHH-13512

:100:


Contributingmd file needed

Hi,
We can add the Contributing.md and CODE_OF_CONDUCT file to this project,
You can assign that to me I will add the required files.

Hi @FireCubeStudios ,
If the Changes in #22 and #27 looks good to you then please merge them.
For this once you are done with the implementation then we can update the contributing.md file with latest detatils.


cleanup(driver):  cleanup nested lookups

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug
/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area API-version

/area build

/area CI

/area driver-kmod

/area driver-bpf
/area driver-modern-bpf

/area libscap-engine-bpf

/area libscap-engine-gvisor

/area libscap-engine-kmod

/area libscap-engine-modern-bpf

/area libscap-engine-nodriver

/area libscap-engine-noop

/area libscap-engine-source-plugin

/area libscap-engine-savefile

/area libscap-engine-udig

/area libscap

/area libpman

/area libsinsp

/area tests

/area proposals

Does this PR require a change in the driver versions?

/version driver-API-version-major

/version driver-API-version-minor

/version driver-API-version-patch

/version driver-SCHEMA-version-major

/version driver-SCHEMA-version-minor

/version driver-SCHEMA-version-patch

What this PR does / why we need it:
Which issue(s) this PR fixes:
During additional modern_bpf tests (lucky me ... again) noticed that for a bespoke distro and kernel release running in a VM, the tty lookup caused the VM to freeze (no ssh possible anymore and couldn't kill the binary, had to force reload the VM). Never noticed such issues before when running modern_bpf on my Linux boxes etc.
Proposing to perform incremental lookups in exctract__tty and checks for each step - exactly like it's done in the old eBPF probe. With these changes everything now seems to work fine in the bespoke VM.
In addition, while here, super minor optimizations.
@Andreagit97 and @hbrueckner would it make sense to carefully re-audit over the next couple of weeks if (as a precaution) some other lookups could benefit from such incremental lookups and checks?

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: incertum
Once this PR has been reviewed and has the lgtm label, please assign hbrueckner for approval by writing /assign @hbrueckner in a comment. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

driver/OWNERS

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

@Andreagit97 and @hbrueckner would it make sense to carefully re-audit over the next couple of weeks if (as a precaution) some other lookups could benefit from such incremental lookups and checks?

First of all, thank you for spotting this!  :rocket:
As I said here https://github.com/falcosecurity/libs/pull/784#discussion_r1045231728, checking for !NULL  between lookups is a sort of anti-pattern in modern bpf (kernels >=5.11) since we can directly access the memory. BTW, if we have some corner cases like this it could be ok, but I would avoid changing it in other places if not necessary :/ BTW the bug here is quite strange, why an additional NULL check should help us in this situation? :thinking:

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, incertum
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

driver/OWNERS [Andreagit97]

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

LGTM label has been added.  Git tree hash: df9ac46eb8f6f09fe29aa695a68eebb5a85cc940

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP, incertum
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

driver/OWNERS [Andreagit97,FedeDP]

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

I would have also expect that the macros handle dereferencing correctly. Just guessing, maybe, there is also some kernel BPF related changes missing?!

It could be, dereferencing something like task->signal->tty->driver->major should be possible without risks of crashes :thinking: I would expect that the code stops at task->signal->tty returning an empty value :thinking:

Hi @Andreagit97 ,

I would have also expect that the macros handle dereferencing correctly. Just guessing, maybe, there is also some kernel BPF related changes missing?!

It could be, dereferencing something like task->signal->tty->driver->major should be possible without risks of crashes thinking I would expect that the code stops at task->signal->tty returning an empty value thinking

I briefly follow-up with @iii on that topic and so far the hang/crash is still strange :thinking: . In case of "faulty" access, e.g., 0/NULL in the deref chain, the ex_handler_bpf() in the kernel recovers and returns 0. Let's see if that is something which we see in other place.

Thanks @hbrueckner and @Andreagit97 following up on slack to further examine. In addition, next steps would be to ad-hoc deploy modern_bpf to some test servers and observe. If all goes well, default to modern_bpf on test clusters after the XMas break and then carefully venture out to canary servers.


A new release that supports MCMCChains 1.0

Hi Rob,
Does CmdStan support MCMCChains 1.0 already? If so, can we get a new release? Thank you.

Hi Mohamed,
Working on it! The plan is to leave the MCMCChains.Chains objects sorted when they are created in CmdStan. Hopefully Travis gets back up, not sure what's happening there.
Best,
Rob

v5.5 just got released.

Cool! Thanks for the super prompt response!


Docs: replace gitea with Gitea

Replaces the lower letters of gitea with the capital Gitea (if it's not a command or something similar).

Codecov Report

Merging #17838 (b19a3db) into main (2e8fc5b) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main   #17838      +/-   ##
==========================================
- Coverage   45.54%   45.53%   -0.01%
==========================================
  Files         808      808
  Lines       90056    90056
==========================================
- Hits        41013    41009       -4
- Misses      42489    42491       +2
- Partials     6554     6556       +2

Impacted Files
Coverage Δ

services/auth/signin.go
55.76% <ø> (ø)

modules/charset/charset.go
71.71% <0.00%> (-4.05%)
:arrow_down:

modules/git/repo_base_nogogit.go
82.85% <0.00%> (-2.86%)
:arrow_down:

modules/git/utils.go
68.05% <0.00%> (-2.78%)
:arrow_down:

models/issue_comment.go
52.40% <0.00%> (-0.85%)
:arrow_down:

services/pull/pull.go
41.78% <0.00%> (-0.41%)
:arrow_down:

modules/queue/queue_bytefifo.go
59.88% <0.00%> (+0.59%)
:arrow_up:

modules/queue/workerpool.go
49.23% <0.00%> (+1.52%)
:arrow_up:

modules/queue/queue_disk_channel.go
62.72% <0.00%> (+1.77%)
:arrow_up:

models/gpg_key_common.go
64.51% <0.00%> (+4.83%)
: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 04c55e9...b19a3db. Read the comment docs.


Fix inconsistent alerts by using the markdown notation - part 4

Why:
As described in the issue #35195 the display of alerts is inconsistent across the documentation.
As the original PR #35216 exceeded the linter limit of 300 files, this PR is part 4 of the changes. It provides changes to alerts across the documentation according to the docs guidelines using the Markdown notation.

What's being changed (if available, include any code snippets, screenshots, or gifs):
Alerts for note, tip, important and warning have been changed and unified from the liquid notation ({% note %}) to the Markdown notation (> [!NOTE]) according to the docs guidelines.

Check off the following:

[x] I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).

For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

[x] For content changes, I have completed the self-review checklist.

Just a note for the record! This series of PRs will be reviewed and merged in order, to keep this process as simple and efficient as possible 💛

@akordowski Part 4 approved! ✨ 🚀 Will get this merged shortly - thank you again 💛


Feature Request: add types for all responses using TypedDict

I was wondering if there is any interest in specifying the types of each response instead of just using Any. The types could be taken from the official API written in Typescript. I looked through #9 and so instead of using dataclasses, I'm proposing type hinting everything using TypedDict. This would make things quite easy for the users since they would get features like autocomplete and would be able run their code through a type checker. Essentially I'm suggesting something like the following:
class Database(TypedDict):
    ...

class DatabasesEndpoint(Endpoint):

    def retrieve(self, db_id: str) -> Database:
        ...

However, one possible issue I'm seeing with this approach is that the return types of the endpoints currently are not suitable for this as far as I know. The SyncAsync[T] does not work well with type checkers so instead separate endpoints classes for synchronous and asynchronous endpoints would need to be maintained.

Yes, I'm definitely interested if you're willing to add them and most importantly maintain them afterwards to stay up to date with the TS client. :)

Yupp I'm willing to add them and maintain them as well. I'll start working on it and hopefully if this makenotion/notion-sdk-js#294 gets resolved, then maintenance would be much easier.

@ramnes
I think we can do something like this? I checked that this works for mypy without errors. This way, we can still have one class for each set of endpoints (no separate classes for sync and async clients). This uses two overloads for each endpoint instead.
from __future__ import annotations
from typing import Generic, TypeVar, Any, TypedDict, Awaitable, Union, overload
from abc import ABC, abstractmethod

T = TypeVar('T', bound=Union[dict, Awaitable[dict]])
ResultDictType = TypeVar('ResultDictType')
MyDict = TypedDict('MyDict', {'name': str, 'age': int})

class Endpoint(Generic[T], ABC):
    def __init__(self, parent: BaseClient[T]) -> None:
        self.parent = parent

class MyDictOutputEndpoint(Endpoint[T]):
    @overload
    def get_something(self: MyDictOutputEndpoint[dict]) -> MyDict:
        ...

    @overload
    def get_something(self: MyDictOutputEndpoint[Awaitable[dict]]) -> Awaitable[MyDict]:
        ...

    def get_something(self) -> Awaitable[MyDict] | MyDict:
        return self.parent.request(method="get", cast_to=MyDict)

class BaseClient(Generic[T], ABC):
    def __init__(self):
        self.mydictoutput_endpoint = MyDictOutputEndpoint[T](self)

    @abstractmethod
    def request(self, method: str, cast_to: type[ResultDictType]) -> Awaitable[ResultDictType] | ResultDictType:
        pass

class Client(BaseClient[dict]):
    def request(self, method: str, cast_to: type[ResultDictType]) -> ResultDictType:
        return cast_to(**{'name': 'John', 'age': 42})

class AsyncClient(BaseClient[Awaitable[dict]]):
    async def request(self, method: str, cast_to: type[ResultDictType]) -> ResultDictType:
        return cast_to(**{'name': 'John', 'age': 42})

# how to use
mydict = Client().mydictoutput_endpoint.get_something()  # return type is MyDict

async def get_async() -> MyDict:
    return await AsyncClient().mydictoutput_endpoint.get_something()  # return type is Awaitable[MyDict]

Yes, we can definitely use @overload, have a look here for a PoC I wrote earlier: https://github.com/ramnes/notion-sdk-py/pull/200#issuecomment-1718229103

Thanks! I read your code, and the implementation was basically the same!! I'll make a draft pull request.

Hi everyone! 👋
I wanted to share that I’ve started working on a project called pydantic-api-sdk-notion, a Python SDK for the Notion API with type-safe support powered by Pydantic. This SDK leverages the excellent work done by notion-client (thanks, @ramnes! 🙌) and adds validation and type-hints for all Notion API interactions.
To make this possible, I’ve also created a separate repository called pydantic-api-models-notion, which maintains up-to-date Notion API data models based on the latest documentation. Most models are already complete, and I’m currently working on Block support. If you're someone who enjoys the benefits of type hints or needs them for better IntelliSense and validation, feel free to try it out!
GitHub repositories:

pydantic-api-sdk-notion
pydantic-api-models-notion

I’d love to hear your feedback, and I’m happy to collaborate with anyone interested in improving type-hint support for Notion's API! 😊


[5.0] Allow dot notation in .env to overwrite

Now that the ENV method is being used to pull SOME_VAR in over file.some.var, we are not able to easily add a new variable to .env. I think that when the variables in the .env should follow the dot notation, and the "env() ?:" stuff removed from the config arrays. Then any config could be dropped in the .env without having to wire it up all over the place.

So, I just ran a test... I'm not sure of the point of this request. It already works if you use dot notation over underscores. Underscores are simply the default provided look. You are free to change it if you wish. And if you are worried about uppercase vs lowercase, just be consistent since env variable naming is case-sensitive.
Is there something I'm missing to this request?
Also, another good tip to keep requests from being closed is to create them in the proper repository. Laravel takes advantage of the phpdotenv package to handle the environment configuration. So if you want something changed with how it is handled, issues need to be opened there. Please read the docs on the phpdotenv readme as well for more tips on how to setup nice env handling (like restricting what variables can be and requiring certain ones be given.)

I agree with @Garbee here.

This has nothing to do with case of variable or even if dotenv supports object oriented looking names. I know that dotenv will support the format--that point was more of a convention request to eep things consistent & make the automagically work.
It has to do with the fact that the config files are becoming default values unless overwritten by an ENV variable. It is just a matter of time when the remaining variables all get the env() method worked arround them, so instead, I'm proposing that Illuminate's config class (hence why this is a laravel/framework issue) just check to see if the env exist & use it. If not, then use the config files. With the naming convention above, this is a simple matter.

@Garbee it seems to me that all of your complaints have already been addressed:

I see you want  env('APP_DEBUG') for example to be overwritten with  app.debug=true  for example in the .env. This is just wrong.

No, env('APP_DEBUG') would not be overwritten since by default there would be no env('APP_DEBUG'). Keys in .env files would simply follow the same convention as Config::get and Config::set and that's it. Saying that "this is just wrong" is not an argument.

You can very easily just specify things consistently throughout your code (as you should) and use the env system's helpers to force required ones to be given on each install. No big deal.

Examples of how littering your config files with env helpers is uglier, more difficult to manage and more difficult to understand were already provided in this comment  above.

@Arhimandril, thanks for having the vision in seeing the need & understanding the request before commenting.

Ok, :fireworks: time.
config/filesystem.php
<?php

return [
'default' => env('filesystems.default')
];

MAGIC! You will get the same dot notation you want, the config engine will operate just fine. And no extra technical debt in the framework that someone has to maintain over time for no good reason! It is an AMAZING solution.... that I stated in my first comment.
As far as the "cleanliness" mentioned. That is all due to what is a misuse of the setup. You shouldn't be setting default void values that won't work. You should simply set them to env('config.path') and then in a service provider make the proper env variables required.

Keys in .env files would simply follow the same convention as Config::get and Config::set and that's it. Saying that "this is just wrong" is not an argument.

Funny how you say exactly what is already possible, as explained initially... Yet you are trying to show I am wrong somehow. Also as a side-note, I was pretty brief with my example, I really meant something more like this:
You want app.php:
<?php

return [
    'debug' => env('APP_DEBUG')
];

to be overridden by app.debug existing in the .env file. Since it follows the same dot notation as the config, if it exists it should be overridden entirely by the config engine. This is what I gathered from the original post (and as pointed out since is STILL entirely the way it is wanted.) Well, this is technical debt for no real good reason. It is confusing behavior unless you are one of the few people who would understand it and then even take advantage of it.
Narrow use-case code, extra logic in core creating debt to maintain, already available end-goal... Not a good request to be implemented. The benefits just aren't there to outweigh the negatives of addition.

@Garbee that seems to me like the opposite of "magic". We're just manually repeating ourselves all over the place. Users of your app still have to edit both the config files and the .env files, and then they have to manage differences between the remote and the local versions, which may become quite a problem depending on how technical those users are.
As far as technical debt is concerned, we're talking about adding a simplest conditional statement to Config::get. With that conditional we would introduce the possibility of replacing all logic in Config::set with a simple assignment operation, thus actually reducing technical debt.
Of course, I'm not at all confident that this is the best approach, or even that it is a good approach. That's why we're discussing it, I guess.


feat: add PROFILE environment variable as alternative to --profile flag

I think this small addition would be very useful to make it easier to conditionally build profiling-enabled builds on CI environments.
Rather than having to redefine the installation script it's enough to set the PROFILE environment variable to true.
Basically, with this, I could have a .env.development with PROFILE=true to automatically make my development (not local) environment builds  include the profiling build of React DOM

@ianschmitz @iansu @mrmckeb @petetnt any chance to get this PR reviewed please?

Not stale


Incomplete directions to locate and install C++/WinRT extension.

The documentation states "you'll need to download and install the C++/WinRT Visual Studio Extension (VSIX) from the Visual Studio Marketplace."
This statement isn't enough to locate the extension in the Visual Studio Marketplace.
I was unable to find it.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: f6f7d77e-7253-cfa2-ef6f-b58820138faa
Version Independent ID: deb39be4-4af1-17ff-cd4e-6bb998f76d9e
Content: Events; how to author and handle them in C++/WinRT - UWP app developer
Content Source: windows-apps-src/cpp-and-winrt-apis/events-author-handle.md
Service: unspecified
GitHub Login: @stevewhims
Microsoft Alias: stwhi

Hi, Noel! Yes, that's true, and in fact it's by design right at this moment but only because C++/WinRT (and the documentation for it) is still in a pre-release form. The documentation is marked pre-release, but we do understand that folks are keen to evaluate the technology and for that reason C++/WinRT is available in Windows Insider builds of the Windows SDK. Until the general availability of C++/WinRT (when the VSIX is expected to be available), for developing with C++/WinRT both inside and outside Visual Studio, I would recommend the great info that you can find on https://kennykerr.ca/articles/ and https://moderncpp.com/.

I'll close this, since we're still in the pre-release phase. Thanks for looking at the C++/WinRT content!


Backtick operator does not parse interpolated variables

The backtick execution operator can have variables that are interpolated, but these are not parsed.
<?php
`hello $world`;

Actual:
(program [0, 0] - [2, 0]
  (php_tag [0, 0] - [0, 5])
  (expression_statement [1, 0] - [1, 15]
    (shell_command_expression [1, 0] - [1, 14])))

Expected:
(program [0, 0] - [2, 0]
  (php_tag [0, 0] - [0, 5])
  (expression_statement [1, 0] - [1, 15]
    (shell_command_expression [1, 0] - [1, 14])))
      (string [1, 1] - [1, 7])
      (variable_name [1, 7] - [1, 13]
        (name [1, 8] - [1, 13])))))

I created some tests for this.

Beautiful! Thanks for the tests. This should be fairly straight forward once all the quirks in heredoc has been ironed out


fix typo

Fix typo in src/LuaEncode.lua.

thank you, merging

bro i just synced back new changes from vscode and it straight up removed your PR from the history idek

okay kinda fixed it i guess, had to manually merge lol


Splash screen, copyright, new issue template - housekeeping cleanup

Minor housekeeping issues to cleanup

Resize the splash screen so that none of the text areas overlap (slight spacing improvement, more height for progress text).
Check/update copyrights in prep for 2022.
github new issue template text is out of date.  Update text and all references to the current ones.

If you notice others, please add to this list (if this issue is still open) - thanks!

It fixed in develop and it is being rework on dash 17 merge.
been updated in develop

The splash screen text issue is related to Windows scaling.  At 100% the text looks fine.  Will check for an easy fix.

The scaling issue is trivial and not worth trying to fix.  At 100%, it looks good, at 125% the text overlaps, and at 150%, the image size is doubled and the text then fits again.
This has already been done in develop.
Fixed.


chore: bump yarn.lock

Draft PR for now so I can easily follow along with the build checks
Motivation
Mocha and jest global types are conflicting. Let's migrate all mocha tests to jest
Solution
Migrate all mocha tests to jest
PR Checklist

[ ] Added Tests
[ ] Updated Documentation
[ ] Updated CHANGELOG.md for the appropriate package

Closing, we're commenting out the tests for now and will re-add once local environment is merged to main


html2canvas - DOMException: CanvasRenderingContext2D.createPattern: Passed-in canvas has height 0

@immissile & @abdurrahmanyildirim
Is this issue fixed in JS file also? Because still I'm able to reproduce this issue with the latest html2canvas js file and latest Firefox browser.

Originally posted by @Elanchezhiyan-AIT in https://github.com/niklasvh/html2canvas/issues/2697#issuecomment-1330652012

We have updated the code in the JS file. Please make a change and add it to the latest version of the html2canvas js file.


sudo add-apt-repository ppa:kivy-team/kivy no longer useable

I can't use sudo add-apt-repository ppa:kivy-team/kivy:
Err:8 http://ppa.launchpad.net/kivy-team/kivy/ubuntu bionic Release
  404  Not Found [IP: <IP_ADDRESS> 80]

And when directly install sudo apt install python3-kivy
I get  python3-kivy amd64 1.9.1-1build3
Which will raise an error of https://github.com/kivy/kivy/issues/5410

Yes, the stable PPA doesn't have a release for bionic currently, because v1.10.0 doesn't work on bionic.
This has been reported before, see here: https://github.com/kivy/kivy/issues/5795#issuecomment-396037899
v1.10.1 is in the process of being released and will have a package once ready. In the meantime, try using ppa:kivy-team/kivy-daily instead.

HI!!!!! I did so
sudo add-apt-repository ppa:http://ppa.launchpad.net/kivy-team/kivy/ubuntu


Could you please provide a complete environment configuration file environment.yml.

What version of Python are you using?
The latest version of cudatoolkit on conda is 11.8, but you installed version 12.5 of cudatoolkit.
The latest version of cuda-toolkit is 12.6. Should I install cuda-toolkit or cudatoolkit?

cuda-toolkit:  https://anaconda.org/nvidia/cuda-toolkit
cudatoolkit:  https://anaconda.org/conda-forge/cudatoolkit

You can use the latest version. See the https://pytorch.org/get-started/locally/ page. You do not have to use a specific Cuda toolkit.


feat(cli): --subaccount flag to manage sub-accounts

This change will allow users to manage sub-accounts with a new flag named --subaccount.
To list integrations from the primary account
$ lacework integrations list

To list integrations from a sub-account
$ lacework integrations list --subaccount sub-account-name

Additionally, it is possible to configure a persistent sub-account with the command:
$ lacework configure --subaccount sub-account-name

To remove the configured sub-account use the --remove_subaccount flag:
$ lacework configure --remove_subaccount

Finally, this new flag comes with its environment variable LW_SUBACCOUNT that can be
used to override settings coming from the Lacework configuration file.
Signed-off-by: Salim Afiune Maya<EMAIL_ADDRESS>

We need to change this PR to match the terminology from our documentation,
instead of --tenant this argument needs to be called --subaccount.

Superseded by https://github.com/lacework/go-sdk/pull/431


Roll Flutter Engine from 840a7b346216 to c183e7701e7e (8 revisions)

https://github.com/flutter/engine/compare/840a7b346216...c183e7701e7e
2022-11-03<EMAIL_ADDRESS>Roll Dart SDK from 883ab3f70e3d to 94ac8f6cc756 (1 revision) (flutter/engine#37267)
2022-11-03<EMAIL_ADDRESS>Apply internal cl for C++20 prep (flutter/engine#37266)
2022-11-03<EMAIL_ADDRESS>Produce both ddc and dart2js platform files. (flutter/engine#37162)
2022-11-03<EMAIL_ADDRESS>[Impeller] Correct the ordering of filters in 'Paint::WithFilters' (flutter/engine#37239)
2022-11-03<EMAIL_ADDRESS>Enter a scope before calling Dart APIs in ThrowIfUIOperationsProhibited (flutter/engine#37226)
2022-11-03<EMAIL_ADDRESS>[macOS, multiwindow] Compositor gets FlutterView lazily (flutter/engine#36392)
2022-11-02<EMAIL_ADDRESS>Update docs to mention felt build --host (flutter/engine#37224)
2022-11-02<EMAIL_ADDRESS>[fuchsia] mouse-input test (flutter/engine#37221)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


Elastalert error out when used with a bearer token

I'm trying to deploy elasrtalert2 version 2.1.0 on OCP 4.6 to integrate with OpenShift's out of the box EFK stack. I used the 'jertel/elastalert2:latest' image.
I created a dedicated service account for Elastalert. Then added it to ./sgconfig/roles_mapping.yml. However, the elastalert gave the following error.
elastalert-create-index --config <config> --index <index_name>
Traceback (most recent call last):
  File "/usr/local/bin/elastalert-create-index", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.9/site-packages/elastalert/create_index.py", line 253, in main
    es = Elasticsearch(
  File "/usr/local/lib/python3.9/site-packages/elasticsearch/client/__init__.py", line 206, in __init__
    self.transport = transport_class(_normalize_hosts(hosts), **kwargs)
  File "/usr/local/lib/python3.9/site-packages/elasticsearch/transport.py", line 108, in __init__
    self.set_connections(hosts)
  File "/usr/local/lib/python3.9/site-packages/elasticsearch/transport.py", line 157, in set_connections
    connections = list(zip(connections, hosts))
  File "/usr/local/lib/python3.9/site-packages/elasticsearch/transport.py", line 154, in _create_connection
    return self.connection_class(**kwargs)
  File "/usr/local/lib/python3.9/site-packages/elasticsearch/connection/http_requests.py", line 39, in __init__
    self.session.headers.setdefault('content-type', 'application/json')
AttributeError: 'str' object has no attribute 'setdefault'

The elastalert config looks like below:
# This is the folder that contains the rule yaml files
# Any .yaml file will be loaded as a rule
rules_folder: /opt/elastalert/rules

#
scan_subdirectories: false

# How often ElastAlert will query elasticsearch
# The unit can be anything from weeks to seconds
run_every:
  minutes: 1

# ElastAlert will buffer results from the most recent
# period of time, in case some log sources are not in real time
buffer_time:
  minutes: 15

# The elasticsearch service for metadata writeback
# Note that every rule can have it's own elasticsearch host
es_host: elasticsearch.openshift-logging.svc.cluster.local

# The elasticsearch port
es_port: 9200

es_bearer: <token>

# The index on es_host which is used for metadata storage
# This can be a unmapped index, but it is recommended that you run
# elastalert-create-index to set a mapping
writeback_index: elastalert_status

# If an alert fails for some reason, ElastAlert will retry
# sending the alert until this time period has elapsed
alert_time_limit:
  days: 2

use_ssl: True
verify_certs: True

# The secrets from the fluent must be mounted!
ca_certs: <ca_cert>
#client_cert:
#client_key:

Hey @akilada - thanks for reporting this, this issue seems to have been introduced in a recent change (see here).
Are you able to test some patched code for me? I don't have access to an ES cluster with Bearer token auth enabled, and would like to confirm my proposed change works before merging.

Hey Feroz
Yeah I can test a patch.
Best Regards,
Akila Amarathunga
On Wed, 19 May 2021, 4:35 pm Feroz Salam, @.***> wrote:

Hey @akilada https://github.com/akilada - thanks for reporting this,
this issue seems to have been introduced in a recent change (see here
https://github.com/jertel/elastalert2/pull/85).
Are you able to test some patched code for me? I don't have access to an
ES cluster with Bearer token auth enabled, and would like to confirm my
proposed change works before merging.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jertel/elastalert2/issues/168#issuecomment-843788746,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AG5URN7L6ZSDZEGLUHBGFS3TONLZRANCNFSM45DTASDQ
.

If you could test my changes at https://github.com/jertel/elastalert2/pull/169, that would be much appreciated.

@StribPav - have you seen this issues?

If @StribPav did the PR testing on an existing ES cluster, with Elastalert indices already created, then it would explain how this issue could have been missed.

I had a test environment with empty elasticsearch:7.10.1 (discovery. type: single-node)  for ElastAlert indices and ElasticSearch:5.6 with data indices. In my solution, it was a bad idea to save ElastAlert indices in the same Elasticsearch(permissions, the naming convention for indices name, etc). I will be able to check this solution only this weekend.

@StribPav - have you seen this issues?

@StribPav - have you seen this issues?

I will be able to check this solution only this weekend.

@ferozsalam - Your patch works.
I added the patch into release 2.1.0 code and built a new image.
 Skipping index creation.
46 rules loaded

Closing. Thanks for the patch @ferozsalam.


create an index for the manual

This should be done using LaTeX's indexing mechanism.
Should the function index be kept separate as it is now?

You're talking about a topic index here right? That would be great. Was this idea rejected or just a casualty of too little man power?

Too little man power.
On Fri, Mar 4, 2016 at 1:09 PM, Jonah Gabry<EMAIL_ADDRESS>wrote:

You're talking about a topic index here right? That would be great. Was
this idea rejected or just a casualty of too little man power?
—
Reply to this email directly or view it on GitHub
https://github.com/stan-dev/stan/issues/454#issuecomment-192387196.

Yes, topic index.  But the manuals are going to be broken apart, and we can make new issues then that arise, like formatting for web and PDF.