Missing Required Props for TextInput Error

When I try to compile the code below, I get a missing props error for the TextInput component. Could you please clarify what prop field I am missing? Using the react native equivalent component does seem to work for some odd reason. Having some documentation with the required props for the TextInput component would have really helped.
import { View, TextInput, SxProp } from 'dripsy'
import { StyleSheet } from 'react-native'
import { Dispatch, SetStateAction } from 'react'

interface InputProp {
    textState: [string, Dispatch<SetStateAction<string>>]
    placeholder?: string
    placeholderTextColor?: string
    sx?: SxProp
}

export function Input({
    textState,
    placeholder,
    placeholderTextColor,
    sx,
}: InputProp) {
    const [text, setText] = textState
    const placeholderText = placeholder || 'Text'
    const placeholderColor = placeholderTextColor || 'rgba(255, 255, 255, 0.96)'
    const labelStyle = sx || styles.container

    return (
        <View sx={labelStyle}>
            <TextInput
                value={text}
                onChangeText={setText}
                placeholder={placeholderText}
                placeholderTextColor={placeholderColor}
            />
        </View>
    )
}

const styles = StyleSheet.create({
    container: {
        backgroundColor: 'rgba(255, 255, 255, 0.06)',
        borderRadius: 16,
    },
})

We're also seeing this error on TextInput
Type '{ style: { color: string; marginVertical: number; fontSize: number; borderBottomColor: string; borderBottomWidth: number; }; placeholder: string; value: string; onChangeText: Dispatch<SetStateAction<string>>; }' is missing the following properties from type 'Omit<Pick<Omit<{ testID?: string | undefined; textAlign?: "center" | "left" | "right" | undefined; textAlignVertical?: "center" | "bottom" | "top" | "auto" | undefined; pointerEvents?: "auto" | "none" | "box-none" | "box-only" | undefined; ... 103 more ...; showSoftInputOnFocus?: boolean | undefined; }, keyof Styled...': onPressIn, onPressOut, onPointerEnter, onPointerEnterCapture, and 14 more.ts(2740)

Package.json
  "dependencies": {
    "@expo/config": "^7.0.2",
    "@fartherfinance/frontend": "^3.5.0",
    "@gorhom/bottom-sheet": "^4.4.5",
    "@magic-sdk/react-native": "^11.1.0",
    "@react-native-async-storage/async-storage": "^1.17.11",
    "@react-navigation/bottom-tabs": "^6.5.0",
    "@react-navigation/native": "^6.1.0",
    "@react-navigation/native-stack": "^6.9.5",
    "@react-navigation/stack": "^6.3.8",
    "@storybook/react-native": "next",
    "@tanstack/react-query": "^4.19.1",
    "axios": "^1.2.1",
    "dotenv": "^16.0.3",
    "dripsy": "^3.8.1",
    "expo": "~47.0.8",
    "expo-asset": "~8.6.2",
    "expo-constants": "~14.0.2",
    "expo-dev-client": "~2.0.1",
    "expo-dev-menu": "^2.0.2",
    "expo-font": "~11.0.1",
    "expo-secure-store": "~12.0.0",
    "expo-splash-screen": "~0.17.5",
    "expo-status-bar": "~1.4.2",
    "expo-updates": "~0.15.6",
    "react": "18.1.0",
    "react-dom": "18.1.0",
    "react-native": "0.70.5",
    "react-native-gesture-handler": "~2.8.0",
    "react-native-reanimated": "~2.12.0",
    "react-native-safe-area-context": "4.4.1",
    "react-native-screens": "~3.18.0",
    "react-native-svg": "13.4.0",
    "react-native-web": "~0.18.9",
    "react-native-webview": "11.23.1",
    "react-query": "^3.39.2",
    "victory-native": "^36.6.8",
    "zod": "^3.19.1",
    "zustand": "^4.1.5",
    "sentry-expo": "~6.0.0",
    "expo-application": "~5.0.1",
    "expo-device": "~5.0.0",
    "@sentry/react-native": "4.9.0"
  },
  "devDependencies": {
    "@babel/core": "^7.20.5",
    "@babel/eslint-parser": "^7.19.1",
    "@types/react": "~18.0.14",
    "@types/react-native": "~0.70.6",
    "eslint": "8.29.0",
    "eslint-config-universe": "^11.1.1",
    "eslint-plugin-functional": "^4.4.1",
    "eslint-plugin-import": "^2.26.0",
    "eslint-plugin-jsx-a11y": "^6.6.1",
    "eslint-plugin-prettier": "^4.2.1",
    "eslint-plugin-react": "^7.31.11",
    "eslint-plugin-react-hooks": "^4.6.0",
    "eslint-plugin-react-native": "^4.0.0",
    "prettier": "2.8.1",
    "typescript": "4.9.4"
  },

Example Code
import { Text, TextInput, View } from "dripsy";
import React, { useState } from "react";
// import { TextInput } from "react-native"; // @TODO TextInput from dripsy thinks all props are required

import { ScreenContainer } from "../components/common/ScreenContainer";
import { useLogin } from "../hooks/useLogin";
import { RootStackReactNavigationProps } from "../navigation/RootStackNavigator";

const LoginScreen = (): JSX.Element => {
  const [email, setEmail] = useState("");

  const login = useLogin();

  return (
    <ScreenContainer>
      <Text variant="h3">{texts.loginScreen}</Text>
      <View variant="styles.verticalSpace" />

      <TextInput
        placeholder="email"
        value={email}
        onChangeText={setEmail}
      />
  <ScreenContainer />

};

We have the same problem

hmm okay and i assume it doesn’t happens with the RN input?
does this only happen with dripsy’s input, or other elements too?

Correct if you switch the import from dripsy to react-native it’s all good. I’m hoping to spend some time looking at the TS definitions. I think it’s just not marking these props as optional

All the other components work perfectly, thank you for a great library!

Does downgrading to Dripsy 3.6.0 fix this? I think it may be related to a recent PR.

I reproduced this with ScrollView as well:
const ScrollView: React.ForwardRefExoticComponent<Pick<Omit<{
    testID?: string | undefined;
    pointerEvents?: "none" | "auto" | "box-none" | "box-only" | undefined;
    style?: import("react-native").StyleProp<import("react-native").ViewStyle>;
    horizontal?: boolean | null | undefined;
    hitSlop?: import("react-native").Insets | undefined;
    onLayout?: ((event: import("react-native").LayoutChangeEvent) => void) | undefined;
    removeClippedSubviews?: boolean | undefined;
    nativeID?: string | undefined;
    collapsable?: boolean | undefined;
    needsOffscreenAlphaCompositing?: boolean | undefined;
    ... 95 more ...;
    persistentScrollbar?: boolean | undefined;
}, keyof StyledProps<...>> & StyledProps<...> & {
    ...;
} & React.RefAttributes<...>, "key" | ... 1 more ... | keyof ScrollViewProps> & {
    ...;
} & React.RefAttributes<...>>
import ScrollView
Type '{ children: Element[]; showsVerticalScrollIndicator: false; }' is missing the following properties from type 'Pick<Omit<{ testID?: string | undefined; pointerEvents?: "auto" | "none" | "box-none" | "box-only" | undefined; style?: StyleProp<ViewStyle>; horizontal?: boolean | null | undefined; ... 101 more ...; persistentScrollbar?: boolean | undefined; }, keyof StyledProps<...>> & StyledProps<...> & { ...; } & RefAttributes<...': stickyHeaderHiddenOnScroll, StickyHeaderComponent, href, hrefAttrs, and 2 more.

I have to see what could be causing this.

I'm also wondering if downgrading TypeScript to 4.4.3 could help.
Apologies for this, TypeScript is changing fast which makes things tricky for library authors.

I've made some minor progress on this. But typescript + @types/react-native + @types/react make things so difficult for library authors to wrap and add custom type inference, especially as versions change. I may need to do a rewrite of many types to work with future TS versions. For now, I think that these versions work together, but not positive:

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

Confirming that these downgrades worked in my project. Don't forget to change the version of TS being used by VS Code (workspace version vs VS Code's version) and save yourself 30 mins of head scratching :)

I've made some minor progress on this. But typescript + @types/react-native + @types/react make things so difficult for library authors to wrap and add custom type inference, especially as versions change. I may need to do a rewrite of many types to work with future TS versions. For now, I think that these versions work together, but not positive:

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

Still happening for me with TextInput using the deps versions you suggested @nandorojo

Going to move this to #276


Trusted Root example

An example showing how to import to the Trusted Root that is not user specific would be useful.  (The current root example is only for the current user.)

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

ID: c694289c-79f5-03cd-38aa-5d2ec76988bd
Version Independent ID: 0a5a5227-c7da-d308-9fca-857b49f6cf7c
Content: Import-Certificate (pkiclient)
Content Source: docset/windows/pkiclient/import-certificate.md
Product: w10
Technology: powershell-windows
GitHub Login: @coreyp-at-msft
Microsoft Alias: coreyp

@officedocsbot assign @e0i

@Vaccano Thank you for your feedback. We have added another example which imports the certificate from the file into the root store of the Local Machine. This can be tracked via PR https://github.com/MicrosoftDocs/windows-powershell-docs/pull/1244
Thanks
Sri


Remove browserify settings

This allows consumers to override the browserify settings, for instance to use babelify and specify loose transforms.

A global browserify transform would then be configured to transform react-forms, e.g. .transform({global: true, only: ['react-forms']}, 'babelify').


use lodash _.defaults

Using patterns like colors: opt.colors || true makes it impossible to set the option to false.
Using _.defaults fixes this as it only overwrites the values if they resolve to undefined.

