text:
error: src refspec HEAD does not match any

git init
git add .
git commit -m "And so, it begins."
hub create -p

git push -u origin HEAD
Initialized empty Git repository in /Users/florin/Coding/MICROSERVICE/.git/
On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)
Updating origin
https://github.com/baditaflorin/MICROSERVICE
error: src refspec HEAD does not match any
error: failed to push some refs to 'github.com:baditaflorin/MICROSERVICE.git'

using the code from the 3rd example
https://hub.github.com/

Using Apple MacOSX
This command worked
# create a repo to host a new project on GitHub
git init
git touch .gitignore
echo ".env" > .gitignore
git touch .env
git add .
git commit -m "And so, it begins."
hub create -p # (creates a new GitHub repository with the name of the current directory)
git push -u origin HEAD

@baditaflorin Hi, sorry that our examples aren't a bit clearer.
As you've found out, these git commands only work if there are files to commit:
git add .
git commit -m "And so, it begins."

Hub examples require some basic knowledge of git, such as making commits.
It sounds like you create a file and managed to push in the end, so I'm going to close this one out. 🙇

@ baditaflorin
git touch .gitignore
git: 'touch' is not a git command. See 'git --help'

doesn't work here, still facing the error

error: src refspec HEAD does not match any
error: failed to push some refs to 'origin'

authors: Mitulsharma123 baditaflorin mislav


text:
Fix git remote when using -C:

use Git root dir instead of working dir to pick a repo name.

Fixes #1105.

Hi thanks for the contribution but your diff was pretty big, and I was sure that the fix for the original issue should be pretty small so I've attempted it myself: 40e0cd22fd141d9b98bb69626f338f4fd9d581af
In the future, could you split different fixes/features into separate PRs?
What does the git root dir change fix and could you open a new PR which only addresses that? Thanks!

I had almost the same code as you do (with the same little change), and then start testing with a real case scenario (instead of unit test as you do), using the scenario described in #1105. I quickly realized that it was then taking the wrong name for the repo, and used the name where the user was working (aruba.git in my case) instead of the one that was specified by -C (dotfiles in my case).

Could you now extract your git root dir name fix as a separate PR please?

Could you now extract your git root dir name fix as a separate PR please?
Done.

A friendly ping.

Thanks for your patience. I wasn't completely on board with your refactoring of helper functions. For instance, the RootDirName() function seemed to be a misnomer since it didn't really return the actual git root directory. All it did is resolve the result of -C global flags, but if those were missing, the function returned a blank string. Also, if you were deeply nested within a project's subdirectories, this method wouldn't return the root directory for the project.
Instead, I've adopted your test and taken my own approach. First, I removed utils.DirName() dependency from some commands. Then, I've replaced remaining DirName() invocations with a combination of two new commands: git.WorkdirName() & github.SanitizeProjectName(). The resulting invocation are a bit more explicit and thus more clear in what they do, the individual functions are simpler, and I avoided having to change git.Dir() function.

Great, I like it.

source: gharchive/pull-request

authors: mislav pcorpet

repo: github/hub

license: mit

license_type: permissive

license_source: bigquery


text:
disassemble.coffee breaks Hubot help

Gets itself into an infinite loop screaming NO DISASSEMBLE

What adapter are you using?  Hubot shouldn't respond to himself, ever.

Talker

if that's broken in the adapter, that would explain why a number of other help lines goof up and trigger themselves

Yeah, I'd take this up with the talker adapter owners.

source: gharchive/issue

authors: atmos rpavlik

repo: github/hubot-scripts


text:
Pasting HTML with links can place link in the wrong place

When pasting HTML such as this:
example example
...the link will end up at the wrong place in the pasted Markdown. This appears to be because we search the text/plain clipboard content for the first occurrence of the linked string. This is a reasonable heuristic, but ends up with edge cases like the one above.
I'm not sure what the right solution here is, but since we have a document returned by a DOMParser, anyway, perhaps we could instead generate Markdown by using NodeIterator or TreeWalker?

I missed this one coming through @jclem – thanks, you're right. We'll take a look.

authors: imjohnbo jclem

repo: github/paste-markdown

license: MIT

license_source: github-api


text:
[Release Radar Request] Spaceship Prompt v4.0

Open Source Project name
Spaceship Prompt
What is your project?
Spaceship is a modular, customizable Zsh prompt. One of the most popular terminal prompt out there. It shows the context of the current environment, like versions of the compiler, runtimes, repository statuses, background jobs, etc
Version
4.x
Date
September 1, 2022
Description of breaking changes

Asynchronous rendering. Most of the computation happens in a separate process, so a user can type the next command right away, without waiting for complex checks to be performed.
Registry for sections. Users now have a better API for creating custom sections and can explore and submit them to the registry on our website.
Configuration file. Spaceship configuration now can be placed in a single file ~/.spaceshiprc.zsh or ~/.config/spaceship.zsh and it will be automatically loaded.
Command Line Interface. CLI will help to perform common tasks easiear, like editing configuration, adding and removing sections, etc.

There are more features described in our blog announcement: https://spaceship-prompt.sh/blog/2022-spaceship-v4
GitHub Repo
https://github.com/spaceship-prompt/spaceship-prompt
Website
https://spaceship-prompt.sh/
Link to changelog
https://spaceship-prompt.sh/blog/2022-spaceship-v4
Social media
https://twitter.com/SpaceshipPrompt/status/1566742940759650305
Anything else to add?
This release is mostly made during the wartime. I was working on this release mostly to get my mind off the reality. This release is partly made when I was sitting in a shelter.

Congrats on being featured in the September 2022 Release Radar 🥳

Read the blog here
Check out our GitHub Tweet

authors: denysdovhan mishmanners

repo: github/release-radar


text:
[RR Request]: Papermark v0.9.0

Open Source Project name
Papermark
What is your project?
Papermark is the open-source DocSend alternative with real-time engagement analytics and fully customizable including custom domains, custom branding, and custom metatags.
Version
v0.9.0
Date
February 1, 2024
Description of breaking changes
This is the first named release of Papermark, which is still pretty big because now Papermark is 100% white-label. This means document senders can add their own custom domain, their own logo and brand color as well as custom metatags (title, description, image) for each shared link.
Viewers of documents through the shared links will only engage with the brand of the sender.
Furthermore, we added gravatar support to show the user images of viewers based on their Gravatar image.

GitHub Repo
https://github.com/mfts/papermark
Website
https://www.papermark.io
Link to changelog
https://github.com/mfts/papermark/releases/tag/v0.9.0
Social media
https://twitter.com/papermarkio/status/1752984941418467765?s=20
Anything else to add?
This is actually the first ever named release of Papermark. Plus a big milestone in becoming 100% white-label solution.

Thanks for submitting this. We have a tonne of projects that shipped major version releases in January so we have to give preference to those. We'd love to feature this project, so please submit when you have version 1.0 and we can feature it 😄

authors: mfts mishmanners


text:
Enterprise-level overview dashboard organized by key domain

Summary
Enhance your understanding of your security landscape with our newly redesigned enterprise-level overview dashboard. This intuitive interface categorizes your security insights into three distinct, streamlined domains: detection, remediation, and prevention. Experience enhanced visibility with top-line metrics from GitHub Advanced Security’s preventative features such as secret scanning’s push protection and CodeQL’s alerts in pull requests. This refined design ensures that you can quickly and easily understand your security metrics, enabling more effective decision-making at a glance.
Intended Outcome
Security managers often struggle to effectively quantify and communicate the critical metrics from the key security activities. This redesigned dashboard makes it straightforward to navigate and understand the current status of your security operations. With immediate access to tangible metrics and insights, this feature empowers you to proactively manage prevention and remediation efforts, demonstrate their impact, and ultimately reduce your enterprise's risk exposure significantly.
How will it work?
The updated security overview dashboard introduces a dedicated prevention section, displaying essential metrics. You'll find vital indicators such as the number of vulnerabilities detected in pull requests, the tally of alerts resolved through autofix, and the count of secrets proactively blocked. Further, the existing dashboard components for detection and remediation have been refined to seamlessly integrate with this new structure. This comprehensive and actionable view enables your team to continually optimize and fortify your security protocols.

This shipped: https://github.blog/changelog/2024-05-23-code-security-and-secret-scanning-insights-for-your-enterprise-public-beta/
And with GHES 3.14: https://docs.github.com/en/enterprise-server@3.14/admin/release-notes

authors: ankneis github-product-roadmap

repo: github/roadmap


text:
Prefer Void over () for return types of closures?

Wanted to bring this up here after looking at ReactiveCocoa/ReactiveCocoa#2059. Personally I prefer () but it's probably better to be consistent with Apple.

https://devforums.apple.com/message/1133616#1133616
http://ericasadun.com/2015/05/11/swift-vs-void/

I can open a PR if there's consensus

Consistency with Apple on this seems worthwhile to me. But I don't have strong feelings.

