R24.05 Policy Hub - Release Checks

[!IMPORTANT]
Follow the guidance on how to use the templates.

Release Info
Please provide information on what you want to be included in the Eclipse Tractus-X release.
If you are not owner of this issue, please provide the information as comment to the issue.
Make sure to assign this issue to expert(s) for their approval, as soon as you have finished preparation. Multiple assignees allowed; they will un-assign themselves once review completed.
Version to be included in Eclipse Tractus-X release: 1.0.0 [NOT YET RELEASED]
Leading product repository: https://github.com/eclipse-tractusx/policy-hub
For the QG Review the latest available Release Candidate (RC) version is to be checked, the RC versions will be kept up to date in the following: 1.0.0-rc.1
Compliance Verifications
This issue tracks all checks, that need to be performed for a product release in Eclipse Tractus-X.

[x] Interoperability checks performed
[ ] Data Sovereignty checks performed

General Checks

[ ] Tractus-X Release Guidelines(TRGs) fulfilled

[!NOTE]
Note: most criteria for documentation and security are now covered in TRGs

Security Checks

[x] Thread Modelling Analysis passed

Test Results

[ ] E2E Integration Test passed
[ ] User Journey approved

Helpful Links

Eclipse Tractus-X openAPI specs on SwaggerHub

Reviewing committer is @tom-rm-meyer-ISST, thanks for taking that over!
I'll inform you in a couple of weeks once you can start with the review

no changes to interoperability in comparison to last release.
QGate approved!

Security Assessment done on 2024-05-15 by @szymonkowalczykzf and me.
Threat Modeling can be marked as passed, as there are not security-relevant changes to the architecture compared to the last assessment.

INT Tests need to be documented. E2E Tests ongoing. Testmanagement Approval cannot be given at this time.

QG review 17-May
data sov pending
only documentation of tests open / expected 17-May
TRG review completely outstanding
User journey approval expected by @jjeroch after test documentation complete

no use of EDC and policies for access of the policy elements. therefore sovereignty requirements are not applicable - if the assumption on sovereignty for this data exchange is feasible. Expert approval granted

@evegufy data sov considered completed

User Journey Approved

INT Tests documented and E2E Tests successful.
TM approves. Thank you for your efforts!

@RolaH1t all done (already 2 days ago):
Version to be included in Eclipse Tractus-X release: 1.0.0 [RELEASED]

Congrats!
QG fully approved with all prerequisites fulfilled.
Thanks for all your efforts.


Add awscli V2 installation package and more --gcp_min_cpu_platform options

Hi,
Can you split the pull request into 2 separate requests?
One for AWS CLI v2 and the other for the GCP change -> then feel free to add me as a reviewer for each PR.

Hi,
Can you split the pull request into 2 separate requests?
One for AWS CLI v2 and the other for the GCP change -> then feel free to add me as a reviewer for each PR.

@shyamsabhaya Thanks for the review. How about now? Is that acceptable?


feat: adding functionality for subscriber popup

ideally, this script should make it possible to have a popup from Mailchimp which should look nicer than the subscribe redirect thing.
https://mailchimp.com/en-gb/help/add-a-pop-up-signup-form-to-your-website/

This is cool, I have added it into a rebase merge


No working dashboard title (links) after update to 21.1.3

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues and I am convinced that mine is new.

Describe the bug
After the update to 21.1.3 the dashboard title (links) do no longer work correctly.
To Reproduce
Update to 21.1.3 and have a look at the dashboard.
Expected behavior
Working dashboard title (links).
Describe alternatives you considered
Live with it.
Screenshots

Environment
Software version used and hardware type if relevant, e.g.:
OPNsense 21.1.3 (amd64, LibreSSL).

Also need to search for closed issues ;)


Modified to display articles in two columns rather than alternating

Link to Trello card

Just pushed a small change to update yarn.lock. It turns out the README was wrong -- we shouldn't be running npm i because this repo uses yarn instead of npm. Instead I ran yarn install and it undid some of the extraneous changes in yarn.lock. Sorry about that! Will update the README

lgtm!


Add actor-related and run-related resource & resource collection clients

This PR:

adds the clients for actors, actor versions, runs & their respective collections
integrates the run-related additions to the placeholders in the task client
refactors the key-value store record encoding code out of the key-value store client, as it's used in more places now (for run inputs, since those are just key-value store records in the end)
slightly reorders the clients in docs to group them a bit more logically (this could still use more thought later)

I've tried to test this as much as I could, but there are honestly so many combinations of inputs to the methods that I'm afraid I missed some, and I apologize in advance if there are some bugs. I can't wait for when we implement proper integration tests.

@fnesveda is this ready for review? It still has draft label. thx

@mhamas Oops, sorry, forgot to mark it ready, good catch :)


Bugfix/empty iterable

What does this PR do?
Fixes #6810
Before submitting

[ ] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[ ] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure your PR does only one thing, instead of bundling different changes together?
[ ] Did you make sure to update the documentation with your changes? (if necessary)
[ ] Did you write any new necessary tests? (not for typos and docs)
[ ] Did you verify new and existing tests pass locally with your changes?
[ ] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is free to review the PR once the tests have passed.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[ ] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[ ] Make sure the title is self-explanatory and the description concisely explains the PR
[ ] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃

Hello @awaelchli! Thanks for opening this PR.

In the file pl_examples/debug.py:

Line 51:10: W292 no newline at end of file

Do see the Hitchhiker's guide to code style


Setup CDN for release and prod with different origins

Set up two CDN's with release and prod as origin servers and share the base urls.

[x]  CDN for release
[x]  CDN for prod

PR to create CDN for prod is ready in cd repo. We will need to run it when required.


DocsArchive-<IP_ADDRESS>Auto archive content

Auto archive content from https://github.com/opstest2/docs-archive-test-source.git

Docs Build status updates of commit 7a4a650:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


State storage in router location vs. Redux store

Hi all - thanks for all the great work lately on 4.x.x. Apologies for opening another "existential discussion" ticket but I wanted to ask a few questions about the react-router-redux state model. I'm working on my first Redux app after several projects in Reflux, so some of this may just be some misunderstanding of how Redux is supposed to work.
Namely I want to question the axiom that "You should not read the location state directly from the Redux store." I know that it's currently unsupported due to react-router's asynchronicity, but I guess I'm wondering if there's a way to make it work. My use case is something like this:
I have a "page" in my SPA that is an interactive chart with a bunch of settings (filters, time ranges, that kind of thing). I'd like to store them in app state because some of the settings may be used by other components on other pages. So I wire the thing up with an UPDATE_CHART_SETTINGS Redux action and a chartReducer that maps the settings into state.chart.settings and it all works like a charm.
The thing is, I know that in a few weeks, the boss will come tell me that "settings X, Y and Z are the most important, we need to save them in the query string so that people can share links and see the same thing." So, (if I understand the docs correctly,) at that point I will need to add a history.pushState somewhere, either in the component onChange callback or (preferably?) in my action, to push the relevant settings to the URL when they change - so far so good. But I will also need to change how this state gets propagated to my components - I have to change my chart container's mapStateToProps to use props instead of Redux state, and I also have to thread react-router's location prop down to it, since it's not a top level Route in this case. And I have to do this for any other components which access this setting.
This seems like a code smell to me - fundamentally, the settings are all still the same kind of app state, and it feels strange to have to handle them differently based on which ones are "saved" in the URL. I think I would be mostly happy if react-router-redux could provide me with a way to know when it was safe to use the state stored in state.routing.location (ie. when the component tree matched state) - maybe something like a boolean state.routing.transitioning that, when true [edit: oops, meant false], guaranteed they were in sync.
But to go a bit further - the above solution would still require moving the Single Source of Truth about some of the settings out of state.chart.settings and into state.routing.location.query - it would be even better if I could just leave them where they were! Again, "URL-savedness" shouldn't dictate where the setting state is stored, IMO. I think in my perfect world, I would be able to define two reducer-esque functions somewhere that looked something like:
const querySettingKeys = ['filters', 'range'];
const paramSettingKeys = ['id'];

export function mapLocationToState(location, state) {
  switch(location.pathname) {
    case "/chart":
      const settings = Object.assign({}, state.chart.settings,
        _.pick(location.query, querySettingKeys),
        _.pick(location.params, paramSettingKeys)
      );

      return _.merge({}, state, {chart: {settings}});

    default:
      return state;
  }
}

export function mapStateToLocation(state, location) {
  const query = _.pick(state.chart.settings, querySettingKeys);
  const params = _.pick(state.chart.settings, paramSettingKeys);

  return _.merge({}, location, {query, params});
}

...and then wire them up to react-router-redux to keep them in sync. Something along these lines seems to me like it would a good functional approach to passing state between location and store - and it would be easyish to unit test by ensuring that mapStateToLocation(mapLocationToState(someLocation)) === someLocation. It would be great to at least get some feedback to know if this falls into the category of A) hmm, interesting... B) trivially possible already somehow, or C) crazy ramblings of a naive Redux dev who has not yet learned the Way. :)
Thanks very much for your time!

:+1:

I realize that react-router-redux doesn't and has never done this, but I'm similarly wondering if it's possible.
When I think about my ideal redux + react-router integration library, all I really want is something that syncs the current route with some part of the Redux store. As @dandelany said, this would make it easy to move "page settings" in and out of the URL, depending on my serialization needs. Conceptually, this seems like "not a big change", but in the current model, it requires a lot of code reorganization.
In my mind, a huge advantage of using redux to manage state is that react-redux allows you to circumvent the awkward choice of passing props far down the tree or reaching into context. It seems unfortunate that I need to make this tradeoff if I want to use URL state in my selectors.

