NFS mounts and Catalina

Issue Type

Bug Report / Support Request

Your Environment
Vagrant 2.2.5
VirtualBox 6.0.12r133076
ansible 2.8.5
  config file = None
  configured module search path = ['/Users/karl/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/Cellar/ansible/2.8.5/libexec/lib/python3.7/site-packages/ansible
  executable location = /usr/local/bin/ansible
  python version = 3.7.4 (default, Sep  7 2019, 18:27:02) [Clang 10.0.1 (clang-1<IP_ADDRESS>)]

Your OS

macOS (10.15)

Summary
Catalina's NFS exports work a little differently, root isn't root anymore. I was able to fix vagrant_synced_folders by changing local_path from /Users/karl/Sites to /System/Volumes/Data/Users/karl/Sites/, but the NFS synced vagrant directory is set in the Vagrantfile using File.dirname(File.expand_path(__FILE__)) which when NFS-mounted is no longer the correct path. On Catalina /System/Volumes/Data should be prepended to host_project_dir.
If I run DRUPALVM_PROJECT_ROOT=/System/Volumes/Data/Users/karl/Vagrant/php72 vagrant up it all works, but it would be nice to not have to set that var each time.
It would also be nice to have vagrant_synced_folders corrected automatically, but I don't have to "hack core" to fix that.

Upstream issue, although this still might need to be fixed in DrupalVM, not sure: https://github.com/hashicorp/vagrant/issues/10961

I don't know how old my version of this I am running but my Vagrantfile is
# the config file need to be contained within this path.
ENV['DRUPALVM_PROJECT_ROOT'] = "#{__dir__}"

# The relative path from the project root to the config directory where you
# placed your config.yml file.
ENV['DRUPALVM_CONFIG_DIR'] = "config"

# The relative path from the project root to the directory where Drupal VM is located.
ENV['DRUPALVM_DIR'] = "vendor/geerlingguy/drupal-vm"

# Load the real Vagrantfile
load "#{__dir__}/#{ENV['DRUPALVM_DIR']}/Vagrantfile"

and I have a config.yml inside a config folder.
These are the vagrant_synced_folders lines I have -
vagrant_synced_folders:
  # The first synced folder will be used for the default Drupal installation, if
  # any of the build_* settings are 'true'. By default the folder is set to
  # the drupal-vm folder.
  - local_path: .
    destination: /var/www/drupalvm
    type: nfs
    create: true

Any ideas where I need to add the /System/Volumes/Data text?

@karlshea I did some more checking, and tried your method. I could get Drupal VM stood up, but the Web root in the VM was blank (but no errors reported). Am doing more checking on this.

@karlshea I was able to get DrupalVM working again with your steps.
However what initially confused me was Vagrant/php72 in your command, but I guess this is your local folder for DrupalVM.
@gideoncresswell I had to make sure all entries in  /etc/exports pointed to /System/Volumes/Data.

Unfortunately as soon as I run vagrant reload all my /etc/export lines change and it breaks. I need a way of making the change to that file persistent.

@gideoncresswell Yes. If I understand correctly, part of the security updates in Catalina directly address access to system files such as this.

NFS mount seems broken for now and needs a fix upstream I guess. The workaround of mine is basically not using NFS shares but native Virtualbox shares by altering the Drupalvm config.yml. On OSX the steps are

shut down drupalvm with vagrant halt
check exports with cat /etc/exports and remove the defective Virtualbox entries that do not have /System/Volumes/Data - In my case I could just set an empty /etc/exports file. Not clearing the invalid entries will disrupt the Vagrant init of the vm.
Alter the Drupalvm config.yml to use native shares instead of nfs and do not forget to update the local_path entry with the added /System/Volumes/Data/Users/{username}

vagrant_synced_folders:
  - local_path: /System/Volumes/Data/Users/daniel/Documents/Sites/natarch
    destination: /var/www/natarch
    # Instead of nfs, use an empty string to indicate native shares. This is considerably slower however.
    type: ""
    create: true

Alter the Drupalvm Vagrantfile to not share the vagrant project with the Virtualbox. Not doing this will halt the sharing process. I just commented out the lines under   # Sync the project root directory to /vagrant.

  # Sync the project root directory to /vagrant
  # unless vconfig['vagrant_synced_folders'].any? { |synced_folder| synced_folder['destination'] == '/vagrant' }
  #   vconfig['vagrant_synced_folders'].push(
  #     'local_path' => host_project_dir,
  #     'destination' => '/vagrant'
  #   )
  # end

Do vagrant up and check your shares.

Tried the workaround without success, I get the same error as gideoncresswell, where mounting fails.
I'm using as well OS X Catalina.

I've been doing more digging. Also, to confirm, have cloned the current Drupal VM, and ran vagrant up. Am getting the same errors.
Now, tracing it down, as well as looking at other solutions, have found something that looks promising:
if Dir.exist?("/System/Volumes/Data")
    [Some Alias] = "/System/Volumes/Data" + [Path in VM] # absolute path to Drupal VM directory on host machine for macos Catalina
else
    [Some Alias] = [Path in VM] # absolute path to Drupal VM directory on host machine
end

This should work in the Vagrantfile for the project. At the moment, I'm doing trial-and-error to see where it will work. If it's successful, it will work for users on Catalina and previous.

I saw this on the original issue. Does this seem to help?

Add /sbin/nfsd in System Preferences > Security & Privacy > Full Disk Access
https://github.com/hashicorp/vagrant/issues/10961#issuecomment-541070382

@dasginganinja Thanks—that solution may work, if the permissions can be accessed (can't see the file to add in System Preferences). I find that if I edit the /private/etc/exports file, it is overwritten on vagrant up.

I don't think this has anything to do with an upstream fix. When you mount an NFS folder you have to tell it the path you want mounted, which on Catalina includes /System/Volumes/Data.
Adding this to my Vagrantfile (along with fixing local_path in vagrant_synced_folders) fixed the issue: (Thanks, @charlieartist)
# Add after this line
host_project_dir = ENV['DRUPALVM_PROJECT_ROOT'] || host_drupalvm_dir

if Dir.exist?('/System/Volumes/Data')
    host_project_dir  = '/System/Volumes/Data' + host_project_dir
end

A similar solution is being used by ddev (drud/ddev#1869)

Also, you can't edit /etc/exports other than removing items, because Vagrant still needs to map things correctly, as you're discovering when vagrant up breaks. The path in /etc/exports needs to match the path Vagrant is trying to mount.

@karlshea Thanks—tried adding that in, but got errors. I probably need to change host_drupalvm_dir to my specific needs. Also, it appears there is Vagrant fix on the way.

Can confirm @karlshea solution above worked for me.
To be absolutely clear:

The Vagrantfile I edited was not the one in the project folder but was the one in vendor/geerlingguy/drupal-vm/ ... obviously not good in the long-term

In my config.yml I updated vagrant_synced_folders thus:

    vagrant_synced_folders:
      - local_path:  /System/Volumes/Data/Users/iain/misfitstheatre.test
        destination: /var/www/drupal
        type: nfs

I deleted ~/.vagrant.d as it had cached previous export directory names

I updated to latest Vagrant and VirtualBox

@iainhouston Thanks—just tried this, and from the CLI looks good, no warnings, but site wasn't installed at web root in the VM. I'll do some more checking and testing.

Thanks @iainhouston your solution worked for me.
Vagrantfile file changes:
# Add after this line
host_project_dir = ENV['DRUPALVM_PROJECT_ROOT'] || host_drupalvm_dir

if Dir.exist?('/System/Volumes/Data')
    host_project_dir  = '/System/Volumes/Data' + host_project_dir
end

config.yml file changes
vagrant_synced_folders:
      - local_path:  /System/Volumes/Data/Users/username/vagrant/drupalvm
        destination: /var/www/drupal
        type: nfs

vagrant version : 2.2.5
Virtual Machine : 6.0
DrupalVM : 5.0.1

I upgraded my vagrant to 2.2.6 today and vagrant up and reload both worked now. I also had to do a vagrant plugin update for VBGuest.
I can log into the server using vagrant ssh but I can't access my site in a browser anymore. I wonder what other protective measures Catalina has introduced.

@gideoncresswell I have updated as well. On the first round, the build was stood up in the VM where it should be, but nothing in the browser. So, tried vagrant reload, and first got the same NFS errors as before.
So, did some testing/trial-and-error.
Got it fixed by updating the VBGuest and Hostsupdater plugins, then by deleting the VM, as well as the ~/.vagrant.d and ~/Vagrant folders. After this, builds stood up fine.
Hope this helps!

@markahrens If you have updated Drupal VM, Vagrant, and VirtualBox, you should be able to stand up your build with the same file settings you used before the Catalina update.
I deleted the ~/.vagrant.d and VMs, as well as the /private/etc/exports file to be sure there wasn't any cruft left over, then vagrant plugin update then vagrant up.

@charlieartist I ran through those steps as well and am still receiving the Stale file handle error. This happens on a brand new instance as well as my previous site. I can cd into what should be the site folder when ssh-ed into the VM, however I get this:
vagrant@drupalvm:/var/www/drupalvm$ ls -la
ls: cannot open directory '.': Stale file handle

I then checked the permissions on the drupalvm folder and it showed the following from within the VM: drwxr-xr-x 23  502 dialout  736 Oct 15 17:26 drupalvm
I tried doing this in both iTerm and Terminal to see if the new folder permissions might be an issue, but it was the same result in both.

@charlieartist I figured out the issue, the sites I was testing this out on were in in the Documents and Downloads folders. Both of these folders have new protections on them which appears to block accessing anything inside them. When i cloned the drupal-vm project in my Users folder directly, then vagrant up ran just fine and the site worked perfectly.
It looks like moving any sites folders that are in Documents or Downloads to the user folder instead should resolve the issue.

@charlieartist I'll take your advice and delete the folders. Although I don't appear to have a ~/Vagrant folder? Is that your default machine folder inside Virtual Box? I have a different folder set so I'd delete that if that's what it is. Thanks.

I did delete everything and got the VM working again. Except it still refuses to connect in the browser or using curl.
I'm guessing it's some kind of firewall issue? Unfortunately that's not my speciality.
I'll try the supplemental Catalina update today.

I faced the same issue today. I followed the following steps to resolve it:

Halt the VM vagrant halt
Upgraded the vagrant to 2.2.6
Upgraded the vagrant plugins vagrant plugin update
Remove the VM information from the /etc/exports file
vagrant up

OK something happened and it's all working now. Definitely the advice by @charlieartist has helped by removing those folders. I did a vagrant up --provision last of all and it is now working fine.

@karlshea Is anyone else still having trouble? If not, should we close this issue?

I updated to the latest Vagrant release and it does seem like they implemented an upstream fix.  Looks like this can be closed.

I tried all the solutions given here. But no luck for me.
I have below configurations.
Mac Catalina
version10.15.7 (19H2)
Vagrant: 2.2.14
VirtualBox: 6.1
Ansible 2.10.3
config.yml
vagrant_synced_folders:

local_path: .
destination: /var/www/8world
type: "nfs"
create: true

I cleaned the /etc/exports and /private/etc/exports
I restarted the nfsd service then vagrant reload but still facing the same issue.
==> 8world: Mounting NFS shared folders...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o vers=3 <IP_ADDRESS>:/System/Volumes/Data/Users/amit.sharma/Sites/mediacorp/8world/8world-drupal /var/www/8world

Stdout from the command:

Stderr from the command:

mount.nfs: Connection timed out


Inconsistent cypress runs between github action and cypress dashboard

Hi 👋
I've recently updated my cypress github workflow to run only on pull_requests against the master branch instead of push events and I'm seeing a weird side effect when opening a new Pull Requests and re-running the cypress job:

Cypress will run the test suite of the master branch (not the head branch that is being submitted as a PR to merge on top of master). On the github status check for the cypress dashboard, I can see it's called default-group (merge) and the title of the run contains the commit hash of my head branch and the HEAD commit hash of the master branch we're merging into.

If I rerun the same job, Cypress will run the test suite of the head branch (as expected). On the github status check for the cypress dashboard, I can see it's simply called default-group and the title of the run

It looks like Cypress Dashboard is somehow capturing 2 different events on the same github ci run (from the same workflow file). I'm pretty convinced that my update  to run cypress only on pull_request events triggered.
Am I doing something wrong?
Here's a screenshot of the pull requests checks:

Here's my Github Workflow file:
name: Run End-to-End Test Suite

on:
  pull_request:
    branches:
      - master

jobs:
  build-and-e2e-test:
    runs-on: ubuntu-16.04
    strategy:
      matrix:
        node-version: [11.x]
    steps:
      - name: Checkout Commit
        uses: actions/checkout@v1
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - name: Cache NPM Dependencies
        id: cache-dependencies
        uses: actions/cache@v1
        with:
          path: node_modules
          key: node-modules-${{ runner.OS }}-npm-cache-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            node-modules-${{ runner.OS }}-npm-cache
      - name: Cache Cypress Binaries
        id: cache-cypress-binaries
        uses: actions/cache@v1
        with:
          path: ~/.cache/Cypress
          key: cypress-binaries-${{ runner.OS }}-npm-cache-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            cypress-binaries-${{ runner.OS }}-npm-cache
      - name: Install Dependencies
        if: steps.cache-dependencies.outputs.cache-hit != 'true' || steps.cache-cypress-binaries.outputs.cache-hit != 'true'
        run: |
          yarn install --force --non-interactive
      - name: Build Application
        run: yarn build
        env:
          CI: true
      - name: Run E2E Tests without recording (if not on master branch)
        uses: cypress-io/github-action@v1
        with:
          browser: chrome
          record: true
          headless: true
          start: yarn serve-built-files
          wait-on: "http://localhost:8081"
          config: defaultCommandTimeout=100000,pageLoadTimeout=100000,watchForFileChanges=false,video=false
        env:
          NODE_ENV: "test"
          CI: true
          CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}

GitHub status checks will trigger differently for CI providers that utilize "Pull Requests builds". Pull request builds are generated by the CI provider (if configured) by merging the head branch with the base branch specified in the pull request (in your case - master). These are helpful in answering the question “What if this PR merged into target (base) branch”. You'll often see the commit message for the associated build look something like "Merge 2f5a7afe97740f99f5c4f5e40a3d7347bc058b30 into 1f40d78961e5d268ac072dca86176f9fb2aa7b13".
These types of builds trigger Cypress's GitHub status checks notated with the note (merge) on the status check.
If your build also runs the action against its current branch (without the generated merge 'pull request build') you would see 2 events triggered from Cypress since there are 2 actions being run.
I'm a bit unsure about whether you are saying this happens on every single PR or whether this only triggers 2 events when you 'rerun' your action. Could you clarify?

Thank you for your answer!

I'm a bit unsure about whether you are saying this happens on every single PR or whether this only triggers 2 events when you 'rerun' your action. Could you clarify?

I get the 1st merge event when I open the pull request and the 2nd event only when I rerun the PR. I'd have expected it to rerun as the 1st event.

@jennifer-shehane is it possible to specify custom message, or point Cypress to proper commit sha? As I understand by default it takes github.sha, however github.event.after would serve better
Now our dashboard doesn't look good

@godban We use these environment variables to display the information in the Dashboard https://on.cypress.io/continuous-integration#Git-information So, if you have some way to overwrite this when GitHub auto creates a merge commit - then you could pass that (I'm not sure if this is possible).

@jennifer-shehane no, this will lead to unexpected behaviour even if possible.

I have looked at what is going on by opening https://github.com/bahmutov/cypress-gh-action-example/pull/14
The workflow is running both on push (commit) and on pull_request events
name: merge
# run this action on Push and on Pull Request
# to demonstrate the difference in commit SHA
on: [push, pull_request]

You can see the Dashboard at https://dashboard.cypress.io/projects/yz8qku and filter by tags since I pass the event name as a tag
- name: Cypress run on ${{ github.event_name }}
  uses: cypress-io/github-action@v2
  with:
    record: true
    group: merge
    tag: ${{ github.event_name }}
  env:
    CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}

Every commit with open pull request thus triggers 2 events = 2 action runs
For example here in GH Actions we see merge #3 which is a push event with the current commit title "print", and merge #4 which is the pull request that uses the original PR title "add pr workflow".

Here is what our Dashboard shows in this case

Build 164 is the recording of the "push" event, has the expected title from the commit "print" and is ok.
Build 162 is the recording of the "pull_request" event, and it uses the default commit title created by GitHub (merge commit A into B), and this is what we would like to change.
When we look closely at the build 162, its commit also is not as nice as it could be

which leads to the merge commit and not to the pull request

Solution
To me the largest problem is the commit message for pull request. Thus a good solution is to set it for pull requests as an environment variable to overwrite the Git information. You can find the file at https://github.com/bahmutov/cypress-gh-action-example/blob/master/.github/workflows/merge.yml and here is the relevant portion
- name: Cypress run on ${{ github.event_name }}
  uses: cypress-io/github-action@v2
  with:
    record: true
    group: merge
    # tag will be either "push" or "pull_request"
    tag: ${{ github.event_name }}
  env:
    CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
    # - if the event is push, the title will be undefined
    # and Cypress will get the commit message from Git information
    # - if the event is pull_request, then we set the commit
    # message to the pull request title
    COMMIT_INFO_MESSAGE: ${{ github.event.pull_request.title }}

The Dashboard shows then:

"push" event shows the commit's subject line.
"pull_request" event shows the PR title.

@bahmutov alright, it works. Thank you!

@bahmutov Thanks for this solution that fixes the dashboard labels, but it breaks the PR comments on github. After applying this solution to my project I don't have cypress bot comments on my PR, after removing the COMMIT_INFO_MESSAGE variable the comments are back.
Any idea on how to keep both of those features working ?

Checking to see if there have been any updates on this issue as I experienced the same thing as @eliasplatekdkt. The solution @bahmutov provided worked for the title but broke all Cypress status updates to the PR in question.
It would be great to configure this option with more nuance, somehow. The current title displayed from the screenshots already posted is not only overly verbose but somewhat unhelpful as to the context of the run.

@eplatek-safyr Try adding COMMIT_INFO_SHA: ${{ github.event.pull_request.head.sha }} as an env var.

@mellis481 After some testing, COMMIT_INFO_MESSAGE is only necessary to obtain the message in the Dashboard when using pull_request as part of the workflow. The COMMIT_INFO_SHA seems to be necessary when using pull_request or workflow_dispatch workflows to definitively determine the run has ended.

@conversaShawn I'm confused why you say COMMIT_INFO_SHA is needed for workflows that use the workflow_dispatch trigger since my manually-initiated workflows are currently working without it.  Plus what value would you use for it?

Spent a while on this one and the solution is to explicitly target the PR head commit instead of the merge commit by adding the ref attribute as shown below. This will remove the (merge) suffix. For us this allows us to run the e2e tests on the pull request and also Github Merge Queues from the same Cypress Group.
 steps:
      - uses: actions/checkout@v2
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - name: Install Cypress and run tests
        uses: cypress-io/github-action@v6


RPC events crashing the server are back with latest commits

Fixed in 7fbac53 - re-test with dev/0.0-dev29 or later

I've built with the latest commits and it's still crashing. But works well with the latest release. Thinks it's been broken again in the new commits 👀
Originally posted by @FlorianV85 in https://github.com/altmp/altv-js-module-v2/issues/115#issuecomment-1742129268

fixed in 30b4fd17f3c783c2bb86220735e01d45f5c5bca1


Updated to Love 11.5

This is an update for the API for latest Love 2D version 11.5.
Only changed entries that had thrown exceptions during the execution of generate_tl.lua.

The new love-api contains more information when the type is function or table, but this will do for now.


Can't tell what assistant I am running

Click explore and select an assistant to run. The assistant starts but I have no indication on the screen what assistant I am running.

We now put the assistant name at the top, but it isnt "pinned", so you lose it once that chat is long. we probably want to "pin" it.

This issue is also tracked in https://github.com/gptscript-ai/desktop/issues/127#issuecomment-2289984973

@sangee2004 if an issue is tracked in two places, then close one as a dupe. ill close yours as a dupe and leave this one open

We're going to take this a step farther and add some additional info and features to the "pinned" bar. At a high level, we'll have a dropdown to indicate what tools the assistant currently has, a way to indicate if the assistant has been modified from its original state (by adding tools), and a way to effectively "Save As..." the thread as a new assistant

I need to has out the UX of this a bit more, so dont just pick this up without working on it without talking to me about it first.

Tested with latest electron build from d3033b74d0f
Able to see the the name of assistant in the chat view which is pinned  at the top of the chat, so that it is visible even when we have a long chat message history and we are at the most recent message (in the bottom of the message list with scroll bar).
We are also presented with the tool list that are available to this thread from the assistant and the dynamic tools that have been added to the thread.
We are also provided with ability to  to delete the dynamically added tools from this list.

Issues seen when testing this feature are tracked in other issues:
https://github.com/gptscript-ai/desktop/issues/287
https://github.com/gptscript-ai/desktop/issues/289

The icons are not tracked as part of this issue. They are tracked here: https://github.com/gptscript-ai/desktop/issues/242


Minispy.inf not working for 64 bit architecture

Hi,
I am working with minispy.
During installation of minispy.inf file, found that the file is not for 64 bit architect machines.
Questions:
1)Could anyone share me the minispy.inf file for 64 bit?
2)Is it possible to create myself a 64 bit minispy.inf file ?
3)If so, what are the changes to be done with minispy?
Kindly help with the above questions
Thanks in advance
Ranjani N

