[BUG]: SCOOP_GH_TOKEN does not get respected

Prerequisites

[X] I have written a descriptive issue title.
[X] I have searched all issues/PRs to ensure it has not already been reported or fixed.
[X] I have verified that I am using the latest version of Scoop and corresponding bucket.

Package Name
none
Expected/Current Behaviour
Expected behaviour is that checkver.ps1 uses the SCOOP_GH_TOKEN env variable to fetch remote packages that require authentication to get to
Steps to Reproduce
* Create Scoop bucket with Autoupdate
* Add package manifest for private repository
* Add Auto update actions workflow
* Add SCOOP_GH_TOKEN to secrets and set it as Environment variable
* Run Workflow

Possible Solution
Maybe the checkver.ps1 script doesn't properly work with CI environment variables?
Scoop and Buckets Version
Current Scoop version:
v0.2.4 - Released at 2022-08-08

### Scoop Config

```console
No config as this is a CI job

PowerShell Version
pwsh so Probably Powershell core 7

Additional Softwares
No response

Use GITHUB_TOKEN that mentioned in README.
https://github.com/ScoopInstaller/GithubActions#available-environment-variables

Wrong token... the GITHUB_TOKEN is for the local repository but this is getting releases from other repositories. GITHUB_TOKEN is specified too its just that the SCOOP_GH_TOKEN Isn't.
on:
  workflow_dispatch:
  schedule:
  - cron: '0 0 * * *'

name: Updater
jobs:
  update:
    name: Auto Update
    runs-on: windows-latest
    steps:
    - uses: actions/checkout@main
    - name: Update Packages
      uses: ScoopInstaller/GithubActions@main
      env:
        SCOOP_GH_TOKEN: ${{ secrets.PAT_TOKEN }}
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        SKIP_UPDATED: '1'
        THROW_ERROR: '0'

here is the workflow file for reference

https://github.com/ScoopInstaller/Scoop/blob/4a31bd330244f7f89f16208cdddda3f9edac2d65/bin/checkver.ps1#L136-L149
https://github.com/ScoopInstaller/Scoop/blob/4a31bd330244f7f89f16208cdddda3f9edac2d65/bin/checkver.ps1#L178-L183
checkver supports GITHUB_TOKEN, and could you give a wrong CI workflow URL?

Not public sorry so I cannot send a link to the wrong CI workflow. But in the logs it says:
Your branch is up to date with 'origin/main'.
Package1: The remote server returned an error: (404) Not Found.
URL https://api.github.com/repos/Org/Package1/releases/latest is not valid
Package2: The remote server returned an error: (404) Not Found.
URL https://api.github.com/repos/Org/Package2/releases/latest is not valid

(note the url's are only representative)
Also note that the token only has access to a single repository but this is a bucket that has to update based on other private repositories.

Since the App has access to a single repo, the token's permissions are limited to the repository that contains your workflow

Neither of the links prove that checkver supports GITHUB_TOKEN. in Checkver.ps1#182 It uses $GitHubToken which comes from the Get-GitHubToken function defined in lib/core.ps1#1088-1090 which clearly uses the $env:env:SCOOP_GH_TOKEN that I am using

Convertion is here:
https://github.com/ScoopInstaller/GithubActions/blob/bb7b1030a83bc3496b96f3513520747850d3e21f/src/Action/Scheduled.psm1#L26
This action assigns GITHUB_TOKEN to SCOOP_GH_TOKEN.

Still a problem since now its overriding a token that has access to all repositories with one that has only access to a single repo

^ Created PR fixing the problem

Closed since #18 was merged


Unable to install eks anywhere with kindnetd cni due to image tags in public.ecr.aws have been changed.

What happened:
kindnetd image tag has been changed on public.ecr.aws from v0.18.0 to v0.18.0-eks-a-45
What you expected to happen:
This cause issue to install eks anywhere on docker when cillium cni has issue to start.
How to reproduce it (as minimally and precisely as possible):
on clean docker factory setting.
run
CLUSTER_NAME=mgmt eksctl anywhere generate clusterconfig $CLUSTER_NAME \    --provider docker > $CLUSTER_NAME.yaml
Then update  mgmt.yaml from cilium to kindnetd
Then run
eksctl anywhere create cluster -f $CLUSTER_NAME.yaml
then use docker ps to inspect hang installation and you will see the image was unable to be pulled down for cni.
Anything else we need to know?:
Environment:

EKS Anywhere Release:  0.18.3
EKS Distro Release: 1.28

I'm also seeing the exact same issue. I'm trying to use Kindnetd because I cannot bootstrap the cluster with Cilium networking on my M1 Mac.

Ill take a look at this, I can repro it as well.
@robertlcx you should be able to create clusters with cilium on M1 Macs, I usually work on M1 mac as well.

@jaxesn just curious. I am using docker for mac on intel. But I see there seems issue to run ebpf on docker for mac? The reason we use kindinetd cni is I can get kind running. but i am having issue to run cilium on docker itself and also in eks anywhere (cilium just crashed).
It there any setting we need to adjust in docker for mac desktop to enable ebfp?

Oh thats odd, I don't believe so. I will try to today on my M1 with cilium to make sure that still works as expected. Ill see if someone can try on an intel mac to confirm as well.
What version of docker do you have installed?

@jaxesn I am using docker desktop for mac intel version
version 4.26.0 (130397)
Engine: 24.0.7
Compose: v2.23.3-desktop.2
Credential Helper: v0.7.0
Kubernetes: v1.28.2

I am seeing the same bpf issue on my mac as well. This is "newish", we've def seen this work in the past. Ill do a like poking around to see if there is a workaround.
@abhay-krishna also fixed the kindnetd manifest for our 0.18.x releases so you should be able to create docker clusters using kindnetd now.

I think this is the same issue: https://github.com/kubernetes/minikube/issues/17780
Try downgrading to the 4.25.x release of docker for mac.

@eugenejen @robertlcx were you able to get further in your cluster creation?

@abhay-krishna i downgraded to 4.25.x. but now i am getting another issue on https://github.com/aws/eks-anywhere/issues/6678 and unable to resolved it.

@eugenejen did you try the workarounds suggested in that issue, particularly switching from VirtioFS to gRPC Fuse? You will find this option under the General tab in the Docker Desktop Settings menu.

@abhay-krishna i have verified that I can swithc to use gPRC Fuse and the issue is resolved and cilium is running.

@eugenejen @abhay-krishna managed to fix this by downgrading to 4.25.x, switching back to cilium, and using gRPC Fuse instead.
Up until a couple of days, my fix was running an older version of eksctl and eks-anywhere, but now, some of the older images have been yanked from their Docker registry, so it wasn't working anymore.


Add phone and website fields to more presets

phone and website are two of the most important information to someone that is searching for a place or using a map app, but they are not a default field in a large number of presets. I think all shops / education / food related presets should have it as default to stimulate people and make it faster to add phones and website values. I can do this job if you agree.

Contact Information is important, but there are already many default fields for some object types (e.g. restaurant). It's up to @bhousel and others to decide about pull requests. Please read https://github.com/openstreetmap/iD/blob/master/data/presets/README.md anyway.

@manfredbrandl Sure we have some exceptions, but, for example, the restaurant preset has a capacity field that is too difficult to survey and less important. Other example: the cafe preset has a wifi essid field.

@willemarcel Please make a pull request for adding phone and website for restaurants (or some other feature type), put the fields in suitable order and wait if @bhousel or someonelse merges it.

Hmm no, this slipped off my radar over the weekend (there was a lot of activity on other issues, and I get an email for every single thing).  Please don't send a PR for this.
I'd really prefer not to default display "Phone" and "Website" fields on all the presets.  I think we already show too many fields (I agree that things like "Capacity" and "Wifi SSID" are probably unnecessary).  I sometimes think we should default hide "Address" and "Operator" too.
The interface for adding more fields is pretty good, but users won't know to use it if they need to scroll past a bunch of unimportant and empty fields to see it.  (We do train people in the walkthrough to use this).
I wonder if it would make more sense to set up the presets up so that we show only the top 4 or 5 fields and then push all the rest of them into the "Add field" dropdown.
Or create an explicit "Add field" list for every preset instead of relying on "universal" presets (which are honestly not that universal - users shouldn't put wheelchair access on an admin boundary, or a phone number on a traffic signal).
Let's discuss a bit instead of just adding more fields under the rationale that "other less important fields are already shown".

May i suggest, that the object editor shows "Default fields" and "More fields" instead of "All fields" and have "More fields" collapsed first and users can expand them like they can now with "All tags" and "All relations". That would make it easier than selecting fields from a list. Now it looks like:

Or create an explicit "Add field" list for every preset instead of relying on "universal" presets

I really like this idea!

My idea of more fields is just another view on the "add fields list". Being able to add fields-content with as few clicks as possible and seeing many options together is a priority, that's why I would prefer "more fields" with "add fields from specific list" in the end.

Or create an explicit "Add field" list for every preset instead of relying on "universal" presets

#4871

Yeah this is moved to #4871
closing here


wordpress: 5.5.1 -> 5.5.3

Motivation for this change
Fixes CVE: #102914
Will need backport to 20.03 and 20.09 branches
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.


Losing wifi credentials

Hi,
I've integrated wifi manager into a battery operated mailbox detection solution. Here I've used the ESP-Wrover module because it can operate on lower voltages. It is powered by 2 x AA.
I notice from time to time that the wifi credentials are lost and needed to be re-configured with the wifi manager ui.
Any idea what can cause this behavior?
Thanks,

I've noticed similar behavior on older version of wifi-manager, but I've never been able to figure out how to repeat the issue.

With recent versions I also have the same problem.

I have also the same problem at latest version.

I have noticed this as well...sometimes it randomly will need to be reconfigured.

I think I figured this out. Comment out line 945 and it will fix it.
The sporadic erasing of credentials happens if you lose wifi signal too many times, or the connection times out.
https://github.com/tonyp7/esp32-wifi-manager/blob/master/src/wifi_manager.c#L945

This is fixed as of v3.1


error in documentation

hello,
we can read in ReadMe :
/* release a reader */
r = eredis_r_release( e );
e or reader ?
Regards,
Nicolas

thank you. bogus line corrected.