I would like something like this as well. Ideally, the store would contain the location as well as the route params, but maybe that is too much to ask :smile:
Our particular scenario is that we have a search/filter page that uses the query string to store state, similar to @dandelany's expressed concern. We maintain that query string through all navigation through the site so that you can always go back to your original search, even through a refresh.
To facilitate this, we have action creators like:
export const changeQuery = (searchParams) => (dispatch, getState) => {
  const pathname = getState().routing.location.pathname
  const queryParams = serializeSearchParams(searchParams)
  return dispatch(replace(pathname + queryParams))
}

export const changePath = (path, searchParams, forcePush) => (dispatch, getState) => {
  const state = getState()
  const currentPathname = state.routing.location.pathname
  const pathname = path ? getPathname(path) : currentPathname
  if (pathname === currentPathname && searchParams && !forcePush) {
    return dispatch(changeQuery(searchParams))
  }
  const queryParams = searchParams ?
    serializeSearchParams(searchParams) : getCurrentQueryString(getState())
  return dispatch(push(pathname + queryParams))
}

The first is for changing the query string w/o changing the current path, the second is for changing the path while keeping the query string the same (or changing it).
Now, it is probably safe for us to use locationBeforeTransitions instead of location in these cases because we only use the action creators as a result of user interaction. But, it is recommended against using locationBeforeTransitions. The alternative for us would be to pass location all the way down, or use a component to throw it in context (we use react-router) and pass location into the action creator. It's a lot of handing stuff around that really feels like it should be easier.
Am I missing something fundamental here?

Sorry for the hold up. I've got a Wall of Text™ to read through here and I do want to give a meaningful response. I haven't had time to do that yet, but I'll be sure to do so in the next couple days.

@dandelany I may be tuning this response a bit too much to your particular example, so I apologize if this isn't generally applicable:
It seems to me like this can be easily handled with some React lifecycle method usage. I don't know why, but they seem to have fallen out of favor lately and people forget they exist or think they're bad or something. Use them!
You should be keeping your chart component's state in your store. The URL is a reflection of that state, but it is not a source of truth. Instead, it can be used at key times: When the component is loaded and when the state changes? And there are two matching lifecycle methods just for this: componentWillMount and componentWillReceiveProps. Here's some pseudocode to do that:
componentWillMount() {
  if (this.props.chart_settings === null)
    this.props.restoreChartSettings(this.props.location);
}

componentWillReceiveProps(nextProps) {
  if (this.props.chart_settings !== nextProps.chart_settings)
    this.context.router.replace(serializeChartSettings(nextProps.chart_settings))
    // You should probably replace here so that they don't undo their changes if they go back
}

You don't need to inject URL serialization into your actions, just let them pick up on lifecycle events and build the behavior declaratively. React has a great lifecycle system that makes this stuff easy to implement without having to tack on yet another library and increase your "JS fatigue".
I'm also seeing a lot of folks trying to turn their store into some sort of event bus. This is not the function of the store. You should be using it simply as a state container and think about state changes more reactively, rather than as imperative event handlers.
@billyjanitsch The biggest problem with trying to force the router state into Redux is that it's not serializable. It's also relative to where you are in the route tree, so it's not absolute. this.props.route will be different for your root route than it is for a leaf node. So, even if we wanted to head in that direction, storage just isn't possible without reimplementing a lot of React Router code ourselves.
@aaronjensen I would make a similar recommendation for you to what I made above: use React lifecycle methods. You have a component that manages the search UI and triggers those changes to state. It can connect to that state and serialize the URL as it changes (your changeQuery action inside of cWRP).
I believe that answers most of the questions here. I'll close this since I don't think there's anything actionable here, but feel free to keep replying and I promise I'll keep up the conversation. And if anything comes up, we can open up a specific issue with specific actionable things to implement.

Thanks for the detailed response @timdorr. Certainly not averse to using lifecycle methods, just wasn't sure of the intended usage here. I guess the key point here is that I have been thinking of routing/syncing location with state as mostly an app-level concern which should be handled outside of components, whereas you are saying the components should be in charge of firing actions which update the store from location when they mount. I don't know yet if I agree 100%, but your pseudocode makes sense and is cleaner than my current approach, so I'll try it this way.

The biggest problem with trying to force the router state into Redux is that it's not serializable.

But surely location is, right? I think the main idea here is just to have a way to automatically map the router location descriptor to a certain part of Redux state so the components don't have to do so when they mount.

@timdorr

You should be keeping your chart component's state in your store. The URL is a reflection of that state, but it is not a source of truth.

This actually surprised me quite a bit, I've been recently writing apps with much more URL linked behavior (filters, deep links, etc) and have come across the very challenges described in this issue. When I work with redux, one of my primary goals is to avoid duplicate state, and it seems like the URL is the single source of truth for this data. My approach to this problem has been to use reselect selectors which take ownProps and grab the data from the url bar. Updates to the url are done via action creators push and replace. This way my connected-component doesn't really have any idea the state comes from the URL or from the redux-store.
I don't love how splitting the url state into being in the store but also updated via the url bar would force logic for keeping this in sync to be included in every component. Maybe there's a way to write a HOC wrapper which could perform this synchronization? react-router-redux-param or something?
I'd imagine an interface like:
// React-Router Param Id Synching
const todoParamSelector = state => state.todo.selectedTodo
class TodoDetails extends Component {
   ...
}

RouterReduxParam(todoParamSelector)(TodoDetails);

// React-Router Query Param Synching
const todoFilterSelector = state => state.todo.todoFilter

RouterReduxQueryParam(todoFilterSelector)(TodoDetails);

@dandelany

I guess the key point here is that I have been thinking of routing/syncing location with state as mostly an app-level concern which should be handled outside of components, whereas you are saying the components should be in charge of firing actions which update the store from location when they mount.

You can certainly just listen to your history instance, but it becomes harder to isolate that listening to just when you have your chart component available. Instead, if you use the lifecycle methods of the component, you can instead tie that behavior to when it is in use.

I think the main idea here is just to have a way to automatically map the router location descriptor to a certain part of Redux state so the components don't have to do so when they mount.

Yes, and it is under state.routing. However, this is the location before the router has had a chance to read it and render the appropriate routes. If you have async routes, then there may be a significant time between the location changing and the router actually updating. That's why we don't recommend reading the location from that source. Instead, you should get it from the route component params, as that will always be after the router has fully resolved all async behaviors. Plus, you don't have to map in any props manually; they are already provided.
@mjrussell
This is somewhat anecdotal, but the 4.0.0 version of this library maintains that the store is the source of truth for the location. We enhance the history instance to first put the location in the store and second notify listeners based on that updated state.
I would find it more troublesome to maintain two sources of truth. It changes the predictability of your state container's behavior. Also, you actually do care where the state came from, as mutating it via an action creator wouldn't work as expected. In fact, if you have parts you don't store in the URL, then you both have to do a replace/push and dispatch an action. That seems pretty hard to reason about and might trip up others working on the same app. If you make it more declarative, then no one has to concern themselves with storage at all.
You can certainly do a HoC method to mix in the location storage, but I don't think it's really needed. You only need two small lifecycle methods and you've got syncing implemented.

@timdorr

We enhance the history instance to first put the location in the store and second notify listeners based on that updated state.

Wow I missed that in the PRs, thats actually pretty nifty.

I would find it more troublesome to maintain two sources of truth. It changes the predictability of your state container's behavior.

Hmm we may be talking past each other here. I thought your proposed solution was to "sync" the router param/query with the url bidirectionally via lifecycle methods. This doesn't seem like a "single source of truth" to me because Im not sure which to believe when they differ.

Also, you actually do care where the state came from, as mutating it via an action creator wouldn't work as expected.

Thats fair, the action creator would know where the data lives (url vs state) but the component would just dispatch an action without that knowledge.
Thanks for the reply, will have me thinking about how I want to the url and store to work together going forward.

