text:
Table id drop down

whats included in this PR?
Changed the title of the application.
Added drop down for table id.
IoPanel variable in main panel is made accessible by a public method to add pull panel as a property change listener to login task.

runtests

Sir I have Implemented changes to download multiple table at once. Download button would work now to download multiple table ids at once. The Download options section currently selects options which are common for all table ids. I will push changes for it to enable selection of options for every table id.

runtests

@Shubhamr837 Support for different options for each table can go in a separate pull request.

Ok @linl33 I will create another pull request for that.

Hi @linl33 I have encountered a major bug in multiple table download, after download completes for a table id it send a property change event with Done event. This enables all the buttons and also updates table list unnecessarily. So I was thinking of moving the entire logic of multiple table id download to the DownloadTask doinbackground method. Your thoughts?

@linl33 @codeknight3 We are getting close to doing a release and I would like to include @Shubhamr837 changes. Therefore it would be very helpful if you could review this PR.

@wbrunette I have Identified few bugs. One was corrected yesterday and other bugs I will try to correct today.

@Shubhamr837. End of the week is fine.

repo: odk-x/suitcase


text:
Missing style in the style resource XML file.

The xml layout for the ChooseSignInTypeFragment  (fragment_choose_sign_in_type) has a missing  style reference on the anonymous sign in button.

This was discovered after checking out to the updated  jdk 11 branch.
Not sure how to proceed with this. Should an already existing style be used in place of this or is this a style that is supposed to be existing?

@wbrunette @elmps2018 how should i proceed with this ?

Make sure to use snapshot to flavor to build

source: gharchive/issue

repo: odk-x/tool-suite-X

license_type: permissive

license_source: github-api


text:
:arrow_up: Upgrade eslint related dependencies to latest

Upgraded eslint + config + prettier dependencies with the following:
npm install --save-dev eslint@latest prettier@latest eslint-config-prettier@latest eslint-plugin-import@latest eslint-config-airbnb@latest

Running the lint script with npm run lint yields the errors.
Some can be fixed automatically, but I'll go through these until linting passes.
$ npm run lint

> opendota-core@21.0.2 lint
> eslint . --ext .js,.jsx --ignore-path .gitignore

/root/dev/ff137/core/dev/cassandraRandom.js
  13:74  error  Parsing error: Unexpected token .

/root/dev/ff137/core/dev/cassandraTest.js
  11:58  error  Unary operator '++' used          no-plusplus
  13:22  error  Unexpected `await` inside a loop  no-await-in-loop

/root/dev/ff137/core/index.js
  15:5  error  Strings must use doublequote  quotes

/root/dev/ff137/core/routes/generateOperationId.js
   1:1  error  Expected exception block, space or tab after '/*' in comment  spaced-comment
  23:7  error  Unexpected string concatenation                               prefer-template

/root/dev/ff137/core/routes/keyManagement.js
  98:46  error  Parsing error: Unexpected token .

/root/dev/ff137/core/routes/requests/importParams.js
  18:25  error  Calls to require() should use string literals  import/no-dynamic-require
  18:25  error  Unexpected require()                           global-require

/root/dev/ff137/core/routes/responses/schemas/hero/HeroStatsResponse.js
  134:42  error  Expected exception block, space or tab after '//' in comment  spaced-comment
  219:7   error  Expected exception block, space or tab after '//' in comment  spaced-comment

/root/dev/ff137/core/routes/responses/schemas/importResponseSchemas.js
  18:25  error  Calls to require() should use string literals  import/no-dynamic-require
  18:25  error  Unexpected require()                           global-require

/root/dev/ff137/core/routes/responses/schemas/player/PlayerCountsResponse.js
  1:7  error  'commonProperties' is assigned a value but never used  no-unused-vars

/root/dev/ff137/core/routes/spec.js
  202:67  error  Parsing error: Unexpected token .

/root/dev/ff137/core/scripts/convertSpec.js
  2:22  error  Unexpected use of file extension "js" for "../routes/spec.js"  import/extensions

/root/dev/ff137/core/store/buildMatch.js
  82:40  error  Parsing error: Unexpected token .

/root/dev/ff137/core/store/queries.js
  1706:36  error  Parsing error: Unexpected token .

/root/dev/ff137/core/svc/apiadmin.js
  102:5   error  iterators/generators require regenerator-runtime, which is too heavyweight for this guide to allow them. Separately, loops should be avoided in favor of array iterations  no-restricted-syntax
  103:7   error  Unary operator '++' used                                                                                no-plusplus
  115:9   error  Unexpected use of continue statement                                                                                no-continue
  152:19  error  Strings must use doublequote                                                                                quotes
  168:16  error  Unexpected function expression                                                                                prefer-arrow-callback
  193:16  error  Unexpected function expression                                                                                prefer-arrow-callback

/root/dev/ff137/core/svc/cassandraDelete.js
  11:74  error  Parsing error: Unexpected token .

/root/dev/ff137/core/svc/fullhistory.js
  6:7  error  'constants' is assigned a value but never used  no-unused-vars

/root/dev/ff137/core/svc/livegames.js
  9:9  error  'invokeInterval' is assigned a value but never used  no-unused-vars

/root/dev/ff137/core/svc/parser.js
  67:10  error  Expected to return a value at the end of function 'parseProcessor'  consistent-return

/root/dev/ff137/core/svc/retriever.js
  440:10  error  Unnecessary 'else' after 'return'  no-else-return

/root/dev/ff137/core/svc/scenariosCleanup.js
  37:8  error  'cb' is defined but never used                         no-unused-vars
  38:1  error  This line has a length of 181. Maximum allowed is 180  max-len

/root/dev/ff137/core/svc/skill.js
  8:7  error  'queries' is assigned a value but never used  no-unused-vars

/root/dev/ff137/core/svc/syncSubs.js
   7:16  error  `stripe` import should occur before import of `../store/db`                                                                                import/order
  11:20  error  'cb' is defined but never used                                                                                no-unused-vars
  14:3   error  iterators/generators require regenerator-runtime, which is too heavyweight for this guide to allow them. Separately, loops should be avoided in favor of array iterations  no-restricted-syntax
  25:38  error  Unary operator '++' used                                                                                no-plusplus
  28:5   error  Unexpected `await` inside a loop                                                                                no-await-in-loop

/root/dev/ff137/core/svc/web.js
  318:17  error  Parsing error: Unexpected token .

/root/dev/ff137/core/test/test.js
  437:35  error  Parsing error: Unexpected token .

/root/dev/ff137/core/util/getGcData.js
  21:26  error  Parsing error: Unexpected token .

/root/dev/ff137/core/util/utility.js
  464:36  error  Unary operator '++' used  no-plusplus

✖ 45 problems (45 errors, 0 warnings)
  9 errors and 0 warnings potentially fixable with the `--fix` option.

Quite a few of those errors (such as Parsing error: Unexpected token .) are due to linter not knowing the javascript version being used. To fix that, I added the following to the .eslintrc.json:
  "parserOptions": {
    "ecmaVersion": 2023
  },

Now there are 181 problems ... 104 of which are automatically fixable.

Ok, with the help of Cursor (VS Code with ChatGPT), I was able to fix most of the linting errors that remained.
Some nice improvements include replacing await in a loop with executing all promises concurrently. The other changes are fairly trivial.
There's a few cases where I couldn't figure out how to replace the await in a loop.
In svc/cassandraDelete.js and dev/cassandraRandom.js, there is a while(true) loop that contains await commands. No idea how to unravel that, so I'm leaving it as is.

So, my renaming of variables (from snake_case to camelCase) broke something in keyManagement/tests, so rolling back those changes
I notice that test are actually quite sparse in this repo (no tests for routes), so with this refactoring it may be worthwhile if I include some more tests to make sure I didn't break anything else with the linting changes.

I'm going to revisit eslint later--I think typescript helps us catch most of the important kinds of errors

source: gharchive/pull-request

repo: odota/core

license: mit

license_source: bigquery


text:
Job Deployment to be Asynchronous on Job Deploy Calls

Scope

Identify the modified/created/deleted jobs update & persists only for the changed jobs.
Ensure whether jobs can be deleted & return the corresponding response to the user.
Trigger the deployment request to scheduler

2. Ensure whether jobs can be deleted & return the corresponding response to the user.

Just to verify @sravankorumilli, ensure means we need to check if there are any other jobs that depend on the jobs to be deleted.

If any, we need to skip it and give the response that these jobs are not able to be deleted.
If not, we need to also provide the response that these jobs are deleted.

authors: arinda-arif sravankorumilli

repo: odpf/optimus


text:
Support flexible choice of open metadata cohort members in VDC chart

The vdc chart currently support a cohort with

Egeria local repo ( in mem [default]. local graph) - but always deployed
Apache atlas - always deployed
IGC - can already be disabled

We should allow any combination - so need to be able to disable local repo, or apache atlas

Making a more general change.
Egeria is mandatory
Kafka is also mandatory, but with a choice of internal or external
All other components (ui, omrsmonitor, gaian, ranger, postgresql, atlas etc) are optional. They will default to enabled, but can be turned off.
This allows for more flexible use - for example someone could just deploy egeria itself, or egeria itself, or everything apart from ranger and atlas etc.
The deployments & jobs have had conditionals added to support this. This extends to all config options in the map too.
At this time I have not added support for EXTERNAL ranger, atlas components -- but that could be a later improvement :-)
Limited testing. Default configuration OOTB & IBM cloud

Also changed
egerialocalrepomode
to
egeria.localrepomode
And added configuration capability for server, user, cohort names

Default configuration OOTB & IBM cloud

Does this mean that running the default configuration requires a (paid) IKS setup?  I'd suggest that in line with all our other open source focus that we ensure that the default configuration does not require any paid or external accounts to run (ie. that it is entirely self-contained and locally-executable unless absolutely unavoidable due to commercial software constraints like IGC)...