@bezoerb  FYI, I have completely refactored the internals of gulp-phpunit and have cleaned out all the cruffy code, including all the object management code (now using lodash defaults0
Just posted version 0.11.0 (tag 0.11.0)

:+1: thanks


Fix crash in JS declaration emit

Our binder has a heuristic that detects X.prototype.y assignment in a JS file and treats X as a class, even if X isn't constructible. That results in a crash in JS declaration emit. This adds a check to ensure that the symbol for X actually has valid signatures.
Fixes #36273

Hmm. Seems like there's more to do here:
// .js
let A;
A = {};
A.prototype.b = {};
class B extends A {}
const x = (new B()).b;

// .d.ts
declare class A {
    private constructor();
    b: {};
}
declare class B {
}
declare const x: any;

The private constructor heuristic is only used in declaration emit. We should probably extend it to type checking class B extends A to make it an error since the constructor is "private".
For the equivalent TS, the output is this:
// .ts
class A {
    private constructor() { }
    b: "x" = "x";
}
// @ts-ignore
class B extends A { }
// @ts-ignore
const x = (new B()).b;

// .d.ts
declare class A {
    private constructor();
    b: "x";
}
declare class B extends A {
}
declare const x: any;

So we're consistent on getting any for (new B()).b, but not in the emit and we don't report errors in JS at the two locations where we do report errors in the TS (labeled above with // @ts-ignore comments.

Hm, the emitting errors part is probably important (declaration emit in the presence thereof a little less so). I agree, we should probably add the error. It's certainly odd that we allow it as a base class when it's not actually constructable... The js does error at runtime, too, right?

Yes, the JS would error at runtime. The JS decl emit differs because the original declaration of A isn't actually a class and a lot of our code in the checker for resolving base constructor types depends on it being a class, regardless of what the binder says. Its probably fine to have the decl emit be wrong here if we report an error when you subclass.


[Accordion] component does not support child accordions

When you place an accordion inside another accordion, the child accordion rows collapse/expand function does not work.
https://carbon-addons-iot-react.com/?path=/story/accordion--default
We opened an issue with Carbon @ https://github.com/carbon-design-system/carbon/issues/4768, but it seems that this issue was fixed at one point but has regressed, and then, they decided to no longer support it for some reason.
There is a consideration to create a "Tree" component, but this would only support text. Maximo needs a full set of components to exist within the child.  https://github.com/carbon-design-system/carbon/issues/2230
Any component placed within an accordion should function (even another accordion). We also have a use case for it in an upcoming design. It's likely that whatever is causing this defect will cause defects in other components placed within accordions.

FYI: The new List component being created will handle nested, expandable lists very similar to accordions with the added bonus of searching and selecting
PR tracking here: https://github.com/IBM/carbon-addons-iot-react/pull/856

closing this issue as Carbon is adamant about not having nested accordions

@bjornalm This request is being closed.


walkthrough-w-5 (tdd) Add calendar service to handle incoming meetings scheduling for users

feature (FindMeetingQuery.java) Construct FindMeetingQuery.java functionality to handle meeting scheduling.

Added Comparator function to Event.java to sort Event objects by start date.

Fill query function in FindMeetingQuery.java to search for potential timeslots to
fit an incoming meeting request.

Added additional constructor to MeetingRequest.java to include optional_attendes
if necessary to build test cases that included optional attendees.

Added requested test cases in FindMeetingQueryTest.java to test for different
scenarios mentioned in the walkthrough.

*** No breaking changes ***

Just a small note on: *** No breaking changes *** in description. It's great to be aware of that, but it might be a little superfluous, because that's assumed to be true by default, since breaking changes are typically a bad thing and are much rarer to see.
It might be better to invert the pattern omit *** No breaking changes *** in favor of *** breaking changes *** for PRs with breaking changes.


How to do diff operation like the demo vedio?

Thats a diff split in fugitive. You can either run the command :Gdiffsplit or press dd when a fugitive object is open (like an old version of a file)


How to summary output of VAE

Hello,
Thank you for this software for scRNAseq. Now I'm wondering, is there any detailed description of the output object of VAE?
Particularly,
I'd like to know if the output includes the estimated dispersion values and/or expected dropout rate? If yes, what special parameter should I set and what command can I use to extract them?
Thank you very much!

You can extract the dispersion with vae.px_r, note this is on the natural log scale.
For dropout, you can get the dropout probability given a sample of z using posterior.generate_parameters. You should inspect the function yourself, the first return value is the tensor you want. Keep in mind this is per gene and per cell.

It works. Thank you very much!


DCV is not pure source library

Also, looks like windows users may have problems with this configuration

I cannot figure out where is this error coming from. Seems like a bug in dub - I tried applying diff from cb3de51c7129c717fd1b3597572a48d462e81935 and at first I got the same error. When I did dub clean everything worked fine. I'm guessing the error is coming from these lines in ffmpeg-d's dub.json. I assume dub's default source path ./source/ gets mixed up somehow with ones given in the config.
The only thing I can't figure out - why has it been working so far. :)
Anyhow, can I ask you to update ffmpeg-d version in dub.json to 2.5.1? There I've cleaned up the dub.json, and removed those lines. I'd assume it would pass then. What you think?

Pass now

Current coverage is 73.32% (diff: 100%)

Merging #46 into master will not change coverage

@@             master        #46   diff @@
==========================================
  Files            25         25
  Lines          2613       2613
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           1916       1916
  Misses          697        697
  Partials          0          0

Powered by Codecov. Last update 9a49eb8...1d21447


Water Halves fall damage option?

There is one for lava, why not water too?
Or even better if it could be removed altogether. Water can already slows the player to a point where they wouldnt take fall damage anyways it doesnt need to negate it completely. Its like terraria wings for some reason.

added in 40ebbd9 (release 3.2.1)


fix: moves auro library to package.json dependencies #140

Alaska Airlines Pull Request
Moves Auro Library into dependencies from devDependencies to avoid installation issues, as originally reported in #573.
Resolves: #140
Summary:

Moved to dependencies within package.json
Regenerated package.lock
Verified build and test ran successfully

Type of change:
Please delete options that are not relevant.

[x] Revision of an existing capability

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[ ] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Chris Friedberg seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

:tada: This PR is included in version 5.0.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Tokenisation issues

There seems to be tokenisation issues for languages with Cyrillic letters, cf the following bug report:

https://github.com/giellalt/lang-myv/issues/3

There is an update to giellalt/lang-myv#3
I am using a M2 Ventura 13.0.1
With LibreOffice. the language is Erzya (myv):
Version: <IP_ADDRESS> / LibreOffice Community
Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5
CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx
Locale: myv-RU (myv_FI.UTF-8); UI: en-US
Calc: threaded
There are problems with the full stop ‹.› and ‹...› touching a previous word.
The comma, question mark, exclamation mark, quotation marks, parentheses, semicolons and colons do NOT cause a problem.

Meadow Mari (mhr) also has a problem with a full stop touching words.
They are recognized.

sms has the same problem

THIS issue does not seem to be one affecting lut. I have drawn hair lines next to accepted words, next to which I have added full stops. The speller accepts them. (Lushootseed has other problems)

Just a reminder: This is actually a nasty bug (since almost all sentences end in a period), and it seems to happen for all languages. Here is my sme. Note the three individuao periods after "Juo" compared to the horisontal ellipsis following "Na" (which works):


Specify provider so it doesn't try to use chocolatey

When I first setup this class on a Windows 2012 host, it failed stating that it needed chocolatey to install the package:
Failed to apply catalog:
  Parameter provider failed on Package[New Relic Server Monitor]:
    Invalid package provider 'chocolatey' at /etc/puppet/environments/production/modules/newrelic/manifests/server/windows.pp:90
    Wrapped exception: Invalid package provider 'chocolatey'

To get around this, I specify the windows provider, which is all that this PR contains.

Anything I can do to get this merged?  Or any reason it's ignored?
In my environment, chocolatey is the default package provider on Windows hosts, which I don't want in this case.  It seems reasonable to specify the proper provider.  Or is there a workaround I can apply?

  Do I need to recreate a new PR w/ the proper branch?

Closing as it's replaced by https://github.com/fsalum/puppet-newrelic/pull/67


[Bug]: Links on the opportunities page are not working.

What happened?
When I navigated to the opportunities page, none of the links are working.
https://github.com/user-attachments/assets/6e95043b-5155-4c6b-b7d5-3f43b3f27156
I will fix this issue by researching each and every relevant link and code it.
@codeaashu Kindly assign this issue to me.
Add screenshots
Add screenshots
What browsers are you seeing the problem on?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

@ishap11, @madhukalita Do assign this issue to me.


Add spreadsheet-like pivot() function

Addded spreadsheet-like pivot function to pivot and optionally filter and sort in a single function.
pivot(df::AbstractDataFrame, rowFields, colField, valuesField; )
See: https://discourse.julialang.org/t/a-spreadsheet-like-pivot-function/2701
(ps: this pull request doesn't include the export of the function.. where is that defined ?)

I'm not sure this kind of function should really live in this package. We're rather trying to make it smaller, concentrated on core features. Ideally that function would be very generic and could support any data source, including e.g. SQL tables.
At some point I wanted to extend the scope of my FreqTables package to any kind of pivot table, but I never found the time to do it. However, I would have returned the result as a NamedArray or a similar structure, not as a data frame. Do we really need a function for that, given that query frameworks make this quite easy? For example, Query makes this kind of thing quite straightforward: http://www.david-anthoff.com/Query.jl/stable/querycommands.html#Grouping-1 A future dplyr-like framework would make this even less verbose.
OTOH, there's previous art in for this kind of function in Pandas: http://pandas.pydata.org/pandas-docs/stable/reshaping.html#pivot-tables

We have stack and join operations in here, perhaps a pivot wouldn't be so out of place, at least for now.

@sylvaticus It would be great if you could take care of the following points:

Add tests
Use lowercase instead of camel case (e.g. rowField -> rowfield)
Use 4 space indents everywhere (you mostly have)
No parentheses around if conditions
Model the docstring formatting after others in this repo (i.e. signature first and indented, etc.)

Sorry for the mess, I couldn't update this pull request, so I opened a new one (#1181) implementing the required changes.


Fix minSize < curSize

Fix #626
Thanks to @kbaik

Coverage remained the same at 18.832% when pulling 1e81a2202616d9c5aadc31ccd3e1dfa568e1dd46 on yuripourre:master into f160c0b4970d3f2d8a9ae572420f3b8c9911fc46 on sarxos:master.

Thank you @yuripourre and @kbaik! I'm merging this PR.


⚠ T:Riza Api has degraded performance

In 1844787, T:Riza Api (https://infra.triza.dev/api) experienced degraded performance:

HTTP code: 200
Response time: 2024 ms

Resolved: T:Riza Api performance has improved in d8c7510.


Auto-invoke inference command

Inference command should be auto-invoked when using the Type4Py extension. Some possibilities:

Invoke when file is loaded
Invoke when file is saved
Invoke when file is edited (very expensive)
Poll invoke in-between edits (less expensive than on edits)

For now, the auto-invoke functionality works when a file is opened. (#15 ).


Missing key algorithms by configuration Multiple public keys.

As shown in the figure, I have configured multiple encryption methods in netconf. However, when I verify it, I find that only two of them are supported.
<netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
    <listen>
        <endpoint>
            <name>default-ssh</name>
            <ssh>
                <tcp-server-parameters>
                    <local-address><IP_ADDRESS></local-address>
                    <keepalives>
                        <idle-time>1</idle-time>
                        <max-probes>10</max-probes>
                        <probe-interval>5</probe-interval>
                    </keepalives>
                </tcp-server-parameters>
                <ssh-server-parameters>
                    <server-identity>
                        <host-key>
                            <name>default-key</name>
                            <public-key>
                                <keystore-reference>genkey</keystore-reference>
                            </public-key>
                        </host-key>
                        <host-key>
                            <name>secp384-key</name>
                            <public-key>
                                <keystore-reference>secp384</keystore-reference>
                            </public-key>
                        </host-key>
                        <host-key>
                            <name>secp256-key</name>
                            <public-key>
                                <keystore-reference>secp256</keystore-reference>
                            </public-key>
                        </host-key>
                        <host-key>
                            <name>secp521-key</name>
                            <public-key>
                                <keystore-reference>secp521</keystore-reference>
                            </public-key>
                        </host-key>
                        <!-- <host-key>
                            <name>x25519-key</name>
                            <public-key>
                                <keystore-reference>x25519</keystore-reference>
                            </public-key>
                        </host-key> -->
                    </server-identity>
                    <client-authentication>
                        <supported-authentication-methods>
                            <publickey/>
                            <passsword/>
                            <other>interactive</other>
                        </supported-authentication-methods>
                        <users/>
                    </client-authentication>
                </ssh-server-parameters>
            </ssh>
        </endpoint>
        <endpoint>
            <name>default-ssh2</name>
            <ssh>
                <tcp-server-parameters>
                    <local-address>::</local-address>
                    <keepalives>
                        <idle-time>1</idle-time>
                        <max-probes>10</max-probes>
                        <probe-interval>5</probe-interval>
                    </keepalives>
                </tcp-server-parameters>
                <ssh-server-parameters>
                    <server-identity>
                        <host-key>
                            <name>default-key</name>
                            <public-key>
                                <keystore-reference>genkey</keystore-reference>
                            </public-key>
                        </host-key>
                        <host-key>
                            <name>secp384-key</name>
                            <public-key>
                                <keystore-reference>secp384</keystore-reference>
                            </public-key>
                        </host-key>
                        <host-key>
                            <name>secp256-key</name>
                            <public-key>
                                <keystore-reference>secp256</keystore-reference>
                            </public-key>
                        </host-key>
                        <host-key>
                            <name>secp521-key</name>
                            <public-key>
                                <keystore-reference>secp521</keystore-reference>
                            </public-key>
                        </host-key>
                        <!-- <host-key>
                            <name>x25519-key</name>
                            <public-key>
                                <keystore-reference>x25519</keystore-reference>
                            </public-key>
                        </host-key> -->
                    </server-identity>
                    <client-authentication>
                        <supported-authentication-methods>
                            <publickey/>
                            <passsword/>
                        </supported-authentication-methods>
                    </client-authentication>
                </ssh-server-parameters>
            </ssh>
        </endpoint>
    </listen>
</netconf-server>

There is another problem. When I try to add the public key and private key of X25519, the server will report an error. Is it a problem with the format I added?
        <asymmetric-key>
            <name>x25519</name>
            <algorithm>x25519</algorithm>
            <public-key>MCowBQYDK2VuAyEAv3emx3R4Bp/Ob8E2YIFs6lGye2KzejbXu/HMlqT19Qs=</public-key>
            <private-key>MC4CAQAwBQYDK2VuBCIEIJgE+P5q9sAhyd7AbUlhOB8m2NM9kw9PTkwrg1aZPiRC</private-key>
        </asymmetric-key>

Could you please help me check if this is a bug?

Could you please include your ietf-keystore content (without the private keys, if you are have deployed them, hope not) for me to see the actual keys that are referenced? Also, you seem to be using old revisions of the YANG modules (old libnetconf2 version) because I cannot find these nodes. But I guess the algorithm leaf was an identityref, whose values need their module prefix in case the identities are from a foreign module. Look into the RFC for specific examples of how to include them in an XML.

Sure. Currently, the public and private keys have not been deployed yet. I can send it to you for a look.
<asymmetric-key>
            <name>secp384</name>
            <algorithm>secp384r1</algorithm>
            <public-key>MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE+H0OgQVKQ/stq0qUem7m6Enb2BEWZ8XJiXLUk7rmQuVAAAOX4+g46jpBV0hCtgtj4HXUJmQnTx/GKC35rfj4Ol2FKaZnkyY8mwK9UVeV6ZJQYK19McHhFcXja/bIgUrD</public-key>
            <private-key>MIGkAgEBBDAHBUQ1Tz+OuAMAGpaGsm7hYRyz26zgB2dkrmeeAr93RKLXJxsArkciNYKOVB74Nt+gBwYFK4EEACKhZANiAAR1ZQGs0zdFVNlCfEXdeiHDTphlOn2B/R3nbX+M0X/LYGi4E8zSGZcjgYmPivrZkv1wz958NTP9pUecJFxGE3xdLr6Ho0MjE7Gt4pmV6LvK7lYY/1CDMZV+xtzBwwhqjiE=</private-key>
        </asymmetric-key>
        <asymmetric-key>
            <name>secp256</name>
            <algorithm>secp256r1</algorithm>
            <public-key>MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEUNnV0WexOQfkg45Cnn/PNhNqI2DGGjEtBUmc+lUd1rbMc3VLn/wPvsCvabrOXQ4daFFL+gep/AhHZHvF1Mi3kw==</public-key>
            <private-key>MHcCAQEEIANphBqVgGmqoNHZq7Rmpqa1ddAPNVCJmBgfK6mr7tkeoAoGCCqGSM49AwEHoUQDQgAEUNnV0WexOQfkg45Cnn/PNhNqI2DGGjEtBUmc+lUd1rbMc3VLn/wPvsCvabrOXQ4daFFL+gep/AhHZHvF1Mi3kw==</private-key>
        </asymmetric-key>
        <asymmetric-key>
            <name>secp521</name>
            <algorithm>secp521r1</algorithm>
            <public-key>MIGbMBAGByqGSM49AgEGBSuBBAAjA4GGAAQA0jmyxfD+YMC+Tazec4oIfUjI/nci4Xwqa5SboqRJPwGfzMZviqFRGMhu+UrcqONuXSc0wXOYPW5NQpNfKH5t6OQBA64ehR6M56PIhiSrOQ5xZ3PE8ktmZlMu+XYGQe3U2zFXSXLv2ZGn1GgDtJMouH2TMQV9TM63tLPQOtzrJN3iFVQ=</public-key>
            <private-key>MIHcAgEBBEIAdPQe0C6H895JvKL1Z1DET9sKlgiYptE0pJ5y57kYWqMhZ+qsHpKA0I7MP/5I8t9WF1JTsMH5AgBSJSBgex6lIKSgBwYFK4EEACOhgYkDgYYABADSObLF8P5gwL5NrN5zigh9SMj+dyLhfCprlJuipEk/AZ/Mxm+KoVEYyG75Styo425dJzTBc5g9bk1Ck18ofm3o5AEDrh6FHozno8iGJKs5DnFnc8TyS2ZmUy75dgZB7dTbMVdJcu/ZkafUaAO0kyi4fZMxBX1Mzre0s9A63Osk3eIVVA==</private-key>
        </asymmetric-key>
        <asymmetric-key>
            <name>x25519</name>
            <algorithm>x25519</algorithm>
            <public-key>MCowBQYDK2VuAyEAv3emx3R4Bp/Ob8E2YIFs6lGye2KzejbXu/HMlqT19Qs=</public-key>
            <private-key>MC4CAQAwBQYDK2VuBCIEIJgE+P5q9sAhyd7AbUlhOB8m2NM9kw9PTkwrg1aZPiRC</private-key>
        </asymmetric-key>

So what libnetconf2/netopeer2 version are you using? It really seems like an old one so I may not be able to provide any support.

Netopeer2 V2.1.62   libnetconf V2.1.34
I don't think that is pretty old version?

It it now more than a year old, in our development schedule that is quite a lot, the used YANG modules were updated and the whole configuration works differently. So I cannot provide proper support and I do not understand why x25519 would be considered an invalid value, seems correct based on the used YANG modules. Also, in that version I do not think all these algorithms were actually supported so that may be the reason why they are not actually used by libssh. My suggestion is to update all the projects (libyang, sysrepo, libnetconf, netopeer2) to their latest release and try to configure it again.


Session Resume

main idea of this project is performance, but no information about tls session resume. Is it handle session resume ? if it is when i check multithread example there is no shared session resume example. If this library has no session resume, nodejs itself a lot of faster than this library. If main idea is only websocket (session resume still matter) why there is http3 etc?

Default is to have a session cache:
SSL_SESS_CACHE_SERVER
Server sessions are added to the session cache. When a client proposes a session to be reused, the server looks for the corresponding session in (first) the internal session cache (unless SSL_SESS_CACHE_NO_INTERNAL_LOOKUP is set), then (second) in the external cache if available. If the session is found, the server will try to reuse the session. This is the default.

thank you for information, how can i share them between threads ?

You could use a read through the user manual to get an idea of how things is designed, first


Ability to proxy requests when serving with trunk serve

Currently, the development server spawned with trunk serve doesn't allow proxying requests. This renders it mostly useless as API calls to backend can't be made from the app served by the development server.

Related issue in Seeder: (see point 3.)  https://github.com/MartinKavik/seeder/issues/1
Personally, I run front-end and back-end on different domains and ports so I don't need it. However I can imagine it's useful e.g. for server dashboards.

renders it mostly useless

😂 lolz
Ok, feature request to support proxying requests to a backend, probably based on URI prefix (eg, /api/).
BTW, I'm not sure how much experience you have on this front, but there are actually lots of other ways solve this problem, especially given the fact that when you ship an application to a production environment, you will not (you should not) be using Trunk as the web server.

if you are using a docker based environment, you can just launch an nginx/traefik or some other simple web server to handle the request, and then do the proxying for you. It can split the traffic sending /api/ traffic to your API, and everything else can be sent over to the Trunk dev server.
if you are using Kubernetes, and perhaps you have a local kind cluster, you can just use K8s ingresses.

There are other simple patterns as well which are designed for development environments (docker-compose comes to mind), but which closely mirror a production environment.

All that said, adding a proxy to Trunk is a good idea. I'll get this prioritized soon.

My experience from Seed community

Many beginners want to fight with two "enemies" at once - backend and frontend. I don't know the reason, maybe there are used to write PHP / NodeJS / Django servers and splitting frontend and backend feels unnatural to them. Or maybe there are many Rust tutorials with servers so it looks like a good start, who knows. Beginners don't use K8s or Traefik.

Another group are veterans who want one server, one favorite database (Postgre/MySQL) and nothing more - the beauty of simplicity. UI is just a part of the server in their world.

That's well said. I agree. Beginners would definitely be overwhelmed at having to setup K8s ingresses or Traefik/nginx &c. I definitely don't want to recommend anything like that as "the way" to work with Trunk.
Definitely going to setup some proxy functionality.
I suppose, in the name of due diligence, what do you all (@MartinKavik && @hamza1311, and anyone else of course) see as being fundamentally need for this?

being able to simply declare a URI prefix, like /api/ and then a target backend, should do the trick in most cases. Transparent proxy.

Anything else which you think is needed here?

Anything else which you think is needed here?

Some user projects/servers serve the FE app from the root (/) and API endpoints are on /api/*. (Ideal case)
Other ones serve API endpoints on / and FE is served from /ui/.  (Backend-first approach, UI is basically a nice-to-have)
3rd option: Everything is on /. FE apps have to use hash routing to prevent conflicts. (Often modernized legacy apps.)

Note: Fetch and SSE should be relatively easy to pass through proxy, however I would be careful with non-HTTP protocols like WebSockets.

Many beginners want to fight with two "enemies" at once - backend and frontend. I don't know the reason, maybe there are used to write PHP / NodeJS / Django servers and splitting frontend and backend feels unnatural to them. Or maybe there are many Rust tutorials with servers so it looks like a good start, who knows. Beginners don't use K8s or Traefik.

People also sometimes run a single instance of their API server and don't want to setup K8s of all things on their workstation for something as simple as an API proxy.

@hamza1311 btw, I meant to ask you this earlier, but are you interested in contributing the code for this? I am about 3 days or so out from being able to switch gears over to the next milestone for trunk, and anyone willing to contribute would be greatly appreciated. No pressure, for sure. But I figured I would ask you and let you know that your code is WELCOME! :)
Just let me know. If not, I should be able to get around to it here quite soon. Cheers!


.env.php file(s) not working

Not sure if Laravel 4.2 has changed the way variables saved into $_ENV from the .env files or if it's my dev environment, but the variables in my "dot files" are copied to $_ENV in the format  $_ENV['stripe.api_key'] not $_ENV[ 'stripe']['api_key'].
Even though my .env.php file looks like this:
return array(
	'stripe' => array(
		'api_key' => 'sk_test_xxxxxx,
		'publishable_key' => 'pk_test_xxxxx'
	)
);

If I dd($_ENV); I can see them:
array (size=16)
  ...
  'stripe.api_key' => string 'sk_test_xxxxx' (length=32)
  'stripe.publishable_key' => string 'pk_test_xxxxx' (length=32)

Fixed with #11.


Add support for aws_db_option_group

Similar to this - https://github.com/douglasfraser-aviva/terraform-aws-rds/commit/a08d7039e151e17acacbf006ad17f3bfe04adb90

First attempt was non-functional, PR #24 is replacement.

v1.17.0 has been released with this feature.


chore(deps): upgrade dev dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-dev-dependencies-k8s-25-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 2867

Questions ?
Please refer to the Backport tool documentation


manually initialize Angular

manually initialize Angular, component is not normal .
angular.module('myApp', [])
  .controller('MyController', ['$scope', function ($scope) {
    $scope.greetMe = 'World';
  }]);

angular.element(document).ready(function() {
  angular.bootstrap(document, ['myApp']);
});

@motopia Can u explain a little? What does it mean 'not normal'?

Hi,
run into the same problem.
When using manual bootstrapping (don't use ng-app="myApp" directive in html) the sidebars not rendered and ui-states don't work (e.g. ui-toggle="uiSidebarRight")

nice

I'm having the same problem. I'm manually initializing (as I'm using meteor), but the sidebars ui-toggle won't work. Anyone find a solution?


Add support to fallback to non-vectorized read path

We need to add support to fallback to the non-vectorized read path for the following reasons:

Provide operators an option to turn on/off vectorized read path for iceberg. This would be a config driven decision.

Since spark doesn't support vectorized read path for complex data types, and till iceberg adds support for the same(https://github.com/apache/incubator-iceberg/issues/521), we would need to make sure that the older/non-vectorized code path is used for such types.

Duplicate of #520


Icon submission: LocalMonero

Icon type
Logo based
URL of the site or app
https://localmonero.co/
Logo / icon info
https://svgur.com/s/65G
Background color info
No response
Upload icon(s)
https://svgur.com/s/65G
Anything else?
No response
Confirmation

[X] I have read and carefully followed CONTRIBUTING document

Wrong icon on the "Upload icon(s)" section.
This has been requested long time ago (#91) and reason why I didn't make icon for this service is because logo is exactly the same as Monero currency symbol. Replacement is "Monero" icon on the generic section.


webpackConfig config example

I already have written webpack.config.js file. How can I integrate it here?

+1

I have been feeding the options via grunt, but just pushed an update now where you can specify a JS config file directly.
See:
https://github.com/theogravity/react-styleguide-generator-alt#command-line-tool
https://github.com/theogravity/react-styleguide-generator-alt#config

Hello
I can't figure out how to integrate react-styleguide-generator-alt with webpack.
Can you provide an example and add it to the readme please ?
Best regards

Ok, I found out in the readme. Sorry for the noise


Fix ipfs.io/blog/* links loaded via DNSLink

We've moved blog to blog.ipfs.io and fixed most of problems in https://github.com/ipfs/blog/pull/182 but links to ipfs.io/blog/* are still around due to the way Discourse integration was done for comments.
Example: try opening https://ipfs.io/blog/2020-01-30-go-ipfs-0-4-23/ with ipfs-companion's redirect to local gateway enabled.
Links under ipfs.io/blog/* break when DNSLink for ipfs.io is resolved:
→  dnslink(https://ipfs.io/blog/2020-01-30-go-ipfs-0-4-23/)
← ipfs resolve -r /ipns/ipfs.io/blog/2020-01-30-go-ipfs-0-4-23/: no link named "2020-01-30-go-ipfs-0-4-23" under bafybeics2j3x4qcn3365docj4f5xfe7gwlbakds7x3it63okc572imyb4e
This means we are unable to sovle this at Nginx level.
I think we need two fixes:

[x] https://github.com/ipfs-shipyard/ipfs-companion/pull/844: adding rule redirecting ipfs.io/blog → blog.ipfs.io should be harmless and would remove frustration from new users who tried to visit the page

fix specific to ipfs-companion, won't work in other user agents that are capable of resolving DNSLink
mitigates the problem of existing links

[x] https://github.com/ipfs/blog/pull/372 (for blog.ipfs.io website): add JS to every page that detects the page was loaded from ipfs.io/blog and redirects to URL at blog.ipfs.io

fixes URLs for everyone, not just companion users
this way people won't be able to copy&paste invalid links (removes the problem going forward)

This could be good "first issue".
Comment below if you'd like to work on this, I'll be happy to provide guidance.

I've implemented both fixes, see https://github.com/ipfs/blog/pull/372 & https://github.com/ipfs-shipyard/ipfs-companion/pull/844

@lidel @olizilla This makes sense to me!

links to ipfs.io/blog/* are still around due to the way Discourse integration was done for comments.

Can we fix discord?

Pretty sure admins can search/replace, but it’d have to be done manually and I’m a bit concerned about the optics of editing community posts. We’ll have the same issue with docs URLs once the legacy docs are deprecated, and the plan was to be really good about redirects on the infra side (we’re talking about something like 55 pages in that case).

There is one sensitive place: the code responsible for displaying comments on the blog.
The tricky line is at:
https://github.com/ipfs/blog/blob/cb4f40549b49efdf5fcefcb49badf50c9dad0682/layouts/post/single.html#L26
AFAIK we can't change this URL for existing posts because it would create new thread for each one, and lose connection to existing comments.
The 'https://ipfs.io/blog/{{ .URL }}' needs to remain as a way of loading comments for existing posts.
What we could do is to add a quick check  if blogpost "publishing date" is after a certain date (eg. make it 1st of March 2020) and switch comment URL to https://blog.ipfs.io/{{ .URL }}. This way new threads for new posts would use safe domain name, finally removing the problem going forward.
Y/n? (I can PR)

That is madness... how do people migrate these things... I can see https://meta.discourse.org/t/embedding-discourse-comments-via-javascript/31963
says you can point people to existing discussions if you use the discourseUrl, but it's much the same problem...this is the worst.

@olizilla yes, it is pretty unfortunate :(
Don't think we can fix this for historical discussion threads without changing values in SQL table of Discourse somewhere.
Perhaps fixing future posts is enough?
See a fix proposed in https://github.com/ipfs/blog/pull/375


Update stable version to 3.x

already 15% of the users are using this

https://github.com/ioBroker/ioBroker.repositories/pull/625/files


Check enforcer should comment on the size of blobs added by a PR

Merge committing a PR will add all of the new blobs in the history of the source branch to the target branch's history.  We should guard against large blobs in the PR history by auto-commenting on the size of new blobs added by a PR:

Merging this PR with a merge-commit will add 120 blobs to the repository with a total size of 50MB
Merging this PR with a squash-commit will add 10 blobs to the repository with a total size of 240KB

This will help identify large files that were added to a branch, but removed before the branch was submitted for PR.  Because of git's default clone / fetch behavior, these deleted files will still affect the fetch size of the repository if the commit is merged.

This doesn't apply for squash commits though, right?

This doesn't apply for squash commits though, right?

Squash commits still add content to the repo, so we should tell the approver how the PR will affect the repo size.

The feature suggested here becomes mostly moot once we get the test recordings out of the repos.  That said, it might be interesting to have some safeguards in place to keep from having large files accidentally find their way into our repos (and their history).  Assigning this to @scbedd to be considered as a possible follow up to the work he's doing moving our test collateral (and recordings) out of our source repos.

Assigning to sima's backlog.  Indeed, now that the recordings are moving out of the repos, this now becomes a lot more interesting and valuable.  Before, it would've just created noise whenever recordings were included in PRs.


Module not found: Error: Can't resolve 'babel-loader'

Bug:
Getting the following error when running the app with yarn dev,
Module not found: Error: Can't resolve 'babel-loader'
The issue is resolved when adding babel-loader as a devDependency using the following command:
yarn add -D babel-loader
Steps to reproduce the behavior:

Clone the repo
Install dependencies yarn
Run: yarn dev
See error
Module not found: Error: Can't resolve 'babel-loader'

Desktop (please complete the following information):

OS: Fedora 33
Browser Google Chrome Latest

Solution:
Add Babel-Loader in package.json

Issue has been resolved, thank you.


User Story 1.1 - Issue 5: The Org Initials in the circle is bigger than design

Still see some issues for eclipse and OP- Issue 5

I see the built is matching with staging now . so I close this defect
https://user-images.githubusercontent.com/70918430/116340816-a75fbd80-a794-11eb-8d97-5169e902393f.mp4


[VideoExport] Unable to change Output and Frames folder paths

User on Illusion Soft Discord server reported changing folder paths in Plugin Settings is not working properly. VideoExport use the default paths regardless when generating video. Changes also reset back to default when Studio is closed.
I looked at the code and noticed it does the configs differently. Would it be safe to change newOutputFolder and newGlobalFramesFolder to ConfigEntry<String> and just do Config.Bind() without going through _configFile.AddString()?
Also not sure why it's necessary to check for existence of new folders before setting them since they get created if they don't exist.
I only looked at this in more detail in HS2, but all games seem use the same code for this. so I'm guessing this is a problem for all games.
This part of the code hasn't changed since a long time ago. I'm a bit surprised I wasn't able to find previous reports of this.

It checks for existing folders inside bepinex to keep backwards compatibility for people that used old versions and have clips saved there already. _configFile can be ripped out entirely to simplify things but I didn't do it just in case this was going to ever be merged back into Joan's repo in which case it would need to support HS1.

If I'm understanding the code correctly, this check would prevent the paths from changing unless the new folder paths exist.
The check for backwards compatibility is already done here.

It does look a bit messy, a PR would be great since I'm busy working on something else.


bug: user email and phone number displayed on course videos

Describe the bug
When I go to any course, my email and phone number appear on every recording
To Reproduce
Steps to reproduce the behavior:

Go to any course video
See error

Screenshots or GIFs

Info

Browser: Chrome

@vikasMotwani , this is not specifically the error I suppose, it did annoy a lot. But I will suggest you to watch videos on https://app.100xdevs.com. And most probably they don't own this codebase of https://harkirat.classx.co.in

It's not the bug, it's to prevent piracy i guess

not a bug lmao

I agree @ramnaresh8 @4kshi7

Understood


Add @DaDodger to list of translators

Update README.md
Description

[x] Added @DaDodger to the list of translators. For reference, see #78 and #88.

Username, profile link or ID
Diego Ramos - Crowdin - Minecraft: Java Edition translator

Thanks for the contribution. Leaving this up to @asiekierka to verify and merge. (Please squash!)
I moved you below the other contributors, since it's in order of first contribution, and reverted the "Brazilian Portuguese" change. I think it simplifies things until we do get a pt_PT translation..? I hope this is okay.


Change package name

Change name to match repo name.

Smoke testing worked.
Double-checking docs-csm 1.2 and main first before calling this okay.

Need to change the name of the spec file to pit-nexus.spec and update the version to 1.1.0.

Seems okay doc-wise:
[602]rusty@C02F43JEMD6P:~/gitstuffs/cray-shasta/docs-csm> grep -Ri cray-nexus *
install/scripts/csm_services/steps/1.initialize_bootstrap_registry.yaml:30:          3.  Load the skopeo image installed by the cray-nexus RPM
install/scripts/csm_services/steps/1.initialize_bootstrap_registry.yaml:38:          podman load -i /var/lib/cray/container-images/cray-nexus/skopeo-stable.tar quay.io/skopeo/stable
operations/package_repository_management/Nexus_Deployment.md:3:Nexus is deployed with the `cray-nexus` chart to the `nexus` namespace as part of the Cray System Management \(CSM\) release. Nexus is deployed after critical platform services are up and running. Product installers configure and populate Nexus blob stores and repositories using the `cray-nexus-setup` container image. As a result, there is no singular product that provides all Nexus repositories or assets; instead, individual products must be installed. However, CSM configures the `charts` Helm repository and the `registry` Docker repository, which all products may use.
operations/package_repository_management/Nexus_Deployment.md:7:For a complete set of available settings, consult the values.yaml file for the `cray-nexus` chart. The most common customizations to set are specified in the following table. They must be set in the customizations.yaml file under the `spec.kubernetes.services.cray-nexus` setting.
operations/package_repository_management/Nexus_Deployment.md:13:|`sonatype-nexus.persistence.storageSize`|`1000Gi`|Nexus storage size, may be increased after installation; critical if `spec.kubernetes.services.cray-nexus-setup.s3.enabled` is `false`|
operations/package_repository_management/Nexus_Deployment.md:45:**Warning:** The `cray-nexus` chart deploys Nexus with a single replica and the corresponding `nexus-data` PVC with `RWX` access mode. Nexus should **NEVER** be scaled to more than one replica; otherwise, the instance data in `nexus-data` PV will most likely be corrupted. Using `RWX` access mode enables Nexus to quickly restart on another worker node in the event of a node failure and avoid additional delay because of volume multi-attach errors.
operations/package_repository_management/Nexus_Deployment.md:55:Product installers vendor the `dtr.dev.cray.com/cray/cray-nexus-setup:0.4.0` container image, which includes helper scripts for working with the Nexus REST API to update and modify repositories. Product release distributions will include the nexus-blobstores.yaml and nexus-repositories.yaml files, which define the Nexus blob stores and repositories required for that version of the product. Also, expect to find directories that include specific types of assets:
operations/package_repository_management/Troubleshoot_Nexus.md:80:successful. If `helm status -n nexus cray-nexus` indicates the status is
operations/package_repository_management/Manage_Repositories_with_Nexus.md:291:Installers typically define Nexus repositories in nexus-repositories.yaml and rely on the `nexus-repositories-create` helper script included in the cray/cray-nexus-setup container image to facilitate creation.
operations/package_repository_management/Manage_Repositories_with_Nexus.md:372:Installers typically define Nexus blob stores in `nexus-blobstores.yaml` and rely on the `nexus-blobstores-create` helper script included in the cray/cray-nexus-setup container image to facilitate creation.
operations/utility_storage/Restore_Corrupt_Nexus.md:35:      /mnt/pitdata/csm-0.9.4/helm/cray-nexus-0.6.0.tgz <-- this is the helm chart to use
operations/utility_storage/Restore_Corrupt_Nexus.md:50:   ncn-m001# helm uninstall -n nexus cray-nexus
operations/utility_storage/Restore_Corrupt_Nexus.md:59:1. Re-install the `cray-nexus` helm chart (using the chart and manifest determined in step 1).
operations/utility_storage/Restore_Corrupt_Nexus.md:62:   ncn-m001# loftsman ship --manifest-path /mnt/pitdata/csm-0.9.4/manifests/nexus.yaml --charts-path /mnt/pitdata/csm-0.9.4/helm/cray-nexus-0.6.0.tgz
operations/image_management/Build_an_Image_Using_IMS_REST_Service.md:12:    -   `cray-nexus`, the Nexus repository manager service
operations/image_management/Delete_or_Recover_Deleted_IMS_Content.md:58:    -   `cray-nexus`, the Nexus repository manager service
operations/image_management/Delete_or_Recover_Deleted_IMS_Content.md:159:    -   `cray-nexus`, the Nexus repository manager service
operations/image_management/Customize_an_Image_Root_Using_IMS.md:14:    - `cray-nexus`, the Nexus repository manager service
upgrade/1.2/scripts/upgrade/update-customizations.sh:120:yq w -i --style=single "$c" 'spec.proxiedWebAppExternalHostnames.customerManagement[+]' "{{ kubernetes.services['cray-nexus'].istio.ingress.hosts.ui.authority }}"
upgrade/1.2/scripts/upgrade/update-customizations.sh:135:yq w -i "$c" 'spec.kubernetes.services.cray-nexus.istio.ingress.hosts.ui.authority' 'nexus.cmn.{{ network.dns.external }}'
upgrade/1.2/scripts/upgrade/prerequisites.sh:347:    pdsh -b -S -w $(grep -oP 'ncn-w\w\d+' /etc/hosts | sort -u |  tr -t '\n' ',') 'for image in sonatype/nexus3:3.25.0 dtr.dev.cray.com/cray/proxyv2:1.6.13-cray1 dtr.dev.cray.com/baseos/busybox:1 docker.io/sonatype/nexus3:3.25.0 dtr.dev.cray.com/cray/cray-nexus-setup:0.3.2; do crictl pull $image; done'
[603]rusty@C02F43JEMD6P:~/gitstuffs/cray-shasta/docs-csm> grep -Ri cray-nexus * | grep rpm
[604]rusty@C02F43JEMD6P:~/gitstuffs/cray-shasta/docs-csm> grep -Ri cray-nexus * | grep zypper
[605]rusty@C02F43JEMD6P:~/gitstuffs/cray-shasta/docs-csm>


Handle focus for non-point geometry once rendering is implemented

Duplicate of #1925

Duplicate of #1925


Share permissions per user, not per device

Share permissions per user, not per device.  Fixes https://github.com/uProxy/uproxy/issues/1014
Design doc: https://docs.google.com/document/d/1p16jeodYUYF9tp2mh9nDVIHlKagzHZLYVHRKZLZkspw/edit

Consent.State is now part of the User object, not RemoteInstance.  This means that if I grant or request access I am granting/requesting for all instances of that user.
remoteGrantsAccessToLocal has been removed from Consent.State.  Even though consent is now per user, when I (the local user) grant access to a remote user, I am granting access to all of that user's devices but only to my current device.  We now use the wireConsentFromRemote.isOffering on each instance to see which (if any) instances the user has permissions me from.
All instance handshake messages now include consent (isOffering and isRequesting).  This allows us to remove an extra round trip of communication for each pair of instances.
RemoteInstance.updateConsent has been merged into RemoteInstance.update, since we now always have consent fields with the instance handshake.  RemoteInstance.update now delays updating until onceLoaded is complete, and returns a Promise so that the caller can tell when update finishes (e.g. to notify the UI with the updated user and instances)
The complex hidden expressions to toggle request/revoke/offer/etc buttons have been replaced by a simpler check for reading user.gettingConsentState and user.sharingConsentState enum values.  These are set in the UI.User's update method.

Tested with updated grunt test, running on Chrome and Firefox

@iislucas , @salomegeo , @lucyhe - you all may be interested in looking at these changes.  Thanks

I will review later today/tomorrow morning; thanks for getting this together so quickly!

Comments from the review on Reviewable.io
Reviewed files:

src/generic_core/consent.spec.ts @ r1
src/generic_core/consent.ts @ r1
src/generic_core/core.spec.ts @ r1
src/generic_core/core.ts @ r1
src/generic_core/local-instance.spec.ts @ r1
src/generic_core/local-instance.ts @ r1
src/generic_core/remote-instance.spec.ts @ r1
src/generic_core/remote-instance.ts @ r1
src/generic_core/social.spec.ts @ r1
src/generic_core/social.ts @ r1
src/generic_core/user.spec.ts @ r1
src/generic_core/user.ts @ r1
src/interfaces/instance.d.ts @ r1
src/interfaces/network.d.ts @ r1
src/interfaces/ui.d.ts @ r1
src/uproxy.ts @ r1

As a heads up, I only scrolled through the code in generic_ui, so that definitely needs more eyes.

src/generic_core/consent.spec.ts, line 19 [r1] (raw file):
Not actually relevant to this review: but this test looks a bit pointless in general.  We should have type-checking for this.

src/generic_core/consent.ts, line 11 [r1] (raw file):
These comments feel overly verbose considering the variable names, could this possibly be done with a single comment at the top?

src/generic_core/core.spec.ts, line 19 [r1] (raw file):
This is a bit outside the scope of this review (again), however, I think it might be better to either create a mock or use createSpyObj for this.  Feel free to ignore this.

src/generic_core/core.spec.ts, line 29 [r1] (raw file):
I think we can actually get rid of this entire block

src/generic_core/core.ts, line 422 [r1] (raw file):
We can replace the above with var user = network.getUser(path.userId).  It also might be good to modify the definition of the InstancePath interface such that it extends UserPath

src/generic_core/remote-instance.spec.ts, line 23 [r1] (raw file):
Personal preference: I think it looks better as new Consent.State().  Feel free to ignore.

src/generic_core/remote-instance.spec.ts, line 79 [r1] (raw file):
I don't think we have a strict guarantee that this will be run before the then block, do we?

src/generic_core/remote-instance.spec.ts, line 99 [r1] (raw file):
Can you make 'instanceId1' a constant? (it needs to be specifically used in some of the following tests)

src/generic_core/remote-instance.spec.ts, line 123 [r1] (raw file):
Basing a test around whether we called a function to show a desktop notification to a user feels wrong.
If you want to make these tests based around that, I'd switch the descriptions to talk about showing a desktop notification instead of just notifying the UI (which is really just based on the variables changing as far as I understand Polymer)

src/generic_core/remote-instance.spec.ts, line 196 [r1] (raw file):
Not related to the review, but can you remove this log while here?

src/generic_core/remote-instance.ts, line 69 [r1] (raw file):
My impression of why this is being made public is so that you are able to call stopShare from user.ts.
My view of how this should fit together is that RemoteInstance should totally encapsulate RemoteConnection and should not need to expose it.  I think a much better solution would be to add a function to RemoteInstance that will close the underlying connection.

src/generic_core/social.spec.ts, line 107 [r1] (raw file):
Why is a tick needed here?kkk

src/generic_core/user.spec.ts, line 176 [r1] (raw file):
I'd try to refer back to instanceData for these fields, or at least for instanceId

src/generic_core/user.spec.ts, line 193 [r1] (raw file):
General comment on this file: would it be possible to use handleMessage instead of syncInstance_ throughout the tests?  `S

src/generic_core/user.spec.ts, line 227 [r1] (raw file):
Empty lines at the start of a functions looks a bit odd, I think it happens a few other places as well

src/generic_core/user.spec.ts, line 231 [r1] (raw file):
In these cases, I think it personally looks a bit cleaner (and makes indentation a bit less wild if you do:
user.modifyConsent(uProxy.ConsentUserAction.REQUEST).then(() => {
  expect(user.consent.localRequestsAccessFromRemote).toEqual(true);
  return user.modifyConsent(uProxy.ConsentUserAction.CANCEL_REQUEST);
}).then(() => {
  expect(user.consent.localRequestsAccessFromRemote).toEqual(false);
  done();
});

src/generic_core/user.spec.ts, line 240 [r1] (raw file):
This does not seem to test anything the above test did not already handle.

src/generic_core/user.spec.ts, line 266 [r1] (raw file):
Same comment as above with the then blocks

src/generic_core/user.spec.ts, line 280 [r1] (raw file):
then block levels

src/generic_core/user.spec.ts, line 315 [r1] (raw file):
I think a better title for this test would be something like "sets ignore request flag when remote is requesting" or something like that (I'd expect the test to function the same if you took out all the lines referring to remoteRequestsAccessFromLocal so feel like there should be some mention of that in the description)

src/generic_core/user.spec.ts, line 325 [r1] (raw file):
And I just realized that all these tests share state... :(
I think we should definitely look at changing that, or at least not using the state for new tests being added.  Thoughts on that?

src/generic_core/user.spec.ts, line 358 [r1] (raw file):
This looks a bit funny indentation-wise.  At the very least, I'd recommend moving the .then call down a line (at best, same then indentation comment as above)

src/generic_core/user.ts, line 188 [r1] (raw file):
This should either check for an error or propogate the rejected promise (I'd personally be in favour of propogation, however, it does not seem like any of the errors from syncInstance_ are critical enough to warrant propogation)

src/generic_core/user.ts, line 224 [r1] (raw file):
Possible better name: getLocalConsentBits.  General feeling is this should encapsulate the fact that this only gets the flags describing the local state to the remote, not the other direction.

src/generic_core/user.ts, line 263 [r1] (raw file):
I think a better description here would be "Received an instance handshake from a client that is not online".  Thoughts?
Regardless, rejection messages should be wrapped in an Error.

src/generic_core/user.ts, line 289 [r1] (raw file):
Any thoughts on switching saveToStorage around to actually return a promise resolving once everything is successfully saved?kkk

src/generic_core/user.ts, line 318 [r1] (raw file):
It feels like this function is doing a lot of processing that could be done in the UI based off of us just returning raw data.  Thoughts on moving towards that? (

src/generic_core/user.ts, line 357 [r1] (raw file):
Any idea if this is still relevant?

src/generic_core/user.ts, line 482 [r1] (raw file):
Not relevant to this review, however, this should at the very least return Promise.resolve<void>().  This has the potential for a TypeError (kind of surprised that TypeScript does not catch this actually, we might want to look into that).

src/generic_core/user.ts, line 511 [r1] (raw file):
I'm a bit unclear on what the promise returned by this command should reflect.  My personal impression of how it should work would be:
return this.onceLoaded.then(() => {
  /* error checking */
  return Promise.all([revoke access for everything])
}).then(() => {
  return Promise.all([send instance handshakes]);
}).then(() => {
  return this.saveToStorage();
}).then(() => {
  /* update the UI */
});

So that this returning would indicate that all steps had been successfully completed.
Anyways, obviously not saying it has to be like that, but it would be good to have a comment explaining what a successfully resolved promise indicated.

src/generic_core/user.ts, line 518 [r1] (raw file):
It seems like the function would return a rejected promise in this case instead of a successfully resolved one.

src/generic_core/user.ts, line 534 [r1] (raw file):
We are already in a block where this.onceLoaded has been called, it should not be needed here as well. (if it is, I think there is probably a bigger bug)

src/generic_ui/polymer/instance.ts, line 6 [r1] (raw file):
I'm guessing you meant to delete this.

 Getting the tests updated looks like it took a lot of work.. Aside from trying to make our tests independent (which Jonathan mentioned), looks solid! It's still kind of hard to keep track of what-means-what wrt consent, so I'll keep trying to think of clearer naming conventions..

src/generic_core/consent.ts, line 13 [r1] (raw file):
Thoughts on naming this localInstanceGrantsAccessToRemote to differentiate it from localRequestsAccessFromRemote and remoteRequestsAccessFromLocal (implied to be user <--> user)? I think that also helps clarify why there's no remoteGrantsAccessToLocal in this class.

src/generic_core/core.ts, line 422 [r1] (raw file):
Did you mean this.getUser?

src/generic_core/remote-instance.spec.ts, line 69 [r1] (raw file):
Does this depend on the onceLoaded from the previous test?

src/generic_core/remote-instance.spec.ts, line 112 [r1] (raw file):
Could you add expect(instance.user. remoteRequestsAccessFromLocal).toEqual(false) at the beginning and .toEqual(true) in the then block?

src/generic_core/social.ts, line 131 [r1] (raw file):
might be nice to rename to localInstance

src/generic_core/user.ts, line 224 [r1] (raw file):
Daniel + I were chatting about how this class can be renamed remote-user or something like that (preferably in another PR, since this one's getting pretty big). I think that would also make this more clear.

src/generic_core/user.ts, line 475 [r1] (raw file):
Rename to localInstance?

src/generic_ui/polymer/contact.html, line 94 [r1] (raw file):
This end tags are super helpful!

src/generic_ui/polymer/instance.html, line 68 [r1] (raw file):
typo

src/generic_ui/polymer/roster.html, line 70 [r1] (raw file):
This fixes the 'same title in both tabs' bug, right?

src/generic_ui/scripts/user.spec.ts, line 27 [r1] (raw file):
Did we want offeringInstances to be defined instead?

Comments from the review on Reviewable.io

src/generic_core/consent.spec.ts, line 19 [r1] (raw file):
I agree, this file is pretty much just a placeholder

src/generic_core/consent.ts, line 11 [r1] (raw file):
I'm gonna keep them, they help me remember what this code is

src/generic_core/consent.ts, line 13 [r1] (raw file):
Right now we aren't using "Instance" anywhere in the variable names.  Are you suggesting one start with "localInstance" and the other just start with "local"?  I'd rather keep these names, we have been using these names for many months and they are in the design documents which I don't can't edit

src/generic_core/core.spec.ts, line 29 [r1] (raw file):
This results in hiding any console.log calls, which doesn't hurt, plus its kinda irrelevant to the changes I made for consent

src/generic_core/remote-instance.spec.ts, line 69 [r1] (raw file):
Yes, when I tried creating new instances I had really terrible async behavior that broke many of the following tests.  I'd rather keep it this way for now, we have several github issues already entered for cleaning up tests and can address dependencies between test cases then.

src/generic_core/remote-instance.spec.ts, line 79 [r1] (raw file):
Yes we do - all then blocks get evaluated asynchronously, even if the promise is already resolved at the time you call .then.  This is nice because we can always our code will run async, rather than having to make sure it handles both sync and async cases.

src/generic_core/user.spec.ts, line 231 [r1] (raw file):
Sorry I prefer this way, I think it better shows that the 2nd call to user.modifyConsent is also async, and that the last expect statement is checking on the behavior of the 2nd modifyConsent call

src/generic_core/user.spec.ts, line 325 [r1] (raw file):
I just copied all these tests from remote-instance.spec.ts, replace intsance.modifyConsent with user.modfiyConsent, and rewrote them to be async.  I agree they are bad but I'd rather leave them for now to keep this pull request a manageable size.  We can revisit these test cases later

src/generic_core/user.ts, line 224 [r1] (raw file):
LocalConsentBits sounds wrong, this is actually the consent sent by the remote side to us.  Also "getConsentBits" is the name we've always been using, I just moved it from the remote-instance class to the user class

src/generic_core/user.ts, line 289 [r1] (raw file):
We intentionally don't wait for saveToStorage to finish so that we can notify the UI right away.  Even if it returned a promise, we'd just want to ignore that promise here

src/generic_core/user.ts, line 318 [r1] (raw file):
Most of this logic has been here for months and is well tested.  The only new logic I added was send only instances which offer consent - this allows the UI do make simple checks in polymer using offeringInstances.length.  I added the isOnline field, which lets the UI know if there are online instances that don't offer access yet.  This code is all working well and I'd rather leave it as is than do another refactor now.

src/generic_core/user.ts, line 357 [r1] (raw file):
Probably not but I don't know enough about this to remove the comment.

src/generic_core/user.ts, line 475 [r1] (raw file):
We've been using myInstance throughout the code since last summer, I'd rather keep this.  "local" only works well when constrasted with "remote", e.g. "localGrantsAccessToRemote" ("myGrantsAccessToRemote" doesn't work grammatically).  But otherwise I think "myInstance" is cleaner

src/generic_core/user.ts, line 511 [r1] (raw file):
We don't actually need the Promise to resolve when all steps are completed, only when the user.consent fields are updated.  The only async bit we actually wait on here is this.onceLoaded - once that's complete we update permissions (using Consent.handleUserAction which is sync), stop sharing if needed (sync), send instance handshakes (sync), save (async but we don't care to wait on it), then notify the UI (sync)

src/generic_ui/polymer/roster.html, line 70 [r1] (raw file):
Yes

Comments from the review on Reviewable.io

src/generic_core/core.ts, line 422 [r1] (raw file):
Yes

src/generic_core/user.ts, line 224 [r1] (raw file):
Okay, I'm now even more confused about what this function is returning, I think there should definitely be some clarification in the naming.  You are saying that localRequestsAccessFromRemoteis whether, from the view of the remote user, the local user is requesting access?

src/generic_core/user.ts, line 511 [r1] (raw file):
Okay, can you add a comment explaining what the semantics of returning from this is?

Comments from the review on Reviewable.io

src/generic_core/consent.ts, line 13 [r1] (raw file):
Yp,! I meant 'localInstance' just the one for granting; since requesting is user-based but granting is still instance-based.

Comments from the review on Reviewable.io

src/generic_core/core.spec.ts, line 29 [r1] (raw file):
No it's good to hide console.logs by default, it makes test output clearer. let's keep this

src/generic_core/remote-instance.ts, line 83 [r1] (raw file):
neat!

src/generic_core/remote-instance.ts, line 235 [r1] (raw file):
Can you explain this? Isn't oldIsRequesting and newIsRequesting always the same?

src/generic_core/user.spec.ts, line 231 [r1] (raw file):
I agree with daniel on this, You'll see this style everywhere in our code base. We can discuss styling during our campfires.

src/generic_core/user.ts, line 255 [r1] (raw file):
Why does this need to return a promise?

src/generic_core/user.ts, line 333 [r1] (raw file):
You don't need totalInstanceCount and allInstanceIds, you can just use keys() and length, am I wrong?

src/generic_ui/polymer/roster.html, line 70 [r1] (raw file):
sweet!

Comments from the review on Reviewable.io

src/generic_core/consent.ts, line 13 [r1] (raw file):
I'll update the comment to make this clear

src/generic_core/core.spec.ts, line 29 [r1] (raw file):
I just removed this along with the trace from MockStorage, now things are cleaner and we don't need to spy on console.log

src/generic_core/core.ts, line 422 [r1] (raw file):
Done

src/generic_core/remote-instance.spec.ts, line 23 [r1] (raw file):
Done.

src/generic_core/remote-instance.spec.ts, line 99 [r1] (raw file):
Done.

src/generic_core/remote-instance.spec.ts, line 112 [r1] (raw file):
Done.

src/generic_core/remote-instance.spec.ts, line 123 [r1] (raw file):
Just updated the description.  We haven't been generating notification text in the core for a long time, although in the future it might be nicer (and make for better tests) if we generate notification text in the UI instead based on some other update from the core.

src/generic_core/remote-instance.spec.ts, line 196 [r1] (raw file):
Done.

src/generic_core/remote-instance.ts, line 69 [r1] (raw file):
Done.

src/generic_core/remote-instance.ts, line 235 [r1] (raw file):
No - this.user.updateRemoteRequestsAccessFromLocal() can modify that value.  i.e. if you just got an instance handshake that set isRequesting=false and that had been the only instance requesting access, user.consent.remoteRequestsAccessFromLocal will change from true to false.  But if there are other instances still requesting access, user.consent.remoteRequestsAccessFromLocal will remain true

src/generic_core/social.spec.ts, line 107 [r1] (raw file):
Removed, not needed after all

src/generic_core/social.ts, line 131 [r1] (raw file):
See comment below - we'll keep this as myInstance for now

src/generic_core/user.spec.ts, line 176 [r1] (raw file):
Done.

src/generic_core/user.spec.ts, line 193 [r1] (raw file):
Just discussed this with Jonathan, we are going to leave this as-is for now.  The problem is that syncInstance_ returns a Promise, but handleMessage does not (handleMessage doesn't really care about the result of syncInstance).  Making handleMessage return a Promise would be a major pain and only really help a bit in making the tests not call private methods

src/generic_core/user.spec.ts, line 227 [r1] (raw file):
Done.

src/generic_core/user.spec.ts, line 231 [r1] (raw file):
Discussed with Jonathan, we'll leave this as is for now.

src/generic_core/user.spec.ts, line 240 [r1] (raw file):
Removed

src/generic_core/user.spec.ts, line 315 [r1] (raw file):
Just changed the title to "ignoring request does not change remoteRequestsAccessFromLocal"

src/generic_core/user.ts, line 224 [r1] (raw file):
Just removed getConsentBits - it was only called in one place (sendInstanceHandshake) and it's clearer to inline this object there

src/generic_core/user.ts, line 255 [r1] (raw file):
syncInstance_ ends by calling instance.update which is now async, as it doesn't complete until instance.onceLoaded resolves (we don't want to update consent fields only to have them clobbered when storage load completes).  No real callers check the Promise returned by syncInstance_ but this is needed for testers to check expectations after syncInstance_

src/generic_core/user.ts, line 263 [r1] (raw file):
We use this wording because the client could be either OFFLINE or ONLINE_WITH_OTHER_APP (e.g. if they are a GTalk user sending us an XMPP message from the chat client in GMail).
But I did change this to an error

src/generic_core/user.ts, line 333 [r1] (raw file):
Done.

src/generic_core/user.ts, line 511 [r1] (raw file):
Just refactored a bit to make it more clear

src/generic_core/user.ts, line 518 [r1] (raw file):
Done.

src/generic_core/user.ts, line 534 [r1] (raw file):
Done.

src/generic_ui/polymer/instance.html, line 68 [r1] (raw file):
Done.

src/generic_ui/polymer/instance.ts, line 6 [r1] (raw file):
Done.

src/generic_ui/scripts/user.spec.ts, line 27 [r1] (raw file):
Done.

Comments from the review on Reviewable.io

I believe

src/generic_core/user.spec.ts, line 280 [r1] (raw file):
discussed this, will leave as is

src/generic_core/user.ts, line 188 [r1] (raw file):
Done

Comments from the review on Reviewable.io

src/generic_core/core.spec.ts, line 19 [r1] (raw file):
Ack, will ignore for now

Comments from the review on Reviewable.io

src/generic_core/user.spec.ts, line 266 [r1] (raw file):
Discussed this with Jonathan, will leave as is

src/generic_core/user.spec.ts, line 358 [r1] (raw file):
Will leave indentation as is for now

Comments from the review on Reviewable.io

(sorry hit publish too soon before)
I believe I've addressed all the comments.  PTAL, we want to have this merged tomorrow morning if possible.


store token in localStorage

For security it might be better but for portability it sucks. Still it might be worth it if people are worried about privacy.

I'm gonna close this for now. I think the utility of the token being stored in settings is better than any imagined security provided by local storage.


Redo Terraform to include vector and DO spaces

https://github.com/loftwah/linkarooie/pull/28

https://github.com/loftwah/linkarooie/pull/28


Endless loading layer is preventing user from adding custom headers

Not sure if I'm adding the headers from the correct position...
I have the same use case as mentioned in #638
but I don't know how to do this...
The only place I have found is under HTTP settings, I tried to input but it's blocked by the Loading layer.
After manually removing the loading nodes via DevTools, I found the settings are not saved actually...
I am using Cloudflare Tunnel and successfully exposed AriaNg to public network (with protection), and I'm trying to access Aria2 hosted from my home...

Please change the options in AriaNg Settings if you want to change the rpc connection configuration. Options in Aria2 Settings would effect the connected aria2 settings.

Please change the options in AriaNg Settings if you want to change the rpc connection configuration. Options in Aria2 Settings would effect the connected aria2 settings.

The UI looks different from my side:

I was using docker compose:
  AriaNg:
    container_name: ariang
    image: p3terx/ariang

Please change the options in AriaNg Settings if you want to change the rpc connection configuration. Options in Aria2 Settings would effect the connected aria2 settings.

The UI looks different from my side:
I was using docker compose:
  AriaNg:
    container_name: ariang
    image: p3terx/ariang

the minimal version which supports custom header is 1.3.1, please upgrade to the latest version. if you use third-party release, please contact the maintainer.

Please change the options in AriaNg Settings if you want to change the rpc connection configuration. Options in Aria2 Settings would effect the connected aria2 settings.

The UI looks different from my side:
I was using docker compose:
  AriaNg:
    container_name: ariang
    image: p3terx/ariang

the minimal version which supports custom header is 1.3.1, please upgrade to the latest version. if you use third-party release, please contact the maintainer.

Oh...I didn't realize I was using a third-party release...
Thank you so much for your help :)


app reloads when starting

When starting the app, I see it load, and then reload about 2 seconds after. It's much quicker when not in developer mode, but it does still reload.
I tried this with current main, and also a previous release 0.24.1. I'm not sure how long it's been happening, and haven't bisected back further.
It's not such a problem because in release mode it's very quick and barely noticeable. In dev mode it's just slightly annoying (to me anyway).

I've looked a bit more into this. When starting the backend it will start watching for plugin changes. When it detects change it will send a X-Reload header to the frontend.
But it also happens just when starting backend for the first time. You can notice the following log in the backend output
 {"level":"info","source":"/home/dubenko/headlamp/backend/pkg/plugins/plugins.go","line":224,"time":"2024-08-01T12:23:23+02:00","message":"Sending reload plugins signal to frontend"}

I've traced it down to plugins.go file. It manually sends a fsevent for all files on the first run, I think this is the issue
func periodicallyWatchSubfolders(watcher *fsnotify.Watcher, path string, interval time.Duration) {
// ...
				// when a folder is added, send events for all the files in the folder
				entries, err := os.ReadDir(path)
				if err != nil {
					logger.Log(logger.LevelError, map[string]string{"path": path},
						err, "reading dir")

					return err
				}
				for _, entry := range entries {
					watcher.Events <- fsnotify.Event{Name: filepath.Join(path, entry.Name()), Op: fsnotify.Create}
				}
// ...
}


atom messy code

i update atom to v0.189.0, then open a file with chinese code, and it's messy

when i set font family 'Loma' or others, it also didn't work, but i can open it normally with gedit

Duplicate of https://github.com/atom/atom/issues/6214.


Skip build on specific user commits

Overview
GitHub PullRequest Builder provides functionality for triggering a Jenkins build on PR commit or comment from specific users. There is a specific use case when commits are made by build bots (checking in build artifacts into PullRequest as a result of the Jenkins build job). In such cases, under current conditions we inevitably running into a "recursive" build scenario, where each build commit will trigger a subsequent build.
Change
Add ability to skip build if commits are made by users indicated in Skip Build Commit Author list configuration (see screen shot)

Log
Feb 23, 2017 4:51:41 PM org.jenkinsci.plugins.ghprb.GhprbRootAction handleAction
INFO: Checking issue comment 'test this please' for repo MyOrg/MyProject
Feb 23, 2017 4:51:41 PM org.jenkinsci.plugins.ghprb.GhprbTrigger handleComment
INFO: Checking comment on PR #1 for job myproject-build
Feb 23, 2017 4:51:41 PM org.jenkinsci.plugins.ghprb.GhprbPullRequest updatePR
INFO: Pull request #1 was updated/initialized on MyOrg/MyProject at 2/23/17 4:51 PM by Illya Chekrygin (comment)

Feb 23, 2017 4:56:29 PM hudson.model.Run execute
INFO: myproject-build #17 main build action completed: SUCCESS
Feb 23, 2017 4:56:33 PM org.jenkinsci.plugins.ghprb.GhprbRootAction handleAction
INFO: Checking PR #1 for MyOrg/MyProject
Feb 23, 2017 4:56:33 PM org.jenkinsci.plugins.ghprb.GhprbTrigger handlePR
INFO: Checking PR #1 for job myproject-build
Feb 23, 2017 4:56:33 PM org.jenkinsci.plugins.ghprb.GhprbPullRequest updatePR
INFO: Pull request #1 was updated/initialized on MyOrg/MyProject at 2/23/17 4:56 PM by Illya Chekrygin (PR update)
Feb 23, 2017 4:56:34 PM org.jenkinsci.plugins.ghprb.GhprbPullRequest checkSkipBuild
INFO: Pull request triggered by Jenkins user. Hence skipping the build.

Tracking
https://github.com/jenkinsci/ghprb-plugin/issues/487

Hi @ichekrygin
I haven't had time to take a close look, but briefly, I wonder if you could change it to "blacklist commit author". That would make it consistent with our whitelist/blacklist nomenclature in the other features. I'll take a closer look at the code soon.

Hi @benpatterson, good call, I will update it.

@ichekrygin just pinging you that this is still on the docket. It's behind the pipelines PR right now (# 497)

@benpatterson: thx for update

@ichekrygin I've merged the other pull request that was in front of this one, but it'll require a rebase on your part. Could you pull in the latest from master and make any adjustments? Then I can take a closer look.

Hi @ichekrygin Could you rebase on master? I was about to merge but a conflict was detected. I don't have time to look into it right not but if you're able to sort through it, I can proceed on my end. Thanks for the help!

Thank you @ichekrygin glad to get this merged!


Update natchez-core, natchez-noop to 0.3.5

About this PR
📦 Updates

org.tpolecat:natchez-core
org.tpolecat:natchez-noop

from 0.3.4 to 0.3.5
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.tpolecat" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.tpolecat" }
}]

labels: library-update, early-semver-minor, semver-spec-patch, version-scheme:early-semver, commit-count:1

Superseded by #318.


reuseAddr for dgram.CreateSocket

Creating a udp4 and udp6 socket on the same port can result in "ERROR: bind EADDRINUSE". Passing reuseAddr: true fixes this.

I'll mention that this only works for node v0.12

Thanks for discovering this! I was running into this issue occasionally and couldn't figure it out.
I added back node v0.10 support and published this as v4.4.2.


PrivateKeyAccess Permission

I'm trying to implement a more restrictive approach regarding private key access. Usually, we'd like private keys not to be accessed at all, but at the same time allow users do things like requesting a cert to be signed or revoke certs.
While in the documentation I found references to such permissions (https://lemur.readthedocs.io/en/latest/administration.html#identity-and-access-management) I couldn't find any kind of implementation and currently I can't see any way of allowing a user to request a certificate without exposing him the private key.
My initial proposal would be something like jplana/lemur@f5a2c96bddc633cc3e8bfc44e026b3fec66b196c
This would require to add a new role, and add this role to every user that needs to access private keys (in this case only for PendingCertificates, but adding this restriction to issued certs would be quite easy).
Would you be interested on adding this?

I agree we shouldn't allow private keys to be exposed for pending certs. The way we have handled this in other places is through creator and owner roles:
https://github.com/Netflix/lemur/blob/master/lemur/certificates/views.py#L448
Would restricting pending_certificates to those roles work for your use case.
cc @castrapel

Actually I was thinking of having the very same approach for certificates (so using the very same annotation in the method you pointed out). While it might seem useful to access the private key, If we can configure destinations properly, and restrict key access, we could probably delegate a lot of tasks to a broader range of users.

@jpartain89, I agree with the general notion of tightening access to the private key, but not all destinations are supported by Lemur, and there are the edge cases, where the cert owner/creator needs to fetch the private key and deploy it on the their end-points manually.

@hosseinsh I completely understand the need for it. Part of our needs come from the fact that, while in our case the destination can be automated, the source for the certificates (the issuer) needs manual interaction (emails and other docs attached), so we wanted some human trusted agents to manage (request/create/revoke) them for us. While these agents are trusted, we don't think they should access private keys.
This patch would work (or at least be helpful) if the manual private key management is really an edge case and just a few users need to deploy to those manual end-points, as you could just add the access_sensitive role to them. If the need is actually more traversal, and a lot of users need to access those endpoints, adding this role to everybody (making it the default?) would work too. The problem is that currently, without this or other similar patch, the creator of any pending certificate is automatically granted access to the private key.
Please let us know if there's any other way we could make this more acceptable for your use case.

This is a great first-step, but the addition of an access_sensitive role seems excessive in that it will grant the cert owner the ability to see all of their certificates' private keys.
It seems more viable to attach a separate set of roles for private key access to the certificate. Right now, a certificate has "Roles". With the addition of a "Roles allowed to view private key" addition (This would default to being nothing, or being admin during cert creation), admins could add any existing role(s) they would like for private key viewership/export.
I think this would require the creation of a new roles -> certificates association table
that would associate certificates to roles which users need to be a member of to view private key (private_key_roles)? And changing the view private key logic a bit to account for this. Thoughts?

@castrapel that was actually our long term plan, but probably only the first step. I'd say that instead of setting up "nothing" or "admin" during cert creation for those "Roles allowed to view private key" defaults, it would be great to make those roles be dependent on the source/destination. So if the user during certificate creation uses a specific source (or sets a specific destination), the role is automatically granted to him. That would mean that giving users access to specific sources/destinations would give them access to their privates keys as necessary. I'd say that this logic should be in the source/destinations plugin (I'm sure about the source as it's probably the only place where it makes sense, but destinations might change during cert lifecycle...)
While this is for sure the way to go, we didn't want to get into it yet as we don't really need it in our first implementation stage (we'll have a set of users that will be able to access all private keys) and these changes will probably take longer to implement than the all or nothing access_sensitive solution.

Hi @jplana, our environment is vastly heterogenous as far as sources are concerned. There are many users operating in a single source that have no business viewing other private keys on that source. We have a number of users that might be confused if we started with a broad access_sensitive model and changed it to more granular private key controls after the fact. If we just implemented access_sensitive, I suspect that our Lemur support oncall would be burdened by numerous user complaints about being unable to view private key for a specific cert, and our only recourse would be to allow them to view all of the things, which would be an unfortunate fix.
I agree with you that some type of role naming syntax that allows key viewership across a source makes sense. Also, for users who need to view all of the private keys but who we don't want to make administrators, having an all-powerful private-key viewership role such as access_sensitive also makes sense.  However in order for us to merge this in, we would also need the capability to specify specific roles allowed to  view a certificate's private key.
Thanks,
Curtis

Did this ever get resolved? Specifically the part regarding allowing users to request certificates to be signed with an authority, but not have access to the authority's private key? If so, what are the necessary changes required to make this happen. Thanks in advance.

Hi @Jonesy22, I don't believe users have access to an authorities private key, because they have the permission to use that Authority. The Authorities' page doesn't ever render the private key of an authority, which for most cases is not accessible to Lemur, e.g., public CAs etc.

@hosseinsh  When an authority is created, a certificate is created in the certificates view for the authority. Here, any user who has operator or admin access can view the private key. But I was wanting a user to use the authority to sign a certificate, without being able to see the key here.


preventDefault not stopping propagation with remote link_to

Problem
Within a stimulus controller action, event.preventDefault is not stopping the ajax request created with remote: true from a link_to element
Expected
I would expect event.preventDefault to stop the ajax request as I believe it does with button_to etc.
Sample code
# index.erb
<%= link_to 'New Article', new_article_path, remote: true, data: {action: "hello#testPreventDefault"} %>

//hello_controller.js
  testPreventDefault(event){
    event.preventDefault()
  }

Output
The logs show the new route is accessed even though event.preventDefault() is called:

Sample repo
https://github.com/MrHubble/stimuluslinkto

event.preventDefault() only prevents the link from being followed. event.stopImmediatePropagation() will stop the event from being propagated to other event handlers.

@fourcube thanks for taking the time to help.
With event.stopImmediatePropagation() the request still went through but this time as HTML rather than JS:

@fourcube I think I must have misunderstood your answer. When I use both preventDefault() and stopImmediatePropagation() together it works which is what I think you were referring to. So the solution is
  testPreventDefault(event){
    event.preventDefault()
    event.stopImmediatePropagation()
  }

Seems I have some reading to do. Thanks again.


Add Context to DefaultProviderAttribute

New Context property for DefaultProviderAttribute which gets passed on
to new Context property on DefaultProvider abstract class.
I added this so that I could determine which property the DefaultProvider was being invoked on.  I could not determine that from the VerbExecutionContext during DefaultProvider.GetDefault().  Another way could be to add a Parameter property to the VerbExecutionContext but this way seemed more flexible.
Now I can use a single DefaultProvider-derived class to service many different properties.  In my specific application, I have a verb to set defaults for other verb/parameter combinations and the my DefaultProvider checks for a saved default if the parameter isn't supplied on the command line.
Example attribute usage:
[DefaultProvider(typeof(ProfileDefaultProvider), "chatId")]
Example DefaultProvider derived class:
public class ProfileDefaultProvider : DefaultProvider
{
public override object GetDefault(VerbExecutionContext context)
{
string verb = context.Method.MethodInfo.Name;
string key = Context;
return Program.ProfileData.GetVerbData(verb, key);
}
}

It doesn't look like you are actively developing this, but just wanted to pass on that I have been using CLAP for years and IMO it's still the best command line lib out there for .NET that I have run into.  I even use it for a command parser in a chat application we have developed.

@MikeJansen that's true.
Unfortunately I am not actively involved in this project anymore.
Thank you for your feedback. I really appreciate it and seeing that CLAP is still being used after so many years means a lot to me :)


stream reference bug  when request set deadline

Please answer these questions before submitting your issue.
Should this be an issue in the gRPC issue tracker?
Create new issues for bugs and feature requests. An issue needs to be actionable. General gRPC discussions and usage questions belong to:

grpc.io mailing list
StackOverflow, with grpc tag

Please don't double post your questions in more locations; we are monitoring both channels, and the time spent de-duplicating questions is better spent answering more user questions.
What version of gRPC and what language are you using?
grpc 1.4.1, C++
What operating system (Linux, Windows, …) and version?
Linux 3.10.0-514.el7.x86_64  Centos 7.3
What runtime / compiler are you using (e.g. python version or version of gcc)
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
What did you do?
async mode client send 100 request per second   to a slow server,  each request has 200K Bytes payload and with a random deadline. Then kill the client and start a new one in a infinite loop.
What did you expect to see?
the slow server will run normally forevver.
What did you see instead?
server crashed after some time,  dead at the abort() in destroy_stream_locked().
Then I found this stream stay on  WRITING list。
 Then, this stream leave the stalled state and become writting state, inc rease the ref count by 1 (the last log). This seems weird。
So, I think there is a stream ref count bug.
Anything else we should know about your project / environment?

maybe the same with #10516

Update: I found this issue still appear in version 1.6.0.

I encounter the similar issue here. A quick client send requests to a slow server, and replace the client in a while. Although I didn't set a deadline, but server will abort the call early which is similar with deadline.


Update logo to fuse branding

Fixes #184
Description

@Yndira-FlowForge my apologies - I scanned the issue and jumped in without noticing you'd provided the graphic already.
Have updated:

Given the logo has 'Device Agent' in it, I have removed the other text from the header as it is redundant.

Don't worry about it. It looks really good!!