Just add arhitecture component like below ,and add legacyuninstall =1  under defaultuninstall. Hope I helped.
`[DefaultInstall.NTAMD64]
OptionDesc = %ServiceDescription%
CopyFiles = MiniFilter.DriverFiles
[DefaultInstall.NTAMD64.Services]
AddService = %ServiceName%,,MiniFilter.Service
;;
;; Default uninstall sections
;;
[DefaultUninstall.NTAMD64]
DelFiles = MiniFilter.DriverFiles
LegacyUninstall=1
[DefaultUninstall.NTAMD64.Services]
DelService = %ServiceName%,0x200`


[1.12.1] Too Many Chicken Mod Nuggets...

Is there any way to automagically setup nuggets from this mod to just use the preferred mod nuggets?  Currently the nuggets produced by the TMC mod uses the ore dictionary but there isn't an event that catches the nuggets when they are in an automated system.  I'm not sure how to convert them other than just take them out of the storage drawers and toss them on the ground.

if you want to get nuggets form a specific mod just add the mod name to preferredMods in config file in the first place.
My mod is not made for converting items that are already in chests or other inventory systems. It's made for converting when getting items.


Register-PackageSource: Source Location 'https://www.nuget.org/api/v2' is not valid.

Prerequisites

[X] Write a descriptive title.
[x] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
When registering source package using below command:
Register-PackageSource -provider NuGet -name nuget.org -location https://api.nuget.org/v3/index.json
Expected behavior
Package installation succeeded.