Not at all. It's just a reference to what I tested after making the change.
Absolutely 200% agree with the principle.
There is absolutely no requirement for any proprietary components including IBM cloud
(More automated tests would be desirable as it's very easy to have issues with templating)

repo: odpi/egeria


text:
Spring mappings

This PR converts all matches of @RequestMapping(method\s=\sRequestMethod.POST,  with calls to @PostMapping Issue #2214

@mandy-chessell I've been removing the @RequestMapping calls in bitesize chunks, after this PR there are 67 occurrences still remaining in the code base, which will remove the remaining HTTP verbs and then the import statement that will be no longer needed ?

Is it possible to remove the obsolete import of the ReguestMapping module?

I made the same comment on an earlier PR, I agree, but it's already planned ... Splitting the changes up does make sense, more manageable.
Inspecting changes looks good. just doing a quick test


text:
🛑 urbamonde.org is down

In 82007b2, urbamonde.org (https://www.urbamonde.org) was down:

HTTP code: 429
Response time: 565 ms

Resolved: urbamonde.org is back up in 8b8751b.

repo: odqo/upptime

license: MIT


text:
🛑 urbamonde.org is down

In f059a11, urbamonde.org (https://www.urbamonde.org) was down:

HTTP code: 429
Response time: 693 ms

Resolved: urbamonde.org is back up in 466e1db.


text:
"fix: kubeVersion: 9.0.0 doesn't exist" Changing it to 1.9.0 to be co…

"fix: kubeVersion: 9.0.0 doesn't exist" Changing it to 1.9.0 to be consistent with the rest of the chart"

@ogmaresca this should fix a regression introduced in the last update

repo: ogmaresca/azp-agent-autoscaler


text:
Edited the nursing care section to a table under nursing tab of patient

Proposed Changes

Fixes #8562
Edited the nursing care section to a table under nursing tab of patient

@ohcnetwork/care-fe-code-reviewers
Merge Checklist

[ ] Add specs that demonstrate bug / test a new feature.
[ ] Update product documentation.
[ ] Ensure that UI text is kept in I18n files.
[ ] Prep screenshot or demo video for changelog entry, and attach it to issue.
[ ] Request for Peer Reviews
[ ] Completion of QA

Also, not all tasks mentioned in the issue is solved. Drop a comment once ready for review.


text:
Fix: UI changes in shifting and resources pages

Proposed Changes

Fixes #9381
Adjusted the height of the "List View" button to match the height of the "Advanced Filters" button on both the shifting and resources pages.
Ensured consistent alignment of the top section in both list view and block view across the shifting and resources pages.

Video of Solution:

@ohcnetwork/care-fe-code-reviewers
Merge Checklist

[ ] Add specs that demonstrate bug / test a new feature.
[ ] Update product documentation.
[ ] Ensure that UI text is kept in I18n files.
[ ] Prep screenshot or demo video for changelog entry, and attach it to issue.
[ ] Request for Peer Reviews
[ ] Completion of QA

Summary by CodeRabbit

New Features

Introduced a new PageTitle component for improved layout and organization.
Added an ExportButton for downloading resource requests in CSV format.

Improvements

Enhanced styling for buttons and components for better visibility and usability.
Improved alignment and spacing of search input and buttons using a flexbox structure.

Bug Fixes

Preserved existing functionality for data fetching and rendering across components.

@bodhish I have now made changes as per your request

LGTM


text:
Errors aren't always displayed

In some cases it build errors are not shown to the user.

This was resolved 🎉


text:
🛑 Ekşi Sözlük is down

In b5f1cdd, Ekşi Sözlük (https://eksisozluk.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ekşi Sözlük is back up in 69d4b86.

repo: okankocyigit/upptime


text:
add classification finetuning notebooks

Description
Adds notebooks showcasing finetuning workflow for Tool Classification with Phi-3
Checklist

[ ] Tests covering the new functionality have been added
[ ] Documentation has been updated OR the change is too minor to be documented
[ ] Changes are listed in the CHANGELOG.md OR changes are insignificant

Will take up points 1, 2, and 4 in the next commit.
Re: 3, if the user is running the notebook in the repo, then this imports the relative path (finetuning/utils.py). This is a carry-over from the Predii notebooks where I moved a lot of the larger, finetuning-specific cells to a utils.py file. I can move these back into the notebook if we want to make it more standalone.

repo: okareo-ai/okareo-python-sdk


text:
OKD 4.13 - new kernelArguments (error: No packages in transaction)

I noticed in the 01-worker-kubelet and 01-master-kubelet machineConfigs for 4.13, the following kernelArguments are present (that weren't in previous versions)
  kernelArguments:
    - systemd.unified_cgroup_hierarchy=0
    - systemd.legacy_systemd_cgroup_controller=1

My kargs already have cgroup_heirarchy=0, but not the controller
$ rpm-ostree kargs
systemd.unified_cgroup_hierarchy=0...

When nodes are attempting to update at the kargs append stage, I get the following error:
I0526 03:59:25.742825    1703 update.go:2010] Running: rpm-ostree kargs --append=systemd.unified_cgroup_hierarchy=0 --append=systemd.legacy_systemd_cgroup_controller=1
Checking out tree 10c2798...done
Resolving dependencies...done
I0526 03:59:36.135510    1703 update.go:2136] Rolling back applied changes to OS due to error: error running rpm-ostree kargs --append=systemd.unified_cgroup_hierarchy=0 --append=systemd.legacy_systemd_cgroup_controller=1: error: No packages in transaction

When attempting to run the append manually just for the cgroup controller, I'm met with the same error:
$ sudo rpm-ostree kargs --append=systemd.legacy_systemd_cgroup_controller=1
Checking out tree 10c2798... done
Resolving dependencies... done
error: No packages in transaction

Please attach (or upload to the public file sharing service) must-gather archive

Attached must-gather
relevant error location:
node: okd-master-1
pod: machine-config-daemon-n899c

I don't see an MC which adds this karg via MCO - are you running this manually? If yes - why?

I don't see an MC which adds this karg via MCO - are you running this manually? If yes - why?

must-gather-clean must've stripped the MCs by default.
01-master-kubelet and 01-worker-kubelet both look like this:
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  annotations:
    machineconfiguration.openshift.io/generated-by-controller-version: 230bb7e5f5620af293f3dc5b9740e01f5644262f
  resourceVersion: '689107396'
  name: 01-master-kubelet
  uid: 09150426-3421-41aa-8795-68a383fecc28
  creationTimestamp: '2021-05-05T20:23:49Z'
  generation: 36
  managedFields:
    - apiVersion: machineconfiguration.openshift.io/v1
      fieldsType: FieldsV1
      fieldsV1:
        'f:metadata':
          'f:annotations':
            .: {}
            'f:machineconfiguration.openshift.io/generated-by-controller-version': {}
          'f:labels':
            .: {}
            'f:machineconfiguration.openshift.io/role': {}
          'f:ownerReferences':
            .: {}
            'k:{"uid":"a8668efc-2745-4a86-9c86-5a57d7df2100"}': {}
        'f:spec':
          .: {}
          'f:baseOSExtensionsContainerImage': {}
          'f:config':
            .: {}
            'f:ignition':
              .: {}
              'f:version': {}
            'f:storage':
              .: {}
              'f:files': {}
            'f:systemd':
              .: {}
              'f:units': {}
          'f:extensions': {}
          'f:fips': {}
          'f:kernelArguments': {}
          'f:kernelType': {}
          'f:osImageURL': {}
      manager: machine-config-controller
      operation: Update
      time: '2023-05-26T20:21:21Z'
  ownerReferences:
    - apiVersion: machineconfiguration.openshift.io/v1
      blockOwnerDeletion: true
      controller: true
      kind: ControllerConfig
      name: machine-config-controller
      uid: a8668efc-2745-4a86-9c86-5a57d7df2100
  labels:
    machineconfiguration.openshift.io/role: master
spec:
  baseOSExtensionsContainerImage: ''
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: 'data:,'
          mode: 420
          overwrite: true
          path: /etc/kubernetes/cloud.conf
        - contents:
            source: >-
              data:,xxx
          mode: 420
          overwrite: true
          path: /etc/kubernetes/kubelet.conf
        - contents:
            source: >-
              data:xxx
          mode: 493
          overwrite: true
          path: /usr/local/bin/kubenswrapper
    systemd:
      units:
        - contents: >
            [Unit]

            Description=Kubernetes Kubelet

            Wants=rpc-statd.service network-online.target

            Requires=crio.service kubelet-auto-node-size.service

            After=network-online.target crio.service
            kubelet-auto-node-size.service

            After=ostree-finalize-staged.service

            [Service]

            Type=notify

            ExecStartPre=/bin/mkdir --parents /etc/kubernetes/manifests

            ExecStartPre=/bin/rm -f /var/lib/kubelet/cpu_manager_state

            ExecStartPre=/bin/rm -f /var/lib/kubelet/memory_manager_state

            EnvironmentFile=/etc/os-release

            EnvironmentFile=-/etc/kubernetes/kubelet-workaround

            EnvironmentFile=-/etc/kubernetes/kubelet-env

            EnvironmentFile=/etc/node-sizing.env

            ExecStart=/usr/local/bin/kubenswrapper \
                /usr/bin/kubelet \
                  --config=/etc/kubernetes/kubelet.conf \
                  --bootstrap-kubeconfig=/etc/kubernetes/kubeconfig \
                  --kubeconfig=/var/lib/kubelet/kubeconfig \
                  --container-runtime-endpoint=/var/run/crio/crio.sock \
                  --runtime-cgroups=/system.slice/crio.service \
                  --node-labels=node-role.kubernetes.io/control-plane,node-role.kubernetes.io/master,node.openshift.io/os_id=${ID} \
                  --node-ip=${KUBELET_NODE_IP} \
                  --minimum-container-ttl-duration=6m0s \
                  --cloud-provider= \
                  --volume-plugin-dir=/etc/kubernetes/kubelet-plugins/volume/exec \
                   \
                  --hostname-override=${KUBELET_NODE_NAME} \
                  --provider-id=${KUBELET_PROVIDERID} \
                  --register-with-taints=node-role.kubernetes.io/master=:NoSchedule \
                  --pod-infra-container-image=quay.io/openshift/okd-content@sha256:cd7949e762391ade516277da8107713ecf632c43474f2b3fe3ec6f719fd24aca \
                  --system-reserved=cpu=${SYSTEM_RESERVED_CPU},memory=${SYSTEM_RESERVED_MEMORY},ephemeral-storage=${SYSTEM_RESERVED_ES} \
                  --v=${KUBELET_LOG_LEVEL}

            Restart=always

            RestartSec=10

            [Install]

            WantedBy=multi-user.target
          enabled: true
          name: kubelet.service
  extensions: null
  fips: false
  kernelArguments:
    - systemd.unified_cgroup_hierarchy=0
    - systemd.legacy_systemd_cgroup_controller=1
  kernelType: ''
  osImageURL: >-
    quay.io/openshift/okd-content@sha256:aed14445e978d17b40bd2a353efea0bff7231c3327ec767cb0abda99f65aa107

I also found this commit in the operator from 2 months ago

Yes, its the new default coming from MCO. What's this bug about - why systemd.legacy_systemd_cgroup_controller=1 is not set?

When nodes are attempting to update at the kargs append stage, I get the following error:

Update via direct rpm-ostree run or via additional MC? If its reproducible via direct rpm-ostree run - then its an FCOS bug I suppose, we don't need to track it here. If it happens via MC run then its a valid MCO bug

I see the same issue on my installation too.

systemd.legacy_systemd_cgroup_controller appears to not a valid package

Its not a package its a kernel arg

I cannot remove these with an additional MC, only overwrite

That's expected - this MC is generated by MCO, but you can overwrite them.
Is this "I can't set any kernel args because rpm-ostree complains about repositories"?

Is this "I can't set any kernel args because rpm-ostree complains about repositories"?

I can set all of the other kernel args, I just cannot set the systemd.legacy_systemd_cgroup_controller kernel arg, whether or not I enable or disable all repositories.  I cannot overwrite the MC's kernel args to any other value, because the arg itself won't set.  rpm-ostree seems to work fine in all scenarios other than setting this one kernel arg, in which case is gives the error error: No packages in transaction
VERSION="38.20230414.3.0 (CoreOS)"
OSTREE_VERSION='38.20230414.3.0'
KERNEL=6.2.9-300.fc38.x86_64

I just cannot set the systemd.legacy_systemd_cgroup_controller kernel arg

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-okd-worker-custom-kargs
spec:
  config:
    ignition:
      version: 3.2.0
  kernelArguments:
    - systemd.unified_cgroup_hierarchy=1
    - systemd.legacy_systemd_cgroup_controller=0

This would overwrite kernel args in 01-worker-kubelet MC as these are applied in the lexographical order, so 99- takes precedence:
sh-5.2# cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt3)/ostree/fedora-coreos-d2605fec211df3ea8a588c4fbc6c881a8a1ea85f33b2c52eb62e469ff6a25622/vmlinuz-6.2.9-300.fc38.x86_64 mitigations=auto,nosmt ostree=/ostree/boot.0/fedora-coreos/d2605fec211df3ea8a588c4fbc6c881a8a1ea85f33b2c52eb62e469ff6a25622/0 ignition.platform.id=aws console=tty0 console=ttyS0,115200n8 root=UUID=ab159700-3e34-4d27-be00-faf609a455f9 rw rootflags=prjquota boot=UUID=f5d98ff4-90e4-4d11-a15f-386dd15c3e2b systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller=1 systemd.unified_cgroup_hierarchy=1 systemd.legacy_systemd_cgroup_controller=0 mitigations=off intel_pstate=disable
sh-5.2# rpm-ostree status
State: idle
Deployments:
* ostree-unverified-registry:quay.io/openshift/okd-content@sha256:aed14445e978d17b40bd2a353efea0bff7231c3327ec767cb0abda99f65aa107
                   Digest: sha256:aed14445e978d17b40bd2a353efea0bff7231c3327ec767cb0abda99f65aa107
                  Version: 38.20230414.3.0 (2023-05-31T09:54:22Z)

I have done this also.  I just took your config, applied it, and set the node's desiredconfig to the latest rendered.  I am still receiving the same error.

Please attach an updated must-gather

I ran into the same problem right now.
Any workaround yet?

Please attach an updated must-gather

Having trouble getting a meaningful updated must-gather; I can only assume because of the condition of the cluster at the moment.

I ran into the same problem right now. Any workaround yet?

I've been unable to workaround.  Even if you patch the kernel arguments manually and they make it into /proc/cmdline, rpm-ostree will not pass the upgrade successfully because there are no packages present in the transaction.  With the inability to remove the default kernelArgs from the MC (there were none prior), rpm-ostree will continue to try and patch them only to fail.
Feels like the perfect storm of an rpm-ostree bug/faulty error handling + newly defaulted kernelArgs in the MC.  I don't know everything for certain because I only interact with the tools within a certain depth.  Obviously defaulting cgroups kernelArgs into the MC is the right approach, it's just an unfortunate circumstance of bleeding edge.

How will we proceed from here? We do not know of any workaround yet, so probably nobody will be able to upgrade from a previous to the current version. Because to me this looks like a problem that will always happen during this upgrade e.g. does not seem to depend on the cloud provider, for example?
Ah, I see there is a new release of 2023-06-04 - anyone tried to upgrade to this from 4.12 yet? I will only be able to try on Sunday or later.

Updated must-gather with machineconfigs included.  Link is private.
https://drive.google.com/file/d/1OkVpLz2DGq_ZuajFOtSb00M0LUamJSzY/view?usp=sharing

2023-06-08T13:05:03.738973287Z Added:
2023-06-08T13:05:03.738973287Z   duktape-2.7.0-2.fc38.x86_64
2023-06-08T13:05:03.738973287Z   kernel-headers-6.2.6-300.fc38.x86_64
2023-06-08T13:05:03.738973287Z   kernel-modules-core-6.2.9-300.fc38.x86_64
2023-06-08T13:05:03.738973287Z   libunistring1.0-1.0-1.fc38.x86_64
2023-06-08T13:05:03.738973287Z   libxdp-1.3.0-1.fc38.x86_64
2023-06-08T13:05:03.738973287Z   rpm-sequoia-1.3.0-1.fc38.x86_64
2023-06-08T13:05:03.741449694Z Changes queued for next boot. Run "systemctl reboot" to start a reboot
2023-06-08T13:05:03.751311192Z I0608 13:05:03.751149    2201 update.go:2025] Running rpm-ostree [kargs --append=systemd.unified_cgroup_hierarchy=0 --append=systemd.legacy_systemd_cgroup_controller=1 --append=systemd.unified_cgroup_hierarchy=1 --append=systemd.legacy_systemd_cgroup_controller=0 --append=mitigations=off --append=intel_pstate=disable]
2023-06-08T13:05:03.760129412Z I0608 13:05:03.759973    2201 update.go:2010] Running: rpm-ostree kargs --append=systemd.unified_cgroup_hierarchy=0 --append=systemd.legacy_systemd_cgroup_controller=1 --append=systemd.unified_cgroup_hierarchy=1 --append=systemd.legacy_systemd_cgroup_controller=0 --append=mitigations=off --append=intel_pstate=disable
2023-06-08T13:05:11.576201748Z Checking out tree aea27d9...done
2023-06-08T13:05:12.107251221Z Resolving dependencies...done
2023-06-08T13:05:12.144767894Z I0608 13:05:12.144557    2201 update.go:2136] Rolling back applied changes to OS due to error: error running rpm-ostree kargs --append=systemd.unified_cgroup_hierarchy=0 --append=systemd.legacy_systemd_cgroup_controller=1 --append=systemd.unified_cgroup_hierarchy=1 --append=systemd.legacy_systemd_cgroup_controller=0 --append=mitigations=off --append=intel_pstate=disable: error: No packages in transaction
2023-06-08T13:05:12.144767894Z : exit status 1

So the error happens after Fedora upgrade is applied and kargs are being applied. Check if removing 99-okd-master-disable-mitigations and 99-okd-worker-disable-mitigations MCs work? These kargs are already set, but MCO is mistakenly trying to apply them again (and probably due to rpm-ostree bug it fails)

2023-06-08T13:05:03.738973287Z Added:
2023-06-08T13:05:03.738973287Z   duktape-2.7.0-2.fc38.x86_64
2023-06-08T13:05:03.738973287Z   kernel-headers-6.2.6-300.fc38.x86_64
2023-06-08T13:05:03.738973287Z   kernel-modules-core-6.2.9-300.fc38.x86_64
2023-06-08T13:05:03.738973287Z   libunistring1.0-1.0-1.fc38.x86_64
2023-06-08T13:05:03.738973287Z   libxdp-1.3.0-1.fc38.x86_64
2023-06-08T13:05:03.738973287Z   rpm-sequoia-1.3.0-1.fc38.x86_64
2023-06-08T13:05:03.741449694Z Changes queued for next boot. Run "systemctl reboot" to start a reboot
2023-06-08T13:05:03.751311192Z I0608 13:05:03.751149    2201 update.go:2025] Running rpm-ostree [kargs --append=systemd.unified_cgroup_hierarchy=0 --append=systemd.legacy_systemd_cgroup_controller=1 --append=systemd.unified_cgroup_hierarchy=1 --append=systemd.legacy_systemd_cgroup_controller=0 --append=mitigations=off --append=intel_pstate=disable]
2023-06-08T13:05:03.760129412Z I0608 13:05:03.759973    2201 update.go:2010] Running: rpm-ostree kargs --append=systemd.unified_cgroup_hierarchy=0 --append=systemd.legacy_systemd_cgroup_controller=1 --append=systemd.unified_cgroup_hierarchy=1 --append=systemd.legacy_systemd_cgroup_controller=0 --append=mitigations=off --append=intel_pstate=disable
2023-06-08T13:05:11.576201748Z Checking out tree aea27d9...done
2023-06-08T13:05:12.107251221Z Resolving dependencies...done
2023-06-08T13:05:12.144767894Z I0608 13:05:12.144557    2201 update.go:2136] Rolling back applied changes to OS due to error: error running rpm-ostree kargs --append=systemd.unified_cgroup_hierarchy=0 --append=systemd.legacy_systemd_cgroup_controller=1 --append=systemd.unified_cgroup_hierarchy=1 --append=systemd.legacy_systemd_cgroup_controller=0 --append=mitigations=off --append=intel_pstate=disable: �[0m�[31merror: �[0mNo packages in transaction
2023-06-08T13:05:12.144767894Z : exit status 1

So the error happens after Fedora upgrade is applied and kargs are being applied. Check if removing 99-okd-master-disable-mitigations and 99-okd-worker-disable-mitigations MCs work? These kargs are already set, but MCO is mistakenly trying to apply them again (and probably due to rpm-ostree bug it fails)

I have removed these machineconfigs. The results are the same.  Even running the rpm-ostree kargs --append command manually results in the error.

I have success.
I had a power outage briefly that resulted in kubelet failing to start on the 2 stuck nodes.  I ended up finding and following this kba to change protectKernelDefaults to false manually on the node's /etc/kubernetes/kubelet.conf.  Turns out, my kargs applied successfully after I did this and my 2 stuck nodes upgraded
On my stuck nodes:

kubelet was stopped due to error
Edited /etc/kubernetes/kubelet.conf and changed protectKernelDefaults to false (existed, but was previously true)
Touched /run/machine-config-daemon-force to force the update due to my corrupted files
Started kubelet
The upgrade picked up, appended the kArgs, and rebooted into F38
Success

On untouched nodes that hadn't updated yet and weren't stuck:

stop kubelet
Edited the /etc/kubernetes/kubelet.conf and ADD the protectedKernelDefaults: true (in the top-most level of the json map, or yaml)
start kubelet
?? fiddle with nodes, machineconfigs, etc if necessary, force the update by touching the file
Success

It seems easy, but I had to fiddle with things a bit just to get the ordering of the apply to take.
You could add a custom kubelet if you feel like it, but this value appears to be set to true by OKD.
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: worker-protect-kernel-defaults
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""
  kubeletConfig:
    protectKernelDefaults: false

Unfortunately, it does not work for me. When I edit the kubelet.conf, I then get:
E0613 12:41:00.352372 1785549 daemon.go:662] Preflight config drift check failed: content mismatch for file "/etc/kubernetes/kubelet.conf"
E0613 12:41:00.352387 1785549 writer.go:200] Marking Degraded due to: content mismatch for file "/etc/kubernetes/kubelet.conf"

When I then touch the /run/machine-config-daemon-force it proceeds but then falls back into the original problem with the kargs and "no packages in transaction".
Any idea?

Unfortunately, it does not work for me. When I edit the kubelet.conf, I then get:
E0613 12:41:00.352372 1785549 daemon.go:662] Preflight config drift check failed: content mismatch for file "/etc/kubernetes/kubelet.conf"
E0613 12:41:00.352387 1785549 writer.go:200] Marking Degraded due to: content mismatch for file "/etc/kubernetes/kubelet.conf"