I much prefer () too. Apple have been wrong with their standards plenty of times in the past. :trollface:

For what it's worth, my vote is certainly for (). I fail to see the value of Void as an alternative, it obscures more than it clarifies.

Void is a typealias, so the debugger (for example) is always going to print () instead. I suggest ().
That said, I’m not sure this actually warrants an entry in the style guide. I think the document is at its best when it’s encouraging best practices for the project and/or the team, and I’m not sure that () vs. Void really matters.

Just my 2 cents: whatever the final decision will be, I think this should be in the style guide to enforce consistency.

I think this should be in the style guide to enforce consistency.

Consistency for consistency’s sake isn’t really in this guide’s charter. “Fewer debates about aesthetics” is the last item on the list for good reason, and since we haven’t had a debate about this on our team, there’s little to be gained by adding it here.
That said, if a team finds this guide useful but has some key differences, they should feel free to fork it & add whatever they see fit—this is, after all, only one team’s style guide, and thus not necessarily representative of any other team’s needs.
Or otherwise put: I don’t believe that there’s a one size fits all solution to code style, and I’d prefer not to act too speculatively—after all, who knows what the language will look like a week from now? :smile:

I’m going to close this out since there isn’t much to motivate a style guide rule.

:+1:  Thanks for the discussion.

authors: MarcoSero alanjrogers alskipp mdiep neilpa robrix

repo: github/swift-style-guide


text:
move most documentation to docs/index.md

This PR moves most of our documentation to docs/index.md, in service of working towards having a separate documentation site.

I wonder if it would make sense to keep the quick start, or some variation of it in the README?

Agreed. I've added an item in the tracking issue: https://github.com/github/view_component/issues/505#issue-722474914


text:
Typo in RUNNER_PID variable name

This should be the same as in lib/support/init.d/gitlab_ci_runner.

:+1:

Thank you!

authors: Razer6 Wachiwi arantir

repo: gitlabhq/gitlab-ci-runner


text:
🛑 MSP-002 is down