I agree with @mjrussell, I'm still having a hard time resolving the "source of truth" question here. In your example, when the component mounts, it calls the restoreChartSettings action creator to update the store based on the router's location. In other words, the URL state drives the store state in this case, it's not just a reflection of state. So I don't think it's always true that "the store is the source of truth" - nor should it be, necessarily. On the other hand, in your componentWillReceiveProps the store state does determine the state of the URL (via router.replace). So it seems to me that there is already a "two sources of truth" problem.
After trying it, it seems like there are a few practical problems with doing it this way. The first is that, contrary to the comment in your example, I do want to use router.push to save state history in the browser history, so users can undo by clicking "Back". This doesn't work because, although history navigation (popstate) gives us a new location prop from the router, the store is driving the location state during componentWillReceiveProps, not vice versa. The other problem is: if I set some settings, then navigate to another "page" route which doesn't sync the URL (ie. click a <Link>), then come back to my chart page, my settings will be cleared. Even though they were saved in the store state, the (now empty) URL state overwrites the store state, because URL drives store state during componentDidMount. (even if it merged instead of overwriting, they'd get out of sync)
So to summarize, here is how I understand the state flow in your example. In the left column are events during which URL state determines store state (ie. URL is source of truth), vice versa on right.

URL -> Store
Store -> URL

componentDidMount
componentWillReceiveProps

history navigation (fwd/back)

action creator modifies state

Despite my initial gut feeling, I have come to accept that the answer to the question "who controls state, URL or store?" must necessarily be "a little of both" - because we obviously want to respond to history navigation, but we also don't want to have to use router.push/replace as a primary means of state mutation (plus time travel!). But I think the ideal state flow is something more like:

URL -> Store
Store -> URL

Initial app load
componentDidMount

history navigation (fwd/back)
componentWillReceiveProps

action creator modifies state

I'm not sure there is a good solution that lives entirely in component lifecycle methods as you propose, and is also capable of distinguishing between the initial app load and componentDidMount, which is leading me back to considering an app-level solution.
I realize that all of this may be well out of scope for what you want to do with react-router-redux but your advice is nonetheless very helpful if I end up implementing a different solution.

Sorry for the double post, I wanted to address this as a separate but related issue @timdorr :

Yes, and it is under state.routing

By "certain part of Redux state," I mean a part that I specify, so that I do not have to move my source of truth to accommodate saving it in the URL.

However, this is the location before the router has had a chance to read it and render the appropriate routes. If you have async routes, then there may be a significant time between the location changing and the router actually updating. That's why we don't recommend reading the location from that source. Instead, you should get it from the route component params, as that will always be after the router has fully resolved all async behaviors.

I am starting to wonder if we are talking about two separate use cases with two different solutions. What you are saying makes total sense to me for "location-y" things (scientific term) like rendering navigation - I wouldn't want the nav to update before the next route transitions in. And it also makes sense to use props.location for this kind of thing.
But I'm talking about using URL to represent pieces of restorable core app state; data that is largely independent of the routes/components that are rendered. I think that in my use case above, if I were to use state.routing, not only is it OK that the value is updated before the router is done, it's desired. This is state that directly controls the <input>s which allow the settings to be changed, so if it does not update immediately, there will be a lag between changing the input and seeing the result.
This is a common pattern for me, and it would be great to have a way to add this "URL-saveability" superpower to any given part of state in the store, with minimal configuration and without changing how state is structured.
Thanks again for your time and advice! :pray:
PS: Since this is an active discussion that seems to resonate with at least a few other members of the community, what do you think about re-opening this ticket for visibility and maybe giving it a discussion tag? Conversations in closed tickets are really hard to people to find.

Interesting discussion. I agree with what is being said about URLs : they are not another source of truth of a redux / react app. They are like the DOM: a state change might update the DOM as a side-effect, and events can arise from DOM interactions to demand state changes.
Replacing with URL: a state change might update the URL as a side-effect, and events can arise from URL interactions (manual change, back & forward buttons) to demand state changes.

@dandelany @erosenberg @aaronjensen @troch @billyjanitsch @rpechayr @cimi
I've been playing with react-router for the first time, and your post really hit home. I wanted to implement the same split source of truth depending on the event (user navigation or state change), and I after a lot of going in circle I also tried to implement mapStateToQuery and mapQueryToState.
I spent a couple days on this to try to find a way, and I think I'm finally onto something. I haven't tested it extensively, but with my few pages it works perfectly under all circumstances. It is not idiomatic at all, but fairly straight forward and painless.
To avoid having to match location.pathname to route-specific logic manually, I created a small wrapper around react-router match(). This way I can put my utility functions directly on the routes. match() looks async, but as long as you don't use async routes [1] it returns within the same frame.
[1] https://github.com/ReactTraining/react-router/blob/master/docs/guides/DynamicRouting.md
Here's the wrapper to get a route based on a path string
getRouteFromPath(routes, path) {
    let route;
    let beacon;

    function extractRoute(_error, redirectLocation, props) {
        // recursively call extractRoute in case we get redirected
        if (redirectLocation) {
            match({ routes, location: redirectLocation }, extractRoute);
            return;
        }

        beacon = true;
        route = props.routes[props.routes.length - 1];
    }

    match({ routes, location: { pathname: path } }, extractRoute);

    // if beacon isn't set to true, extractRoute hasn't been run synchronously
    // and we're in trouble
    if (!beacon) {
        throw new Error('Router.match() is running async for some reason :/');
    }

    return route;
}

The routes and their mapping methods
const routes = {
    path: '/',
    component: App,
    indexRoute: { onEnter: (nextState, replace) => replace('/search') },
    childRoutes: [{
        path: '/search',
        component: Search,
        mapStateToQuery(state) {
            return Search.getParams(state).toJS();
        },
        mapQueryToState(dispatch, query) {
            return dispatch(Actions.search.setParams(
                _.pick(query, ['type', 'date'])
            ));
        },
    }, {
        path: '/pick',
        component: Pick,
        mapStateToQuery(state) {
            return Search.getParams(state).toJS();
        },
        mapQueryToState(dispatch, query) {
            return dispatch(Actions.search.setParams(
                _.pick(query, ['type', 'date'])
            ));
        },
        validatePropsOrRedirect(state) {
            if (
                Search.getParams(state).get('type') &&
                Search.getParams(state).get('date')
            ) {
                return null;
            }
            return '/search';
        },
    }],
};

In the main app file, I listen to history changes and "monkey-patch" the location. This is slightly savage, especially with the whole app built with FP in mind, but heh it works. Maybe a future version of react-router could implement a way to send a new location in the onBeforeChange listener.
The main app
const store = StoreFactory();

// filter empty parameters from the query to avoid ugly ?param=&param2=
const filterEmpty = map => _.pickBy(map, value => (
    value !== '' && value !== undefined && value !== null
));

function onBeforeHistoryChange(location) {
    // abusing the fact that we can mutate location in here to manipulate the history
    // for POP events, we try to update the state using the query
    // for other events, we use the current state to complete the query, so we don't
    // have to explicitly specify parameters everytime we navigate

    // ignore REPLACE events from the store middleware
    if (
        location.action === 'REPLACE' &&
        location.state && location.state.generated_by_store
    ) {
        return;
    }

    // get the actual route based on location.pathname, as state/query manipulation
    // function are defined directly on the route. Will break for async routes, god
    // forbid we need them at some point
    const route = RouterUtils.getRouteFromPath(routes, location.pathname);
    if (!route) return;

    if (location.action === 'POP') {
        // mapQueryToState dispatches regular actions
        if (route.mapQueryToState) {
            route.mapQueryToState(store.dispatch, location.query);
        }
    } else {
        if (route.validatePropsOrRedirect) {
            const redirectTo = route.validatePropsOrRedirect(store.getState());
            if (redirectTo) {
                location.pathname = redirectTo;
                return;
            }
        }

        // set the route query based on the current state
        if (route.mapStateToQuery) {
            const query = filterEmpty(route.mapStateToQuery(store.getState()));
            const newLocation = browserHistory.createLocation(
                _.extend({}, location, { query })
            );
            location.query = newLocation.query;
            location.search = newLocation.search;
        }
    }
}

// on the first page load, update the state based on the query
const route = RouterUtils.getRouteFromPath(routes, location.pathname);
if (route && route.mapQueryToState) {
    route.mapQueryToState(store.dispatch, browserHistory.getCurrentLocation().query);
}

browserHistory.listenBefore(onBeforeHistoryChange);

In the store, this middleware keeps the query in sync with the state
const setHistoryQueryMiddleware = store => next => action => {
    const result = next(action);

    const location = browserHistory.getCurrentLocation();
    const route = RouterUtils.getRouteFromPath(routes, location.pathname);
    if (!route) return result;

    if (route.mapStateToQuery) {
        const query = filterEmpty(route.mapStateToQuery(store.getState()));
        // history.replace needs to run AFTER the store is updated, otherwise
        // our onBeforeUpdate listener is going to use the previous version of
        // the store to set the route params
        window.setTimeout(() => {
            // generated_by_store allows onBeforeChange to ignore those changes
            // as they do not need further processing, and can cause loops
            browserHistory.replace(
                _.extend({}, location, { query, state: { generated_by_store: true } })
            );
        });
    }

    return result;
};

If you have async routes, ...
I suppose many of us choose to avoid async routes at all, it would be nice to have a solution for us, even if it were behind a config flag.

@troch @timdorr URLs are not simply a reflection of state, "like the DOM". the entire point of a URL, by definition, is to hydrate some facet of your app state. at least on page load.
@timdorr your suggestion using life cycle methods almost works- but as @dandelany suggests it breaks when the user navigates using "back" or "forward". in your example, componentWillReceiveProps is called when the user hits "back"- but will never try to reconcile those URL changes with the state.
anyone trying to serialize a reasonably complex state in their URL is going to hit this roadblock right away. so i am surprised to see no one's made any real progress solving this. am i missing something?

URLs are not simply a reflection of state, "like the DOM". the entire point of a URL, by definition, is to hydrate some facet of your app state. at least on page load

@kn0ll I didn't say that URLs where simply a state reflection. But you are right, and a URL, like pre-rendered HTML is a starting state.

@troch but you'd said URLs are "not another source of truth of a redux / react app". which in my mind contradicts "a URL [...] is a starting state". think i just misunderstood the semantics- i think we are saying the same thing. :)

@kn0ll oh I see it's a bit clumsy, I meant more that your React components have only one source of truth in a React / redux app, which is the redux store. So the URL is not a source of truth, it is a starting point. Then the history can emit events, which eventually will be transformed into an action ending up in your store. I think the following reflects more what I said:

a state change might update the URL as a side-effect, and events can arise from URL interactions (manual change, back & forward buttons) to demand state changes.

Just to add to the conversation, the solution proposed by Dan Abramov to exactly the same problem was to treat the url as the single source of truth and not to duplicate the state with Redux.
https://stackoverflow.com/questions/36596996/how-to-sync-redux-state-and-url-query-params

I'm glad i'm not not the only one having this issue.
I think I'll just remove react-router-redux in this case because the declarative nature of the URL mapping which is closely tied to the component tree makes this problem very hard.
I'm currently leaning towards a mechanism that uses actions to trigger store+location updates and a part outside of the component tree to listen on history changes and syncs the relevant parts to the store.
I think what we are seeing here might be a basic incompatibility between the embedded routing within components and state changes that occur from outside the component tree (URL changes).
This might be something that react-router-redux cannot resolve with the current architecture.

I recommend looking at redux-little-router and reading this article series.
I've replaced react-router with redux-little-router in a web application centered around data visualisation. Using it together with redux-saga, I've added deep linking and browser back/forward navigation support; the visualisation which triggers updates to the page location on user interactions.


Redirect to Not Found page instead of main dashboard for unmatched paths in UI

Description
Follow up action to discussion thread starting with https://github.com/stackrox/stackrox/pull/1171#pullrequestreview-932011200
Take another step toward the goal of consistent feedback for the following:

Path does not match any pattern
Path does match a pattern, but feature flag is not enabled
Path does match a pattern, but user role does not have access
Path does match a pattern, but resource type does not exist (see Residue)
Path does match a pattern, but resource id does not exist (see Residue)

Previous inconsistent behavior before #1171

Redirect to main dashboard if path does not match any pattern
Redirect to main dashboard if path does match a specific pattern, but feature flag turned off or user role does not have access
Render PageNotFound if path does match a generic pattern, but second-level resource does not exist (for example, /main/vulnerability-management/unknown)
Render PageNotFound if path does match generic pattern, but second-level id does not exist (for example, /main/vulnerability-management/policies?…)

Somewhat more inconsistent behavior after #1171

Redirect to main dashboard if path does not match any pattern
Redirect to main dashboard if path does match a specific pattern, but feature flag turned off or user role does not have access
Render PageNotFound if path does match specific pattern, but feature flag turned off or user role does not have access, and path does match a generic pattern, but second-level resource does not exist (for example, /main/vulnerability-management/reports)
Render PageNotFound if path does match generic pattern, but second-level resource does not exist (for example, /main/vulnerability-management/unknown)
Render PageNotFound if path does match generic pattern, but second-level id does not exist (for example, /main/vulnerability-management/policies?…)

Incrementally improved behavior

Body redirects to 404 which renders NotFoundPage for 1
Body redirects to 404 which renders NotFoundPage for 2 or 3, except if path matches a generic pattern, therefore does not (yet) redirect, see next item
Some containers render PageNotFound at the original path for 4 (see Residue)
Some containers render PageNotFound at the original path for 5 (see Residue)

Residue
Proposal for discussion:

Continue to display Not Found if resource type or resource id does not match.
Redirect to 404 at deepest depth 0, 1, 2 that does match, for example:

/main/404 for /main/unknown (this pull request) with link to Dashboard
/main/vulnerability-management/404 for /main/vulnerability-management/reports if feature flag is not enabled or if no role access, with link to Vulnerability Management Dashboard
/main/vulneratility-management/cves/404 for /main/vulnerability-management/cves?…unknownId with link to Vulnerability Management CVEs

Here is an observation and a brainstorm about workflow page addresses, related to 404 at deepest depth:
Classic workflow with side panel
Current resource type or id is at end of query string:

/main/vulnerability-management/cves
/main/vulnerability-management/cves?workflowState[0][t]=CVE&workflowState[0][i]=CVE-2021-20231
/main/vulnerability-management/cves?workflowState[0][t]=CVE&workflowState[0][i]=CVE-2021-20231&workflowState[1][t]=IMAGE
/main/vulnerability-management/cves?workflowState[0][t]=CVE&workflowState[0][i]=CVE-2021-20231&workflowState[1][t]=IMAGE&workflowState[2][t]=IMAGE&workflowState[2][i]=sha256%3Ad1217333dd1f1c76da0a9dbe85aef481c0fde0643a900c3f7113caf3fe4db1d7
/main/vulnerability-management/image/sha256:d1217333dd1f1c76da0a9dbe85aef481c0fde0643a900c3f7113caf3fe4db1d7/deployments
/main/vulnerability-management/image/sha256:d1217333dd1f1c76da0a9dbe85aef481c0fde0643a900c3f7113caf3fe4db1d7/deployments?workflowState[0][t]=DEPLOYMENT&workflowState[0][i]=65b80760-848e-4a6f-9d25-7599ca40f258

Steps 3 and 4 display Images and Image but cves is resource type at depth 1
Steps 5 and 6 display Deployments and Deployment but image is resource type at depth 1
Future workflow without side panel
Current resource type and id might be at beginning of address and breadcrumb stack might be in query string?

/main/vulnerability-management/cves
/main/vulnerability-management/cves/CVE-2021-20231
/main/vulnerability-management/images?workflowState[0][t]=CVE&workflowState[0][i]=CVE-2021-20231
/main/vulnerability-management/images/sha256%3Ad1217333dd1f1c76da0a9dbe85aef481c0fde0643a900c3f7113caf3fe4db1d7?workflowState[0][t]=CVE&workflowState[0][i]=CVE-2021-20231
/main/vulnerability-management/deployments?workflowState[0][t]=IMAGE&workflowState[0][i]=sha256:d1217333dd1f1c76da0a9dbe85aef481c0fde0643a900c3f7113caf3fe4db1d7
/main/vulnerability-management/deployments/65b80760-848e-4a6f-9d25-7599ca40f258?workflowState[0][t]=IMAGE&workflowState[0][i]=sha256:d1217333dd1f1c76da0a9dbe85aef481c0fde0643a900c3f7113caf3fe4db1d7

React Router
https://reactrouter.com/docs/en/v6/upgrading/v5#remove-redirects-inside-switch

Remove any <Redirect> elements that are directly inside a <Switch>.

If you want to redirect client-side, move your <Redirect> into a <Route render> prop.
Normal <Redirect> elements that are not inside a <Switch> are ok to remain. They will become <Navigate> elements in v6. [We can evaluate this option when the time comes.]

PatternFly
https://www.patternfly.org/v4/ux-writing/http-404-pages/
For an example of path, patternfly.org/v4/unknown redirects to patternfly.org/v4/404/
Changes

Edit src/Components/PageNotFound.tsx

Declare resourceType and useCase props as optional.

Edit src/Containers/AppPage.tsx

Move Redirect element into render prop of Route element.

Edit src/Containers/MainPage/Body.tsx

Define NotFoundPage which returns PageTitle and PageNotFound elements
Add <Route path={notFoundPath} component={NotFoundPage} />
Move Redirect element into render prop of Route element, which does have exact prop.
Add Redirect element in render prop of Route element, which does not have exact prop.

Edit src/routePaths.js

Export notFoundPath for /main/404

Checklist

[x] Investigated and inspected CI test results
[x] Unit test and regression tests added

Testing Performed

https://localhost:3000 redirects to /main/dashboard
https://localhost:3000/unknown renders black screen
https://localhost:3000/main redirects to /main/dashboard
https://localhost:3000/main/dashboard renders Dashboard
https://localhost:3000/main/unknown redirects to /main/404 and renders NotFoundPage
https://localhost:3000/main/vulnerability-management renders Vulnerability Management Dashboard
https://localhost:3000/main/vulnerability-management/reports with access renders Vulnerability Management Reporting
https://localhost:3000/main/vulnerability-management/reports without access renders PageNotFound
https://localhost:3000/main/vulnerability-management/unknown renders PageNotFound
https://localhost:3000/main/system-health-pf with feature flag renders System Health
https://localhost:3000/main/system-health-pf without feature flag redirects to /main/404 and renders NotFoundPage

Picture of first draft /main/404 without PageSection element has mixed PatternFly and classic style

Picture of second draft /main/404 with PageSection element has PatternFly style

As a side note, is upgrading to React-Router v6 something on the near-term road map? I was looking through their docs and they have a useSearchParams() hook that is very similar in API to the one we are introducing. When we upgrade it should be an easy migration to switch over to that version, if we want to.

@dvail Good question about React-Router v6. Let's plan for incremental updates after the package is released:
https://reactrouter.com/docs/en/v6/upgrading/v5#backwards-compatibility-package

We are actively working on a backwards compatibility layer that implements the v5 API on top of the v6 implementation. This will make upgrading as smooth as possible. You'll be able to upgrade to v6 with minimal changes to your application code. Then, you can incrementally update your code to the v6 API.

We recommend waiting for the backwards compatibility package to be released before upgrading apps that have more than a few routes.


[ENH] Added MSTL to STLForecaster

closes #240

thx for review, can you pls have another look. I added now a ColumnsEnsembleForecaster for default season forecast and an EnsembleForecaster for default resid forecast.

On another note, when using STL people usually forecast the signal that's trend+residuals with one model e.g. ETS(AAN) or a non-seasonal ARIMA and then add the seasonal stuff on top. I think we should make that option feasible here too, but that's another PR for another day. What do you think?

Yes that would probably best be a separate forecaster?

Happy to have a closer look once the tests are passing.

Worth remembering that tests only happen on certain OS/Py Version currently. Its possible the failing tests arent being run on the passing actions.

oh why is that?

Part of the "matrix testing" implemented in sktime ages ago im pretty sure

I assume it was because a full test will take too long, but I wasnt involved at that time (https://github.com/aeon-toolkit/aeon/issues/154)


Validation fails to detect invalid SetNull referential action referencing non-optional fields

This missed validation triggers a migration error when using MySQL, SQL Server, SQLite, and CockroachDB, but not on Postgres.
Example with MySQL:
// schema.prisma

generator client {
  provider = "prisma-client-js"
  previewFeatures = ["referentialIntegrity"]
}

datasource db {
  provider = "mysql"
  url = env("DATABASE_URI_MYSQL")
}

model User {
  id      String @id
  profile Profile?
  enabled Boolean?
}

model Profile {
  id       String @id
  user     User @relation(fields: [userId], references: [id], onUpdate: SetNull, onDelete: SetNull)

  // notice that this field should become optional in order to support `SetNull`
  userId   String @unique

  enabled Boolean?
}

We can see that the schema is wrongfully considered valid:
❯  prisma validate
Prisma schema loaded from prisma/schema.prisma
The schema at /.../reprod/prisma/schema.prisma is valid 🚀

If we attempt a push, we get the following error:
❯ prisma db push --skip-generate
Prisma schema loaded from prisma/schema.prisma
Datasource "db": MySQL database "PRISMA_DB_NAME" at "localhost:3306"

MySQL database PRISMA_DB_NAME created at localhost:3306
Error: Column 'userId' cannot be NOT NULL: needed in a foreign key constraint 'Profile_userId_fkey' SET NULL
   0: sql_migration_connector::apply_migration::migration_step
           with step=AddForeignKey { foreign_key_id: ForeignKeyId(0) }
             at migration-engine/connectors/sql-migration-connector/src/apply_migration.rs:21
   1: sql_migration_connector::apply_migration::apply_migration
             at migration-engine/connectors/sql-migration-connector/src/apply_migration.rs:10
   2: migration_core::state::SchemaPush
             at migration-engine/core/src/state.rs:349

If we try to create/update the Profile model via the Prisma client, we get the following migration error:
await prisma.$transaction([
  prisma.user.create({
    data: {
      id: '1'.
      profile: {
        create: { id }
      }
    }
  })
])

    Column 'userId' cannot be NOT NULL: needed in a foreign key constraint 'Profile_userId_fkey' SET NULL
       0: sql_migration_connector::apply_migration::apply_migration
                 at migration-engine/connectors/sql-migration-connector/src/apply_migration.rs:9
       1: migration_core::state::SchemaPush
                 at migration-engine/core/src/state.rs:349

On Postgres, oddly, prisma db push it doesn't fail, so migration error is thrown:
❯ prisma db push --skip-generate
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "PRISMA_DB_NAME", schema "public" at "localhost:5432"

PostgreSQL database PRISMA_DB_NAME created at localhost:5432

🚀  Your database is now in sync with your Prisma schema. Done in 64ms

Is this actually not valid at the database level? We should test first that a CREATE TABLE exhibiting that pattern is rejected by the databases we support before writing a PSL validation.

MySQL
Test SQL Statement:
CREATE TABLE categories(
  categoryId INT AUTO_INCREMENT PRIMARY KEY,
  categoryName VARCHAR(100) NOT NULL
) ENGINE=INNODB;

CREATE TABLE products(
  productId INT AUTO_INCREMENT PRIMARY KEY,
  productName varchar(100) not null,
  categoryId INT,
  CONSTRAINT fk_category
  FOREIGN KEY (categoryId)
      REFERENCES categories(categoryId)
      ON DELETE ${action}
      ON UPDATE ${action}
) ENGINE=INNODB;

with
type Action
  = 'RESTRICT'
  | 'CASCADE'
  | 'SET NULL'
  | 'NO ACTION'
  | 'SET DEFAULT'

let action: Action

The following SQL referential actions work for both ON UPDATE and ON DELETE on mysql:5.7 and mysql:8:

RESTRICT
CASCADE
SET NULL
NO ACTION

The following only works on mysql:8:

SET DEFAULT

On mysql:5.7, it fails with:
SqlError: (conn=22, no: 1215, SQLState: HY000) Cannot add foreign key constraint

SQL Reproduction with one-to-one optional relations
MySQL

Foreign key docs

Test SQL Statement:
CREATE TABLE User (
    id INTEGER PRIMARY KEY
) ENGINE=InnoDB;

CREATE TABLE Profile (
    id INTEGER PRIMARY KEY,
    userId INTEGER NOT NULL UNIQUE,
    FOREIGN KEY (userId) REFERENCES User(id)
      ON DELETE ${action}
      ON UPDATE ${action}
) ENGINE=InnoDB;

with
type Action
  = 'RESTRICT'
  | 'CASCADE'
  | 'SET NULL'
  | 'NO ACTION'
  | 'SET DEFAULT'

let action: Action

The following SQL referential actions work for both ON UPDATE and ON DELETE on mysql:8:

RESTRICT
CASCADE
SET NULL
NO ACTION
SET DEFAULT

The following does not work on mysql:8:

SET NULL

On mysql:8, it fails with:
SqlError: (conn=60, no: 1830, SQLState: HY000) Column 'userId' cannot be NOT NULL: needed in a foreign key constraint 'profile_ibfk_1' SET NULL

To recap, @tomhoule, the SQL database don't validate the CREATE TABLE statements when defining SET NULL referential actions, but I think Prisma should, in order to avoid panics at runtimes.

but I think Prisma should, in order to avoid panics at runtimes.

Makes sense. One thing to keep in mind that could prevent us from going into that direction is the principle that we should be able to introspect a valid database schema to a valid prisma schema in as many cases as possible, so if it's valid at the database level, we may want to accept it. Maybe warn.

What we want to do (from Notion)
Make schema with non-optional 1:1 relation and SetNull referential actions invalid.
Optional but nice DX: Add special error message for PostgreSQL that links to a documentation page that explains why some valid SQL for PostgreSQL can lead to an invalid Prisma schema via Introspection: While the CREATE TABLE works, the INSERT/UPDATE/DELETE on that table will all fail.

To summarise the output of the tests done in https://github.com/prisma/prisma/pull/15728 in relevant to this issue:

For both 1:1 and 1:n relations:

postgres doesn't validate DDL statements that set a SET NULL referential action on a foreign key constraint whose referenced column (or one of the referenced columns) is NOT NULL, all other database throw a validation error in this case.
postgres fails at runtime with a not-null constraint violation error when UPDATE /  DELETE statements trigger the SET NULL referential action on a column defined as NOT NULL

Optional but nice DX: There's also an odd behavior that may be useful to document and/or validate against:

sqlserver fails at runtime on 1:1 NULL relations because NULL conflicts with UNIQUE indexes in that particular database


Port changes of [#15699] to branch-2.8

What changes are proposed in this pull request?
The UfsJournalCheckpointThread calls System.exit(-1) when encountering journal corruption. This causes a deadlock between the UfsJournalCheckpointThread and the shutdown hook calling AlluxioMasterProcess.stop().
This PR removes the System.exit() calls in favor of propagating exceptions when the thread completes.
The net effect is that the master process completely releases its resources when shutting down and terminates without having to be issued kill -9.
Why are the changes needed?
For clean master process termination on errors.
Does this PR introduce any user facing changes?
No.
[This is an manually generated PR to cherry-pick committed PR Alluxio/alluxio#15699 into target branch branch-2.6]

alluxio-bot, merge this please


Fix MsLinger Getter to use new GetDouble

Fix MsLinger Getter to use new GetDouble.  It currently uses GetEnum which fails with ArgumentException when it tries to Enum.Parse a typeof(double)

It looks like @lorienpatt hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement here.
Once you've signed reply with [clabot:check] to prove it.
Appreciation of efforts,
clabot

@confluentinc It looks like @lorienpatt just signed our Contributor License Agreement. :+1:
Always at your service,
clabot


BUG - group field names don't exist

Are you a current Fivetran customer?
yes
Describe the bug
package doesn't run with latest pendo landing schema
Steps to reproduce
Run package on latest pendo schema
Expected behavior
works
Project variables configuration
dbt run --profiles-dir user/.dbt --profile sustain-nonprod-snowflake --var '{"pendo_database": "vault_db", "pendo_schema": "pendo", "group": "\"VAULT_DB\".\"PENDO\".\"GROUP\"", "pendo_database":"vault_db", "pendo_schema":"pendo"}'

Package Version
same as in master
Warehouse

[ ] BigQuery
[ ] Redshift
[ x] Snowflake
[ ] Postgres
[ ] Databricks
[ ] Other (provide details below)

Additional context
Screenshots
Please indicate the level of urgency
I have a fix which I'm happy to contribute
Are you interested in contributing to this package?

[x ] Yes, I can do this and open a PR for your review.
[ ] Possibly, but I'm not quite sure how to do this. I'd be happy to do a live coding session with someone to get this fixed.
[ ] No, I'd prefer if someone else fixed this.  I don't have the time and/or don't know what the root cause of the problem is.

I've created this PR in my fork.  It needs some more attention as DIV0 is likely not working for other warehouses?
https://github.com/leinemann/dbt_pendo/pull/1


Sign in logs adal

@danielwood95

@danielwood95 updated with some flavor text - do you think that makes sense or is there something else we should add?


Code style in matrix-two branch seems to be different than standard

The main thing I've noticed so far is it uses 2 spaces instead of 4 spaces.
Is there a plan to unify the style...?

please use 4 spaces 😭

Ah, my bad. Just my vim setup.

There is a plan to break out the eslint into a separate repo, might start on that today

Huh, well actually it's the eslint configured by creat-react-app. I think we'll need to eject

I think we'll need to eject

There does appear to be EXTEND_ESLINT advanced config env var that could be set, but if that's not enough, may want to eject.


Don't use the reserved host field anymore

In 6.4 versions Elasticsearch invented a reserved nested field host.
When Icingabeat connects directly to Elasticsearch it wants to write into the field host like it has done before. (And like almost any user does :-( ) But Elasticsearch will refuse to write the new data into an index.
Please change icingabeat so it won't write a "host" field anymore.
/ref/NC/558885

Here is the interesting part out of the logfile:
"reason":"failed to parse [host]","caused_by":{"type":"illegal_state_exception","reason":"Can't get text on a START_OBJECT at 1:49"}}

Can't paste all of the log because there's some company data in it.

I had this issue when downgrading to 6.1.1 as well (with Elastic 5.5), but this was due to the fact that there are two field definitions for "host" in the icingabeat template. I first changed only one instance and got this issue.

I moved all icinga related fields to an icinga group, this will solve the issue.


Profile manager mnemoincs validation

Description
All validation is working instantly after typing except for Couldn't find a user for the provided mnemonic on dev network error, you have to press connect button to check it.
Same case on playground is validated instantly after the typing is done.
Steps to reproduce

Type wrong mnemonics (for a twin not the same network).
Enter your password and confirm password.
press Connect button.

Logs/Alerts
Before pressing connect button, the mnemonics is valid.

After

please check (pr)[https://github.com/threefoldtech/tfgrid-sdk-ts/pull/936]
https://www.loom.com/share/e8404bebcc6a49a4ba92b559e5cd7a1a?sid=8ff53b52-f3f9-4960-b83b-164a07b30798

verified on devnet
connect button is disabled now unless you inserted the right mnemoincs for tthe right network


n0 dns server doesn't return relay records

records can be resolved with https://app.pkarr.org when pointing it to https://dns.iroh.link/pkarr. a bit surprising is that the relayer doesn't publish to the dht, so you can't resolve it with a different relayer. Seems like this is intended after discussing with @rklaehn . however the DnsResolver (the only one currently provided by default in iroh-net) fails to return any records. trying to query it manually seems to show that the problem is with the n0 dns server.
dig _iroh.7qy7is9kco9oygshi4ocmbw5ibogm4jme659bdgkrbthkwzxy5yy.dns.iroh.link. txt

; <<>> DiG 9.18.27 <<>> _iroh.7qy7is9kco9oygshi4ocmbw5ibogm4jme659bdgkrbthkwzxy5yy.dns.iroh.link. txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42232
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_iroh.7qy7is9kco9oygshi4ocmbw5ibogm4jme659bdgkrbthkwzxy5yy.dns.iroh.link. IN TXT

;; AUTHORITY SECTION:
dns.iroh.link.		7007	IN	SOA	testdns.iroh.link. hostmaster.iroh.link. 1 7200<PHONE_NUMBER> 86400

;; Query time: 3 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>) (UDP)
;; WHEN: Wed Jun 26 12:30:40 CEST 2024
;; MSG SIZE  rcvd: 156

@Frando ?

$ dig _iroh.7qy7is9kco9oygshi4ocmbw5ibogm4jme659bdgkrbthkwzxy5yy.dns.iroh.link. TXT

; <<>> DiG 9.18.24 <<>> _iroh.7qy7is9kco9oygshi4ocmbw5ibogm4jme659bdgkrbthkwzxy5yy.dns.iroh.link. TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52136
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_iroh.7qy7is9kco9oygshi4ocmbw5ibogm4jme659bdgkrbthkwzxy5yy.dns.iroh.link. IN TXT

;; ANSWER SECTION:
_iroh.7qy7is9kco9oygshi4ocmbw5ibogm4jme659bdgkrbthkwzxy5yy.dns.iroh.link. 18 IN TXT "relay=https://euw1-1.relay.iroh.network./"

;; Query time: 1870 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>) (UDP)
;; WHEN: Wed Jun 26 13:17:21 CEST 2024
;; MSG SIZE  rcvd: 155

?

mmh, how long does it take for the record to propagate? the pkarr relay interface returns the record immediately

seems to be some issue somewhere in the dns stack. checked my dns config and the system resolver starts resolving the record after a while, but somehow the node never manages to resolve itself. possibly a local issue, so fine if you want to close it. for now I'll work around it by implementing a resolver using the pkarr http interface.

> dig -t SOA dns.iroh.link

; <<>> DiG 9.19.25-185-g392e7199df2-1-Debian <<>> -t SOA dns.iroh.link
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28062
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dns.iroh.link.			IN	SOA

;; ANSWER SECTION:
dns.iroh.link.		86217	IN	SOA	testdns.iroh.link. hostmaster.iroh.link. 1 7200<PHONE_NUMBER> 86400

;; Query time: 4 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>) (UDP)
;; WHEN: Mon Jul 01 11:41:46 CEST 2024
;; MSG SIZE  rcvd: 97

IIUC this means the authoritative DNS server asks any clients (or recursive DNS servers) to remember the fact that a record was missing for 86400 seconds, or 24 hours.  That is way to long for how this service works.  So I think this is a misconfiguration of the DNS server probably.


AP bev for MV3D,VoxelNet and F-PointNet

how did you get the AP bev of three algorithms above?
it did not apply in their  paper

http://www.cvlibs.net/datasets/kitti/eval_object.php?obj_benchmark=bev


Add Swagger option for API documentation in Django projects

Add automatic RESTful api docs using https://drf-spectacular.readthedocs.io/en/latest/readme.html

[ ] Enable when DRF is installed

It looks a duplicate of https://github.com/sixfeetup/cookiecutter-sixiedjango/issues/25


Factor out waves module...

... Check Chris file too!

Probably not worth it. This module is mostly for teaching purposes and should be removed if no one is using it.


Show my support

On the home tab, i would like to have a "show my support" to:

post a tweet about OrgCheck in one click
post on Linkedin about OrgCheck
etc.

Maybe access to a survey?
Or a more clear "SUPPORT" section...

Link on LinkedIn is: https://www.linkedin.com/posts/vincentfinet_technicaldebt-activity-6776216981533200384-Zs2X
Link on Twitter is: https://twitter.com/VinceFINET/status/1370446145999212553


ValueError: path cannot be absolute

Hi,
I'm having trouble installing WorldEngine; the problem seems to be with PyPlatec, and since the project is maintained by these developers, I thought you might be able to help me.
The error I get is:
ValueError: path '/home/federico/repos/plate-tectonics/src/bounds.cpp' cannot be absolute
Can this be changed to relative?
I'm trying to install via PIP, but I've also tried to build from source, and I've run into similar issues. I'm on a Win10x64 machine; is that the problem?

Update: I got it working. I had to install Python 2.7 in order to get it to work. I normally run Python 3.
So I guess it's only an issue with Python 3. Now that I have it working, maybe I can help with a fix...

Sure, if you find problems on the Python3 side please help us fix it.
Python3 has been been a moving target lately. ;)


Pause on the Carousel dont work in Google Chrome

OS: Windows 10
Browser: Google Chrome Version 55.0.2883.87m
Problem: Pause on the Carousel dont work
The Chrome Browser on my Desktop don't stop the Slide when i hover the Mouse over the Carousel. The check of !('ontouchstart' in document.documentElement) evaluate to True  and the Mouseenter and Mouseleave Event is not registered. I think another check is needed.

yes, checking for ontouchstart is bound to give false positives (or rather, it doesn't test what some authors expect) and will only get more muddy in the near future https://bugs.chromium.org/p/chromium/issues/detail?id=392584
also, this doesn't seem to take into account scenarios where there are BOTH a mouse and a touchscreen. in short, this code (and any other instances of conditionals depending on ontouchstart being present, e.g. in https://github.com/twbs/bootstrap/blob/65ffb1c3b6e94440812a2e228cb8e8be512652ec/js/src/dropdown.js#L98) will need to be rethought. /cc @mdo

For me pause (on hover) Carousel work, see this CodePen (BS 4 Alpha 6) : http://codepen.io/Johann-S/pen/oBedMZ
But we should follow what @patrickhlauke said

+1 not working with Chrome workaround found at #1048
$('.carousel').hover(function () {
  $(this).carousel('pause')
}, function () {
  $(this).carousel('cycle')
})

I checked once again my CodePen and everything is working
This is my version of Chrome : 56.0.2924.87 (64-bit)

My version is 56.0.2924.87 (64-bit) too !
I work on Windows 10 with an hybrid PC (Lenovo Yoga) connected to an external screen...

+1 noworky on Window 10, Chrome 56.0.2924.87, touchscreen Samsung ATIV.  Fixed with xsalto-camille's jQuery workaround. Thanks.

so is this a touch issues or also a mouse hover issue?
i'm on a macbook pro with macos 10.12.5 and chrome 59.0.3071.115 and the mouse hover seems to work, in the inspector the touch>hold kind of hover is also working

Should all be fixed by https://github.com/twbs/bootstrap/pull/22442


crash the home assistant core 2024.04

After upgrading to 2024.04, when cleaning starts after a few seconds, HA restarts until you stop cleaning.
Intergation version 2.0.0b13

Model Name : dreame.vacuum.p2140p
Firmware Version: 4.3.3_1026
Home Assistant Version: 2024.4.0
Configuration Type With map support
If you deactivate the card, then there are no problems

Yes. I have a debugging log.
home-assistant_dreame_vacuum_2024-04-04T14-36-06.761Z.log

Can someone confirm is it safe to use 2.0.0b13 with HA 2024.04?

So far I have no problems with HA 2024.04. Running HAOS in proxmox virtualisation


Translation on Gboard not working

Translation on Gboard not working
Live translation couldn't download/enable language
Device: Google pixel 7, Google pixel 5

I'm on a oneplus 8t and what worked for me was downloading mindetach module, and detaching android system intelligence from play store so it didn't update, and then reinstalling pixelify. i had the same issue.


nvidia-x11 4.10 kernel patch url is borken

Issue description
I tried to update my NixOS and found it fails to fetch a kernel patch required here:
https://github.com/NixOS/nixpkgs/blob/b5c35862896e228305c402c4174720c09c12a8f6/pkgs/os-specific/linux/nvidia-x11/generic.nix#L61
Steps to reproduce

Use nixpkgs version 17.09pre107265.0afb6d789c
specify boot.kernelPackages = pkgs.linuxPackages_4_10 and services.xserver.videoDrivers = [ "nvidiaBeta" ]; in configuration.nix
nixos-rebuild boot

Technical details

System: 17.09pre105622.f0fac3b578 (Hummingbird)
Nixpkgs version: 17.09pre107265.0afb6d789c
Sandboxing enabled: true

cc @MP2E who added this patch, thank you!

Same thing on 17.03.1123.4a7a03913d (Gorilla) with nvidia videodriver
trying https://git.archlinux.org/svntogit/packages.git/plain/trunk/kernel_4.10.patch?h=packages/nvidia
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 404
error: cannot download nvidia from any mirror
builder for ‘/nix/store/b504xk2j9s72d6j4hkxfpq75zc6ma831-nvidia.drv’ failed with exit code 1

This is probably because the latest version of the nvidia driver supports 4.10 without patches. #25698 should hopefully fix it simply because it won't need the patch anymore, although I didn't remove the reference in case someone does want to use the older driver.

https://git.archlinux.org/svntogit/packages.git/commit/?h=packages/nvidia&id=358fcb0a5336bd502ef0117bd6bcf88dbcc0709d this is what broke it. We can probably still refer to an older version from the history. I'll add it to my PR.

I am not sure if nvidiaBeta (378.13) supports 4.10 without the patch. (I guess no)
Anyway, 378.13 seems outdated according to nvidia's Unix Driver Archive, @lheckemann it would be great if you can also update nvidiaBeta to the newest version.

thanks for the ping, have addressed this by updating the nvidia stable and beta drivers to their latest versions


Update the third party packages to the latest releases

Try to find a correct one for RapidJSON as the last release is over two years old and there is a lot of pipeline failures.
I would like if everyone could check that it works on their system, particularly I would like if you could try to build this with -DGINKGO_BUILD_BENCHMARKS=ON @hartwiganzt.
This is related to #270, I want to have the benchmark build with RapidJSON working after this MR.

My bad, looks like gflags changed their flag pattern, they finally added a GFLAGS prefix 👍 . I will update that part, so wait before trying.

This is now ready for review.
@hartwiganzt does the build pass for you on Mac OS with -DGINKGO_BUILD_BENCHMARKS=ON ?

Also works fine on my Ubuntu 18.04 system.

It does not resolve the MacOS build probem.

@hartwiganzt or anyone with a Mac, can you try building this branch again and see whether the patch I added changes anything?

no, still no success. sorry.

@hartwiganzt what about now?
A safe procedure for updating is the following:
git stash
git fetch
git checkout update_third_party_packages
git reset --hard origin/update_third_party_packages

I compile them with #280 successfully on my MacOS. (benchmark=on, reference=on, but shared_lib=off).
I also compile #278 with this #274 and #280 successfully. (benchmark=on, reference=on, example=on, shared_lib=on)

working!


[11.x] Encryption

This PR allows you to specify multiple previous_keys which are old encryption keys you are rotating out. All newly encrypted strings will be encrypted using the app.key like normal. On decryption, the current key will be tried first. If that key is not able to decrypt the data, decryption will be attempted with previous keys. Of course, if all keys fail to decrypt the data, the process will fail like normal.

I love this addition - having the ability to rotate encryption keys is incredibly powerful. 🤓
It looks great for rotating keys, but I wonder if it's worth expanding it to support rotating ciphers as well? So you would define a previous key & cipher pair, so that both can be safely rotated in the same process. That said, unless a big vuln is discovered in AES-256-CBC, we'd probably have a few years notice for the need to upgrade. crypto standards don't move quickly like that. So it's probably fine to keep it simple with just the keys for now.
I just noticed the methods you've added to the Encrypter will need to be added to \Illuminate\Contracts\Encryption\Encrypter, I'll PR that in a minute. 🙂

I feel like along with this PR, now would be a good time to separate out the database encryption key from the application encryption key.  I believe this has been a request for awhile, to allow people to rotate their app key on deployments.
With this change, will data encrypted with old keys be re-encrypted with the current key when saved back to the database?

Currently you can manually override the model encryption key using Model::encryptUsing(new Encrypter($key, $cipher));. Are you suggesting shifting that to be an env var alongside the main app key?
The key:generate command could populate both at once, and it could fallback to using app key if not provided. That could be a relatively painless way implement it.
Are you interested in PRing it?

With this change, will data encrypted with old keys be re-encrypted with the current key when saved back to the database?

It won't re-encrypt data that's currently stored in the db. There is a blurb about this in the docs too: https://laravel.com/docs/10.x/eloquent-mutators#key-rotation
But I believe it will re-encryption data you're working with, even if it hasn't changed.
See: https://github.com/laravel/framework/commit/c3ac147923dcaff6603c161671ba7c112e426a8b

Hey all. Taylor doesn't always see closed/merged PR's. Please PR something if you want him to look something over. Thanks!


Compatibility with AWS Kinesis Aggregator library?

Hello Team,
I am using this library to store data from Kinesis stream to S3.
I appreciate the overall design of the library, but then I want to aggregate some data (e.g. calculate sum of timespan group by visitor id) before uploading it to S3.
After some googling I come to find another library https://github.com/awslabs/amazon-kinesis-aggregators but I am not sure how to use them together with the connector library.
I guess I should follow the instructions under this section: https://github.com/awslabs/amazon-kinesis-aggregators#integrating-aggregators-into-existing-applications
but where should I put the aggregate(), checkpoint(), initialize(), shutdown() calls? For which class(es) should I extend to do so ?

Hi Gene,
I'd suggest that you put the logic for aggregators into the IEmitter class that you build for your connected endpoint. This will allow the Connectors architecture of buffering and transforming to still be used. You would then aggregate just before/after the output to the connected data store. Because the IEmitter receives an UnmodifiableBuffer instance, you will want to transform the data into an Aggregators InputEvent type, and use the aggregateEvents method. If you are want to use one of the built in Emitters for S3, you can just extend the basic emitter, do your aggregation call, and then call super.emit().
HTH,
Ian


Houdini + SvelteKit prerendering without SSR tries to load missing __data.json

Describe the bug
When setting up a SvelteKit project with Houdini, if SSR is disabled and prerendering enabled, attempting to access the site will query for __data.json files that do not exist, causing 500 errors.
Running yarn build once, removing the Vite plugin, then running yarn build again mitigates the issue, but this isn't tenable for CI.
Let me know if I'm missing something obvious that's my fault!
Severity
serious, but I can work around it
Steps to Reproduce the Bug

Create a new SvelteKit + TS project (yarn create svelte test-project)
Install dependencies (yarn)
Add Houdini (yarn add -D houdini; yarn run houdini init, add Vite plugin to config`)
Build (yarn build)
Run preview (yarn run preview)
Try to access index

I made a repository that can reproduce this issue. Just clone it, yarn; yarn build; yarn run preview.
Reproduction
https://github.com/ascclemens/houdini-no-ssr-issue

Huh,  that's very strange. Thanks for reporting this.
It'll probably be a little bit before I have some time to dig into this. If you have the time to figure this out, I'd gladly offer any help you need here or on discord.

Okay, i pulled down the reproduction. Thanks for putting that together - i was able to see the issue.
The issue did go away when I updated kit to the latest version i don't think this is a problem any more. I'm going to close this issue to keep things tidy but feel free to let me know if you're still running into this and I can reopen it

I can verify that this still happens. I have updated the reproduction repository.

Ah yea I see that too. I'll take a look and see what I can find

Okay, as far as I can tell, I think this issue is related to a combination of these two issues: https://github.com/sveltejs/kit/issues/7967 and https://github.com/sveltejs/kit/issues/7637. Basically, the vite plugin causes a .server.js file to be created which understandably confuses kit during prerendering.
I have some ideas of things to try but it might take me a few days to find the time to dedicate to it since family is over for the holidays. thanks for being patient!

Okay so once #786 gets merged, you'll be able to set static to true in your houdini-svelte config object to prevent the session infrastructure which was causing the request to __data to be sent.

The update should now be a part of 0.19.2

Can confirm it's fixed both in my minimal repro and in my original prod use-case, once static: true has been added to the Houdini config. Thank you so much!

Fantastic! Thanks for confirming so quickly ❤

This is still happening to me. Might be for a different reason. But it's definitely because of Houdini.


Not possible to copy/paste wallet adress on Osmosis on Keplr mobile app ios

Its not possible to copy, for example a terra wallet adress for deposits on Osmosis/keplr mobile ios.
The adress is shortened using ... which also translates to copy/paste
Please add a copy full adress button.

Can you take the lead on this @victortokaito? Let me know if you get blocked on anything.


Fix bug in encode_cf_datetime

[ ] Closes #2272
[ ] Tests added (for all bug fixes or enhancements)
[ ] Fully documented, including whats-new.rst for all changes and api.rst for new API (remove if this change should not be visible to users, e.g., if it is an internal clean-up, or if this is part of a larger project that will be documented later)

Hello @spencerkclark! Thanks for submitting the PR.

There are no PEP8 issues in the file xarray/coding/times.py !

There are no PEP8 issues in the file xarray/tests/test_coding_times.py !


Smoke Test Kit: create _CoqProject files in each package folder which requires -Q or -R options

Currently if a smoke test file requires -Q or -R options, it cannot be run in CoqIDE as is. An easy fix would be to create _CoqProject files in the folders with the proper options.

Fixed via commit fa85561.


can I use this react-sortablejs?

can I use this react-sortablejs, it can work?

Hey @RubaXa I could work on this project

@geofmureithi  check email.

Accepted invitation. Getting on it.

@geofmureithi 👍


Update codecs.md

I'm going to close this PR as well and refer you to my response in #337

Please also refer to the related Jira for a Jackson-based Codec: https://jira.mongodb.org/browse/JAVA-1314


Nothing happens when I execute the script

When I execute the script, I get a command prompt  ">" and nothing happens.  To get back to my shell I have to hit CNTRL C.

Are you using Debian?

Yes. Debian Bullseye Arm64 (Raspberry pi 4).   I also tried on AMD64 with my chromebook.

How are you running it? Are you pasting the script?

just like your wiki suggests....
I followed the instructions to get my token.   I cloned the script.  I made sure it had execute permissions.  From the same folder I executed the command and replaced the example token with my token...
./warp.sh -T eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

@Doug411 what if you prepend bash to ./warp.sh?

interesting.... good idea... let me give it a go!

if it doesn't work, can you please run the script with sh -x so I could see where this is happening?

We're getting somewhere!   I got a response.....[ ](curl: (22) The requested URL returned error: 401)

@Doug411 that means the token is too old, you need to get a new token.

wait.  i think i missed the last charachter.  Trying again...

Same as before I'm getting a prompt.  Like im inside bash... It doesnt return me back to my linux shell.  I have to break out of it.

Interesting though.  I hadnt tried putting in an incorrect token.  The first time I tried with an incorrect token it finished and returned me back with an an error code..

Can't reproduce on debian 9 either, it's a bit weird...

it finishes if i try without the token just sudo bash ./warp.sh,  It prints out a profile on the screen.  Is it supposed to create a file, or just print one out?

it's supposed to print it out, optionally you could pipe it to a file.

So.... of all things my token ends with the quote charachter "

The first time I tried with you I mistakenly left out the quote and it processed with an error code.  I tried again and got an error code.  Can you try replacing your last charachter with a quote?

i just saw your ask about -x.   What is the full command you want me to run Is it  bash warp.sh -x -T aadjfkasjdfalkjf

Are you doing something like ./warp.sh -T some_token" (with that quote at the end?)

Well that was really dumb....   :)   I pasted the element into an email to crop the token.   The token appeared on a separate, independent line.  There was no starting quote after the = sign, so i guess I thought the whole thing was the string (which was odd).  Now I look at the entire header, and I can see the quote is closing out above token.
So one step forward.  It produced a profile.  I copied it into a text file and attached in WG.   It is rapidly doing a handshake and reporting that it received a response.  No internet access.  Is there something else I need to change before using the profile?
Thanks for you patience!  I appreciate your help!

There shouldn't be, though you might have to disconnect and reconnect the interface to get internet access. Once you get internet access it should work permanently from there and you won't need to do such a thing again.

Hi again.   Just wanted to provide an update.  I finally got it working.  I was attempting it on a chromebook and an android phone.   Just an FYI, I had to remove the CIDR suffix from the local IP addresses (both IPV4 and IPV6).  Once I did that, it connected right away and has been rock solid!

So you simply didn't specify /32 and /128?

It's weird because those are the default suffixes anyway. So I'm not sure why being explicit about them would make a difference and causes it to not work. Either way, I don't see any harm in doing this, it's just strange that it was needed in your case.


How 'beta' is beta?

Is it advisable to use Imager on a production site yet?

Hard to say, that's why I labelled it a beta. ;) I'm using it on three sites now which is still in development, and there are some small occasional bugs that keep popping up, but all in all it works very well. I consider the syntax finalized, pretty sure that won't change, except for options being added.
The parts that needs the most testing at the moment are optimizations with external tools (like jpegoptim, optipng, etc), and the AWS support. It works in my tests, but I'm not using it in everyday development right now. I'm moving all optimizations to tasks when I get the chance, and currently files that are uploaded to AWS isn't optimized (with external tools) yet.
It's been tested on Apache and nginx, OSX and Ubuntu, with PHP 5.6. No idea how it'd work i PHP 7 or older versions right now.
If you decide to take it for a spin I'd love to hear how it works out for you. If you already have a site in production, you could test in on some templates first to see if it works for you, and continue converting it later. Imager lives happily side by side with Craft's built-in image transforms. :)

Thanks André. I'm testing it out now. One of the requirements is serving the transformed images from S3.
They seem to be transforming and uploading OK, and I've changed the imagerUrl setting to point at S3 so they're being served correctly so far.
Do the transforms still need to be created locally as well? I notice I can also see them locally based on the imagerSystemPath setting.

Yeah, it should work uploading and serving them from AWS. What doesn't work at the moment is if you want to use TinyPNG, jpegtrans, or any of the other external tools for further optimizing images, then the file that is on AWS isn't being optimized. I'll get around to fixing that shortly I hope.
The transformed images are still saved in imagerSystemPath, even if they are uploaded to AWS as part of the transform process. The local file is used as a cache for deciding what transforms have been created, and when they need to update. This is so that Imager doesn't have to do a check the file on AWS (by downloading it), or save information to the database like the built-in functionality does. Imager is optimized for performance, definitely not for disk space. ;)

Cool, that makes sense. Thanks.


New package: com.spacestation14.Launcher version v0.28.0

Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[x] Is there a linked Issue?

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@microsoft-github-policy-service agree

Closing for now and will resubmit after I contributed an "installer" to upstream project


frame too close to the bottom on small screens

Can we center this?

This is essentially a duplicate of #189. Let's discuss there :)
Cheers!


Cursor too large (disappears inside Xwayland windows on external monitor with output scale >2.7)

I believe my issue described in https://github.com/swaywm/wlroots/issues/2526#issuecomment-756042358 is separate to #2525, so I'm posting a new issue here.
Under the following conditions the mouse cursor completely disappears:

cursor must be inside Xwayland window (tested with glxgears, VS code)
only occurred on external display (nouveau)
scale of the external output must be quite high (e.g.: for a 4K display, the cursor was fine up until scale=2.7, then scale=2.71 broke it)

Relevant log line:
00:00:25.410 [ERROR] [wlr] [backend/drm/drm.c:930] connector HDMI-A-1: Cursor too large (max 64x64)

This seems relatively straightforward  - when the output scale is very large, is the cursor texture just too large to fit into the hardware cursor plane? Confused why this only affects Xwayland windows though.
Should there be some sort of automatic fallback to software cursors in this case?
no_cursor_in_xwayland_windows_3.log

Indeed, this is a separate issue.
Can you try running drm_info to see what the max cursor size is? Maybe also add some logging to see what the texture size is.

Indeed, this is a separate issue.
Can you try running drm_info to see what the max cursor size is? Maybe also add some logging to see what the texture size is.

I'll have to leave the logging till tomorrow - but here's the drm_info output - afraid I'm not quite sure how to decipher it myself. There's one cursor plane which appears to be 256x256, but I think that's Intel.
/dev/dri/card1 (nouveau) has:

DRM_CAP_CURSOR_WIDTH = 64
DRM_CAP_CURSOR_HEIGHT = 64

drm_info.txt

I'll have to leave the logging till tomorrow - but here's the drm_info output - afraid I'm not quite sure how to decipher it myself. There's one cursor plane which appears to be 256x256, but I think that's Intel.
/dev/dri/card1 (nouveau) has:

DRM_CAP_CURSOR_WIDTH = 64
DRM_CAP_CURSOR_HEIGHT = 64

drm_info.txt

This patch may help with newer NVIDIA cards, but we still need to fix the wlroots bug: https://gitlab.freedesktop.org/lyudess/linux/-/commit/fc3b3bcce48594968317132767503555b9ca70aa

This patch may help with newer NVIDIA cards, but we still need to fix the wlroots bug: https://gitlab.freedesktop.org/lyudess/linux/-/commit/fc3b3bcce48594968317132767503555b9ca70aa


read configuration also from environment

@mcdonnelldean
Need this to start vidi-dashboard in fuge with external Concorda support.

@mcdonnelldean
It will be great if this is also published.

@mcdonnelldean ping, please also publish this version


README docs: Add autoconf to dependencies

Context: Installed btcdeb this morning on a fresh Debian machine (PureOS distribution).
Nit: In addition to libssl-dev and libtool, autoconf was a required dependency. It might not be present by default in a new environment. Thus, this minor proposed doc change.
Cheers.
[skip ci]

Thanks!

T.Schmelzer
Am 11.08.2018 13:28 schrieb "Jon Atack"<EMAIL_ADDRESS>
Context: Installed btcdeb this morning on a fresh Debian machine (PureOS
distribution).
Nit: In addition to libssl-dev and libtool, autoconf was a required
dependency. It might not be present by default in a new environment. Thus,
this minor proposed doc change.
Cheers.
[skip ci]
You can view, comment on, or merge this pull request online at:
https://github.com/kallewoof/btcdeb/pull/22
Commit Summary

Add autoconf to README dependencies

File Changes

M README.md
https://github.com/kallewoof/btcdeb/pull/22/files#diff-0 (3)

Patch Links:

https://github.com/kallewoof/btcdeb/pull/22.patch
https://github.com/kallewoof/btcdeb/pull/22.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kallewoof/btcdeb/pull/22, or mute the thread
https://github.com/notifications/unsubscribe-auth/Am454CI3mwCVD5xVISo2PPiToHqprEcuks5uPr_rgaJpZM4V5Irr
.


Do not enclose localhost hostname with square brackets #4950

Inet6Address is returning localhost as hostname under specific network env (ex. Vpn).
“Localhost” should not be enclosed with square brackets since they will produce IllegalArugmentException in HttpUrl if so.

This is the most simple fix, which asserts that hostname never becomes "[localhost]".

Can you add a test to RecordedRequestTest

Please complete our contributor’s agreement:
https://github.com/square/okhttp/blob/master/.github/CONTRIBUTING.md

@CoderSpinoza Any plans to sign the CLA and add a test, or should we take over and reimplement with tests?


[HOLD #16514] Month is not updated reopening the calendar after changing year and month and date

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open the app
Open settings
Open profile
Open personal details
Open Date of birth
Click on date
Change year and month and date and close the date widget
Reopen date widget

Expected Result:
App should display updated month, year and date on reopening of date widget
Actual Result:
App updates the year but does not display the updated month
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

Version Number: 1.2.89-0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/227733946-19645163-0412-48db-a905-db681d8e4414.mp4
https://user-images.githubusercontent.com/43996225/227733952-f86fee98-b974-4f3b-abd8-fcb7a45be978.mp4
Expensify/Expensify Issue URL:
Issue reported by: @dhanashree-sawant
Slack conversation:
https://expensify.slack.com/archives/C049HHMV9SM/p1679753397190599
View all open jobs on GitHub

Triggered auto assignment to @sophiepintoraetz (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

Still holding.

Dropping to monthly while we wait for the holding solution to be implemented.

Still holding

This bug cannot be reproduced now that the linked issue has been deployed. @dhanashree-sawant - I sent a reporting offer your way!


cupertino date picker: fixed column month width

Some smartphones within portuguese language has a layout break in a Cupertino date picker columns widths.

I’ve noticed that build months columns widget according month name length size. But, it’s may have a problem when the month have letters like as: i or t per example. Because it’s a short letters in comparison with a or b per example.
However, I’ve a hope I fixed it.

Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

@LeonardoRosaa thank you for your contribution!
Unfortunately, this change appears to be incorrect (it compares the strings lexically instead of by width). We really should be measuring the text using TextPainter in some way.
This would also need a test.
I recommend filing an issue on this topic so that we have a place to discuss the issue before fixing it. I'm going to close this PR for now since it is not in a state where we can accept it.