When I then touch the /run/machine-config-daemon-force it proceeds but then falls back into the original problem with the kargs and "no packages in transaction". Any idea?

The only thing that worked for me was to:

SSH to the node
Stop kubelet manually
Edit the config
Touch the machine-config-daemon-force file
Start kubelet

That's exactly what I also did but it did not help in the case of my cluster.
What sed commands? When?

That's exactly what I also did but it did not help in the case of my cluster. What sed commands? When?

I don't know if it mattered or not, but during the mc daemon writing the new files to the node, I just did a quick sed -i s/protectKernelDefaults\:\ true/protectKernelDefaults\:\ false/g /etc/kubernetes/kubelet.conf

You mean because otherwise it would already have undone that change. It would explain the behaviour.
But of course, not an easy fix ..

No matter how hard I try - I don't get it past the "no packages in transition" error.
If only I knew more about the stuff and had any idea how to tackle this problem ... :-(
Apparently, at the moment nobody of the OKD team has time to look into this.
As long as that is the case, it means we are stuck at 4.12 2023-04-16 and will be unable to upgrade any further.
I am waiting for 4.13 because of the increased vSphere CSI support (automatic migration) ...

Before rolling back the cluster once again, I at least also pulled a must-gather.
https://domino.ars.de/file/must-gather.local.2721338799474098678.tar.gz

No matter how hard I try - I don't get it past the "no packages in transition" error. If only I knew more about the stuff and had any idea how to tackle this problem ... :-( Apparently, at the moment nobody of the OKD team has time to look into this. As long as that is the case, it means we are stuck at 4.12 2023-04-16 and will be unable to upgrade any further. I am waiting for 4.13 because of the increased vSphere CSI support (automatic migration) ...

Do you have any custom Kubelet.conf being applied in your machineconfigs?

No, nothing at all.

Hi All, Not sure i'm hitting the same issue but my upgrade to 4.13 also broken but with the below message I see in the mcp and machine config
Last Transition Time:  2023-06-14T14:18:49Z
    Message:
    Reason:
    Status:                False
    Type:                  RenderDegraded
    Last Transition Time:  2023-06-14T11:39:16Z
    Message:               Node worker-1-nbg-eu.k8stest.route.net is reporting: "Failed to remove rollback: error running rpm-ostree cleanup -r: \x1b[0m\x1b[31merror: \x1b[0mInvoking cleanup: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code1: Error binding to address (GUnixSocketAddress): No such file or directory\n: exit status 1"
    Reason:                1 nodes are reporting degraded status on sync
    Status:                True

I0614 20:48:04.866827    1726 daemon.go:582] State and Reason: Degraded Failed to remove rollback: error running rpm-ostree cleanup -r: error: Invoking cleanup: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code1: Error binding to address (GUnixSocketAddress): No such file or directory
: exit status 1
I0614 20:48:04.868065    1726 daemon.go:1587] Running: /run/machine-config-daemon-bin/nmstatectl persist-nic-names --root / --inspect
[2023-06-14T20:48:04Z INFO  nmstatectl::persist_nic] /etc/systemd/network/.nmstate-persist.stamp does not exist, no prior persisted state