Actual behavior
Getting below error:
Register-PackageSource: Source Location 'https://api.nuget.org/v3/index.json' is not valid.

Error details
Getting below error:
Register-PackageSource: Source Location 'https://api.nuget.org/v3/index.json' is not valid.

Environment data
Name                           Value
----                           -----
PSVersion                      7.1.3
PSEdition                      Core
GitCommitId                    7.1.3
OS                             Microsoft Windows 10.0.19042
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Visuals
No response

Please report the issue https://github.com/oneget/oneget


Typescript & DefinitelyTyped

Hiya,
Is anyone out there working on getting this project a declaration file to add to DefinitelyTyped ( https://github.com/DefinitelyTyped/DefinitelyTyped ) for working with it in typescript ?
Thanks.

You can add to it in Typescript adding this reference at the top your file:
import '../../../libraries/seriouslyjs/seriously.js';
declare var Seriously: any;

@utiq True, but that is true of any JavaScript library.
Maybe I worded my post wrong, When I said working with it in TypeScript, I meant having the advantages of type definition.. IntelliSense and such.
That said, I'm sure pointing this out will help others.


Disable Azure syslog exception logging

As a follow-up to #3331, this disables Azure exception logging to syslog.
Fixes #2565

[x] I added CHANGELOG entry for this change.
[ ] Change is not relevant to the end user.

Changes
Disabled Azure pipeline ForceLog.
Verification
Ran a build of my branch against an Azure blob storage container and confirmed no further exceptions were being sent to syslog.

I ran e2e tests locally and they pass. Seems like the failures are test flakiness? Do you want me to any additional validation on my side?


[Docs] [Bug] Broken links under "Using APIs"

Same issue as the developer guide page, all links under using APIs [1] are 404
[1] https://is.docs.wso2.com/en/5.9.0/using-wso2-identity-server/using-APIs/

https://github.com/wso2/docs-is/issues/122


Max guests, description not being stored to database when editing a meal as a user or admin.

Fill fields:

Click Update:

See incorrect info:

Info not returned when editing again:

Fixed w/ 7d8038279d88b00efbbff888860e84a396db5a70. Deployed and tested.

:+1:


For Json_format=True, Failed when xmltotxt generate None

I'm not sure I can reproduce the bug with this information, could you please provide a complete example? (including the processed content and the error message)


The "hub co" for pull request on renamed repo fails

There 2 repos:

https://github.com/Behat/docs
https://github.com/minkphp/docs

If you try to fork both of them into same account you run into naming conflict and are forced to fork either of repos under different name.
For example try:

clone https://github.com/minkphp/docs repo
do hub co https://github.com/minkphp/docs/pull/45

It fails with this error:
fatal: Couldn't find remote ref refs/heads/session
error: Could not fetch stof

This is because attempt is made to to read docs/session ref from Behat/docs fork.
I think that we shouldn't blindly assume that every forked repo is named the same and use GitHub API for detecting actual fork name for every user.

Currently I was able to mediate that problem by editing path to a remote after the error was shown and then repeating the command.

fatal: Couldn't find remote ref refs/heads/session
error: Could not fetch stof

I looked at the PR you want to checkout and it's to merge minkphp:master from stof:session. However, the https://github.com/stof/docs repo doesn't have the branch session. That's why your fetch failed.

I think that we shouldn't assume that every forked repo is named the same and use GitHub API for detecting actual fork name for every user.

We're using the GitHub API for actual fork name, e.g. the Go implementation https://github.com/github/hub/blob/master/commands/checkout.go#L69.

I looked at the PR you want to checkout and it's to merge minkphp:master from stof:session. However, the https://github.com/stof/docs repo doesn't have the branch session. That's why your fetch failed.

Of course it doesn't. It's because https://github.com/stof/docs is fork from https://github.com/Behat/docs , but I'm executing that command on https://github.com/minkphp/docs clone and expecting that repo fork to be found through that PR.

@aik099: This might be a GitHub bug. Thanks for reporting.
It might be that stof first opened the PR, then renamed his docs repo to be named mink-docs. That made the information about the fork name in the PR stale. We'll have to solve it on GitHub's end.
In the meantime, here's how to checkout any PR without using hub:
git fetch origin "+refs/pull/${num}/head:refs/pr/${num}"
git checkout -b "$branch" "pr/${num}"

@jingweno Actually, only the label property of the PR is stale. We should be using the head.repo property instead.
{
  "url": "https://api.github.com/repos/minkphp/docs/pulls/45",
  "number": 45,
  "state": "open",
  "title": "Rewrite the session chapter",
  "user": {
    "login": "stof",
    "id": 439401,
  },
  "merge_commit_sha": "a684b5a5a8a9d7583e08f0aed5710a6f375ff67e",
  "head": {
    "label": "stof:session",
    "ref": "session",
    "sha": "296d69704b039e1bb5c2f1ce061005c63dbed7ce",
    "user": {
      "login": "stof",
      "id": 439401,
    },
    "repo": {
      "id": 28839329,
      "name": "mink-docs",
      "full_name": "stof/mink-docs",
      "owner": {
        "login": "stof",
      },
      "private": false,
      "html_url": "https://github.com/stof/mink-docs",
      "fork": true,
    }
  },
  "base": {
    "label": "minkphp:master",
    "ref": "master",
    "sha": "afed839c6a7805c2835cbd8ad4299240105eeee4",
    "user": {
      "login": "minkphp",
      "id": 10380339,
    },
    "repo": {
      "id": 2093133,
      "name": "docs",
      "full_name": "minkphp/docs",
    }
  }
}

Thanks for looking into that.
It's actually the first time I had this issue because usually all repos have unique names (even without user/organization name).

@jingweno Oops, sorry, it's kinda late and I'm not thinking straight. The label property is alright and the complete API response looks correct. There's no GitHub bug here.
It might be a hub bug then? The stof/mink-docs repo indeed has the "session" branch.
@aik099 How do you think the Behat/docs repo comes into play here? When you git config remote.stof.url after the failed checkout, which URL does it display?

As you know when you fork a repo, then GitHub replaces user/organization name of original repo with yours to create new repo name. I guess @stof originally forked Behat/docs repo into stof/docs repo.
Then after some time when he decided to fork minkphp/docs the GitHub was confused and asked (I'm just guessing here) for Stof to pick up a new name for his fork because stof/docs is already taken by another repo (fork or not).
By the way you can see in GitHub API output that stof/docs is never mentioned there, so it's Hub's wild guess that fork name is stof/docs by combining part before : from head.label with original (non-forked) repo name :wink:

I guess that hub does not read the repo section at all.
Btw, hub could decide to fetch the refs/pull/45/head reference from the origin repo, which would allow to get the code of a PR even when the source repo has been deleted from github. This would avoid having to know the name of the fork repo altogether

Name of the fork is still needed because Hub creates remote with username of whoever created a fork and pulls branches for each pull request into it.

Well, read my comment again: I'm saying it is not necessary to access the content of pull requests (and it limits it to PRs where the source repo has not been deleted)

and it limits it to PRs where the source repo has not been deleted

Are you sure, that even though forked repo is deleted or branch, which was PR source was deleted the GitHub still retains changes made in that PR when it wasn't merged yet?

If source repo is deleted, then you can't use Hub in general by the way, because you clone source repo (not own fork) and use hub command on it.

@aik099 I'm talking about the source of the PR, not about the upstream repo. The target repo of a PR keeps the reference even when the source is deleted

@mislav I saw a spec that deliberately prefers label over repo. Is it still true, considering we'd want to prefer repo over label in this case. There's another one having the same expectation.

The second one looks like what we need, but it applies only on hub merge command, but I was using hub co command.

@aik099 The second one prefers label over repo though, which causes the problems you met. From @mislav JSON blob, the label is stof:session while the repo is stof/mink-docs. My intuition is we should use repo instead but need to confirm if the spec is still valid and what problem it tries to solve.

Ah, I think I know why. The changes are only in git-merge but not in git-checkout. I'll provide a fix.

Thanks for your patience @aik099 @stof :bow:

Thanks.


Product warehouse assignment is mandatory

PHP Version
8.1
Shopware Version
6.5
Affected area / extension
Platform(Default)
Expected behaviour
When you assign a warehouse group to a product you should not be forced to add a stock for each warehouse in the group.
Actual behaviour
If you don't define a stock for each warehouse in the assigned group you'll encounter an error when placing the order. The error says: Value is not a valid UUID
How to reproduce
Go to administration, edit a product and assign a warehouse group without changing/saving stocks for the warehouses in the group.
Go to storefront and try to place an order containing the previous product.

[public] Automated response: This issue is linked to the internal issue  https://shopware.atlassian.net/browse/NEXT-38007 Pending  .
[created from NEXT-38007, comment 489487]


Add support for tsdoc {@inheritDoc}

Unlike jsdoc's @ inheritdoc,
tsdoc's @inheritDoc enclosed in "{ }" braces, is not supported by vscode.
/** {@inheritdoc IStringBuilder.append} */

This feature is powered by the TypeScript project. Please file a feature request upstream


Default to using terminfo to set the terminal title

Currently, the title is only set on supported terminals (i.e. xterm, urxvt, screen etc.). Using terminfo entries to set the terminal title adds support for many more terminals.

Hi @moyamo, I didn't know about tsl/fsl, thank you for your contribution. We recently changed the termsupport.zsh code though, so this needs to be rebased. It should go inside this section as an else.
You should use the builtin echoti instead of tput as well, and test for those capabilities with
[[ -n "$terminfo[fsl]" ]] && [[ -n "$terminfo[tsl]" ]]

Thanks!

Is this alright?

Almost perfect, there's an indentation mismatch. It should be 2 spaces wide. We're not yet following any sort of project-wide style convention but at least on a file-by-file basis it should be the same.
Thanks!

Fixed

Thanks! :smile:


Better error message for missing Server::expose

A missing Server::expose() currently results in the following error message:
PHP Fatal error:  Uncaught Error: At least one interface must be specified (see Aerys\Internal\Host::expose()), an empty interfaces array is not allowed
The error message shouldn't refer to an internal API, but instead refer to Server::expose().

Sockets are now passed as constructor argument to Server, but I think there's still no check for an empty array.


[BEAM-3744] Expand Pubsub read API for Python.

R: @chamikaramj

Were the comments addressed ? Lemme know if I can continue the review.

@chamikaramj Yes, please continue. I'll remove ReadStringsFromPubSub in a subsequent PR.

@chamikaramj , I believe your comments are referring to a different PR?
retest this please

Yeah, that was an invalid diff. Please ignore those comments. I'm re-reviewing.

LGTM. Thanks.

@chamikaramj Were you planning to merge this?

Yeah, merging now. Was waiting for tests to pass.


[New Port Request]

Library name: libremidi
Library description: A modern C++ MIDI real-time & file I/O library. Supports Windows, macOS, Linux and WebMIDI.
Source repository URL: https://github.com/jcelerier/libremidi
Anything else that is useful to know when adding (such as optional features the library may have that should be included): this is a fork of RtMidi, and since RtMidi is already in vcpkg, I imagine the starting point to port would be just copy and paste the config files from https://github.com/microsoft/vcpkg/tree/master/ports/rtmidi and tweak them.

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now, consider making a pull request instead.

I see that libremidi is now available. It's the first component that I'm trying after installing vcpkg and I have linker issues that may be related to the port or to my inexperience with vcpkg.
I want to use the x64-static version in VS2022 Community. I have set the "Use static libraries" option in my project's vcpkg properties page, and set the RT to static in the Code Generation properties page. In order to link correctly, I still have to
• add the path to the vcpkg binaries in VC++ Directories | Library Directories
• add libremidi.lib to Linker | Input
• also, add winmm.lib to Linker | Input
Now everything builds and runs fine. I think that I should not have to manually add the vcpkg binaries path and the library... should I??? The fact is that I don't see the vcpkg binaries path in the evaluated library path:

I have run vcpkg integrate install (as administrator just to be sure); in fact, headers are resolved with no need to manually adjust the include path, and intellisense works for libremidi.
Any help appreciated... thanks!

@LilyWangLL Marked port-resolved.

Did you try ./vcpkg integrate install first?

Did you try ./vcpkg integrate install first?

@JackBoosY yes, I did. I have run vcpkg integrate install (as administrator just to be sure); in fact, headers are resolved with no need to manually adjust the include path, and intellisense works for libremidi.

So can you please provide the results of ./vcpkg list libremidi and which arch do your project use?
Also please provide the build log.

~So can you please provide the results of ./vcpkg list libremidi and which arch do your project use? Also please provide the build log.~
Fine, that's a good news.

Well, I still have the issue of having to manually tweak the project. As I wrote in my first comment, I had already run ./vcpkg integrate install ahead, before commenting.

Here's the result of running .\vcpkg list libremidi:
libremidi:x64-windows                             4.2.3#1             A modern C++ MIDI real-time & file I/O library
libremidi:x64-windows-static                      4.2.3#1             A modern C++ MIDI real-time & file I/O library

This is the build log when I remove both the path from vcpkgs binaries to Library path, and not the name of libremidi.lib from Linker Input:
1>------ Build started: Project: libremidi_test_2, Configuration: Debug x64 ------
1>libremidi_test_2.obj : error LNK2019: unresolved external symbol "public: __cdecl libremidi::observer::observer(struct libremidi::observer_configuration)" (??0observer@libremidi@@QEAA@Uobserver_configuration@1@@Z) referenced in function main
1>libremidi_test_2.obj : error LNK2019: unresolved external symbol "public: __cdecl libremidi::observer::~observer(void)" (??1observer@libremidi@@QEAA@XZ) referenced in function main
1>libremidi_test_2.obj : error LNK2019: unresolved external symbol "public: class std::vector<struct libremidi::input_port,class std::allocator<struct libremidi::input_port> > __cdecl libremidi::observer::get_input_ports(void)const " (?get_input_ports@observer@libremidi@@QEBA?AV?$vector@Uinput_port@libremidi@@V?$allocator@Uinput_port@libremidi@@@std@@@std@@XZ) referenced in function main
1>D:\SWDev\MISSILI\libremidi_test_2\x64\Debug\libremidi_test_2.exe : fatal error LNK1120: 3 unresolved externals
1>Done building project "libremidi_test_2.vcxproj" -- FAILED.

The path I added to Library directories is $(VcpkgRoot)\installed\x64-windows-static\debug\lib\static

__cdecl is correct in static build. But why the libs are in lib/static?
@LilyWangLL Needs to check the build output paths.

__cdecl is correct in static build. But why the libs are in lib/static? @LilyWangLL Needs to check the build output paths.

I will confirm it.

Looks like the dll is written to the correct path x64-windows/bin, but both the import library for the dll and the static library are in a /static subdir (x64-windows\lib\static and x64-windows-static\lib\static, and both only contain just libremidi.lib).
I tried and move the static .lib and then I could get rid of my project tweaks. I just have to manually add winmm.lib to Linker | Input.

but both the import library for the dll

hmm, the install rule in cmake is
  install(TARGETS libremidi
          EXPORT libremidi-targets
          ARCHIVE DESTINATION lib/static
          RUNTIME DESTINATION bin
          LIBRARY DESTINATION lib
  )

which should install:

libremidi.dll in bin/
libremidi.lib (import library) in lib/static
libremidi.lib (static library) in lib/static

Would it be better to change:
ARCHIVE DESTINATION lib/static

into
 ARCHIVE DESTINATION lib

?

ARCHIVE DESTINATION lib is the right thing for a tiny patch in vcpkg.
Upstream should use input variables for destinations, ideally those from GNUInstallDirs.

PR #34718 will fix the wrong lib path.

Anyone encountered this issue can test https://github.com/microsoft/vcpkg/pull/34718 ?

Anyone encountered this issue can test #34718 ?

@JackBoosY I would but I'm not sure how can I test the patch before it's merged. Anyway, I had manually altered my installed directory, should I revert the changes I made? Would the patch be able to remove the files in the previous wrong /static directory?

Ok, I managed to fetch @LilyWangLL 's commits from the PR into my local repository. This is what I have done:
• Reverted the manual adjustments I had made
• vcpgk remove libremidi
• the previous command only removed x64-windows, so I also ran vcpgk remove libremidi:x64-windows-static
• verified that the lib/static folder was gone, and libremidi.lib with it
• cherry-picked the commits
• vcpkg install libremidi:x64-windows-static
libremidi.lib was then found in lib folder and my test project compiles and links, both for debug and release configurations (and with no manual tweaks of the project options).
This workflow didn't allow me to check whether the updated script would be able to remove the static directory. I should have not removed libremidi before merging the PR... I only thought about it later.

I was feeling bold, so I removed libremidi after installing it using the patched scripts, reverted the scripts to HEAD, reinstalled libremidi (it went to the wrong static directory), then re-applied the PR, and run vcpkg upgrade --no-dry-run. The static directory created by the previous installation was removed, and libremidi.lib was created in the right place in lib alongside other libraries.
D:\SWDev\SDKs\vcpkg>vcpkg list libremidi
libremidi:x64-windows-static                      4.2.3#2             A modern C++ MIDI real-time & file I/O library

note that I changed to use gnuinstalldirs in the latest libremidi HEAD commits: https://github.com/jcelerier/libremidi/blob/master/cmake/libremidi.install.cmake

It looks like the libremidi port needs to add a dependency for readerwriterqueue, at least when the pipewire backend is being used on Linux. I'm not very familiar with vcpkg, so am not sure if it would be enough to just add this to the port file:
  "dependencies": [
    {
      "name": "readerwriterqueue",
      "platform": "linux"
    },
    ...


Showcase how to create an up-to-date pending changelog

Not a request, just some thoughts (that could potentially be a nice addition to the README):
git sv release-notes creates the currently pending changelog for the next upcoming version.
In the current CI runs of this repo there is already a step that generates those (https://github.com/thegeeklab/git-sv/blob/647aa9cf538545142d7877c5af9015f663947063/.woodpecker/build-package.yml#L20-L25) but only publishes them on a tag event.
Arguably, a pending changelog that is somewhat visible and easy to find while at the same time unintrusive can be beneficial for certain projects. I was thinking about this coming from the plugin-release-ready-go plugin. I like that git-sv is a lot more lightweight and doesn't keep a static PR that even triggers all pull_request workflows by default.
A middle-way between a static PR and local invocation could be to have a dedicated pipeline (instead of a step) that just cats the pending release notes.
I don't see an easy way to dynamically infer the link to the respective latest pipeline execution (to add this then to the README), so the README would likely need a statement like "for the pending changelog, visit the "changelog" pipeline of the most recent CI run of the main branch").
PS: very nice work overall! 👍

Personally, I would use an issue e.g. something like the renovate dashboard to always show the upcoming release changelog but I dont think I would like to implement it for this repo.

An issue would be neat indeed. I also thought about this but had the impression that this tool wants to avoid forge-specific code/actions and aims to only interact with the local git information. Which is why I focused on the "link to the latest CI run" idea.
But yes, I also think that this would be great. It would also solve the issue of the plugin-ready-release plugin which always triggers unrelated checks for every changelog update.

I don't want to implement it in this repo as, indeed, the tool should stay independent of a forge. My suggestion would to use preferred CI system to update a forge issue on every commit to the default branch.

I'm going to close this issue for now. If you have built something like that and want to document it, I'm happy to add it to the readme. Hope that's fine for you.

Here's an example of a generic solution that can be c/p in any (Forgejo/Gitea) repo. It is also CI agnostic, thanks to git-sv, of course.
A similar solution can easily be created for GH, maybe you're motivated to do so?
Examples for both GH and Gitea in the README would be a great addition, I think.


Add .travis.yml

This patch adds a simple .travis file. It's a PR for testing travis CI.

It worked well.


Work around Stay bugs and improve edits

This pull request makes several changes:

Improves the example code
Makes edits more versatile and work more "as expected"
Works around bugs in stays
Commit messages should give further clarification.

LGTM, but let's ensure Travis tests green.

I will also build it on Windows, just in case :smile:

It was not easy to test (had to rebase on top of the latest master and sync rhea to use @jbo-ableton's fork), but I can confirm that it builds on Windows!

@miv-ableton @ala-ableton The required changes have been merged in Rhea and I have updated the pull request accordingly. Also I have added doxygen documentation as suggested by @gck-ableton.


Add more OpenShift installation details

Add more details for successful OpenShift installation

If we can add it to the chart then great,
I deliberately split line 110 so it was more obvious

@sdodsley I see we have https://github.com/purestorage/pso-csi/blob/master/pure-pso/templates/plugin/scc.yaml#L14-L15, which should allow privileged containers, and we have it assigned to the proper service account.

This was not a problem with OpenShift 4.6, but 4.7 seems to require this manual command again

@sdodsley: Do you want to merge this one?


pydantic.dataclasses with typing.TYPE_CHECKING has a different behaviour than dataclasses.dataclass

Checks

[x] I added a descriptive title to this issue
[x] I have searched (google, github) for similar issues and couldn't find anything
[x] I have read and followed the docs and still think this is a bug

Bug
I would expect pydantic.dataclasses to work as same as the dataclasses.dataclass when we use postponed annotations. Am I missing something? Is there a way to get the same behavior with pydantic? Adding the update_forward_refs() calls to the main don't fix the issue.
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
             pydantic version: 1.9.1
            pydantic compiled: True
                 install path: /home/.../project/venv/lib/python3.9/site-packages/pydantic
               python version: 3.9.9 (main, Jan  7 2022, 10:36:15)  [GCC 11.1.0]
                     platform: Linux-5.16.15-arch1-1-x86_64-with-glibc2.35
     optional deps. installed: ['dotenv', 'email-validator', 'typing-extensions']

In module_a.py:
from __future__ import annotations

from typing import TYPE_CHECKING
from pydantic.dataclasses import dataclass

if TYPE_CHECKING:
    from module_b import NodeB

@dataclass
class NodeA:
    node: NodeB

In module_b.py:
from __future__ import annotations

from typing import TYPE_CHECKING
from pydantic.dataclasses import dataclass

if TYPE_CHECKING:
    from module_a import NodeA

@dataclass
class NodeB:
    node: NodeA

File main.py:
from module_a import NodeA
from module_b import NodeB

if __name__ == '__main__':
    NodeA(node=None)
    NodeB(node=None)

Output:
Traceback (most recent call last):
  File "/home/master/Development/bitrodens-platform/bitrodens/test.py", line 5, in <module>
    NodeA(node=None)
  File "<string>", line 4, in __init__
  File "pydantic/dataclasses.py", line 98, in pydantic.dataclasses._generate_pydantic_post_init._pydantic_post_init
    # +-------+-------+-------+
  File "pydantic/main.py", line 1038, in pydantic.main.validate_model
  File "pydantic/fields.py", line 833, in pydantic.fields.ModelField.validate
pydantic.errors.ConfigError: field "node" not yet prepared so type is still a ForwardRef, you might need to call NodeA.update_forward_refs().

Thank so much for the help! This is one of the most useful library have been using with Python :)

Hi there! are there any news around this issue?

Same here (with 1.10.2)


Optionally skip the private IP check

It's nice to have the check exist by default, but for advanced users, maybe allow them to skip the check?
This PR allows setting ALLOW_GLOBAL_ROUTABLE_IP=1 to skip the private IP check.

I'd love to understand your use case a little more please, can you describe why this change would be useful to you?

I deploy public IPs + CGNAT IPs at home (legit setup), and lancache refuse to start in this case.


Add an option for handling missing language

Some users put a dummy language (for example "unknown") while using code block in markdown if no language provided in order not to conflict with the line numbering and line highlighting properties if for example rehype-prism-plus is used.(here).. They prefer to reserve the first word for the language and go with the dummy language approach:
```unknown {1}
<Component/>
```

For those who want to go with a dummy language (like above "unknown"), needed to set another option (handleMissingLanguageAs) in the remark-flexible-code-titles in order to choose a dummy language string, and the plugin will assign this option  into node.lang instead of null. So, the remark-flexible-code-titles will ensure that the dummy language will be rendered in the class attribute of the code tag, without explicitly saying "unknown" in markdown.
Possible usage of the new option could be:
import remarkCodeTitles from "remark-flexible-code-titles";
...
.use(remarkCodeTitles, {
  handleMissingLanguageAs: "unknown", // or "dummy" what so ever
})

Handled in the v1.1.3, https://github.com/ipikuka/remark-flexible-code-titles/releases/tag/v1.1.3

Handled in the v1.1.3, https://github.com/ipikuka/remark-flexible-code-titles/releases/tag/v1.1.3


scm_anti_spyware_profile, rules.threat_name can not be null or any

Describe the bug
When creating the rules for scm_anti_spyware_profile the attribute threat_name can not be set to "any" or "null".
There is a validation in place for string length > 4 charachters.
Expected behavior
Should allow following rule:
 rules = [
    { name = "simple-critical"
      action = { reset_both = true }
      category = "any"
      packet_capture = "single-packet"
      severities = ["critical"]
      threat_name    = "any"
    },
 ]

Current behavior
Terraform error:
Error: Provider produced inconsistent result after apply │ │ When applying changes to scm_anti_spyware_profile.bt_default_spyware, provider "provider[\"registry.terraform.io/paloaltonetworks/scm\"]" produced an unexpected new value: .rules[0].threat_name: was   │ null, but now cty.StringVal("any"). │ │ This is a bug in the provider, which should be reported in the provider's own issue tracker. ╵
Possible solution
Allow threat_name to be set to "any"
Steps to reproduce

Create a resource:

resource "scm_anti_spyware_profile" "example" {
 name = "test_scm_spyware"
 folder = "Prisma Access"
 rules = [
    { name = "simple-critical"
      action = { reset_both = true }
      category = "any"
      packet_capture = "single-packet"
      severities = ["critical"]
      threat_name    = "any"
    },
 ]
}

Context
I am creating scm_anti_spyware_profile by looking up "best-practice" and replicating the rules.
Your Environment
Terraform v1.7.4
on linux_amd64

provider registry.terraform.io/paloaltonetworks/scm v0.6.0

Happens also to me:

If I set to "any": same validation error.
If do not set at all (null):

Error: Provider produced inconsistent result after apply
│
│ When applying changes to scm_anti_spyware_profile.xxxx, provider "provider[\"registry.terraform.io/paloaltonetworks/scm\"]" produced an unexpected new value: .rules[1].threat_name:
│ was null, but now cty.StringVal("any").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Environment
Terraform v1.9.8
on darwin_arm64

- Using previously-installed paloaltonetworks/scm v0.9.2


Portal Document Management System

Description
Validation of the need of an document management system connection from the portal backend instead of storing the documents inside the portal db
Impact
Additional information

[ ] I'm willing to contribute to this feature

current assumption is that storage solutions of the used cloud provider would be used.
based on this assumption discussed with @jjeroch  and @evegufy  we do not see any benefit to follow up on this topic as a open source solution would not provide overarching benefits.


[BUG][v1.6.0-rc1] Negative test case failed: Stop Volume Node Kubelet For More Than Pod Eviction Timeout While Workload Heavy Writing

Describe the bug
During negative test case Stop Volume Node Kubelet For More Than Pod Eviction Timeout While Workload Heavy Writing executing, after stopped kubelet (k3s-agent) service on the volume attached node for more than pod eviction timeout, the workload pod gets stuck in Terminating state forever.
NAME                     READY   STATUS        RESTARTS   AGE   IP           NODE            NOMINATED NODE   READINESS GATES
longhorn-test-minio      1/1     Running       0          15h   <IP_ADDRESS>    ip-10-0-2-97    <none>           <none>
test-statefulset-rwo-0   0/1     Terminating   0          15h   <IP_ADDRESS>   ip-10-0-2-238   <none>           <none>

NAME                              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
pod-data-test-statefulset-rwo-0   Bound    pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068   3Gi        RWO            longhorn-test   15h

The test step is like:
1. Create statefulset with rwo volume
2. Keep writing data to statefulset
3. Stop volume node kubelet of statefulset for 360 seconds
4. Wait for volume of statefulset healthy
5. Wait for statefulset stable
6. Check statefulset works

Currently it's stuck in step 5: Wait for statefulset stable: https://ci.longhorn.io/job/private/job/longhorn-e2e-test/150/consoleFull
Lots of error messages in kubelet logs of node ip-10-0-2-238. Please see the attached support bundle.
To Reproduce
Run negative test case Stop Volume Node Kubelet For More Than Pod Eviction Timeout While Workload Heavy Writing
Expected behavior

Support bundle for troubleshooting
supportbundle_04d0770c-250f-4473-89d3-4b12e7540e8a_2024-01-16T03-35-21Z.zip
Environment

Longhorn version: v1.6.0-rc1
Impacted volume (PV):
Installation method (e.g. Rancher Catalog App/Helm/Kubectl):
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: v1.27.1+k3s1

Number of control plane nodes in the cluster:
Number of worker nodes in the cluster:

Node config

OS type and version:
Kernel version:
CPU per node:
Memory per node:
Disk type (e.g. SSD/NVMe/HDD):
Network bandwidth between the nodes (Gbps):

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal):
Number of Longhorn volumes in the cluster:

Additional context
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJkekNDQVIyZ0F3SUJBZ0lCQURBS0JnZ3Foa2pPUFFRREFqQWpNU0V3SHdZRFZRUUREQmhyTTNNdGMyVnkKZG1WeUxXTmhRREUzTURVek1qSTBPVEl3SGhjTk1qUXdNVEUxTVRJME1UTXlXaGNOTXpRd01URXlNVEkwTVRNeQpXakFqTVNFd0h3WURWUVFEREJock0zTXRjMlZ5ZG1WeUxXTmhRREUzTURVek1qSTBPVEl3V1RBVEJnY3Foa2pPClBRSUJCZ2dxaGtqT1BRTUJCd05DQUFSWWRySWwwSGJ0VzhsZTRVVWY3bnBFYXZMaWdUSUVHQWlWdEdlSFp3K08KTUNRc0lSeG9sWFV2a3p3ekpOWkNuZ2lSckFhWHA0WS9uZUhsSE1xMWxFbEdvMEl3UURBT0JnTlZIUThCQWY4RQpCQU1DQXFRd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBZEJnTlZIUTRFRmdRVUdZYk1iTnRvRzV2Mzl4WW5td1ZOCmo5aEpmREV3Q2dZSUtvWkl6ajBFQXdJRFNBQXdSUUlnUUpTcUNWTG4wREo2TEc0RVN6REZ4RkZUTHcrWU0vQ1QKcU8vZXFVdUFyVVFDSVFEeE5EV09rRlpRNndZT3lIRllWRCsyZ0NZNWozcEpYc1cxMENPVlBUcEZoZz09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    server: https://<IP_ADDRESS>:6443
  name: default
contexts:
- context:
    cluster: default
    user: default
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJrakNDQVRlZ0F3SUJBZ0lJUWU2MTdHZ1Q3Smd3Q2dZSUtvWkl6ajBFQXdJd0l6RWhNQjhHQTFVRUF3d1kKYXpOekxXTnNhV1Z1ZEMxallVQXhOekExTXpJeU5Ea3lNQjRYRFRJME1ERXhOVEV5TkRFek1sb1hEVEkxTURFeApOREV5TkRFek1sb3dNREVYTUJVR0ExVUVDaE1PYzNsemRHVnRPbTFoYzNSbGNuTXhGVEFUQmdOVkJBTVRESE41CmMzUmxiVHBoWkcxcGJqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJJamVmN1FuMU5pWnBVN0MKK2ExeFdoaEFhK3pRbHZ4WlFuK3VjM1Y4M1FjOXdVMXlyRDRFVlF0WUFDZzJlTityYnZHakZYd2hLUEU1ZFBqQgpPdUtFd2tHalNEQkdNQTRHQTFVZER3RUIvd1FFQXdJRm9EQVRCZ05WSFNVRUREQUtCZ2dyQmdFRkJRY0RBakFmCkJnTlZIU01FR0RBV2dCU1FpM205K1Q5aCt3RHBEME9xYklGNzhudW9KREFLQmdncWhrak9QUVFEQWdOSkFEQkcKQWlFQXZDT3lJbXMzR1BKTHJ3Vm5Rb3BHbzU4bHVhRHU0SHBHUFRRdS9xbVU3bzhDSVFEZjNOSzlIRGZzUERJSgpUeTQ0MGg5dzlwaGVZZlh0cnFUMWV4V21CYmI3QVE9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCi0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLQpNSUlCZURDQ0FSMmdBd0lCQWdJQkFEQUtCZ2dxaGtqT1BRUURBakFqTVNFd0h3WURWUVFEREJock0zTXRZMnhwClpXNTBMV05oUURFM01EVXpNakkwT1RJd0hoY05NalF3TVRFMU1USTBNVE15V2hjTk16UXdNVEV5TVRJME1UTXkKV2pBak1TRXdId1lEVlFRRERCaHJNM010WTJ4cFpXNTBMV05oUURFM01EVXpNakkwT1RJd1dUQVRCZ2NxaGtqTwpQUUlCQmdncWhrak9QUU1CQndOQ0FBVHEwUkVnOGE4V3VjZlpsZUQrcm9rTmMzdlpZU3ZGV3VtNExXcmpXWEVJCjhyZ2VjZWV2dXRsclRZei9LWVpWeGpUNFdqZHRDelhWNUQwa05WUHhtT3BRbzBJd1FEQU9CZ05WSFE4QkFmOEUKQkFNQ0FxUXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QWRCZ05WSFE0RUZnUVVrSXQ1dmZrL1lmc0E2UTlEcW15QgplL0o3cUNRd0NnWUlLb1pJemowRUF3SURTUUF3UmdJaEFJUlpQcjNYYWdwRjRtWEQ0S2c3VVlyYkFZTGtJekkzCktWaW5TQlVzVmlWR0FpRUF4a3dzMVA3bUlmRUppdHZWYTNnRWFlU1Jmci95SjV1Y1pQbFE2anE2QmRVPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    client-key-data: LS0tLS1CRUdJTiBFQyBQUklWQVRFIEtFWS0tLS0tCk1IY0NBUUVFSUlFUkxDcDRpRFZSVnRZdHhGOWVsbzJWSFR4MmFWdm40aFltVExMME1yb3VvQW9HQ0NxR1NNNDkKQXdFSG9VUURRZ0FFaU41L3RDZlUySm1sVHNMNXJYRmFHRUJyN05DVy9GbENmNjV6ZFh6ZEJ6M0JUWEtzUGdSVgpDMWdBS0RaNDM2dHU4YU1WZkNFbzhUbDArTUU2NG9UQ1FRPT0KLS0tLS1FTkQgRUMgUFJJVkFURSBLRVktLS0tLQo=

2024-01-15T13:21:15.185411391Z time="2024-01-15T13:21:15Z" level=error msg="Failed to prepare mount point for volume pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068 error unmounted existing corrupt mount point /var/lib/kubelet/pods/a702f7b8-287e-467c-8cc8-e3497867776e/volumes/kubernetes.io~csi/pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068/mount" func="csi.(*NodeServer).NodePublishVolume" file="node_server.go:207" component=csi-node-server error="unmounted existing corrupt mount point /var/lib/kubelet/pods/a702f7b8-287e-467c-8cc8-e3497867776e/volumes/kubernetes.io~csi/pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068/mount" function=NodePublishVolume
2024-01-15T13:21:15.185435975Z time="2024-01-15T13:21:15Z" level=error msg="NodePublishVolume: err: rpc error: code = Internal desc = Failed to prepare mount point for volume pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068 error unmounted existing corrupt mount point /var/lib/kubelet/pods/a702f7b8-287e-467c-8cc8-e3497867776e/volumes/kubernetes.io~csi/pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068/mount" func=csi.logGRPC file="server.go:138"

Jan 16 03:35:30 ip-10-0-2-238 k3s[818]: E0116 03:35:30.987799     818 reconciler_common.go:169] "operationExecutor.UnmountVolume failed (controllerAttachDetachEnabled true) for volume \"pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068\" (UniqueName: \"kubernetes.io/csi/driver.longhorn.io^pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068\") pod \"a702f7b8-287e-467c-8cc8-e3497867776e\" (UID: \"a702f7b8-287e-467c-8cc8-e3497867776e\") : UnmountVolume.NewUnmounter failed for volume \"pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068\" (UniqueName: \"kubernetes.io/csi/driver.longhorn.io^pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068\") pod \"a702f7b8-287e-467c-8cc8-e3497867776e\" (UID: \"a702f7b8-287e-467c-8cc8-e3497867776e\") : kubernetes.io/csi: unmounter failed to load volume data file [/var/lib/kubelet/pods/a702f7b8-287e-467c-8cc8-e3497867776e/volumes/kubernetes.io~csi/pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068/mount]: kubernetes.io/csi: failed to open volume data file [/var/lib/kubelet/pods/a702f7b8-287e-467c-8cc8-e3497867776e/volumes/kubernetes.io~csi/pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068/vol_data.json]: open /var/lib/kubelet/pods/a702f7b8-287e-467c-8cc8-e3497867776e/volumes/kubernetes.io~csi/pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068/vol_data.json: no such file or directory" err="UnmountVolume.NewUnmounter failed for volume \"pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068\" (UniqueName: \"kubernetes.io/csi/driver.longhorn.io^pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068\") pod \"a702f7b8-287e-467c-8cc8-e3497867776e\" (UID: \"a702f7b8-287e-467c-8cc8-e3497867776e\") : kubernetes.io/csi: unmounter failed to load volume data file [/var/lib/kubelet/pods/a702f7b8-287e-467c-8cc8-e3497867776e/volumes/kubernetes.io~csi/pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068/mount]: kubernetes.io/csi: failed to open volume data file [/var/lib/kubelet/pods/a702f7b8-287e-467c-8cc8-e3497867776e/volumes/kubernetes.io~csi/pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068/vol_data.json]: open /var/lib/kubelet/pods/a702f7b8-287e-467c-8cc8-e3497867776e/volumes/kubernetes.io~csi/pvc-dc8e8f17-dce7-4ad4-a806-5e959242a068/vol_data.json: no such file or directory"

On node ip-10-0-2-238, kubelet log is flooding with vol_data.json: no such file or directory error.
The issue looks very similar to:

https://github.com/kubernetes/kubernetes/issues/116847#issuecomment-1718342451
https://github.com/longhorn/longhorn/issues/4782#issuecomment-1852413341

We also need to consider another scenario:

Volume engine crashes.
Volume marked for remount.
Volume workload pod deleted due to auto-delete-pod-when-volume-detached-unexpectedly setting
Volume workload pod in Pending state.
Volume re-attach to a replica that is on an unschedulable node.
kubelet stopped
CSI involves node publish volume and the target mount point is corrupted, the target mount point deleted
The taint-manger deletes pods.
The volume manager started the reconcile loop.

Volume re-attach to a replica that is on an unschedulable node.
kubelet stopped
CSI involves node publish volume and the target mount point is corrupted, the target mount point deleted

Do you mean that the previous pod is successfully deleted (along with the previous volume unmounted and detached)? And will the new pod attach the volume onto a different node? I am not sure what step 5 means...

Do you mean that the previous pod is successfully deleted (along with the previous volume unmounted and detached)? And will the new pod attach the volume onto a different node? I am not sure what step 5 means...

Sorry if the steps look very confusing, I've reworded them a bit.
What I mean is the pod was not deleted before the Kubelet shutdown but Longhorn called for volume reattachment. Then Kubelet shutdown and the node gets the taint NoExecute, when the Kubelet restarts, the NodePublishVolume will continue as due to the reattachment, but also the taint managing might try to evict the pod due to the NoExecute taint.

Verified passed on master-head (longhorn-manager c7d9d7c) and v1.6.x-head (longhorn-manager 1640c56) by running negative test case Stop Volume Node Kubelet For More Than Pod Eviction Timeout While Workload Heavy Writing.
Test results:
master-head: https://ci.longhorn.io/job/private/job/longhorn-e2e-test/273/
v1.6.x-head: https://ci.longhorn.io/job/private/job/longhorn-e2e-test/274/

Memo of why this PR could fix the CSI issue:
What happens if kubelet is down for more than pod eviction timeout?

The taint manager sets a NoExecute taint for the pod on that node (Pod Eviction). And the pod becomes Terminating.
The corresponding volume gets crashed as well due to the instance manager pod eviction. This will trigger the volume automatic reattachment after kubelet back.

What happens after kubelet back?

The volume reattach mechanism will be triggered after kubelet is back. The volume will be rettached to the same node automatically.
Besides, the volume remount mechanism is triggered as well. But this does not matter since the workload pod is already marked as terminating.
As for kubelet, it somehow wrongly sends CSINodePublishVolume for the volume regardless of the corresponding pod is already in state Terminating.
After receiving call CSINodePublishVolume, due to the volume being already reattached, Longhorn CSI plugin will clean up the corrupted mount point then error out!!!
Later on, kubelet (volume manager) starts the regular reconcile loop. Inside the first step of the reconcile, the unmount handling, tries to read vol_data.json from the mount path. But here the path is not the mount point anymore, kubelet cannot read anything from the path. Then kubelet keeps failing at this step and the pod termination cannot be completed.

Notice that kubelet can read vol_data.json from a corrupted (read-only) mount point. To fix this bug, we need to guarantee that there is a mount point before step 5.
There are 2 potential solutions:

DO NOTHING and keep the corrupted mount point for this kind of volume in step 4 CSINodePublishVolume. But it's hard to figure out this kind of volumes/cases.
CSINodePublishVolume should set the mount point as long as the volume is mountable. This is the solution we choose. With the fix, CSINodePublishVolume will continue mounting the reattached volume correctly rather than erroring out after the corrupted mount point cleanup.

Later on, kubelet (volume manager) starts the regular reconcile loop. Inside the first step of the reconcile, the unmount handling, tries to read vol_data.json from the mount path. But here the path is not the mount point anymore, kubelet cannot read anything from the path. Then kubelet keeps failing at this step and the pod termination cannot be completed.

I am trying to evaluate what (if anything) we still need to do for https://github.com/longhorn/longhorn/issues/4782, so I am reading through all the context in this ticket. I keep getting hung up on this point. The linked code only unmounts /var/lib/kubelet/pods/.../pvc-####/mount. It does not delete /var/lib/kubelet/pods/.../pvc-#### or ``/var/lib/kubelet/pods/.../pvc-####/vol_data.json. In fact, I can find no location in our code that does this (I think only kubelet has this responsibility). Can you help explain a bit more why vol_data.json` goes missing @shuo-wu or @c3y1huang?


Update PowerToys index.md

Awake should not be localized since it is a product name.

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

#label:"aq-pr-triaged"

Good call! Thanks @franky920920!


[Bug]: Fix translocation removal behavior when unexpected things occur

Is there an existing issue for this?

[X] I have searched the existing issues

Contact Details
No response
Version Info
Compiled from develop
What operating system are you seeing the problem on?
macOS
Bug Behavior
When the anti-app-translocation quarantine removal runs during first launch, the following few things cause unwanted behavior to happen:

Launching Etterna without having the folder present. (i.e. accidentally only copying the app over). This should fail for obvious reasons, but with an error message or something instead of the current behavior of repeatedly opening Etterna in a loop
Launching Etterna through a shortcut instead of by directly clicking the app. This also causes Etterna to repeatedly open itself in a loop.
Launching Etterna from within a read-only location, most commonly the installer disk image. This is a common mistake made by first-time users which results in the same loop behavior.

Expected Behavior
No response
Reproduction Steps
No response
Anything else?
No response

Added extra detail about the most commonly encountered form of this bug, namely launching Etterna from within the installer dmg


mousePressed() Example Error

Most appropriate sections of the p5.js website?
Reference
What is your operating system?
Mac OS
Web browser and version
Chrome 116.0.5845.187
Actual Behavior
The example code at: https://p5js.org/reference/#/p5/mousePressed does not function, no response when key is pressed. This is due to an error in the variable names. It seems that the example was ported from the "keypressed()" examples which use "value". However, this example uses "colorValue" instead. So, the variable "value" on example code line 12 should be changed to "colorValue".
Expected Behavior
The example code should change the rectangle back and forth from black to white.
Steps to reproduce
Issue is currently live on the website at: https://p5js.org/reference/#/p5/mousePressed
Would you like to work on the issue?
It would be my first time but yes, I would be willing to work on this issue.

Resolved in #6413. Will be available upon the next release. Thanks.


Command-line flags page for query instances is not populated

The 'command-line flags' page is visible in the UI for query instances, but is not populated.
If the UI is only enabled on the query instances, perhaps it's not worth including this in the UI and would be better as an API endpoint?
It's inconsistent to expose this information for query instances but not other instance types, so maybe we should remove it entirely.

Other instance types like store, sidecar etc? Well, they don't have UI so there is no inconsistency. But let's remove it if it's not even populated - fair point.

Well, they don't have UI so there is no inconsistency.

That's part of where the inconsistency stems from, i.e. why would you use the UI to know the command-line flags for the query instance but not the other instances.

Totally agree :+1:
However, I am looking forward to seeing some other useful UI views like:

store/query nodes in the system and their labels/time ranges at the time.
last storeAPI errors if any
There was an idea to add these in a totally new UI, but maybe worth to add these in current UI ASAP as well


[RFC] allow to skip setgroups(2)

There are cases where it would be necessary to skip the setgroups(2) syscall so that the original additional groups can be maintained.
It can be used, for example, by rootless containers to keep access to a storage directory that is accessible only by a secondary group.
runc already skips the setgroups in some cases: either if the user had euid != 0 or if /proc/self/setgroups is set to deny.  I'd like to add a third condition where the setgroups is skipped also if explicitly requested.
Do we need a new field under process/user, e.g. keepOriginalGroups?  Would be enough to reuse additionalGids to have some special value (e.g. -1 to keep current groups)?

If we do add an option, it needs to have a really scary name (disableSetgroupSecurity or something). Not dropping supplementary groups weakens the userns security boundary, and really is something that very few people should actually want to do (not least of all because it will confuse all sorts of programs to be touching unmapped files).
In my view, the best solution to the problem of such volumes is to do exactly what LXD does -- "punch out" the GID that the storage volume is owned by (by adding a single 1:1 mapping for that GID). The most ideal solution would be the next-gen "shiftfs" work that was discussed recently, but obviously we'll have to wait for that to actually land.

I am skeptical, and think it could be a long wait, especially to get it upstream.

(Also I would seriously suggest that this is functionality that should be exposed through a runtime-specific annotation and not a first-class field in config.json -- the runtime-spec already has lots of really odd features we probably shouldn't have added, and this one just rubs me the wrong way.)

In my view, the best solution to the problem of such volumes is to do exactly what LXD does -- "punch out" the GID that the storage volume is owned by (by adding a single 1:1 mapping for that GID). The most ideal solution would be the next-gen "shiftfs" work that was discussed recently, but obviously we'll have to wait for that to actually land.

how would it work with rootless containers or in general with IDs that are not mapped in the current namespace?  I guess rootless containers won't still be able to map arbitrary IDs from the host.

Hello @cyphar ,
I also agree with Giuseppe since I have a customer that has exactly the same problem: he is wanting to use rootless podman but is currently limited by the missing subgroups to access mounted directories..
Also not sure why you think it would be a a decreased security boundary: I mean all groups the user has configured are exptected to be inherited with such an option; why limit it to the main group only?
About what kind of option should be used by runc, I'm of course open to any naming etc since that is less relevant.
What is relevant for my customer is that he will still decide to go with rootless podman depending on this feature to work or not, since otherwise he does see only the chance to run it as root which from a scurity point of view I guess it's clearly worse..
Thanks for letting me know,
Cisco.

This feature has become very popular in Rootless Podman,  We are seeing lots of users that need access to files and devices, via supplemental groups. We have recently made this a first class feature of podman.
podman run --group-add keep-id ...
Currently this is only supported in crun, and we would love to get it to work in runc.  I would hope in the future we had better support, where we could keep access to the groups as well as add groups within the user namespace, but for now this fixes a key issue rootless users are hitting.  I think we see this a lot more in enterprise customers then we even see in wild.

@kolyshkin @mrunalp @AkihiroSuda  @vrothberg FYI.

As an unprivileged user on a host, I have read/write access to various files, some via ownership and some via group membership.
I can mount any files I want into my container as volumes, but I can only read/write to the ones I own.  The ones I access via my group memberships can only be read/written via podman with crun thanks to the --group-add option.
I don't really understand why this is only possible via the special crun flag; if I can bring files into my rootless container by mounting them as volumes shouldn't I be able to access them in the same way as outside the container?
I know there are technical reasons, but I think the security model should be considered differently in different contexts.  Sometimes a container is used to isolate and contain an external application (i.e. something pulled from a repository) in a controlled environment and you don't want it to see or touch anything outside.  But in other cases (Singularity, rootless podman), you as the user are already "outside" and you're choosing to contain yourself , so you should have full control of how that happens and how to invoke the containment tool; the same security considerations do not apply since you can already do whatever you want on the host.

@rptaylor

I know there are technical reasons, but I think the security model should be considered differently in different contexts. Sometimes a container is used to isolate and contain an external application (i.e. something pulled from a repository) in a controlled environment and you don't want it to see or touch anything outside. But in other cases (Singularity, rootless podman), you as the user are already "outside" and you're choosing to contain yourself , so you should have full control of how that happens and how to invoke the containment tool; the same security considerations do not apply since you can already do whatever you want on the host.

I want to add as the sysadmin of a HPC batch cluster at major biomed academic center, this secondary group issue is the primary reason we are using Singularity rather than rootless podman.  We use secondary groups extensively for various users and group to work together on sensitive data sets.  Containers are used to run analysis programs like Tensorflow from NVIDIA NGC or distributed docker images of apps built on (for example) Ubuntu 20 that otherwise cannot run on the RHEL7 nodes.

@rptaylor

I know there are technical reasons, but I think the security model should be considered differently in different contexts. Sometimes a container is used to isolate and contain an external application (i.e. something pulled from a repository) in a controlled environment and you don't want it to see or touch anything outside. But in other cases (Singularity, rootless podman), you as the user are already "outside" and you're choosing to contain yourself , so you should have full control of how that happens and how to invoke the containment tool; the same security considerations do not apply since you can already do whatever you want on the host.

I want to add as the sysadmin of a HPC batch cluster at a major biomed academic center, this secondary group issue is the primary reason we are using Singularity rather than rootless podman.  We use secondary groups extensively for various users and group to work together on sensitive data sets.  Containers are used to run analysis programs like Tensorflow from NVIDIA NGC or distributed docker images of apps built on (for example) Ubuntu 20 that otherwise cannot run on the RHEL7 nodes.

If it can be useful for you: Podman when used together with crun supports the --group-add keep-groups extension to skip setgroups in the container

If it can be useful for you: Podman when used together with crun supports the --group-add keep-groups extension to skip setgroups in the container

crun is not available on RHEL7 that I can find
There is an oddness on CentOS8 Stream box
$ rpm -q podman
podman-4.0.2-1.module_el8.7.0+1106+45480ee0.x86_64
$ rpm -q runc
runc-1.0.3-3.module_el8.7.0+1106+45480ee0.x86_64
$ ls -ald /tmp/gptest
drwxrws---. 2 root sysadm 4096 May 18 15:44 /tmp/gptest
$ groups
raines httpd fsdev sysadm coregp webdev hcpdata
$ podman run -it --runtime=/usr/bin/crun  --userns=keep-id --group-add=keep-groups -v /tmp/gptest:/gptest b1b6387124d9 /bin/bash
raines@806c89baacd3:/$ groups
raines nogroup
raines@806c89baacd3:/$ id
uid=5829(raines) gid=5829(raines) groups=5829(raines),65534(nogroup)
raines@806c89baacd3:/$ cd /tmp/gptest
bash: cd: /tmp/gptest: No such file or directory
raines@806c89baacd3:/$ cd /gptest
raines@806c89baacd3:/gptest$ uname -a > foobar.txt
bash: foobar.txt: Permission denied
raines@806c89baacd3:/gptest$ ls -ald .
drwxrws---. 2 nobody nogroup 4096 May 18 19:44 .
The 'nogroup' thing is wierd (singularity reports the groups normally) and I don't understand why I can cd to /gptest (read access) but not write.

It is not available on RHEL7. I think you need to specify the --runtime option to o podman before the run like podman --runtime=... run ...

On fortunately still not quite right:
$ echo here > /tmp/gptest/iamhere.txt
$ mkdir /tmp/gptest/subdir
$ ls -ald /tmp/gptest/subdir
drwxrwsr-x. 2 raines sysadm 4096 May 18 16:46 /tmp/gptest/subdir
$ podman --runtime=/usr/bin/crun run -it --rm --annotation=run.oci.keep_original_groups=1 --userns=keep-id --group-add=keep-groups -v /tmp/gptest:/gptest b1b6387124d9 /bin/bash
raines@6bcd8fc2304e:/$ groups
raines nogroup
raines@6bcd8fc2304e:/$ ls -ld /gptest
drwxrws---. 2 nobody nogroup 4096 May 18 19:44 /gptest
raines@6bcd8fc2304e:/$ cd /gptest
raines@6bcd8fc2304e:/gptest$ ls
ls: cannot open directory '.': Permission denied
raines@6bcd8fc2304e:/gptest$ echo foobar > foobar.txt
bash: foobar.txt: Permission denied
raines@6bcd8fc2304e:/gptest$ cat iamhere.txt
here
raines@6bcd8fc2304e:/gptest$ echo too >> iamhere.txt
raines@6bcd8fc2304e:/gptest$ cat iamhere.txt
here
too
raines@6bcd8fc2304e:/gptest$ cd subdir
raines@6bcd8fc2304e:/gptest/subdir$ ls
ls: cannot open directory '.': Permission denied
raines@6bcd8fc2304e:/gptest/subdir$ ls -ald /gptest/subdir
drwxrwsr-x. 2 raines nogroup 4096 May 18 20:46 /gptest/subdir

So actually it is 'x' bit that works for the cd, but 'r' and 'w' do not.  But one can read and write to existing files in the dir.  Really wierd.


Allow configuring fixture location

A lot of Symfony applications don't use bundles. Without the ability to specify a custom location of fixture files, this bundle is useless in the no-bundles setup.

Well, I wouldn't say that a lot Symfony applications are not using bundles, but there is at least some and making this configuration would be a good feature. This is in progress, see #71, but unfortunately I couldn't find the time to finish it, maybe at the end of the year. Any help on that is welcomed :)

I solved the problem locally by overriding the Hautelook\AliceBundle\Doctrine\Finder\FixturesFinder class in a compiler pass with this code:
<?php
namespace App\Misc;

use Hautelook\AliceBundle\Doctrine\Finder\FixturesFinder as BaseFixturesFinder;

class FixturesFinder extends BaseFixturesFinder
{
    /**
     * @var string
     */
    private $rootDir;

    /**
     * @param string $rootDir
     */
    public function setRootDir($rootDir)
    {
        $this->rootDir = $rootDir;
    }

    protected function getLoadersPaths(array $bundles, $environment)
    {
        return [$this->rootDir.'/DataFixtures/ORM'];
    }
}

<?php
namespace App\Misc;

use Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;

class OverrideServiceCompilerPass implements CompilerPassInterface
{
    public function process(ContainerBuilder $container)
    {
        $definition = $container->getDefinition('hautelook_alice.doctrine.orm.fixtures_finder');
        $definition->setClass(FixturesFinder::class);
        $definition->addMethodCall('setRootDir', [$container->getParameter('kernel.root_dir')]);
    }
}

It was pretty easy to do. I'd be even easier to do if you didn't hardcode the class used for hautelook_alice.doctrine.orm.fixtures_finder so that I could override it with a parameter.
I'm short on time myself. Otherwise I'd help with the bundle. :wink: I might one day though.

Ha your solution is good enough for a temporary solution :)
Yeah I'm not a big fan of classes as parameters, but you have the FixturesFinderInterface so you can just roll your own Finder and override the finder service completely (instead of changing the classname via a parameter).

Using parameters for classnames instead of hardcoding them is a very common and idiomatic approach for reusable bundles. :wink:

It used to be considered as a best practice, but it often resulted with tons of parameters never used for most people and needlessly polluting your parameter bag. It's arguable, but IMO for such specific use cases you're as good to declare your own service to override the bundle one instead of just trying to change the bundle service classname. Besides, it often hides the real problem. Here for example, the configuration path should be configurable, and it should be made so instead of providing a more hacky way to solve that.
But well in the end it's more a matter of taste ;)

Little update on the issue, a easy temporary solution besides yours is to override the service used:
<service id="hautelook_alice.doctrine.orm.fixtures_finder"
                 class="Hautelook\AliceBundle\Doctrine\Finder\FixturesFinder">
            <argument type="string">DataFixtures/ORM</argument>
            <call method="setContainer">
                <argument type="service" id="service_container" />
            </call>
        </service>

I don't have much time to continue to work on 1.x, there was https://github.com/hautelook/AliceBundle/pull/71 but I could not finish it.
2.x will support it.

The support has been added to 2.x :)