In 2660fdb, MSP-002 (https://msp-portal.gw002.oneitfarm.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MSP-002 is back up in 9daaa73.

repo: gitsrc/upptime


text:
Updating to ACSII Quotes

Updating quotes per Splunk support to fix combability with Splunk 8.2.2105.2+

Thanks, must have missed that one

authors: gjanders jordanfelle

repo: gjanders/SplunkAdmins


text:
🛑 zetwal is down

In 2ebbf66, zetwal (https://www.zetwal.mq) was down:

HTTP code: 500
Response time: 631 ms

Resolved: zetwal is back up in acfa4ee after 22 minutes.

repo: glefait/martinique-public-websites


text:
🛑 Schoelcher is down

In 2938ba7, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in 35e71c7 after 5 minutes.


text:
🛑 Le Robert is down

In 4d59b83, Le Robert (https://www.ville-robert.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Le Robert is back up in b20d876 after 9 minutes.


text:
🛑 Schoelcher is down

In fb5abf6, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in 6d97915 after 5 minutes.


text:
🛑 Saint-Pierre is down

In c801f26, Saint-Pierre (https://saintpierre-mq.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Saint-Pierre is back up in 936f627 after 5 minutes.


text:
🛑 Schoelcher is down

In f62c5fd, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in bae3b50.


text:
🛑 Schoelcher is down

In c1e8ecb, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in e06d439.


text:
🛑 Comite Martiniquais du tourisme is down

In 8f573ea, Comite Martiniquais du tourisme (https://www.martinique.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Comite Martiniquais du tourisme is back up in 7d0e1ad.


text:
🛑 Schoelcher is down

In 512f8bb, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in edaf926.


text:
🛑 Schoelcher is down

In 9109393, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in 3d19b7e.


text:
Allow having short keybinds for the dashboard buffertype

Is your feature request related to a problem? Please describe.
Basically in https://github.com/startup-nvim/startup.nvim you could have very short keybinds like q to quit the editor or f to open the file explorer only when you are inside the plugin buffertype, currently it seems like I need to jump through hoops to have any sensible keybinding... for example this is my config currently for dashboard https://hastebin.com/jeqanemuso.lua but any of the keybinds don't really work even though visually everything is fine.
Describe the solution you'd like
Well allowing short keybinds for the dashboard buffertype
Describe alternatives you've considered
https://github.com/startup-nvim/startup.nvim

yup I already think about this. will implement it .

Is your feature request related to a problem? Please describe. Basically in https://github.com/startup-nvim/startup.nvim you could have very short keybinds like q to quit the editor or f to open the file explorer only when you are inside the plugin buffertype, currently it seems like I need to jump through hoops to have any sensible keybinding... for example this is my config currently for dashboard https://hastebin.com/jeqanemuso.lua but any of the keybinds don't really work even though visually everything is fine.
Describe the solution you'd like Well allowing short keybinds for the dashboard buffertype
Describe alternatives you've considered https://github.com/startup-nvim/startup.nvim

You can creata an autocmd for that:
-- Set keymaps only when dashboard is active
vim.api.nvim_create_autocmd('FileType', {
  group = vim.api.nvim_create_augroup('DashboardMappings', { clear = true }),
  pattern = 'dashboard',
  callback = function()
    vim.keymap.set('n', 'e', '<Cmd>enew<CR>', { buffer = true })
    vim.keymap.set('n', 'q', '<Cmd>q!<CR>', { buffer = true })
  end,
})

authors: MordechaiHadad glepnir gnsfujiwara

repo: glepnir/dashboard-nvim


text:
Make enums optional

Hey!
Awesome project you have, I love it, used for typescript and c#, however I would like to have the feature to toggle if it should generate enums or just put "string". Here is an example:

I have provided a sample data of about 50 entries, and I don't want to be limited to these colors for example. Right now I manually have to replace everything with string, but would be nice if it was a toggle to use enums or strings.
Thanks, best regards
Philip

I just want to reignite the discussion since we generate schemas from numerous sources and aim to avoid enum generation. It would also be beneficial to have the ability to specify field names for which we do not want to generate enums.

repo: glideapps/quicktype


text:
Capacity to specify timezones by env var

It would be great to be able to specify which timezone you run the container by just injecting the environment variable like in Debian:
 TZ: "Europe/Madrid"

This appears to already be supported by musl: http://wiki.musl-libc.org/wiki/Environment_Variables#TZ. Do you have an example that is not working?

@andyshinn thanks for the tip! It seems you have to install the tzdata package or specify in the POSIX way. On a running Debian/Ubuntu you can find that information for example in /usr/share/zoneinfo/Europe/Madrid.
In my case it was easier to change the env var:
TZ: "Europe/Madrid" → "CET-1CEST,M3.5.0,M10.5.0/3"

http://stackoverflow.com/tags/timezone/info
https://pkgs.alpinelinux.org/package/main/x86_64/tzdata

This doesn't appear to be working on alpine:latest as the tzdata package is not installed.
Once the tzdata package is installed, it correctly sets the timezone from the TZ environment variable.
# date
Fri Mar 31 03:41:11 GMT 2017
/ # apk --update add tzdata
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/community/x86_64/APKINDEX.tar.gz
(1/1) Installing tzdata (2016i-r0)
Executing busybox-1.25.1-r0.trigger
OK: 9 MiB in 16 packages
/ # date
Fri Mar 31 16:41:36 NZDT 2017

authors: andyshinn gdhnz paurullan

repo: gliderlabs/docker-alpine


text:
Currently examples are not linked to the wordnets

I propose we add a macro or two:
Linked to omw 1.0 for now, but can change to omw 2.0 soon:
{%- macro pwn(name, key) -%}
{{ name }}
{%- endmacro %}
And maybe: for named ili links:
{%- macro ilin(name, symbol) -%}
⟪{{ name }}⟫
{%- endmacro %}
We could also think of trying to get the name with a language parameter from OMW in the future, not quite sure how, ...
@goodmami  does this look good to you?   I have some examples and would like to get a student to add them in, with links, ...

In general this looks good. We had some issue before with choosing a macro name that doesn't clash with other variables, etc. in the templates. As long as we're careful about that these should be fine.
And, forgive my ignorance, but are named ili links fundamentally different than non-named links, or is the name just optional? If the latter, then I think we can just use the current ili() macro but give it a name parameter with a default value.

I think this issue has been resolved?

authors: fcbond gconnect goodmami

repo: globalwordnet/gwadoc


text:
Windows overapping with Taskbar

Describe the bug
When the Taskbar isn't located at the bottom of the screen, but at the top or sides, then Amethyst positions the windows so that they're overlapping with the taskbar, while ther's an empty space at the bottom of the screen.
To Reproduce
Steps to reproduce the behavior:

Move the Taskbar from the Bottom to the Top or Sides
Force the Windows to be reevaluated mod1 + Z

Screenshots

Desktop (please complete the following information):

OS: Windows 10 Version 20H2 Build 19042.746

+1 to this, I think this is due to Amethyst windows only taking in account if the taskbar is at the bottom. I would propose 2 solutions, have settings to have custom paddings, meaning I can choose each side and each padding separately. You could also just get the taskbar position and height programatically and have it all seamlessly.

When I place the task bar to the right side of the screen it works perfectly, does not overlap. Only overlaps when the taskbar is in the left or top.

Hi all! This will be solved with #19.
I will keep you posted.

Hi the problem is solved. Going to release asap.

authors: garciaErick glsorre hlorand jonathan-reichardt

repo: glsorre/amethystwindows


text:
feat:[#732] Implement Gcd and Lcm function to ast_builder

resolves #732
I have implemented  Gcd and Lcm functions to ast_builder.
Many thanks

Pull Request Test Coverage Report for Build 2818361093

42 of 42 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.03%) to 97.914%

Totals

Change from base Build 2817759474:
0.03%

Covered Lines:
29294

Relevant Lines:
29918

💛  - Coveralls

authors: ChobobDev coveralls

repo: gluesql/gluesql


text:
Liveness & Readiness Probe is failing for the daemonSet pods

I followed all the prereqs mentioned in the Install Doc on my Debian machines.
╰─ ./gk-deploy -n storage -g
Welcome to the deployment tool for GlusterFS on Kubernetes and OpenShift.

Before getting started, this script has some requirements of the execution
environment and of the container platform that you should verify.

The client machine that will run this script must have:
 * Administrative access to an existing Kubernetes or OpenShift cluster
 * Access to a python interpreter 'python'

Each of the nodes that will host GlusterFS must also have appropriate firewall
rules for the required GlusterFS ports:
 * 2222  - sshd (if running GlusterFS in a pod)
 * 24007 - GlusterFS Management
 * 24008 - GlusterFS RDMA
 * 49152 to 49251 - Each brick for every volume on the host requires its own
   port. For every new brick, one new port will be used starting at 49152. We
   recommend a default range of 49152-49251 on each host, though you can adjust
   this to fit your needs.

The following kernel modules must be loaded:
 * dm_snapshot
 * dm_mirror
 * dm_thin_pool

For systems with SELinux, the following settings need to be considered:
 * virt_sandbox_use_fusefs should be enabled on each node to allow writing to
   remote GlusterFS volumes

In addition, for an OpenShift deployment you must:
 * Have 'cluster_admin' role on the administrative account doing the deployment
 * Add the 'default' and 'router' Service Accounts to the 'privileged' SCC
 * Have a router deployed that is configured to allow apps to access services
   running in the cluster

Do you wish to proceed with deployment?

[Y]es, [N]o? [Default: Y]: y
Using Kubernetes CLI.
Using namespace "storage".
Checking for pre-existing resources...
  GlusterFS pods ... not found.
  deploy-heketi pod ... not found.
  heketi pod ... not found.
  gluster-s3 pod ... not found.
Creating initial resources ... serviceaccount/heketi-service-account created
clusterrolebinding.rbac.authorization.k8s.io/heketi-sa-view created
clusterrolebinding.rbac.authorization.k8s.io/heketi-sa-view labeled
OK
node/kubernetes-master-agent labeled
node/kubernetes-agent-2 labeled
node/kubernetes-agent-3 labeled
daemonset.extensions/glusterfs created
Waiting for GlusterFS pods to start ... pods not found.

Doing a describe on the pods, I get ;
Events:
  Type     Reason                 Age              From                              Message
  ----     ------                 ----             ----                              -------
  Normal   SuccessfulMountVolume  1m               kubelet, kubernetes-master-agent  MountVolume.SetUp succeeded for volume "glusterfs-ssl"
  Normal   SuccessfulMountVolume  1m               kubelet, kubernetes-master-agent  MountVolume.SetUp succeeded for volume "kernel-modules"
  Normal   SuccessfulMountVolume  1m               kubelet, kubernetes-master-agent  MountVolume.SetUp succeeded for volume "glusterfs-lvm"
  Normal   SuccessfulMountVolume  1m               kubelet, kubernetes-master-agent  MountVolume.SetUp succeeded for volume "glusterfs-cgroup"
  Normal   SuccessfulMountVolume  1m               kubelet, kubernetes-master-agent  MountVolume.SetUp succeeded for volume "glusterfs-config"
  Normal   SuccessfulMountVolume  1m               kubelet, kubernetes-master-agent  MountVolume.SetUp succeeded for volume "glusterfs-etc"
  Normal   SuccessfulMountVolume  1m               kubelet, kubernetes-master-agent  MountVolume.SetUp succeeded for volume "glusterfs-misc"
  Normal   SuccessfulMountVolume  1m               kubelet, kubernetes-master-agent  MountVolume.SetUp succeeded for volume "glusterfs-logs"
  Normal   SuccessfulMountVolume  1m               kubelet, kubernetes-master-agent  MountVolume.SetUp succeeded for volume "glusterfs-dev"
  Normal   SuccessfulMountVolume  1m (x3 over 1m)  kubelet, kubernetes-master-agent  (combined from similar events): MountVolume.SetUp succeeded for volume "default-token-k8m59"
  Normal   Pulled                 1m               kubelet, kubernetes-master-agent  Container image "gluster/gluster-centos:latest" already present on machine
  Normal   Created                1m               kubelet, kubernetes-master-agent  Created container
  Normal   Started                1m               kubelet, kubernetes-master-agent  Started container
  Warning  Unhealthy              18s              kubelet, kubernetes-master-agent  Readiness probe failed: /usr/local/bin/status-probe.sh
failed check: systemctl -q is-active gluster-blockd.service
  Warning  Unhealthy  11s (x2 over 36s)  kubelet, kubernetes-master-agent  Liveness probe failed: /usr/local/bin/status-probe.sh
failed check: systemctl -q is-active gluster-blockd.service

On the nodes I only installed  glusterfs-client.
Is there something else I need to deploy on the nodes ?

I am finding this exact issue too - was there a resolution?  I am struggling to find any mention of a gluster-blockd.service anywhere.

I had faced the same problem. I had glusterfs service running on K8 nodes too. After stopping and disabling the glusterfs service,  restarted the K8 nodes. All the glusterfs pods came up automatically.

authors: TommyKTheDJ ghost gnreddy06

repo: gluster/gluster-kubernetes


text:
typo on the website

environmnet   should be  environment within  No user contextual changes or root escalation allowed  of http://singularity.lbl.gov/#home

Fixed in [gh-pages ae38112]. Thank you!

authors: gmkurtzer yarikoptic

repo: gmkurtzer/singularity


text:
🛑 Good News From Indonesia is down

In 8acb3c3, Good News From Indonesia (https://www.goodnewsfromindonesia.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Good News From Indonesia is back up in 079b28d.

repo: gnfi/status


text:
登录页是否考虑增加个背景图

登录页是否考虑增加个背景图
目前登录页有点过于单调，显得登录框很突兀

登录页是否考虑增加个背景图 目前登录页有点过于单调，显得登录框很突兀

等你来PR

authors: gngpp threerog

repo: gngpp/luci-theme-design


text:
Update 1 Inch app to v1.2.3

Update 1 Inch Safe App

@francovenica I think this one should be check on mainnet
https://ipfs.io/ipfs/QmRWtuktjfU6WMAEJFgzBC4cUfqp3FF5uN9QoWb55SdGG5/

@francovenica I think this one should be check on mainnet
https://ipfs.io/ipfs/QmRWtuktjfU6WMAEJFgzBC4cUfqp3FF5uN9QoWb55SdGG5/

Travis automatic deployment:
https://pr1816--safereact.review.gnosisdev.com/rinkeby/app

Travis automatic deployment:
https://pr1816--safereact.review.gnosisdev.com/rinkeby/app

Travis automatic deployment:
https://pr1816--safereact.review.gnosisdev.com/volta/app

Travis automatic deployment:
https://pr1816--safereact.review.gnosisdev.com/volta/app

Added the new app. Tried one swap and it worked fine for me

Added the new app. Tried one swap and it worked fine for me

Travis automatic deployment:
https://pr1816--safereact.review.gnosisdev.com/rinkeby/app

Travis automatic deployment:
https://pr1816--safereact.review.gnosisdev.com/rinkeby/app

Travis automatic deployment:
https://pr1816--safereact.review.gnosisdev.com/volta/app

Travis automatic deployment:
https://pr1816--safereact.review.gnosisdev.com/volta/app

authors: dasanra francovenica gnosis-info

repo: gnosis/safe-react


text:
🛑 Beacon RPC is down

In 0b57651, Beacon RPC (https://rpc-gbc.chiadochain.net/eth/v1/beacon/headers) was down:

HTTP code: 502
Response time: 15752 ms

Resolved: Beacon RPC is back up in f616d66 after 1 hour, 16 minutes.

repo: gnosischain/chiado-uptime


text:
🛑 GnosisPay TESTNET Explorer is down

In 33aa931, GnosisPay TESTNET Explorer (https://explorer.testnet.gnosispay.network) was down:

HTTP code: 502
Response time: 432 ms

Resolved: GnosisPay TESTNET Explorer is back up in ba428b2 after 12 minutes.

repo: gnosischain/gnosispay-uptime


text:
when auth plugin return err with 403, restserver should use ir status…

… code

Can one of the admins verify this patch?

Pull Request Test Coverage Report for Build 1787

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
14 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.01%) to 61.909%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

server/restful/restful_server.go
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

core/server/options.go
2
50.0%

core/rest_invoker.go
2
91.84%

server/restful/form_mapping.go
2
16.67%

core/config/fault_injection_config.go
3
0.0%

core/lager/logrotate.go
5
36.74%

Totals

Change from base Build 1786:
-0.01%

Covered Lines:
5513

Relevant Lines:
8905

💛  - Coveralls

authors: coveralls daqingshu tianxiaoliang

repo: go-chassis/go-chassis


text:
Add Op.String() and fix Event.String() to use Op.String()

Event.String() seemed to, at one point in time, return a list of events? It looks like it there can only be one Op in an event so..

There can be multiple Ops in an event. That's why it is a bitmask.

@techjanitor for your info, #165 has been merged, resolving the issue you set out to with this pull request.

authors: nathany techjanitor

repo: go-fsnotify/fsnotify


text:
Updating issues via API does not work if "state" field is present but unchanged

Description
If i try to update an issue via:
curl --location --request PATCH 'http://localhost:3000/api/v1/repos/root/test/issues/1' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer ***' \
--data '{
  "assignees": [],
  "body": "Test 123",
  "title": "Dependency Dashboard",
  "state": "open"
}'

The issue is updated just fine but Gitea returns status code 500.
The problem here is the state field. Without the state field everything works just fine.
I think the problem was introduced with https://github.com/go-gitea/gitea/commit/a50026e2f30897904704895362da0fb12c7e5b26#diff-f33622667aa80c1735ccaef8e7331422504e8c449f691c6847ec4f6737a278cd. @yp05327 maybe you can have a look at it.
The problem occured because Renovate Bot useses the state field in its model (see https://github.com/renovatebot/renovate/blob/main/lib/modules/platform/gitea/types.ts#L171-L176) for issue creation / update via the Gitea API.
Gitea Version
1.22.1
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
The logs:
2024/08/19 07:11:13 ...api/v1/repo/issue.go:894:EditIssue() [E] ChangeStatus: Issue [1] 0 was already closed
2024/08/19 07:11:13 ...eb/routing/logger.go:102:func1() [I] router: completed PATCH /api/v1/repos/root/test/issues/1 for 172.17.0.1:36648, 500 Internal Server Error in 33.5ms @ repo/issue.go:742(repo.EditIssue)

The API returns:
{
    "message": "Issue [1] 0 was already closed",
    "url": "http://localhost:3000/api/swagger"
}

Git Version
No response
Operating System
No response
How are you running Gitea?
Docker
Database
SQLite

Thanks for your report. I will check it later.

I got this error. But the issue is opening not closed.

I think it is not related to the changes you mentioned. It looks that this is an old bug.

Nothing should be performed if current status is same as target status

The logic here is a bit strange, nothing should be performed but it returns error. 😕

Emmm, this logic can be traced far before (about 5 years ago). No need to figure out it any more, just need to find a solution to fix it.

I see. It was part of my fault. But I still think the logic in changeIssueStatus is strange.

repo: go-gitea/gitea


text:
Enable Webpack ESM output and move assets to /assets/ without subdirectories

Enable Webpack to output ESM aka. modules. This is still flagged experimental, but in my testing, it works pretty well. With ESM, all the JS now runs in strict mode which has potential to bring up new JS errors. Also I consolidated the entrypoint scripts to single files because this is required anyways for a future migration to Vite. jQuery.are-you-sure is moved to a vendor file because it is not compatible with strict mode.
I noticed Webpack had some issues with lazy-loading the PNG from monaco, and I concluded that it's not worth to maintain the js,css,fonts etc subdirectories, so I moved the assets to a single subdirectory static which is also what vite does and it eliminates this class of webpack errors.
This works quite well in my testing, but I'm putting WIP because I think there i a strict mode violation in bootstrap.js which is only triggered on error, so I'll investigate that later.

This has an interaction with https://github.com/go-gitea/gitea/pull/25907, so that one should merge first after which I will move the output directory to /assets/static.

Needs updates now that https://github.com/go-gitea/gitea/pull/25907 is in.

This is ready. I could not reproduce the strict mode violation that I previously saw with vite, so maybe it was something vite-specific.

The strict mode-related error showed up on devtest:

Some code like initGlobalErrorHandler is executed more than once.

Changed it to a Proxy which eliminates the error. This here demonstrates that the Proxy is working:

Some code like initGlobalErrorHandler is executed more than once. (not tested yet, just a guess)

I think the old error was caused by the duplicate calls to the "init" functions. If the duplicate calls still exist, I guess you would create a Proxy of a Proxy of a array.

initGlobalErrorHandler was only called once in bootstrap.js, right after creation, making it and essentially a noop, so I removed it.

So everything is working besides the modal buttons on second row below:

First row works because it's using data-modal, I'm inclined to refactor the other modals to that mechanism.

First row works because it's using data-modal, I'm inclined to refactor the other modals to that mechanism.

Well, I have different opinion. It seems that the root problem is the moduled "devtest.js" just doesn't co-work with "index.js/fomantic.js".

So the problem might be that devtest code runs before fomantic init and there are two jQuery instances active. $.fn.modal is undefined in devtest code.

I guess we could just eliminate the devtest JS chunk and run it as part of the index.js chunk with a condition that compiles it out during production.

Everything works in single JS and CSS chunks now. The only drawback is that devtest.css is now bundled in index.css, which was needed to avoid style flash in it, but I think it's acceptable to have these few extra bytes in the CSS.
As far as I'm aware, webpack can not dynamically @import CSS based on environment, and the only way to get it to work would be to dynamically append the file in webpack.config.js, but I like to avoid this because such a mechanism is not available for a future migration to Vite or other bundlers.

WIP again because of https://github.com/go-gitea/gitea/pull/25940#discussion_r1278302505. Maybe we can't actually do ESM for the webcomponents because of that flicker.

https://github.com/go-gitea/gitea/pull/25940/commits/178538c4218c50c4a188d80394640af4414bd3ff appears to work to avoid the flicker. I do realize it's not ideal to load a module script as non-module, but it should work as long as we don't do import() inside the webcomponents chunk, which would be bad anyways because it again would be a source of flicker.

Found a way to extract the devtest css again, so nothing from devtest should load in prod build again.

As per this, combining type=module with async may be worth a try to get the webcomponents script to execute in a render-blocking way, I need to try.

There is another consideration with type=module scripts from MDN:

Unlike classic scripts, module scripts require the use of the CORS protocol for cross-origin fetching

This would introduce additional issues for people who host assets on another domain. While I discourage this as it's unnecessary since HTTP2, it's a breaking change to them.
I have a feeling this change of script type is not worth it, at least not yet.

This would introduce additional issues for people who host assets on another domain. While I discourage this as it's unnecessary since HTTP2, it's a breaking change to them.
I have a feeling this change of script type is not worth it, at least not yet.

Then I guess it breaks STATIC_URL_PREFIX  and Set `[server] STATIC_URL_PREFIX = http://cdn.example.com/gitea` in your configuration., and Gitea won't work with CDN?

It could only work if said CDN would emit CORS headers, e.g. Access-Control-Allow-Origin. Still, I would never recommend serving assets on a different domain, but I know there might be existing users that still do this.
If offloading the gitea binary from asset requests, the /asset/ subdirectory can be handled by the reverse proxy, and everything remains same-origin and browser security is happy.

If this does not lande, we should use esbuild banner feature to run all JS in strict mode:
https://github.com/evanw/esbuild/issues/422#issuecomment-739740602

I haven't tested or fully understood the CDN problem. If it breaks CDN behavior, it would be a problem for many instances which depend on CDN ...... sorry I can't comment at the moment.

I think long-term, we eventually have to move to ESM script output to benefit from newer JS features and to remove this unnecessary translation to CommonJS that webpack does.

Not going to continue here for now. Maybe another try later.

authors: silverwind wxiaoguang


text:
Make actions default enabled for newly created repository

Users can still use [repository].DEFAULT_REPO_UNITS= to define the default units.

It seems to be suitable to be backported?

Is it really a good idea? I think that there are more repos that do not need Actions than those that do. Basically the same argument, if your specific instance needs Actions nearly every time, you can enable it through the config - but I'd leave it disabled per default.

Is it really a good idea? I think that there are more repos that do not need Actions than those that do. Basically the same argument, if your specific instance needs Actions nearly every time, you can enable it through the config - but I'd leave it disabled per default.

IMO the enabled "actions" feature doesn't harm anyone, if you don't use it.

Is it really a good idea? I think that there are more repos that do not need Actions than those that do. Basically the same argument, if your specific instance needs Actions nearly every time, you can enable it through the config - but I'd leave it disabled per default.

But many people do not use projects, pull requests packages, wiki but those are enabled by default, why actions is special?

authors: denyskon lunny wxiaoguang


text:
Fix API deadline removal

I got a comment by @bobemoe in #8696 and looked more into setting (and resetting) deadline via API. Because the variable is set to be of type "*time.Time" only nil or a full golang time is valid input.

This issue fixes so that deadline can be removed in the edit issue and edit pull endpoint by setting it to time zero (0001-01-01T00:00:00Z).
Also there was already a comment to the API that is now also handled in the implementation: "If using deadline only the date will be taken into account, and time of day ignored. "

This issue shouldn't be relevant for 1.9 branch but can be backported to 1.10.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@690a8ec). Click here to learn what that means.
The diff coverage is 0%.

@@            Coverage Diff            @@
##             master    #8759   +/-   ##
=========================================
  Coverage          ?   41.37%
=========================================
  Files             ?      539
  Lines             ?    69360
  Branches          ?        0
=========================================
  Hits              ?    28700
  Misses            ?    36967
  Partials          ?     3693

Impacted Files
Coverage Δ

routers/api/v1/repo/pull.go
35.88% <0%> (ø)

routers/api/v1/repo/issue.go
22.67% <0%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 690a8ec...f0f4db2. Read the comment docs.

we wont need deadline var if we put all together...
deadlineUnix = timeutil.TimeStamp(time.Date(form.Deadline.Year(), form.Deadline.Month(), form.Deadline.Day(), 23, 59, 59, 0, form.Deadline.Location()).Unix())

but it wont be so readable anymore ... so OK

How about another param removal or another router method DELETE to do that? It's not friendly to let user use 0001-01-01T00:00:00Z.

@lunny Maybe that was why the additional /deadline endpoint was added?
I think it would make sense to have removal param, but now there is a specific endpoint for it I am not sure about cluttering it more...

Hmmm.
I agree setting to 0001-01-01T00:00:00Z. Whats wrong with using null? Infact there is a description on the deadline endpoint "If set to null, the deadline is deleted."
My earlier experiment confirmed that null doesn't error so surely its a case of detecting it to trigger removal.
I was wondering why there was a specific endpoint for this single field, I was considering suggesting that once the deadline can be managed through the issue endpoint that we deprecated the then redundant deadline endpoint?

@bobemoe I think null will be translated to golang nil, which would be the same as omitting the deadline. And in that case we don't want to change the deadline. That is why it works for the specific deadline endpoint, becuase there we can allow it to always update the deadline (new date or removed).
So the only think we can do if we want to have simpler way to remove deadline in the update issue endpoint is to add a parameter unset deadline as suggested by lunny. Or we can change the deadline parameter to a text string and then try to parse it (values like "" can then be treated as zero)

For a better API usage, I think give a parameter 0000-01-01.... is tricky.

I added parameter unset_due_date.
Should the endpoint /repos/{owner}/{repo}/issues/{index}/deadline be marked as deprecated?

make lgtm work ..

authors: 6543 bobemoe codecov-io davidsvantesson lunny


text:
go install gorm.io/gen/tools/gentool@latest is currently having an issue

go install gorm.io/gen/tools/gentool@latest
produces the following error:
go: downloading gorm.io/gen v0.3.10
go: gorm.io/gen/tools/gentool@latest (in gorm.io/gen@v0.3.10):
	The go.mod file for the module providing named packages contains one or
	more replace directives. It must not contain directives that would cause
	it to be interpreted differently than if it were the main module.

Looks like https://github.com/go-gorm/gen/pull/484 introduced the replace in go.mod.
#484 was a part of the https://github.com/go-gorm/gen/releases/tag/v0.3.9 release.

try go install gorm.io/gen/tools/gentool@7d4e27eab3b36f3c2079d405492944bd060c26d1 temporarily. Next release will fix this bug

repo: go-gorm/gen


text:
Update reference to TargetModuleScanner to use SigScanner service

The DI update replaced DalamudPluginInterface.TargetModuleScanner with a global SigScanner service. Need to update https://goatcorp.github.io/faq/development#q-how-do-i-hook-a-game-function to reflect that.

I've had a go at this in my fork https://github.com/snowoutwith/faq but am unsure whether we want to keep the rest of the sample code as is or update it all to be DI style at once?

authors: philpax snowoutwith

repo: goatcorp/faq


text:
Update kubejob for fixing copy process

FYI: https://github.com/goccy/kubejob/pull/33

Codecov Report

Merging #68 (399a548) into master (29326e4) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #68   +/-   ##
=======================================
  Coverage   62.03%   62.03%
=======================================
  Files          15       15
  Lines        2639     2639
=======================================
  Hits         1637     1637
  Misses        735      735
  Partials      267      267

authors: codecov-commenter goccy

repo: goccy/kubetest


text:
Create Traditional Chinese Version Documents

Create Traditional Chinese Version Documents

/LGTM

authors: ReganYue qmhu

repo: gocrane/crane


text:
CRD status field

/kind feature
As a creator of ExternalSecrets  i want to know the status of the sync process. Because we're relying on 3rd party APIs it can happen that they are unavailable or - due to misconfiguration - we can not access them.
Without actively looking into the logs or having proper alerts in place using the sync_calls metrics there is no way to tell if the secret is actually up to date.
Why are these options not enough?

looking into logs might not be possible because a different team owns the service (think "platform" or "devops" :trollface: or whatever)

Most issues arise while bootstrapping (setting up roles, secrets etc.) and - from my experience - people just don't write alerts before they actually implement stuff.

To Σ this up: Having a status field is more than a nice-to-have feature. It actually would have solved a bunch of support requests.
Proposal
The following would be a MVP implementation:

the timestamp of the last sync action
the error that might have occurred during that sync action

risks:

we could potentially expose sensitive information in these error messages.

apiVersion: 'kubernetes-client.io/v1'
kind: ExternalSecret
metadata:
  name: hello-world
secretDescriptor:
  backendType: secretsManager
  data: {}
  # add this field
status:
  lastSync: 1572384571963 # unix timestamp
  lastSyncResult: "unable to assume role arn:aws:iam::123456789012:role/test-role"
  observedGeneration: 866

Relates to #178
Please vote :+1: :-1: if you would find it helpful and/or comment if you have further suggestions

#133 covers some of this after I refactored to use the status api :)

:heart: thanks for implementing it! I'll test it once released

authors: Flydiverny moolen

repo: godaddy/kubernetes-external-secrets


text:
AWS Service Linked Role Not Working

I set up the chart to use an aws service linked role and it is not working. The pod is trying to assume the role of the worker node instead of the service account. I checked the pod and the iam token from the correct role is actually mounted to the pod.
Here is my service account
kind: ServiceAccount
apiVersion: v1
metadata:
  name: kubernetes-external-secrets
  namespace: foo
  labels:
    app.kubernetes.io/instance: kubernetes-external-secrets
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: kubernetes-external-secrets
    helm.sh/chart: kubernetes-external-secrets-4.0.0
  annotations:
    eks.amazonaws.com/role-arn: >-
      arn:aws:iam::123456:role/ExternalSecretRole
    meta.helm.sh/release-name: kubernetes-external-secrets
    meta.helm.sh/release-namespace: foo

Here is my trust relationship:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/123456789"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-west-2.amazonaws.com/id/123456789:sub": "system:serviceaccount:foo:kubernetes-external-secrets"
        }
      }
    }
  ]
}

Since the pod is trying to use the nodes worker role instead of the role from the service account, I am also unable to use the spec.roleArn in the ExternalSecret resource. I get an error saying the nodes worker role can't assume whatever role I put there.
So far the only way I can get this project to work is to use a secret with AWS credentials and bind it in the chart values.
e.g.
envVarsFromSecret:
  AWS_ACCESS_KEY_ID:
    secretKeyRef: aws-credentials
    key: id
  AWS_SECRET_ACCESS_KEY:
    secretKeyRef: aws-credentials
    key: key

Any ideas why it does not work with the service account?

Ohhhh, never mind. Didn't quite understand the values file and docs. I've never heard service linked roles called IRSA...
Figured it out:
securityContext:
  runAsNonRoot: true
  # Required for use of IRSA, see https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html
  fsGroup: 65534

Sounds like you solved your issue so closing :)

authors: Flydiverny kferrone


text:
Remote debug fails in chrome browser Godot 4.3

Tested versions
Reproducible in 4.3
System information
Godot v4.3.stable - Windows 10.0.22631 - GLES3 (Compatibility) - NVIDIA GeForce RTX 4070 Ti (NVIDIA; 32.0.15.6614) - AMD Ryzen 9 7950X 16-Core Processor (32 Threads)
Issue description
Remote debug works for Firefox and Edge browsers, but fails for Chrome browser.
The following error is logged in the web debugger:
Uncaught (in promise) TypeError: WebAssembly.instantiate(): Import #0 "a": module is not an object or function
at tmp_js_export.js:153:17
This has happened for any project I have exported in Godot 4.3.
Couldn't find an issue for it, so wasn't sure if this was known or if others don't have this issue.
Projects work fine in chrome once they are hosted on an external site such as itch.io. It just fails to load in the debugger.
Thanks!
Steps to reproduce

Open any Godot project.
Export to Web.
Run remote debugger

Minimal reproduction project (MRP)
new-game-project.zip

So I did a bit of testing on this, and randomly happened to notice that if I enable TLS in the Editor settings
(Editor > Editor Settings > Export > Web > Use TLS), then the problem seems to go away.
This allows web exported projects to load in the remote debugger. However there are still TLS handshake errors in the console output (TLS handshake error: -27648).
I couldn't find exactly what this error code means, but it seems to just repeat the same error several times and then it calms down.
There were no errors in the web debugger.

repo: godotengine/godot


text:
Embedded resources

Operating system or device, Godot version, GPU Model and driver (if graphics related):
any, all
Issue description:
Godot doesn't have anyway to view embedded resources. This becomes a problem if you created a resource but forget to save to disk. this is troublesome to troubleshoot on a large project since it would likely get buried. Needle in a haystack anyone!
Steps to reproduce:
create a embedded resource like a shader. Leave it; Forget it; wait till your project grows. Then good luck.
Link to minimal example project:
Nice to have a profiler for embedded resources or just a way to keep track of them.

Yeah seems to be a use case if you always embed resources when creating stuff and at some point you want to re-use one. Though I almost never embed resources unless I intentionally know they are small enough or never going to be reused. But if I change my mind... searching by name won't work because they have no name, so only way is to find the scene in which it is and remember in which spot it wad used.
Would this present in a window showing all embedded resources in all scenes? (Remember they have no name)

Maybe an option in the fle manager RMB menu, "Show embedded resoures?"

Maybe an option in the fle manager RMB menu, "Show embedded resoures?"

I think this, along with dynamic auto-generated names would be a good solution. When you enable Show Embedded Resources, any scenes in the currently viewed directory will have their embedded resources show, with auto-generated names along-the-lines of SceneName@Node/Path!Property
Obviously the actual solution would need some more thought put into it than that, but I think it's a starting point.

I'm really new to Godot (and very impressed by it!) and I too have thought about this usability issue already.
How about just putting everything imaginable in the Node tree view? I think it would be the most logical and fastest place to look for anything a specific node has eaten. They would stay organized. I know virtually nothing about Blender, but at least it looks like they have done it about that way and thus it might be a good candidate to steal and rework ideas from:

(Such as the possibility to show all scenes in a unified tree view at once, like the "All Scenes" button suggests -- possibly the main scene even highlighted with a special icon or background, why not -- in addition to the everything-in-the-node-tree feature, of course.)

How would you show embedded resources that are shared between multiple nodes? Just shown twice?

@lmjk Right click on any node and you can see the embedded resources already,.

@Zylann As my potential solution involves the node as part of the auto-generated resource name, listing for each use is viable. Especially if an identifier could be visibly added that signified if different listings pointed to the same resource.
Another possible alternative is to list only the first instance of the resource that's found, but if you right-click the listing, you're given all known aliases (as the auto-generated name essentially acts as a human-usable path to the embedded resource).

@reduz Didn't know, thanks for the tip! I'm mostly learning the 2.1 now, but those v3 features are quite tempting...

Judging by reduz's comment, this was implemented in 3.0 already, closing.

authors: Calinou RabbitB Zylann lmjk reduz vonflyhighace2


text:
Project with extra large icon triggers X11 error: BadLength (poly request too large or internal Xlib length error)

Godot version:
3.0.3-stable and current master branch (80f7eacf)
OS/device including version:
Linux (Mageia 6 x86_64) with X11 1.19.5
Nvidia GTX 670MX
Issue description:
The Godot jam entry Meltdown Hydrocooler Force by @DarrellWulff doesn't run on Linux X11 64-bit. The (custom) splash screen is shown, and then freezes on the splash screen with this error in the terminal:
OpenGL ES 3.0 Renderer: GeForce GTX 670MX/PCIe/SSE2
Boot splash path: res://DWLogo.png
X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Serial number of failed request:  242
  Current serial number in output stream:  242

This could be reproduced by another user too: https://itch.io/post/448272
Source code for the game is available, and I could confirm that the same issue happens when running from the source code with both Godot 3.0.3-stable and the current master branch.
Steps to reproduce:

Download https://github.com/DarrellWulff/Meltdown-Hydrocooler-Force-Godot-Game-Jam-
Open it in the editor to get assets imported
Try to run the main scene

Minimal reproduction project:
See above.

The issue happens because of this line: https://github.com/DarrellWulff/Meltdown-Hydrocooler-Force-Godot-Game-Jam-/blob/14aaba438560cf9cc1556769529e3946398dec28/project.godot#L18
That project tries to load a 3072x2048 PNG (!) as project icon (!!), which X11 likely doesn't like: https://raw.githubusercontent.com/DarrellWulff/Meltdown-Hydrocooler-Force-Godot-Game-Jam-/master/UI/MainTitle.png
We likely need to add some icon validation logic on X11 to prevent such issues (might also be relevant on other platforms).

Hmm, yeah, I don't think this should work, but we obviously also shouldn't just crash. I'll try to fix this.

authors: akien-mga hpvb


text:
Not selecting last item in Tree class [Godot 2.1.x]

Godot version:
Godot 2.1.x (Steam)
OS/device including version:
Win7x64
Issue description:
Not selecting last item in Tree class.
[Work]

[Not work]

Minimal reproduction project:
example.zip

Is this reproducible on 3.1 or with a daily build of the master branch?

authors: Calinou Heyter


text:
Thread.wait_to_finish() second call is an error, is this desired?

Godot version:
3.0.5 Stable Official
OS/device including version:
Linux Mint 18.3 64-bit Nvidia Drivers 384.130 GPU=Nvidia GTX950M
Issue description:
Call wait_to_finish() twice on the same thread, an accidental call usually, results in an error that stops the rest of the function from executing.
Steps to reproduce:
Please see the simple attached program.
Minimal reproduction project:
ThreadsWaitToFinish.zip

The answer is probably a yes and with some more careful programming I have been able to avoid this potential scenario. But I am still curious if this is what the developers want, but it may be impossible to avoid given the context of threads. so I am closing but at least  others will find this. The key is to put some guards in place to make sure you only call wait_to_finish() once.


text:
Arrays and vectors always resize after a push or a remove

Godot version:
3.0.6.stable.mono
OS/device including version:
Linux, Ubuntu 18.04, g++
Issue description:
I'm writing a library in C++ with GDNative and running it in Godot with C#.
The library is returning an Array of Vector2.
The problem is that every time I push an element, it always trigger a resize of the corresponding Vector.
Steps to reproduce:
If I write this code:
Array result;

for( int i = 0; i < 1000; i++ )
  result.push_back( Vector2( 0.0f, 0.0f ) );

return result;

Valgrind shows that it's triggering resize every time instead of once every power of two.

CC @karroffel

The same should happen when you do it from GDScript or VisualScript or any other language. As you can see it's going through the Array::push_back() call and there's nothing that GDNative does extra, it just forwards. So this is a core issue, not a GDNative one.

Having it call resize sounds legit, isnt it supposed to resize the capacity instead at every power of two?

Taking a look at this, and indeed, it seems like array.h, darray.h, and cowdata.h all basically assume that capacity == size, and will resize by +1 when inserting and -1 when removing. As far as I can tell, the code doesn't currently keep track of "capacity" separately, in addition to current size.
Regarding the growth factor, I'm personally leaning away from 2 (and instead, towards something like 1.5) based on info from the Dynamic array wiki page and this StackOverflow discussion. Specifically, a growth factor of 2 has the following disadvantages:

Assuming memory is allocated sequentially, there is never a time where previously de-allocated memory can be re-used during a growth operation. With growth == 1.5, there is.
Since 2 is fairly rapid growth, it's easier to "run out" of memory even though significant free space is still available. With growth == 1.5, this is less of an issue (albeit still present).

Thoughts / suggestions are welcome!

Any movement here?
I'm currently writing a grid based A* implementation following up on a bunch of people in the community using A* in that way anyways and it being possible to optimize it quite a bit with that in mind, but I'm finding that the final limit I'm hitting is the same as was found in #28925, namely that the constant reallocs occurring due to the arrays resizing when the open list is pushed to/removed from has a fairly big performance impact.
So I also did a quick experiment with the new grid based A* (called our here), the default graph-sort A* implementation godot has (called default here) and the new grid based A* but with std::vector in place of the open list instead of godot's Vector as the only change (our_std_vector here):

As you can see just replacing the open list alone leads to > 2x improvement, so I'd love to see some movement in this issue!
I imagine mitigating the issue here would lead to improvements across the entire Godot codebase (I also ran a similar test with the previously improved default A* and also saw a nearly 2x improvement just by replacing the open list with std::vector which doesn't reallocate on every modification).

Is it actually similar to https://github.com/godotengine/godot/issues/24731 ?

@Zylann Ah yes, you're quite right, it is indeed, I'd missed that one existed!

authors: Daw11 Zylann akien-mga karroffel profan voithos


text:
Changing image outside editor cause reimport but doesn't update image size until I move it.

Godot version:
3.1 c1779b1
OS/device including version:
Windows 10
Issue description:
When I change image to smaller outside editor, which was use in Project, I see that image hasn't good size and have strange lines, until I move this.
(Image should look strange because I test connecting several images into one)

Steps to reproduce:
https://streamable.com/6407d

Duplicate of #20614.

authors: akien-mga qarmin


text:
Godot should prompt a dialog when an inherited scene has orpan nodes due to a change in the parent scene.

Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.

Godot version:
11d77386
Issue description:
When working with scenes inherited from external created files (escn, collada, etc.) if the hierarchy is changed externally (fox example in blender) and there are nodes instanced inside the inherited hierarchy, all those nodes are forever lost. I believe Godot has the ability to recognise if there are orphan nodes in a tscn file.
In my specific case, I could not use the most updated escn file, since i was forced to choose between losing all the logic in my tscn file vs. taking the updated model. Of course this can be worked around by not changing the hierarchy in the modeling software, but this method makes the pipeline extremely more fragile, since the loss of the work is silent.
Related to #16650 #19520
Proposal
If there are hierarchy changes that leave nodes orphan, Godot should prompt a dialog similar to the one for broken dependencies to allow the user to give a new position in the hierarchy to the nodes that would be, otherwise, lost. It would be great if the ability to reparent the nodes is present also for the non orphan nodes (as their position in the hierarchy might have changed)

i had this happen to me and wanted to open an issue, then i found this.
The way unity handles deleted parent nodes from up in the inheritance is it just moves the orphaned children up the hierarchy which i think is a good compromise.

This is still a huge issue in 3.2.4.rc3, which makes working with inherited scenes quite meaningless (having to ignore a main feature that should be one of godots strengths).
https://user-images.githubusercontent.com/8841352/110289564-e457d100-7fe9-11eb-8cce-a65c0679bf16.mp4
BugProject.zip

reduz has been reworking the 3D workflow to not rely on inherited scenes anymore, so this may be less of an issue in 4.0.

From reading this https://github.com/godotengine/godot-proposals/issues/1823 it sounds like one way to handle this in 4.0 will be dummy nodes, this sounds like an okayish compromise, but is not a fix (and still leaves 3.2 in a buggy state). In unity renaming and moving children that are 'inherited' in variants works just fine (no problems afterwards), so logically this is doable; i hope someone addresses this for godot as its detrimental to an iterative (standard) workflow.

I'm not sure if this is the same issue, but I noticed that when a base scene's node is renamed, it's non-distructive to inherited scenes, because no inherited .tscn file is changed. This means that every inherited scene file retains all the information for the node hierarchy prior to the change (it just incorrectly references the old name, since it wasn't updated) and is inherently broken until resaved. Resaving ironically "fixes" it by overwriting and destroying the saved information. This is easily avoidable, though. All that needs done is to rename the [node name="OldNodeName"... portion to the correct name in the inherited .tscn files, preventing data loss. This is very tedious to do manually, but I imagine would be an easy bug-fix to implement as an automatic process when renaming.

authors: Calinou Flavelius QbieShay markdibarry


text:
Theme editor opens itself on scene save

Godot version:
4ee8ecd
Issue description:
When a Control node has a Theme resource and the resource is unfolded in the inspector, the Theme Editor dock will open each time you save the scene. IMO it should only open when interacting with the theme. I had it open in the script editor until I realized I need to fold the Theme resource.
Steps to reproduce:

Create a Control node
Create some Theme resource for the node
Unfold the new resource
Close the "Theme" dock and go somewhere else (like Console, Script Editor etc.)
Save
Theme dock opens itself

Testing on linux mint 18.3.
Tried in several versions of Godot between 3.0 and 3.2.3.rc3, haven't been able to reproduce this.
There were some versions where the theme dock and the output dock would stack vertically (eg. 3.1.1), and since at least 3.1 the theme dock will open if you choose a different dock, switch to another scene, then switch back (though since 3.2 when you do the theme in the inspector will be rolled up, so if you repeat the switch the theme dock won't appear the second time).
But I can't get it to open on save. Maybe it requires some project/editor setting?

I can't reproduce it anymore, so let's just close.

authors: KoBeWi tom-jk


text:
Cannot build module with a reference to an int

Godot version: 3.1
OS/device version: Windows 10 64bits
Issue description: I need to use a reference to an int for my module, but it apparently doesn't work.
I got this when I typed scons platform=windows bits=64 vsproj=yes
C:\Users\FlutterTal\Desktop\godot-3.1\core/method_bind_ext.gen.inc(2066): error C2039: 'convert' : is not a member of 'PtrToArg<P3>'         with         [             P3=int &         ] C:\Users\FlutterTal\Desktop\godot-3.1\core/method_bind_ext.gen.inc(2066): note: see declaration of 'PtrToArg<P3>'         with         [             P3=int &         ] scons: *** [modules\ggpo\ggpo.windows.tools.64.obj] Error 2 scons: building terminated because of errors.
And I got a bunch of them while it's still the same error.

Have you tried using int64_t?

I already tried with int32_t, and that still doesn't work

If anyone want to see the module so they can be able to help me:
https://github.com/FlutterTal/godot_ggpo

Am just guessing here, but I think the functions that can be bound support a limited set of arguments (the kind of things that work in gdscript), maybe integers by reference are not supported .. see the list aaronfranke posted.
If you want to return an integer, you could return it by value. If you want to return a bunch of integers, you could maybe return an array of integers in a variant?

Well, I tried using an array instead, but it in fact got even worse. And as of the limited set of arguments, I used #include "core/core/method_bind_ext.gen.inc" to fix it.

You can use anything on the c++ side, but as soon as it is exposed to gdscript you are pretty limited.
AFAIK by reference or by pointer arguments are not supported by gdscript in any way or form, with exception to some internal classes and Ref<Object>.
Probably you will need to:

wrap GGPOPtr to the Object class and use Ref<GGPOPtrWrapper>
use Dictionary or another wrapper class to return multiple values to gdscript.
use gdscript signals instead of function pointer (pre-defined c-callback functions, emitting signal in the GGPOPtr wrapper)
use some wrapper for uint64_t* (there is no direct equivalent in gdscript)

Here'r some mock-ups:
class GGPOSessionWrapper: public Object {
	GDCLASS(GGPOSessionWrapper, Object);

private:
	GGPOSession* ggpoptr = NULL;

public:
	bool begin_game(const char* game) {
		emit_signal("begin_game", String(game));
	}

	/*.......*/

	void _bind_methods() {
		ADD_SIGNAL(MethodInfo("begin_game", PropertyInfo(Variant::STRING, "game")));
		/*.......*/
	}
};

/*......................*/

int GGPO::start_session(Ref<GGPOSessionWrapper> &sessionRef, const String &game, int numPlayers, int localPort) {
	callLogv("start_session - %s %i %i", game.utf8().get_data(), numPlayers, localPort);
	GGPOSessionCallbacks cb;

	cb.advance_frame = &sessionRef->advanceFrame;
	cb.load_game_state = &sessionRef->loadGameState;
	cb.begin_game = &sessionRef->beginGame;
	cb.save_game_state = &sessionRef->saveGameState;
	cb.load_game_state = &sessionRef->loadGameState;
	cb.log_game_state = &sessionRef->logGameState;
	cb.free_buffer = &sessionRef->freeBuffer;
	cb.on_event = &sessionRef->onEvent;

	GGPOSession* ggpo;
	auto result = ggpo_start_session(&ggpo, &cb, game.utf8().get_data(), numPlayers, sizeof(uint64_t), localPort);
	sessionRef->set_ggpoptr(ggpo);
	return result;
}

/*......................*/

Dictionary GGPO::get_network_stats(Ref<GGPOSessionWrapper> &sessionRef, int pHandle) {
	callLogv("get_network_stats - %i", pHandle);
	GGPONetworkStats stats;

	Dictionary d;

	d["result"] = ggpo_get_network_stats(sessionRef->get_ggpoptr(), pHandle, &stats);
	d["sendQueueLen"] = stats.network.send_queue_len;
	d["recvQueueLen"] = stats.network.recv_queue_len;
	d["ping"] = stats.network.ping;
	d["kbpsSent"] = stats.network.kbps_sent;
	d["localFramesBehind"] = stats.timesync.local_frames_behind;
	d["remoteFramesBehind"] = stats.timesync.remote_frames_behind;

	return d;
}

Well, great news and bad news. Bad news is that I still have a bunch of errors on my module. Good news is that those errors is no longer about the engine, but only about the module. I just edited my repo, so you can see what is happening

Well, good news and bad news. Bad news is that I still have a bunch of errors on my module. Good news is that those errors is no longer about the engine, but only about the module. I just edited my repo, so you can see what is happening

It seems you got things working as there are recent commits to your module?
As for this issue, what's left is to define whether we want to extend the binding system to support references to pod types or not (I guess not, but I'll ask on IRC).

authors: FlutterTal aaronfranke akien-mga bruvzg lawnjelly


text:
Shadow overlap sprite with billboard mode and "Shaded" flag enable

Godot v3.2.3:
OS/device including version:
Linux 5.9.16-1-MANJARO
Tested with GLES2 and 3, same problem.
Issue description:
I want a sprites in billboard mode to cast shadows in a 3D environment. I've enabled billboard mode, check "Transparent", "Shaded" and "Double sided" flags and set "Alpha Cut" to "Opaque Pre-Pass". It casts shadows as expected, but there is some ugly shadow artifacts in front of my sprite, like this :

This problem only occurs when I enable the "Shaded" flag. It work just fine when I disable it, like this :

Steps to reproduce:
I tried on different computers, with both Linux and Windows, I ran it with GLES 2 & 3, I tried with the Sprite node and the MeshInstance one, with Spot, Directional Omni Lights,  still the same... It really seems to be the Shaded flag fault.
To reproduce you just have to instantiate a Ground, a Sprite, and a OmniLight with Shadow enabled, set options described above on the sprite and watch.
Minimal reproduction project:
BugReport.zip

Duplicate of #45147

Duplicate of #45147

authors: inara-work pycbouh


text:
Normalmap on a generated Mesh does not work

Godot version
3.3.3
System information
Archlinux GLES3 Nvidia Geforce GTX 1650 Super
Issue description
On a generated mesh, a shader can't use normalmap
Steps to reproduce
Generate a mesh through code, assign a shader to it
Minimal reproduction project
https://ufile.io/chduihco

Can confirm that this is happening for me on Godot 3.5.1 stable, Windows 10. The material I'm using works fine on default meshes, but it doesn't work on a generated mesh. I'm generating my mesh using ArrayMesh, vertex normals and UVs are set and work as intended. As soon as a normal map is assigned the mesh will just turn dark as if it's completely in shadows.
I've attached a minimal repro that I've confirmed has this issue in 3.5.1 stable.
generated_mesh_normal_map.zip

Can confirm that this is happening for me on Godot 3.5.1 stable, Windows 10. The material I'm using works fine on default meshes, but it doesn't work on a generated mesh. I'm generating my mesh using ArrayMesh, vertex normals and UVs are set and work as intended. As soon as a normal map is assigned the mesh will just turn dark as if it's completely in shadows. I've attached a minimal repro that I've confirmed has this issue in 3.5.1 stable.
generated_mesh_normal_map.zip

Do you also generate per-vertex normals and tangents? You need normals and tangents for normal mapping to work correctly.

Can confirm that this is happening for me on Godot 3.5.1 stable, Windows 10. The material I'm using works fine on default meshes, but it doesn't work on a generated mesh. I'm generating my mesh using ArrayMesh, vertex normals and UVs are set and work as intended. As soon as a normal map is assigned the mesh will just turn dark as if it's completely in shadows. I've attached a minimal repro that I've confirmed has this issue in 3.5.1 stable.
generated_mesh_normal_map.zip

Do you also generate per-vertex normals and tangents? You need normals and tangents for normal mapping to work correctly.

Ah looks like missing tangents caused the issue. I'm surprised these are needed from my code, couldn't those just be generated when missing? From what I can recall I don't think they're needed in Unity when generating a mesh from arrays.

Answering my own question here, ArrayMesh.regen_normalmaps() seems to do the job. We might need some better documentation there.

Answering my own question here, ArrayMesh.regen_normalmaps() seems to do the job. We might need some better documentation there.

Absolutely, this is the sort of thing that should be mentioned multiple places so its a quick find.

I think it should also be mentioned here: https://docs.godotengine.org/en/3.5/tutorials/3d/procedural_geometry/arraymesh.html
And I think ArrayMesh.regen_normalmaps() needs a better description. It doesn't regenerate normal maps (no textures are generated), it (re)generates any mesh data that's necessary to support normal maps.

The method should be renamed to something else in 4.0, such as regenerate_tangents.

Don't have this problem this ages ago

You mean it's fixed in 4.0? Or you don't experience it anymore in 3.5.x?

I mean it's fixed in 4.0, I don't use 3.x anymore

authors: Calinou Hannyson akien-mga clayjohn robbertzzz


text:
Cannot edit autotile after navigating away from the autotile editor (workaround: reset zoom by clicking the "1" button)

Godot version
3.4
System information
OSX, GLES3
Issue description
There appears to be a bug in 3.4 where you can no longer edit a tilesets autotile after navigating away from the autotile editor. This is not an issue in 3.3.4.
Steps to reproduce

Create a new project
Create a TileMap node
Add a tileset
Add a texture
Navigate away (place some tiles for example)
Go back to the tileset - it can now no longer be edited

Minimal reproduction project
No response

Might be related to #52760.

Might be related to #52760.

It seems so. Zooming in and out fixes it for me too. Feel free to close this issue, thank you!

Can confirm also with Single Tile or Atlas Tile.
Once you navigated away from the Tileset editor, you cannot create another Tile with the same texture either.
However if you add another Texture, then the bug seems to have disappeared. You suddenly can again edit the tiles and create new Tiles

I think I'm seeing the same issue. If I navigate away from the TileSet Editor I can't even edit existing tiles. Changing/resetting the zoom seems to make it work again.

Duplicate of #52760

authors: MatteoPiovanelli-Laser akien-mga golddotasksquestions matsjs


text:
AnimatedSprite2D animation frame previews are displayed without regard to the selected filter

Godot version
v4.0.alpha.custom_build (bf12719cc)
System information
Windows 11, Geforce 1660
Issue description
In 4.x previews are blurry, although the sprite is displayed correctly on the scene.
https://user-images.githubusercontent.com/10379487/152166892-b03eb757-7c3d-4ac1-b13f-ee4cc60fe72a.mp4
In 3.x previews are crisp:

Steps to reproduce
-open bat scene;
-select AnimatedSprite2D node.
Minimal reproduction project
PreviewTest_G4.zip
Bugsquad edit (keywords for easier searching): SpriteFrames, nearest, nearest-neighbor

Godot4.beta3 ,  debian

I already collected Screenshots to report this, its really annoying ty for that
(but its called "AnimatedSprite2D" not "AnimationSprite2D" in the title though)
The sprite frames from AnimatedSprite2D in the AnimationPlayer have the same Issue.

Still reproducible in 4.0 RC 2.

Have this same issue in rc3 although it's not a big deal.
More problematic for me is losing SpriteFrames from 3-to-4 conversion.
Does anyone know how to keep SpriteFrame data from v3?
https://godotforums.org/d/32908-animatedsprite2d-spriteframes-lost-from-3-to-4-conversion

@naturally-intelligent Please continue the discussion in https://github.com/godotengine/godot/issues/73696.

Still an issue in 4.0.2 stable.

Duplicate of #74337, fixed by #74341.

Technically, #74341 is more of a workaround as it's not respecting the filter configured for the resource. So it solves the symptoms most users will face doing pixel art projects, but might not cut it for games which actually need filtering.
Anyway, we can consider this fixed and see if anyone complains about the new default filtering.

just wanted to confirm as well, seemed to be fixed now in 4.1 RC1, awesome work

authors: Calinou akien-mga carnifexx dalexeev elvisish lufog naturally-intelligent sakunix


text:
UWP Exporter doesn't copy the GDNative DLL to the final APPX

Godot version
v3.4.4.stable.official.419e713a2
System information
Windows 11, GLES3, Nvidia GeForce GT 1030.
Issue description
Hello, I'm exporting a UWP project that contains a DLL file but when I export the project the DLL is missing, Here are some screenshots about it:

(game/ folder)

Steps to reproduce

Add the dll to the project
Export the project
Try to execute it or see the contents inside the APPX file

Minimal reproduction project
UWP Game.zip

I fixed it by adding a function to copy the dynamic libraries, I will close this issue and I will open a pull request.

This should be kept open until the PR fixing this issue is approved and merged :)

Fixed by #61262.

authors: ElCosmoXD Geometror akien-mga