I0614 20:48:04.911187    1726 daemon.go:1283] Previous boot ostree-finalize-staged.service appears successful
I0614 20:48:04.911235    1726 daemon.go:1387] Current config: rendered-worker-5e41d064ac4bae89092b26688ed0e72f
I0614 20:48:04.911246    1726 daemon.go:1388] Desired config: rendered-worker-5cec028aed9dc6d2319187923a9de4e1
I0614 20:48:04.911251    1726 daemon.go:1390] state: Degraded
I0614 20:48:04.920594    1726 daemon.go:694] Detected a login session before the daemon took over on first boot
I0614 20:48:04.920651    1726 daemon.go:695] Applying annotation: machineconfiguration.openshift.io/ssh
I0614 20:48:04.983986    1726 update.go:2010] Running: rpm-ostree cleanup -r
E0614 20:48:05.076803    1726 writer.go:200] Marking Degraded due to: Failed to remove rollback: error running rpm-ostree cleanup -r: error: Invoking cleanup: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code1: Error binding to address (GUnixSocketAddress): No such file or directory
: exit status 1

I'll be absent now for two weeks. Afterwards I will need to continue to search for a solution.
@vrutkovs, do you have any idea how we could try to solve this problem?

I just ran into the same issue when trying to update an older cluster (which has been upgraded multiple times) from 4.12.0-0.okd-2023-04-16-041331 to 4.13.0-0.okd-2023-05-22-052007. Just managed to get the first master node past this problem by some combination based on https://github.com/okd-project/okd/issues/1614#issuecomment-1584771598 - manually added protectKernelDefaults: false, ran rpm-ostree reset and rebooted the node, also forced an mc upgrade along the way (maybe multiple times). Trying to get better actual steps with the next nodes.
What I don't understand though, is why these kernel args are present at all?
https://docs.okd.io/4.13/nodes/clusters/nodes-cluster-cgroups-okd.html

By default, OKD uses Linux control group version 2 (cgroup v2) in your cluster.