Cool. Thanks. 🙂


Implement a device type SCSG based on the Linux SG 3 driver, e.g. for SCSI-to-USB

A new device type SCSG shall use the Linux SG 3 (generic SCSI) driver. This device type exposes any device that the Linux SG driver supports as a SCSI device, e.g. USB drives.
As all commands are passed through to the actual device, INQUIRY does not report "SCSI2Pi:SCSI HD" but the real name of the device, based on the device's INQUIRY data. The same applies for other device data like the SCSI level.
Notes:

Linux limits the maximum SCSI transfer size per SCSI command. This means that s2p has to split large transfers into smaller chunks. s2p does this for block-oriented commands, but not for others.
s2p can only support known SCSI commands, i.e. those listed on https://www.scsi2pi.net/en/scsi_commands.html. This is because the target (s2p) needs to know the number of bytes in each CDB.  Unknown commands are rejected with INVALID COMMAND OPERATION CODE.
Knowledge about each command is also required in order to correctly split large transfers into smaller ones, e.g. a single READ(10) transfer in several smaller READ(10) transfers with sizes within the Linux limits.

My POC is working except for transfers >= 128 KB. The SG driver rejects these. I hope the author of the driver can help.

A work-around has been applied because Linux (depending on the kernel and the device drivers) indeed has limits wrt to the maximum SCSI transfer size.