However, these kernel arguments seem to disable cgroup v2 and enforce usage of v1. Having this part of the default config contradicts the documentation, and even is a step "back" from defaults in OKD 4.12 (at least my cluster seemed to run on v2 by default already, as it didn't have these kernel args before)?

so the exact steps that worked for me to get 2 more master nodes out of the broken condition:
started in-between the MCO configuration cycles, i.e. before it attempted to apply the config again. At this point protectKernelDefaults was not present in /etc/kubernetes/kubelet.conf.

systemctl stop kubelet
echo "protectKernelDefaults: false" >> /etc/kubernetes/kubelet.conf
rpm-ostree reset
systemctl reboot
wait for the system to reboot, as soon as it's available again apply the next step
touch /run/machine-config-daemon-force

I waited for the nodes to enter the broken state before applying these, didn't check if applying these commands on not yet updated clean nodes would prevent the issue too.

What I don't understand though, is why these kernel args are present at all?
https://docs.okd.io/4.13/nodes/clusters/nodes-cluster-cgroups-okd.html

By default, OKD uses Linux control group version 2 (cgroup v2) in your cluster.

However, these kernel arguments seem to disable cgroup v2 and enforce usage of v1. Having this part of the default config contradicts the documentation, and even is a step "back" from defaults in OKD 4.12 (at least my cluster seemed to run on v2 by default already, as it didn't have these kernel args before)?

@ssams thank you for commenting.  I agree completely.
I understand there are a lot of issues out there regarding cgroups, as well as folks who started on different versions of OKD having completely different experiences with said issues.  I can only assume that those are reasons why the forcing of cgroupsv1 via kargs is now defaulted.  I also assume that we are in the vast minority with our issues here.

I can only assume that those are reasons why the forcing of cgroupsv1 via kargs is now defaulted.

Oh, wait, this is not intentional. It comes from MCO enforcing v1 for OCP in 4.13 - and accidentally this also gets applied to OKD

Tested the following upgrade path:

4.11.0-0.okd-2023-01-14-152430
4.12.0-0.okd-2023-04-16-041331
4.13.0-0.okd-2023-05-22-052007
4.13.0-0.okd-2023-06-24-145750

and didn't hit this. Next time I'll try to do "earliest 4.11 -> next 4.11 -> .. -> earliest 4.12" and see if specific release in the upgrade path triggers it

Our clusters are much older - these were originally created with 4.6 or 4.7 ...

Our clusters are much older - these were originally created with 4.6 or 4.7 ...

Same.  My cluster was created at 4.7

I can only assume that those are reasons why the forcing of cgroupsv1 via kargs is now defaulted.

Oh, wait, this is not intentional. It comes from MCO enforcing v1 for OCP in 4.13 - and accidentally this also gets applied to OKD

Any plans to revert this unintentional change? I'm waiting to upgrade to 4.13 until this is fixed, as my current clusters have cgroups v2 atm.

Any plans to revert this unintentional change? I'm waiting to upgrade to 4.13 until this is fixed, as my current clusters have cgroups v2 atm.

Even if this is done, it will be difficult. It would only be possible for a future release, not the existing releases, right?
But currently the upgrade graph does not allow to skip 4.13 2023-05-22 ...

I have the same issue, my nodes are also old and have systemd.unified_cgroup_hierarchy=0 (without systemd.legacy_systemd_cgroup_controller=1) which came I assume from /etc/pivot/kernel-args and old 99-okd-master-disable-mitigations (after I deleted this mc it was recreated without the pivot stuff).

This would overwrite kernel args in 01-worker-kubelet MC as these are applied in the lexographical order, so 99- takes precedence:

It gets merged. I even tried setting cgroups:v2 with config.openshift.io/Node and ended up with all the options (v1+v2+mitigations) in final rendered mc kernelArguments. I did not find a way to override this.
Any ideas why "rpm-ostree kargs ..." fails in okd? It runs fine in clean fcos 38.20230414.3.0

ended up with all the options (v1+v2+mitigations) in final rendered mc kernelArguments

What does it mean? Which options were applied on the node in the end? Also, please attach must-gathers, its really hard to fix a bug with vague descriptions (previous attachments have expired, so lets save some time and not make them temporary / private)

I had linked to a must-gather from my case above. The link did expire meanwhile but I renewed it right now. You can have the file again whenever you need it. But I cannot attach it here as it is too big.

Tested clean 4.9 -> ... -> 4.13 upgrade which had cgroupsv1 still - test passed. Seems its for born-in-4.7 clusters, where some repos had to be disabled on the host to work.
Still not sure what protectKernelDefaults has to do with this and why it helps. It looks like "rpm-ostree is in weird state and won't apply kargs" to me

What does it mean? Which options were applied on the node in the end? Also, please attach must-gathers, its really hard to fix a bug with vague descriptions (previous attachments have expired, so lets save some time and not make them temporary / private)

This is new rendered-master/worker from 4.13.0-0.okd-2023-05-22-052007, which fails to apply:
  kernelArguments:
    - systemd.unified_cgroup_hierarchy=0 //01-master-kubelet
    - systemd.legacy_systemd_cgroup_controller=1 //01-master-kubelet
    - systemd.unified_cgroup_hierarchy=1 //97-master-generated-kubelet
    - cgroup_no_v1="all" //97-master-generated-kubelet
    - psi=1 //97-master-generated-kubelet
    - mitigations=off //99-okd-master-disable-mitigations
    - intel_pstate=disable //99-okd-master-disable-mitigations

Current applied one from 4.12.0-0.okd-2023-03-18-084815 has "kernelArguments: []" plus /etc/pivot/kernel-args from https://github.com/openshift/okd-machine-os/commit/f730c6552cec2b5ede20c9413de0d0e9639d4ac0

It looks like "rpm-ostree is in weird state and won't apply kargs" to me

Yes, looks like rpm-ostree issue to me. MC does not really matter here, as rpm-ostree will not apply anything.
[core@okd-master-1 ~]$ sudo rpm-ostree kargs --append=x=y
Jul 11 18:53:32 okd-master-1 systemd[1]: Starting rpm-ostreed.service - rpm-ostree System Management Daemon...
Jul 11 18:53:32 okd-master-1 rpm-ostree[356008]: Reading config file '/etc/rpm-ostreed.conf'
Jul 11 18:53:32 okd-master-1 rpm-ostree[356008]: In idle state; will auto-exit in 64 seconds
Jul 11 18:53:32 okd-master-1 systemd[1]: Started rpm-ostreed.service - rpm-ostree System Management Daemon.
Jul 11 18:53:32 okd-master-1 rpm-ostree[356008]: client(id:cli dbus:1.2704 unit:session-5.scope uid:0) added; new total=1
Jul 11 18:53:32 okd-master-1 rpm-ostree[356008]: Loaded sysroot
Jul 11 18:53:32 okd-master-1 rpm-ostree[356008]: Locked sysroot
Jul 11 18:53:32 okd-master-1 rpm-ostree[356008]: Initiated txn KernelArgs for client(id:cli dbus:1.2704 unit:session-5.scope uid:0): /org/projectatomic/rpmostree1/fedora_coreos
⠁ Checking out tree aa5e914...
Jul 11 18:53:32 okd-master-1 rpm-ostree[356008]: Process [pid: 356004 uid: 0 unit: session-5.scope] connected to transaction progress
Jul 11 18:53:32 okd-master-1 rpm-ostree[356008]: Librepo version: 1.15.1 with CURL_GLOBAL_ACK_EINTR support (libcurl/7.87.0 OpenSSL/3.0.8 zlib/1.2.13 libidn2/2.3.4 nghttp2/1.52.0)
Checking out tree aa5e914... done
Resolving dependencies... done
error: No packages in transaction
Jul 11 18:53:35 okd-master-1 rpm-ostree[356008]: Preparing pkg txn; enabled repos: [] solvables: 0
Jul 11 18:53:35 okd-master-1 rpm-ostree[356008]: Txn KernelArgs on /org/projectatomic/rpmostree1/fedora_coreos failed: No packages in transaction
Jul 11 18:53:35 okd-master-1 rpm-ostree[356008]: Unlocked sysroot
Jul 11 18:53:35 okd-master-1 rpm-ostree[356008]: Process [pid: 356004 uid: 0 unit: session-5.scope] disconnected from transaction progress
Jul 11 18:53:35 okd-master-1 rpm-ostree[356008]: client(id:cli dbus:1.2704 unit:session-5.scope uid:0) vanished; remaining=0
Jul 11 18:53:35 okd-master-1 rpm-ostree[356008]: In idle state; will auto-exit in 63 seconds
[core@okd-master-1 ~]$

I have no idea how to debug rpm-ostreed, it does not seem to have any debug options/logs.

This is new rendered-master/worker from 4.13.0-0.okd-2023-05-22-052007, which fails to apply:

Ah, okay, only the last one will be in effect anyway.
I assume your cluster is also born-in-4.7? I wouldn't have to ask this silly question if you'd link to a must-gather though

4.5.0-0.okd-2020-07-14-153706-ga | Jul 16, 2020, 4:32 PM
I did not upload must-gather, to not mislead anyone in case it's broken somehow over the years. Also must-gather from others seem to cover this.

Okay, I'll try if 4.7 is still installable and can get to 4.13 today.

enabled repos: []

This is weird. On 4.11 upgrade it should have Fedora repos enabled in /etc/yum.repos.d. Could you check that repo files are there and standard (at least fedora and fedora-updates) are enabled?
Also, what's the output of rpm-ostree status? Maybe it got stuck in some transaction

rpm-ostree status -bv
State: idle
AutomaticUpdates: disabled
BootedDeployment:
● ostree-unverified-registry:quay.io/openshift/okd-content@sha256:aed14445e978d17b40bd2a353efea0bff7231c3327ec767cb0abda99f65aa107 (index: 0)
                   Digest: sha256:aed14445e978d17b40bd2a353efea0bff7231c3327ec767cb0abda99f65aa107
                  Version: 38.20230414.3.0 (2023-07-07T14:19:46Z)
                   Commit: aa5e914e7b920ac897ba3a2ebbd39569a170e97cb9b09f675dff6727af6143ee
                   Staged: no
                StateRoot: fedora-coreos
         InactiveRequests: NetworkManager-ovs qemu-guest-agent

I did not like InactiveRequests there, so I did "sudo rpm-ostree uninstall NetworkManager-ovs qemu-guest-agent && sudo systemctl reboot" and this seems to fix the issue with "rpm-ostree kargs". Update to 4.13.0-0.okd-2023-05-22-052007 finished successfully.
My kargs after update to 4.13.0-0.okd-2023-05-22-052007
systemd.unified_cgroup_hierarchy=0 console=tty0 console=ttyS0,115200n8 $ignition_firstboot ostree=/ostree/boot.1/fedora-coreos/d2605fec211df3ea8a588c4fbc6c881a8a1ea85f33b2c52eb62e469ff6a25622/0 ignition.platform.id=vmware systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller=1 mitigations=off intel_pstate=disable
And after switching to cgroupMode:v2
console=tty0 console=ttyS0,115200n8 $ignition_firstboot ostree=/ostree/boot.1/fedora-coreos/d2605fec211df3ea8a588c4fbc6c881a8a1ea85f33b2c52eb62e469ff6a25622/0 ignition.platform.id=vmware systemd.unified_cgroup_hierarchy=0 systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller=1 systemd.unified_cgroup_hierarchy=1 cgroup_no_v1="all" psi=1 mitigations=off intel_pstate=disable

I did not like InactiveRequests there

InactiveRequests is fine, it means "previously we requested to overlay packages (in 4.7) but now they are provided as part of the image". That's weird that it was the culprit.
@kai-uwe-rommel @BonzTM could you check that sudo rpm-ostree uninstall NetworkManager-ovs qemu-guest-agent && sudo systemctl reboot is the workaround which unblocks setting kargs?

Will test as soon as I can - probably tomorrow in the evening.

I did not like InactiveRequests there

InactiveRequests is fine, it means "previously we requested to overlay packages (in 4.7) but now they are provided as part of the image". That's weird that it was the culprit.
@kai-uwe-rommel @BonzTM could you check that sudo rpm-ostree uninstall NetworkManager-ovs qemu-guest-agent && sudo systemctl reboot is the workaround which unblocks setting kargs?

My cluster is in a functioning state and has gone through several upgrades already without issue.  I do not wish to change anything at the moment, but am watching this thread.
My cluster is born-in-4.7 and I was able to workaround the issue by forcing protectKernelDefaults as some of my comments/replies above suggest.

seems similar to https://github.com/coreos/rpm-ostree/issues/1733

Oops, I just saw you meant "rpm-ostree status -bv" and not just "rpm-ostree status".
It also shows the InactiveRequests now:
[root@master-01 ~]# rpm-ostree status -bv
State: idle
AutomaticUpdates: disabled
BootedDeployment:
● ostree-unverified-registry:quay.io/openshift/okd-content@sha256:53abd41811f53c940ac41dc8b9d5475813d9c96e20ce893c8664ba951044d6a3 (index: 0)
                   Digest: sha256:53abd41811f53c940ac41dc8b9d5475813d9c96e20ce893c8664ba951044d6a3
                  Version: 37.20230322.3.0 (2023-04-20T08:58:49Z)
                   Commit: 2d52598c70acd966234f822dcde09af2f1264b006ba6ff836469d8a3a324e8fa
                   Staged: no
                StateRoot: fedora-coreos
         InactiveRequests: NetworkManager-ovs qemu-guest-agent
[root@master-01 ~]#

I'lls try the suggested workaround now.

So it looks good, the workaround ("rpm-ostree uninstall NetworkManager-ovs qemu-guest-agent") seems to cure the issue. The three master nodes are now updated.
The first worker node was stuck for a while at reboot time for some other problem (stale pod, couldn't remove one of its directories because not empty) so I had to fix that but now it is updated as well and the MCD is progressing to the next worker. I assume the rest of the workers will update fine as well.

As expected, the cluster upgrade went fine. I even upgraded already another cluster the same way.
Thanks to @tvanderka and @vrutkovs for finding out!

Excellent, I'm going to close this as this seems to be an rpm-ostree bug (not sure if its worth filing as its unclear how to reproduce this).

Are InactiveRequests a common szenario? I have no idea.
Especcially in combination with someone attempting to change kargs.

Yeah, InactiveRequests is common - i.e. additional package was requested, but then it was included in the base so it becomes inactive. I can't think of a valid way for it to interfere with kargs

@vinisman Show us the output of a "rpm-ostree status -v" (run as root) on one of your nodes.

rpm-ostree status -v

Hi! Look please:
State: busy
AutomaticUpdates: disabled
Transaction: rebase --experimental 'ostree-unverified-registry:quay.io/openshift/okd-content@sha256:aed14445e978d17b40bd2a353efea0bff7231c3327ec767cb0abda99f65aa107'
  Initiator: client(id:machine-config-operator dbus:1.345 unit:crio-a3475d45ecfda94f093aba54c715949907e60274f473c01eb29bdc316c9aaca2.scope uid:0)
Deployments:
● ostree-unverified-registry:quay.io/openshift/okd-content@sha256:53abd41811f53c940ac41dc8b9d5475813d9c96e20ce893c8664ba951044d6a3 (index: 0)
                   Digest: sha256:53abd41811f53c940ac41dc8b9d5475813d9c96e20ce893c8664ba951044d6a3
                  Version: 37.20230322.3.0 (2023-10-09T15:10:36Z)
                   Commit: 2037cb5ed19a0ade53891fd8dedafcf3e01c19613997379d6bef600b1fd9b201
                   Staged: no
                StateRoot: fedora-coreos
         InactiveRequests: qemu-guest-agent

Since you only have to remove qemu-guest-agent, only a "rpm-ostree uninstall qemu-guest-agent" should be needed and a reboot.

rpm-ostree uninstall qemu-guest-agent

Interesting behavior, only for one problem node it does not help. I had to delete it. The remaining nodes were updated successfully, for some helps "rpm-ostree uninstall qemu-guest-agent and systemctl reboot"

authors: BonzTM LorbusChris aneagoe aschufft balait4 kai-uwe-rommel ssams tvanderka vinisman vrutkovs

repo: okd-project/okd


text:
Sosiaalinen media (iconit) ja logot kuntoon.

Tarvitaan logo avoimelle rajapinnalle.

En näe mitään tarvetta tällaiselle varsinkaan kun Issue:ssa ei ole mitenkään perusteltu tätä tai logojen tai ikonien käyttöä. Tässä on kai kyse siis rajapintamäärityksestä, eikä mistään brändättävästä tuotteesta tai myytävästä palvelusta..

Määrityksen jalkauttaminen on ihan keskeinen osa hommaa ja siinä varmasti myös some-kanavilla on oma roolinsa. Ei varmaankaan mikään high-priority juttu, mutta en nyt sulkisi kuitenkaan.

Mä en oikeen ymmärrä mitä @Mygee tarkoitat näillä: "sosiaalinen media (iconit)" ja "logot". Ja milloin ne olisivat kunnossa (eli siis definition of done)?

gh-pages branch sisältää _config.yml -tiedoston, jossa määritetään käytössä olevalle teemalle kolmannen osapuolen verkkopalveluiden osoitteet. Niitä ei kuitenkaan ole vielä tällä hetkellä näkyvissä ulkoasussa.
Palveluiden linkit / kuvakkeet tulevat tällä hetkellä _includes/header.html -tiedostossa määriteltyyn kohtaan.
Jostakin syystä _config.yml -tiedostossa oleva display-social-icons: true -muuttuja ei toimi oikein, joten pitäisi selvittää mistä niiden näkymättömyys johtuu.

Tarkoittaako tää siis FB- ja Twitter-sharebuttoneita. Musta ne on aika lameja. En usko, että meidän kohderyhmä tarvii niitä ja lisäks ne vielä träkkää ihmisten nettikäyttymistä. Multa saa tarvittaessa itetehdyt JavaScript-funktiot, jotka tekee jakamisen noita (ja träkkäämistä) ilman. Mutta en usko, että tarvitaan. Sen sijaan on tärkeää, että og-metadatat sun muut on kunnossa, että some-jakaminen näyttää hienolta.

Samaa mieltä siitä että jakonapit ovat usein aika turhia. Kyllä suurin osa ihmisistä osaa kopioida URL-osoitteen osoiteriviltä, jos todella tahtovat sivun jakaa eteenpäin.

Ok. Suljen issuen.

repo: okffi/open-api-definition


text:
Add first tests

What this PR does / why we need it:
Create a few tests using cypress
Which issue this PR fixes:
fixes #625
Special notes for your reviewer:
Adding Cypress caused an update on Bootstrap which didn't cause any issues with the theme but I'm gonna investigate it further. Also I'm gonna migrate a few other tests and add more tests for the functionality. Most tests that I've written test the core functionality not user interactions or styling. I'll add more tests in that area moving forward.
Release note:
- We now have automated tests to keep from breaking things.

For something like this splitting of the bootstrap update into its own commit would be great. Even so merging the update in with e2e tests feels problematic for future reference.

Also the bootstrap update was more of a downgrade from v4.3.1 to v4.1.3, which does make this a merge blocker in general.

I had removed the cypress starter files. Can't remember what happened. They shouldn't be here. I'll remove them. Also the bootstrap trick is something else that cypress did. Didn't check the diff. Sorry.

I resolved to force pushing this one. Removed useless files, reverted bootstrap downgrade, merged master into the branch and pushed it again.

authors: mpourismaiel stp-ip

repo: okkur/syna


text:
Folder name with space breaks lint

Description
Hi,
faced with an issue: when folder contains space in it's name, e.g Test Projects, lint beaks with error:
project path is /Users/username/Test Projects/good_chat.
➜  good_chat git:(master) ✗ yarn lint-staged
yarn run v1.3.2
$ $(yarn bin)/lint-staged
/bin/sh: /Users/username/Test: No such file or directory
error Command failed with exit code 127.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

However, if the folder will be named "TestProjects" the package works like a charm.
Sorry if it doesn't concern this package.
Steps to reproduce
Make a folder with bad name, run lint-staged in it.
Environment

OS: macOS 10.13.3
Node.js: 9.5.0
lint-staged: 4.3.0

Thanks for submitting and I think it concerns the package a lot! Do you want to try fixing it and submit a PR? I think the problem is with how we pass file paths to commands. Probably we'll need to wrap them into parenthesis or do something else.

I'd like to make a PR but I don't quite understand how the package works. I've had a look the code and haven't been able to identify where the error could be (I'm new to node.js ecosystem).
I've cloned repo and tried to run the code like this:
➜  good_chat git:(master) node ../../../GitHub/lint-staged/index.js
 ↓ Running tasks for config/webpack/**/*.js [skipped]
   → No staged files match config/webpack/**/*.js
 ↓ Running tasks for frontend/**/*.js [skipped]
   → No staged files match frontend/**/*.js
 ↓ Running tasks for frontend/**/*.css [skipped]
   → No staged files match frontend/**/*.css

and it worked! And now it's a bit confusing.

@shiroginne Could you please add a --debug flag for lint-staged and share the debug output? You'd need to update to the latest version, v6.0.0 as well.

I have tried this on Windows as well as linux and I did not face any issue. @okonet, @luftywiranda13 Could you check if you are able to reproduce the issue on mac?

I've installed lint-staged into global scope, and it worked. The problem appeared only when I use yarn lint-staged from project folder. Maybe it's not a problem at all

I tried to reproduce the bug, since I am using the exact same system and yarn versions.

Set up an empty project in a folder /Users/cstuff/Workspace/Test Project
Initalized npm with the following packages:

"eslint": "^4.18.2",
"eslint-config-airbnb-base": "^12.1.0",
"eslint-plugin-import": "^2.9.0",
"husky": "^0.14.3",
"lint-staged": "4.3.0"

Set up lint-staged as follows in package.json:

"lint-staged": {
	"*.js": ["eslint"]
}

Produced fake JS file ìndex.js`:

export default {
	a: 'b'
};

Ran yarn lint-staged

yarn run v1.3.2
warning package.json: No license field
$ '/Users/cstuff/Workspace/Test Project/node_modules/.bin/lint-staged'
 ❯ Running tasks for *.js
   ✖ eslint
✖ eslint found some errors. Please fix them and try committing again.

/Users/cstuff/Workspace/Test Project/index.js
  2:1  error  Expected indentation of 2 spaces but found 1 tab  indent
  2:2  error  Unexpected tab character                          no-tabs
  2:8  error  Missing trailing comma                            comma-dangle

✖ 3 problems (3 errors, 0 warnings)
  2 errors, 0 warnings potentially fixable with the `--fix` option.

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Nothing unusual here. Spaces work just fine.

Thanks @Regaddi! Closing the issue.

authors: Regaddi okonet shiroginne sudo-suhas

repo: okonet/lint-staged


text:
When login it throws an error

Hi ,
I was able to connect okta with the angular app. The problem is that when complete the fields with valid values and click on login, the web page throws this error. The thing is that if I refreshed the page it is logged in correctly.
authorize?client_id=0oae36zsdrQjLSLWY0h7&redirect_uri=http%3A%2F%2Flocalhost%3A4200&response_type=id_token&response_mode=okta_post_message&state=c3oxtbKHlYuxCYRD4PEB18ZApDWFciheNMfp8eb2oSa940T0DxoNls0BQoLCSucs&nonce=UX9THrM6D1srrFGcrnAAt913nJ7kO0n6lSWWULazCgEtqLw9iLsBb6exxUgInztk&prompt=none&sessionToken=20111VypeI7P0zj_9TvO6enb8xPxhJOV2eQ7-hyRMmbSsSFKBQYuDdu&scope=openid email:42 error.errorCode: invalid_request, error.description: The authorization server id is invalid.
onWindowLoadHandler @ authorize?client_id=0oae36zsdrQjLSLWY0h7&redirect_uri=http%3A%2F%2Flocalhost%3A4200&response_type=id_token&response_mode=okta_post_message&state=c3oxtbKHlYuxCYRD4PEB18ZApDWFciheNMfp8eb2oSa940T0DxoNls0BQoLCSucs&nonce=UX9THrM6D1srrFGcrnAAt913nJ7kO0n6lSWWULazCgEtqLw9iLsBb6exxUgInztk&prompt=none&sessionToken=20111VypeI7P0zj_9TvO6enb8xPxhJOV2eQ7-hyRMmbSsSFKBQYuDdu&scope=openid email:42
Do you know what I an doing wrong?

What's the error that the page is throwing?

I was able to fix it. It was related to a wrong Okta configuration. Can close this issue.

authors: agustincelentano nbarbettini


text:
Import journals to ojs.io

[x] Import journals 1008, 5261 , 5001, 1007
[x] Import article file statistics
[x] Download article / issue files to server
[x] Import issue images.

i can't find supplementary files download link on dergipark. i guess, supplementary files not shown on article detail page. it's related only review process. i can't find how to import this files.

I found! and fix it in there https://github.com/okulbilisim/ojs-tools-bundle/commit/524d1f2a227b90183b97585d5b4f8b3a379c6f47

repo: okulbilisim/ojs


text:
3rd age pick / axe not giving bonuses

On BSO,
When going to mine, cut logs, etc. 3rd age pick and axe are no longer giving correct bonuses to activity. Watched Veras unequip and equip axe while re-attempting sulliusceps, and then tg03 attempt coal several times.
That's all. Cheers - thanks for yalls work on the bot.

resolved

authors: Centennials Lajnux

repo: oldschoolgg/oldschoolbot


text:
Raw Queries

I want to write one select query.
Is there a way to write the query raw?

You can create instance of the class OHMySQLQueryRequest.

Let me know whether it works for you.

authors: beatscode oleghnidets

repo: oleghnidets/OHMySQL


text:
chore(main): release 0.9.0

:robot: I have created a release beep boop
0.9.0 (2024-08-12)
Features

enable nginx-more metrics (3048828)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.9.0
:sunflower:

repo: oleksii-honchar/nginx-reverse-proxy


text:
Slighly less ugly build paths

Here's one modest improvement to the elegance.... npm is able to pick out the local copy of uglify, but apparently only if it's run through a script defined in package.json. Still not amazing.... thoughts?
https://lostechies.com/derickbailey/2012/04/24/executing-a-project-specific-nodenpm-package-a-la-bundle-exec/

Beautiful.

authors: oliver-moran strandedcity

repo: oliver-moran/jimp


text:
Controlling HomeKit devices possible?

Hi,
Not really an issue, but more like a question: I have a electrical plug that I control via HomeKit (Elgato Eve), is it possible to also control it via node-red? If so, how would you suggest approaching this?
Thanks,
Christoph

I want to do something similar, get data from Homekit to use in Node-red. My guess is that you need an automation in Homekit. In your case you would need a status input or sensor that can be read by Homekit and to cause an action through an automation. I can't test this as I don't have a home hub and while some automations work they aren't possibly reliable without the home hub and not a good base for testing.
If this does work we really need a whole host of 'reverse' devices in Node-red to mirror real ones in Homekit. Also perhaps someone would test the theory and post some examples?

It's simple.  Create a switch in NR which you can see in Homekit.  You should be able to turn it on or off either via HK or NR.
In Homekit create two automations -- "An Accessory is Controlled" -- one for "turns on" and one for "turns off", and then have your electrical plug (or whatever) mirror the state.
A bit of a pain in the arse, and slightly laggy sometimes, but it works :)

Is there alot of interest in this feature?  Am thinking of creating this based on my homebridge-alexa plugin.

I think it would be good to add this feature here as it would help to omit HomeKit Hub requirement for automation.
@NorthernMan54 are you working on solution for this?
Do you want to cooperate?

I have been playing with this for a bit and have this as an Alpha level code base, which allows control of all Homebridge devices.
https://github.com/NorthernMan54/HAP-NodeRed

I think Nick Farina's HomeBridge is the most comprehensive solution for that. But the approach is different. You have another piece of services outside Node-Red and Home.app to manage.

Abandoned.

authors: NorthernMan54 Shaquu TheOriginalMrWolf cburgdorfer djiwondee lespatots


text:
issue with parameters passed by onChangeIndex

The API docs for onChangeIndex show it is called with function(index, fromIndex) but it doesn't seem to work properly for me. I am a bit of a noob so maybe I'm not understanding it but I did dig through the code to try to figure it out. Here's what I see:
this.props.onChangeIndex() is called in a number of different files but sometimes it is called with one parameter this.props.onChangeIndex(indexNew); and other times with two this.props.onChangeIndex(indexNew, indexLatest); . Am I correct in asserting the API will not always pass the fromIndex parameter? If so, is this maybe a bug because shouldn't onChangeIndex only fire when the index changes from something to something else?
Also I don't think those two parameters have the correct meaning when passed anyway.
In the handleTouchEnd function of both the index.native.antimated and SwipeableViews.js you have the variables:
indexNew, indexCurrent, and indexLatest
indexNew gets assigned
    if (Math.abs(this.vx) > this.props.threshold) {
      if (this.vx > 0) {
        indexNew = Math.floor(this.state.indexCurrent);
      } else {
        indexNew = Math.ceil(this.state.indexCurrent);
      }
    } else {
      // Some hysteresis with indexStart
      if (Math.abs(this.indexStart - this.state.indexCurrent) > 0.6) {
        indexNew = Math.round(this.state.indexCurrent);
      } else {
        indexNew = this.indexStart;
      }
    }

then sometime later this.setState is used to give indexCurrent and indexLatest the value of indexNew
    this.setState({
      indexCurrent: indexNew,
      indexLatest: indexNew,
      isDragging: false,
    },

and just a couple lines later in the setState callback indexNew is checked to see if it matches indexLatest
, () => {
      if (this.props.onSwitching) {
        this.props.onSwitching(indexNew, 'end');
      }

      if (this.props.onChangeIndex && indexNew !== indexLatest) {
        this.props.onChangeIndex(indexNew, indexLatest);
      }
    });

but how would they ever not be the same?
There is a good chance I just don't understand something about React or ES6 correctly.

@funkyeah You are right, the API isn't consistent. Can you have a look at https://github.com/oliviertassinari/react-swipeable-views/pull/58? It should improve this.

It looks like it should work to me. I'll be happy to give it a test when you want.
The only thing that looked a little fishy to me is the use of this.state.indexCurrent which often appears to be a duplication of this.state.indexLatest in https://github.com/oliviertassinari/react-swipeable-views/blob/standardize-onChangeIndex/src/SwipeableViews.js#L245
Although that is not always the case in other files. I guess it's just a little hard to understand what they are supposed to mean at all times... but probably still functioning correctly.

Well indexStart and indexCurrent are used for different purposes.

indexStart is for adding some hysteresis.
indexCurrent is for reflecting the swipe position at the next render.

You raised some good points. I could have added some comment to be more explicit. Are even better test them.

I wouldn't go that for. I would say my points are OK at best. I'm more just pointer to things that are hard for me to understand, which only means that they are hard for a total beginner to understand, not that anything is necessarily wrong.
Anyhoo, thanks for doing this project. I'm trying to use it in a react native app to setup gmail like swipe row items... basically the swipe to archive feature but instead swipe to mark as done. So the event API is what I'm depending on.

authors: funkyeah oliviertassinari

repo: oliviertassinari/react-swipeable-views


text:
Support model allenai/OLMoE-1B-7B-0924

i want check performance this model(MoE)

+1

repo: ollama/ollama


text:
[BUG] 2022.2.0.dev20220109

On the newest devs of HA the integration isnt't loading anymore. The same happened to the node-red integration. Also it cant be found anymore in the store of Hacs when searching for it.

This is a HACS issue, see #261. Please close this issue if updating HACS fix the issue.

Yup that did it. Sorry about that!


text:
🛑 MediaNet is down

In 0012f07, MediaNet (https://medianet-pa.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MediaNet is back up in a382af1.

repo: olmloa/upptime


text:
Proxy support?

Hi, great project. I'm considering a rewrite of my existing scraper in scrapy but i can't seem to find any proxy support in the docs. Is there a way to customize the request to go through a proxy?

Thanks for feedback @Ziinc! I have planned to add proxy support to Crawly. If it could help you to choose Crawly over Scrapy, I would re-prioritize this work to deliver it faster.
Please also let me know if you need any other support.

Proxy support would be awesome, but there's not pressing need for it right now, I'll give crawly a spin for sites that don't need a proxy.
Do you have a roadmap of future releases?

Yes, I have a plan. Actually, I am working on two big things:

Cookies support
Robots.txt fixes (the current third party lib Gollum, has several bugs I want to resolve)

But proxy support can be easily added. So I will do it before the planned tasks

@Ziinc The proxy support is available now!
Could you please give it a try, to see if I can do anything on the top of it?

authors: Ziinc oltarasenko

repo: oltarasenko/crawly


text:
[docs] Rewrite INSTALL.md

Add actual instructions for desktop/android/ios.

@vng @int02h could you please validate updated instructions?

Thanks, @andrewshadura! Have you tried to build the app by using these instructions?

! Have you tried to build the app by using these instructions?

Not yet, but I certainly will.

Need to mention how to install qt && cmake on Mac.

@vng @biodranik please take a quick look. I try to actualize the build documentation based on my newbie experience.

Updated according to comments.

authors: andrewshadura rtsisyk

repo: omapsapp/omapsapp


text:
🛑 OME contributing (redirected) is down

In 1018696, OME contributing (redirected) (https://www.openmicroscopy.org/site/support/contributing/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: OME contributing (redirected) is back up in 56a3bb1 after 22 minutes.

repo: ome/upptime


text:
Fix Floor proto

Address #304:

Floor PROTO instances in humanoid_sprint.wbt are outdated
texture mapping in Floor PROTO is wrong and displays mirrored textured

test me

Build Failed :confused:
https://cyberbotics2.cyberbotics.com:8443/job/Webots/537/consoleText

test me

Build Failed :confused:
https://cyberbotics2.cyberbotics.com:8443/job/Webots/538/consoleText

test me

Build Passed :ok_hand:
You can safely merge 'fix-floor-proto' into 'develop'.

test me

Build Passed :ok_hand:
You can safely merge 'fix-floor-proto' into 'develop'.

:+1:

:eyes:

repo: omichel/webots


text:
setup containers with releases

This is part 1 of work that needs to be done to move our deployment towards OTP releases.
All images are based on Alpine 3.8 - https://github.com/omisego-images/docker-elixir-omg
Integration tests run towards custom alpine with geth and solc. It would be good to move away from this model though.
Processes and flows have been adjusted in a way similar to eWallet... thanks @sirn !!! But with separate repositories so that we're not coupled with their work.

Coverage remained the same at 81.373% when pulling 02bca5b829857d8f330dda5f51acd607d345bcc1 on 579-publish_release_docker into 4013969dc8b5e575041f9b1da9980c5ae0c9fbc2 on master.

Will this still allow for ENVs to be collected at runtime? Presumably this clears the way for Distillery releases too?

Will this still allow for ENVs to be collected at runtime? Presumably this clears the way for Distillery releases too?

Yes @jbunce the work that applies ENVs has been done via Config Providers (more about them here https://hexdocs.pm/distillery/extensibility/config_providers.html). In code, they can be observed as OMG.Eth.ReleaseTasks.SetContract. These modules (https://github.com/omisego/elixir-omg/blob/master/rel/config.exs#L42) kick in just before the application release starts, does what you tell it to do and applies the configuration.

authors: InoMurko coveralls jbunce

repo: omisego/elixir-omg


text:
Multi-line notes are improperly formatted

Related to https://github.com/omnivore-app/obsidian-omnivore/issues/23 but for notes
When a multi-line note is rendered inside a quote block it ignores the new lines within the note so no new >  are inserted and the formatting looks wrong

The first line is displayed inside the quote block but the following ones don't add a >  per new line so anything after the first line is badly formatted

This is the template I'm using:
# {{{title}}}
{{{#description}}}
{{{description}}}
{{{/description}}}
{{#highlights.length}}
## Highlights

{{#highlights}}
> [!QUOTE]+ Highlighted on {{{dateHighlighted}}}
>
> {{{text}}} [⤴]({{{highlightUrl}}}) {{#labels}} #{{name}} {{/labels}} ^{{{highlightID}}}
{{#note}}

> {{{note}}}
{{/note}}

{{/highlights}}
{{/highlights.length}}

It is inspired off the Raindrop Highlights plugin that uses this Nunjucks template:
{% if is_new_article %}# {{title}}
{% if excerpt %}
{{excerpt}}
{% endif %}
## Highlights
{% endif -%}{% for highlight in highlights %}
{% if highlight.color == "red" -%}
    {%- set callout = "danger" -%}
{%- elif highlight.color == "blue" -%}
    {%- set callout = "info" -%}
{%- elif highlight.color == "green" -%}
    {%- set callout = "check" -%}
{%- else -%}
    {%- set callout = "quote" -%}
{%- endif -%}
> [!{{callout}}]+ Updated on {{highlight.lastUpdate}}
>
> {{highlight.text.split("\n") | join("\n>")}}
{% if highlight.note -%}> > {{highlight.note + "\n"}}{%- endif %}

{%- endfor -%}

👍

authors: Thiago-Morais levidcd

repo: omnivore-app/obsidian-omnivore


text:
Update SwiftSyntax support range

Motivation is the same with https://github.com/omochi/CodegenKit/pull/9 .

SwiftTypeReaderはCodegenKitと違ってswift-syntaxの機能をしっかり使うので、"509.0.0"..<"600.0.0"くらいにとどめておいたほうがいいかもしれない？

ここで説明されてますね。
targetに対してcanImportできる風だけど、
これはマクロのビルドが特殊だから？
それとも SwiftTypeReaderのような通常のライブラリでもできる？
https://github.com/apple/swift-syntax/blob/main/Sources/SwiftSyntax/Documentation.docc/Macro Versioning.md

canImportによる分岐ができるのは、以下のような感じで
https://github.com/apple/swift-syntax/blob/30358074c1d8031d9aa8c540d180d861798e5f26/Package.swift#L142-L157
単にダミーのターゲットが存在するかどうかのアドホックな対応だと思います。

試してみたところ、確かに import SwiftSyntax509 とか書いてコンパイルはできるので、
productとして公開されていない孫ターゲットも、依存元プロジェクトのコードから判定に使えそう。
つまりマクロと同じ方法でクロスバージョンに実装できそう。
困ったらこの技を使う想定で、クロスバージョンサポートをやってみることにしましょうか。

authors: omochi sidepelican

repo: omochi/SwiftTypeReader


text:
ISSUE: play button while debugging skips all the following breakpoints

It is not working as the play and pause (F5) button of the debugging controls, it just skips everything.

pressing F5 also skips all the remaining breakpoints


text:
:recycle: Explicitly state exported flag on manifest

Android API 31 and above requires this.

Looking at this @issyzac  and why the build is failing

@ekigamba am seeing its missing mapbox and that was added as a module dependency in the project

Yea, mapbox dependency requires authentication and I had already configured it. I'm not sure what has changed that the current access key returns a 401. I'll need to test locally also

Sure thing

authors: ekigamba issyzac

repo: onaio/kujaku


text:
cron job sidekiq error

ERROR: CRON JOB: can't convert Rufus::Scheduler::ZoTime into an exact number
2016-12-07T08:37:16.663Z 54023 TID-ove97gil0 ERROR: CRON JOB: /Users/tangwei1/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/activesupport-4.2.4/lib/active_support/core_ext/time/calculations.rb:232:in `-'

this is already fixed in master
@ondrejbartas I see that you already bumped version to 0.4.5 Would you please cut a new release? Thanks!

Oh, actually 0.4.5 is already released on rubygems so just update your bundle

ok, i try it

There wasn't a tag on the release, but I see that 0.4.5 in fact resolved this issue for me

relesaed 0.5.1

authors: Tkwon123 dreyks ondrejbartas tomwey

repo: ondrejbartas/sidekiq-cron


text:
Fix path

The file main.f90 is in the current folder, not in lab
Existing Sample Changes
Description
Fix submission script
Fixes Issue#  https://github.com/oneapi-src/oneAPI-samples/issues/1659
External Dependencies
No new external dependencies
Type of change
Please delete options that are not relevant. Add a 'X' to the one that is applicable.

[x ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Implement fixes for ONSAM Jiras

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Command Line
[ ] oneapi-cli
[ ] Visual Studio
[ ] Eclipse IDE
[ ] VSCode
[ ] When compiling the compliler flag "-Wall -Wformat-security -Werror=format-security" was used
[x] Tested on Dev cloud

See
https://github.com/oneapi-src/oneAPI-samples/pull/1671

repo: oneapi-src/oneAPI-samples


text:
FIX: distributed knn double sqrt bug

Description
Removes unnecessary duplicate sqrt of distances

/intelci: run

/intelci: run

repo: oneapi-src/oneDAL


text:
Fix of xgemm call.

Small fix of BlasGpu<algorithmFPType>::xgemm call signature. The value "1" in this context should be uint32_t, not algorithmFPType.

/intelci: run

/intelci: run


text:
modified approach for setting results_to_compute

replaced train_results_to_compute with error_metrics_to_compute.
and infer_results_to_compute with results_to_compute.
Also added corresponding operators.

/intelci: run

/intelci: run

/intelci: run

/intelci: run

/intelci: run

/intelci: run

/intelci: run


text:
testParseRemoteXML fails on fresh checkout

Is this what others experience or is this environment-specific? Here's roughly what I did:
docker run --name alpine-openj9 -it adoptopenjdk/openjdk8-openj9:x86_64-alpine-jdk8u212-b04_openj9-0.14.2
then something like:
apk add git mvn bash
apk update && apk upgrade
bash

then I cloned the repo, checked out the latest tag, and mvn clean install. There are numerous errors exceptions and error messages logged, but only one test failure:
testParseRemoteXML(com.onelogin.saml2.test.settings.IdPMetadataParserTest): expected:<https://try[].onelogin.com/trust/...> but was:<https://try[-demo].onelogin.com/trust/...>
# mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T19:00:29Z)
Maven home: /usr/share/java/maven-3
Java version: 1.8.0_212, vendor: Eclipse OpenJ9, runtime: /opt/java/openjdk/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-60-generic", arch: "amd64", family: "unix"

Is there another manual step I need to take to setup before building which I overlooked?
Do note this is with Alpine and OpenJ9, so not exactly the most common type of environment.

FWIW I wanted to test if updating xmlsec past https://nvd.nist.gov/vuln/detail/CVE-2019-12400 would break anything. Both before and after updating, I get the same test failure given above.

The above test failure blocks a couple of projects from building, but when I add -Dmaven.test.failure.ignore=true there are no additional test failures (after upgrading xmlsec, which is probably irrelevant).

Thanks for letting me know about the CVE.
I will review why that test is failing, update the xmlsec and release a new java-saml version

That fixes the test
https://github.com/onelogin/java-saml/commit/4cd854373202d5d10cde3201842e178f85273464

new xmlsec raises issues on java7, trying to figure it how fix them

https://github.com/onelogin/java-saml/releases/tag/v2.5.0

Wow that was painless for me. Thanks!
I hope discontinuing support for Java 7 doesn't block anyone!

It was the unique option in order to update the xmlsec dependency that is compiled with java8.
Java 7 customers have 2 options:

Migrate to Java 8
Keep using the v2.4.0 of java-saml and patch the xmlsec jar with the fix:
https://github.com/apache/santuario-java/commit/52ae824cf5f5c873a0e37bb33fedcc3b387cdba6

authors: pitbulk shark-horse

repo: onelogin/java-saml


text:
Non http(s) redirects should be allowed

As per this line https://github.com/onelogin/php-saml/blob/3.0.0/src/Saml2/Utils.php#L289, only http(s) URLs are allowed to be redirected to. IMO this is not something the library should take care of, especially considering the URL is checked for general valitidy one line afterwards.
For our exact use case, we want to redirect to mibrowsers://<url> instead of https://<url>, so that we can make use of this. Again, IMO the use case doesn't even matter, the library should not care about the protocol in general. Or at the very least this check should be configurable. What's your view on this?

The FILTER_VALIDATE_URL consider an URL without protocol as valid, that why we validate the protocol previously.
You can provide a PR that modify the regex to add the 'mibrowsers' as a valid protocol.

I don't think that a very scalable approach. Then someone else will need to add another protocol in a couple of months.
I think for a tightly controlled environment the package should allow skipping the check altogether. What about adding another parameter for this?

The toolkit has several years is that is the first petition.
I don't want to add a new setting parameter.
What about adding a new parameter to the Utils class: allowed_redirect_protocols
by default http and https, and a way to modify it programarically?

I've created a small pull request :)

authors: gitnik pitbulk

repo: onelogin/php-saml


text:
Resizing strategy

After downloading an image, I would like to cache a resized version of it (thumbnail). Am I right to assume the best approach for this would be to:
1- Not use the KingfisherManager.swift
2- Create my own Manager that uses ImageCache.swift and ImageDownloader.swift and inject this logic in a method "similar to this".

There is no need to do so. You can just use ImageCache separately. You could just throw your thumbnail to the default cache (KingfisherManager.sharedManager.cache) by calling storeImage:forKey: with a key different from your original file. Of course, you can create a new cache object to store these thumbnail if you do not want to mess it up with the default cache. It depends on you.
When you need to access these thumbnails, you could use retrieveImageForKey:options:completionHandler:. If there is no such cached image there, you will get nil and then you know you should download it from web.

Thanks for the feedback @onevcat

authors: RuiAAPeres onevcat

repo: onevcat/Kingfisher


text:
Handle errors from GetLatestBlock

Description
Previously I encountered a runtime panic when trying to generate FLIX templates in flow-core-contracts repo:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x40 pc=0x101eb4374]

goroutine 1 [running]:
github.com/onflow/flixkit-go/internal/v1_1.(*Generator).generateDependenceInfo(0x140011b31d8, {0x102e9b3a0, 0x1044c3d00}, {0x140015e0e20, 0xd})
        /Users/bartkozorog/Projects/flixkit-go/internal/v1_1/generator.go:222 +0x244
github.com/onflow/flixkit-go/internal/v1_1.Generator.processDependencies({{0x140008bc688, 0x15, 0x23}, {0x140015ca5c0, 0x5, 0x8}, 0x14001986270}, {0x102e9b3a0, 0x1044c3d00}, 0x1020f65c6?)
        /Users/bartkozorog/Projects/flixkit-go/internal/v1_1/generator.go:181 +0x100
github.com/onflow/flixkit-go/internal/v1_1.Generator.CreateTemplate({{0x140008bc688, 0x15, 0x23}, {0x140015ca5c0, 0x5, 0x8}, 0x14001986270}, {0x102e9b3a0, 0x1044c3d00}, {0x14001216c00, ...}, ...)
        /Users/bartkozorog/Projects/flixkit-go/internal/v1_1/generator.go:126 +0x198
github.com/onflow/flixkit-go/internal.flixService.CreateTemplate({0x140010e1140?}, {0x102e9b3a0, 0x1044c3d00}, 0x140016738f0, {0x14001216c00, 0x3d9}, {0x0?, 0x10106b3e0?}, {0x14000b3c780, 0x5, ...})
        /Users/bartkozorog/Projects/flixkit-go/internal/flix_service.go:201 +0xf8
github.com/onflow/flow-cli/internal/super.generateFlixCmd({_, _, _}, {{0x0, 0x0}, {0x1020db9f2, 0x4}, {0x16f8473c9, 0x8e}, {0x0, ...}, ...}, ...)
        /Users/bartkozorog/Projects/flow-cli/internal/super/flix.go:259 +0x32c
github.com/onflow/flow-cli/internal/super.generateCmd({0x14001602b40, 0x1, 0x3}, {{0x0, 0x0}, {0x1020db9f2, 0x4}, {0x16f8473c9, 0x8e}, {0x0, ...}, ...}, ...)
        /Users/bartkozorog/Projects/flow-cli/internal/super/flix.go:207 +0x11c
github.com/onflow/flow-cli/internal/command.Command.AddToParent.func1(0x140015db700?, {0x14001602b40, 0x1, 0x3})
        /Users/bartkozorog/Projects/flow-cli/internal/command/command.go:144 +0x4cc
github.com/spf13/cobra.(*Command).execute(0x104321e20, {0x1400004e210, 0x3, 0x3})
        /Users/bartkozorog/go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:989 +0x828
github.com/spf13/cobra.(*Command).ExecuteC(0x14000cbc908)
        /Users/bartkozorog/go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:1117 +0x344
github.com/spf13/cobra.(*Command).Execute(...)
        /Users/bartkozorog/go/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:1041
main.main()
        /Users/bartkozorog/Projects/flow-cli/cmd/flow/main.go:129 +0xc34

Now when the error is handled, it's clear what the issue is:
❌  Error while dialing: dial tcp 127.0.0.1:3569: connect: connection refused"
🙏 Make sure your emulator is running or connection address is correct.

@jribbink Thanks for the approval! Can we merge this (I don't have permission to do that)?

repo: onflow/flixkit-go


text:
configure.ac fails to detect libusb if pkg-config is not installed

When libusb-1.0 is installed through Homebrew on Mac OS X, it will not be detected by configure.ac, as this requires pkg-config. The Homebrew recipe does not depend on pkg-config. As a result, libusb-1.0.pc will not be installed.
Add a libusb detection method to configure.ac that does not depend on pkg-config.
Thanks to Paul Pritz for reporting this.

Supporting both systems with and without pkg-config is difficult.
However, there is a workaround: As long as autoconf and automake are executed on a system with pkg-config installed, the resulting configure script can be instructed to ignore pkg-config.
Just execute configure like so:
LIBUSB10_LIBS="-L/usr/local/lib -lusb-1.0" LIBUSB10_CFLAGS="-I/usr/local/include/libusb-1.0" ./configure
This will skip the pkg-config step and set appropriate compiler/linker options directly.

Added documentation in 4f16eb20feed1d49a6ea6d441335221d6d95e5e4 .

repo: onitake/daliserver


text:
Reduce installation size and footprint

Includes work for #350, which will decrease size / footprint on disk. Will be easier to fix that after the full set of fixes.

There are several other places we need to optimize the package size, though:

Are all the node_modules needed? Are they being pruned correctly? Should they be flattened? This is a pretty huge culprit, at ~150MB.
Remove unbuilt sources from package
Does all of font awesome need to be included?
Some of the images can be excluded

Long term, some packages should not be included by default - like oni-plugin-csharp. This is a contributing factor to the size of the node_modules. This will be easier once there is a plugin story for Oni.
I would like the install size to be on par with some of the other Electron editors (~50 MB), and the footprint ideally to be under 100MB.

lodash seems pretty huge too - we should only include the subset needed, and remove it from node_modules entirely - it's getting double-packed, both in node_modules and in the webpack bundle.

The initial set of pruning is done - we should track further items individually.

repo: onivim/oni


text:
Bugfix/path concatenation

@bryphe, whilst investigating a solution to #1061, I realised that swapping out shell-env for the call to childProcess.exec does not actually work the same way i.e. logging the path output of both processes, shell-env correctly picks up the path and plain process call doesn't once the app is built. I hadn't realised that that wasn't working as I still had the additional env variables set in my config so it was picking up my executables which led me to believe the process exec method was working.
With shell-env things appear to work correctly and the which go-langserver returns the correct response. Apologies thought we had cracked it earlier and wouldn't need the extra dependency, which I've re-added. I've also left out shell-env's associated dependencies and just installed shell-env.

As a side note, which has led to a bit of confusion on my end,  the PATH variable echo'ed by term in nvim does not seem to reflect the path that the neovim process is using, which is very confusing but in effect if you run echo $PATH (no !) as an excommand you see a path which is what I think neovim uses however the path for the terminal in nvim in oni seems to have ?extra or different access as the variable it outputs does not match that.
The term path variable in my case seems to include extra separators as I noticed in #1061 but the nvim echo $PATH output does not 😕

Apologies for what is beginning to feel like a stream of consciousness/rant, whilst adding shell env seemed to return the correct path, unfortunately in go files it was not picking up hover info for external libs etc. I think this is due to the fact that go depends on things like GOROOT and GOPATH environment variables. I've resolved this by merging the default process.env from electron with shell-env's environment which gives the user access to all their shell variables.
This solves the problem of finding dependencies based on shell vars and also allows user to have access to all their shell variables, which at least for me is quite helpful as my vimrc references shell variables I or other programs set up.

Thanks for working on this @Akin909.
I can confirm that this solves the problem reported in #1061.

Thanks for catching this and fixing it, @Akin909 ! Sorry I led you down the wrong path in terms of childProcess.exec versus shell-env.

I think this is due to the fact that go depends on things like GOROOT and GOPATH environment variables. I've hopefully resolved this by merging the default process.env from electron with shell-env's environment.

Awesome! Yes, this makes sense.
Thanks @josemarluedke for confirming the fix, too! I suspect this could impact #868 as well, as the python provider is sensitive to not having the appropriate paths to load the python runtime.

Oh and this is interesting:

The term path variable in my case seems to include extra separators as I noticed in #1061 but the nvim echo $PATH output does not 😕

I wonder if this is specific to Oni, or if it happens in nvim too?
Change looks good to me - the test failures on TravisCI don't seem related to your change (and when I ran locally, they passed). I'll take a look at those failures.  Thanks again for the investigation + fix here, @Akin909 !

@bryphe through very superficial perusing of issues re neovim's terminal I think it sources it's path differently as it's essentially another program embedded in nvim. Re the fix I tried it locally yesterday with no issues except I can't get reason running yet but that pre-dates this issue (I haven't set it up properly yet I think) but I made some tweaks since then and think my local build (which includes my experiments is no longer properly sourcing the tss) will the tests pick that up? if not i'd like to revert some changes rebuild and make sure there aren't any issues there.

@Akin909 - in theory the tests should pick it up (which may be why it is failing in the CI machine) - at least the AutoCompletion-TypeScript test should fail if we're unable to start tss (it looks like that is the test that is failing). The Demo-Screenshot test is also dependent on it, since it waits for the completion UX to show to generate the screenshot.

if not i'd like to revert my build back to this commit and make sure there aren't any issues there.

If you wouldn't mind double-checking, that'd be great! I'll double-check on my machine too. I'll hold off on bringing it in until we confirm that tsserver is starting correctly.

@bryphe sorry false alarm re tss I've got it running, I was experiencing some crashes in the console due to some plugin tinkering, but I've built a version off of that branch i've got a functioning tss

@Akin909 Oh ok, great, thanks for the update! I built locally and it is working for me as well.
I'll bring this in, and investigate the stability of those tests.

authors: Akin909 bryphe josemarluedke


text:
🛑 Paste is down

In 5a10507, Paste (https://paste.ononoki.org/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Paste is back up in e5ee89d.


text:
Simpler interface on mobile

I have tried several storybook packages and yours does have the best code.
Kudos for a very clean solution.
I was wondering would you consider separate ui for mobile ?
Something like [the interface from other library(https://link.medium.com/QsIhC21zP6) seem to be more user friendly in mobile.
What do you think ?
I’m considering use case of being able to see stories states quickly without too many clicks.
I’d be happy to help with PR

Thanks, nice to hear that :)
Yeah, having the stories in a list makes navigation between stories easier, but at the same time, if story has knobs (interactive elements to control story state) they will occupy some space and the story has to be full-screen anyway.
For example, in the project where we're using this storyboard, almost every story has these knobs, so it will still end up with a list of stories with links to the full-screen page.
But there's definitely something to think about 🤔

Agree. It can still to details page when clicked on it.
There is two different use cases:

Developing and checking different knobs combos
Verification that common styles didn’t broke anything - visually by scrolling through  the list.

authors: Maxim-Filimonov ookami-kb


text:
Kernel version

Including the system kernel version details.

what?


text:
Add an option to pass an io.Writer to audits

Description of PR
To make audits easier to test, pass in an io.Writer to be used for writing the text reports. This will allow the writer to be changed out with a buffer for instance so it can be validated in a test without writing directly to stdout.
Signed-off-by: Brad P. Crochet brad@redhat.com

Fixes #299

Changes (required)

Add an option for passing an io.Writer to audits
Pass the cmd.OutOrStdout to RunAudits

Checklist (required)

[X] I have reviewed and followed the contribution guidelines
[X] I have performed a self-review of my code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have made corresponding changes to the documentation if needed
[X] I have checked that my changes pass all tests

Looking at this one and the previous one with the afero file system I believe we could stick only with a generic io.Writter and use afero as another io.Writer. Is it possible? Like with the os.File one?

Let me look at how that might work...

Looking at this one and the previous one with the afero file system I believe we could stick only with a generic io.Writter and use afero as another io.Writer. Is it possible? Like with the os.File one?

I'd say let's maybe take care of that after @skattoju is done with his work on the reports.

/approve

authors: acmenezes bcrochet

repo: opdev/opcap


text:
REST API cleanup

make xoslib and core use the same base classes [done]
backend_icon stuff to one spot [done]
use a consistent error-handling mechanism [to-do]

Done.

repo: open-cloud/xos


text:
Optimize file content in deploy-kubernetes-resources

Adding syntax highlighting enhances readability for the readers.
Rectifying the representation of command-line inputs for consistency throughout the article.
Adjusting proper indentation for improved formatting.

/assign @mikeshng


text:
validate user proxy flags

Signed-off-by: liuwei liuweixa@redhat.com

/lgtm

authors: skeeey xuezhaojun


text:
Schema, README, extension metadata

I wasn't able to complete the checks locally as the URL in extension.json documentationUrl returned an error. It may be due to current Github's  network issues.

Aha, it's because you accidentally created a private repo. I made it public now, and I've disabled the creation of new private repos :)

authors: ColinMaudry jpmckinney