This feature has passed initial tests with an Atari TT, accessing a USB stick plugged into a Pi.


Model architectures should appear in alphabetic order

Yeah sure why not

I get triggered when they don't 😅


Add base types for Swift pod compilation.

Small PR that adds a base_types directory when each language can add any required source files to be distributed alongside the generated events (I think this may only be necessary with Swift for now).
Also updates the podspec to add these and with a plan of maintaining a release/swift branch that element-ios will use for its dependency.

On Android I have VectorAnalyticsEvent and VectorAnalyticsScreen that I host in Element Android project for now, but could possibly be hosted here.
If in the future we want this project to host a binary for Android (Jar) it will be mandatory to do that or the generated code cannot be compiled.


Improved logging

Hi there. Very useful package you have there! Would you be interested in a contribution with extended logging statements using the debug module (see https://www.npmjs.com/package/debug)? I've had to hunt down an issue in my usage of the code and some extended configurable logging would have helped.

Sure that would be awesome.


Built in support for static translations

It would be nice to have the possibility to statically translate Keys in the HTML. An angular-translate build task for Grunt and Gulp if you may. If you need a reference as to what Im talking about:
https://mobinni.io/2015/06/21/quickfire-compiling-angularjs-with-static-translations/

Something like https://github.com/angular-translate/grunt-angular-translate ?

I think so after a short glance at the library. Quick question, does it search for all the translations in HTML for instance and generate static HTML, for instance:
locales
- nl.json
- en.json

After task
dist
- views (en views)
- nl
  - views (nl views)

This so you have base routes to certain translated views?

Sorry for the delay.. please restart the question in this repo. Hopefully, the (sub) maintainer can answer this more precisely. I'm not aware of all features of the grunt task.. Ok?

No problem I will!


[iot-modelsrepository] add ci.yml

/cc @YoDaMa

@mitchdenny Should the CI be running as part of this PR, or only after the ci.yml file is merged?

/azp run prepare-pipelines


semantic_analyser: validate use of calls as map keys

Fixes: https://github.com/iovisor/bpftrace/issues/697
Fixes: https://github.com/iovisor/bpftrace/issues/633

@mmarchini  ping

Merged in #975


HEIC file support and HEIC HDR file support (19H1 and above)

Todo: use embedded metadata when possible. Unclear if we want to trust this over explicitly generating metadata via compute shader.
/heifHDR/MaximumLuminanceLevel
/heifHDR/MaximumFrameAverageLuminanceLevel
/heifHDR/MinimumMasteringDisplayLuminanceLevel
/heifHDR/MaximumMasteringDisplayLuminanceLevel
/heifHDR/CustomVideoPrimaries

Fixed as of commit: 2c01a5ac9d54da907e139e8e371a23345a672429


Undefined Behavior in signed right shift microkernel IREE_UKERNEL_X32B_SHRSI

I'm seeing undefined behavior on 32-bit android when importing into Google's monorepo. Specifically, the shift exponent is -1. I'm guessing this is improper casting going on in ASSI32:
#define ASSI32(ptr) *((iree_ukernel_int32_t*)ptr)
Isn't that blindly casting a uint32 to an int32?
https://github.com/iree-org/iree/blob/ab6ba22d2d/runtime/src/iree/builtins/ukernel/elementwise_impl.c.inc#L183

Perhaps duplicate of https://github.com/iree-org/iree/issues/10156


Need validation for the Newsletter form

Description

There is no validation of the input fields in the newsletter form .
Expected Behavior

should not proceed without any input
Screenshots

Enviroment:

OS: [e.g. Ubuntu]
Browser: [e.g. Chrome, Safari]
Version: [e.g. 22]
Device: [e.g. laptop, iPhone 8]

[Optional] To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

[Optional] Additional Context
Add any other context about the problem here.
Contributor Resources
The meshery.io website uses Jekyll and GitHub Pages. Site content is found under the master branch.

See the Contributing to Meshery.io Website section of the readme.md and other contributing instructions, too.
See Meshery site designs in this Figma designfile. Fill-in the Layer5 Community Member Form and join the Layer5 Community Slack for access.

Hi @YashKamboj, Can I work on this issue, please?

Yeah!!, Go ahead 👍

👍

@Vidyaa123 Yeah!!, Go ahead 👍

👍

@Vidyaa123 you can check layer5io/getnighthawk#234 for reference, if you face any problem

@Vidyaa123 you can check layer5io/getnighthawk#234 for reference, if you face any problem

I have completed and raised a PR for this issue.

Oh, you forgot to connect the pr


withColorProvided and useColor are not exported

It looks like withColorProvider is not exported in version 3.2.2
In my node_modules I see:
export { Alpha$2 as Alpha, Alpha as AlphaPicker, Block$1 as BlockPicker, Checkboard, Chrome$1 as ChromePicker, Circle$1 as CirclePicker, Compact$1 as CompactPicker, ColorWrap$1 as CustomPicker, EditableInput$1 as EditableInput, Github$1 as GithubPicker, Google$1 as GooglePicker, Hue$2 as Hue, Hue as HuePicker, Material$1 as MaterialPicker, Photoshop$1 as PhotoshopPicker, Raised, Saturation, Sketch$1 as SketchPicker, Slider$1 as SliderPicker, Swatch$1 as Swatch, Swatches$1 as SwatchesPicker, Twitter$1 as TwitterPicker };

So I can't access neither useColor nor withColorProvided

Bump


Accurate Acre Images

The Island Acres need Acre Editor images. There are default ones for Island Left & Right (2), but they aren't size accurate.

I can help out with graphics

I'd very much appreciate the help! If you want to create only accurate island images, then that's fine. If you feel like making acre images like how NLSE has them, then you are welcome to as well. It's not a necessity, but I was considering doing it after the core features are complete.

Message me on skype?

Sure, my Skype is cuyler.36

Done.

Opened again until all acres have a "real" image.

I'd like if the acre maps included the large bushes and also ponds, if that wasn't already planned
I could try and help with graphics if it's still needed?

That was planned. I was actually just taking screenshots from a modified version of Dolphin I made. It sets the camera top-down so I can get a view of the map properly. There are a ton of acres, however, and I've been busy with making the unified editor. Anyways, here's what it will look like for the GameCube games:

oh, nice!! this is great work you're doing : ) can't wait to see it!

Already finished in the new ACSE: https://github.com/Cuyler36/ACSE


Request to publish wheels for this package

Hi! Thank you for making this package ❤
I am using a build tool called bazel which only works with python wheels: https://github.com/tubular/rules_pygen
It seems that wheels are currently not published for the pandocfilters package. Please could you publish wheels for this package?
The instructions at https://pythonwheels.com/ may be helpful, it says that once you have installed the wheel package, where you would normally run python setup.py sdist, instead you can run python setup.py sdist bdist_wheel.

Duplicated. See #55.

For pure Python packages, to create a wheel along with source distribution:
(venv) $ pip install --upgrade pip setuptools wheel
(venv) $ python setup.py sdist bdist_wheel

# See dist/*.whl

To upload wheels:
(venv) $ pip install twine
(venv) $ twine upload dist/*

Duplicated. See #55.

As mentioned in the other thread, I barely maintain this now.
I actually never use Python and don't know the first thing about its packaging infrastructure.
It would really be better if someone else could take over maintenance of the pandocfilters package; I just have too much on my plate as it is...

I can help maintaining it if you want.

@ickc that would be great, I'll give you privileges on this repo.

Thanks!
Do you want me to manage the package at PyPI too? In that case you'll need to invite me as maintainer at PyPI as well. The handle is the same (ickc.)
A few things I probably will be working on:

go through the issues/PRs
add CI testing, perhaps improve the "Compatibility" section in the README
may be add type annotations, which means that at some point we're going to drop Python2

do a final release for Python2 first before dropping it

improve the dist as mention in this issue

may work with conda-forge recipe maintainer(s) to add run constrains matching pandoc versions.

Does that sound good?
I think it will be more about maintaining than adding any new things. As I'm helping maintaining panflute too, that would be the recommended tool to use. But there exists an ecosystem (especially in the backend like RMarkdown, jupyter) that depends on this so this should be continued to be maintained in the foreseeable future.

Great, I've invited you as maintainer.

That all sounds good to me.