Service Call to homeassistant.turn_on with entity_id: all does not function

Home Assistant release with the issue:
0.93.1
Operating environment (Hass.io/Docker/Windows/etc.):
Docker
Component/platform:
homeassistant.turn_on
Description of problem:
Service calls for homeassistant.turn_on or turn_off using entity_id: all per https://www.home-assistant.io/docs/scripts/service-calls/ does not function.
2019-05-25 23:25:12 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.1761996688] not enough values to unpack (expected 2, got 1)
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/websocket_api/commands.py", line 121, in handle_call_service
    connection.context(msg))
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/core.py", line 1141, in async_call
    self._execute_service(handler, service_call))
  File "/usr/lib/python3.5/asyncio/futures.py", line 380, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/usr/lib/python3.5/asyncio/tasks.py", line 304, in _wakeup
    future.result()
  File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
    raise self._exception
  File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
    result = coro.send(None)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/core.py", line 1163, in _execute_service
    await handler.func(service_call)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homeassistant/__init__.py", line 34, in async_handle_turn_service
    entity_ids = await async_extract_entity_ids(hass, service)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/service.py", line 126, in async_extract_entity_ids
    hass.components.group.expand_entity_ids(entity_ids)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/group/__init__.py", line 139, in expand_entity_ids
    domain, _ = ha.split_entity_id(entity_id)
ValueError: not enough values to unpack (expected 2, got 1)

I am noticing that homeassistant.turn_on or homeassistant.turn_off doesn't work with multiple entities (e.g. {"entity_id": "light.kitchen_sink_bottom, group.interior_lights"} either. It works fine with a single entity. Also using light.turn_on/off works with multiple entities fine as well. This just started not working when I upgraded past v.92


Append new Content issue

Hi there,
I don't think it is working ,  $('ul.grid').trigger('ag-add', [$('Hello World')]); iam trying to trigger it on button click but nothing happens

https://jsfiddle.net/ugod2gLw/


The report doesn't display the failing step

Current behavior
Hi guys, I want to thank you for everything, this plugin very amazing, I just have a question: are we have any way to display the step having an issue due to the report just display the spec having issue and I don't know what step is failing.

Desired behavior
Can we modify the report to display the step having issues? Please have a look at the image for more details:

Versions

Cypress version: 5.5
Preprocessor version: 3
Node version: 12.16.1

+1

+1

Due to personal reasons, the previous maintainers of this package are stepping down and handing the reigns over to me, a long-time contributor to the project and a user of it myself. This is a responsibility I'm very excited about. Furthermore, I'd like to thank @lgandecki ++ for all the work that they've done so far.
Read more about the transfer of ownership here.
The repository has however moved and all outstanding issues are being closed. This is not a reflection of the perceived importance of your reported issue. However, if after upgrading to the new version, you still find there to be an issue, feel free to open up another ticket or comment below. Please make sure to read CONTRIBUTING.md before doing so.


New Bluesky user

Title
Yusuf Kaka
Bluesky profile url
https://bsky.app/profile/yusufk.co.za
Twitter profile (url or username)
https://x.com/yusufkza
Category
dev
Type
None

Added tx.


frontend/qml: Just transform original View for minimap

Right now the minimap is just the original view duplicated with a smaller font size. This means that it is doing all the same work twice. It'd be better if it was possible to simply have just a single LimeView component and we have another component with the scale property set which then references the original component.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/2662555-frontend-qml-just-transform-original-view-for-minimap?utm_campaign=plugin&utm_content=tracker%2F282001&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F282001&utm_medium=issues&utm_source=github).

Migrated to limetext/lime-qml#8.


feat(@angular/cli): specify multiple default collections

Hi 😉
This PR is related to issue posted on angular/devkit repository by @jeffbcross . It looks like the whole implementation of executing schematics belongs to @angular/cli itself so that's the reason for creating PR against this repo.
The proposed solution adds possibility to specify additional collections property in defaults of schematics in angular-cli.json. That way app has base collection which defaults to @schematics/angular (but could be overridden too) and potential to add unlimited additional collections. Execution priority is that the first collection containing requested schematics wins.
the additional collections property should make this solution backwards compatible.
This is initial working implementation. Review of someone who knows that part would be highly appreciated. Also some guidance on how to test this is very welcome.
Check out screenshot of working solutions.

@clydin  a bit meta question, how does it work with this repo, is it ok to always mention main guys in PR to let them know something was created or do they check PRs themselves, don't want to spam.

Hi @Brocco , I have seen you did PR #8812 concerning schematics and collections, maybe you can have a look on this one too? Its about support for multiple collections per project.

@tomastrajan we monitor all the PRs but if you think a PR should be reviewed by a particular team member, there's no harm in mentioning them.
Also, thank you for contributions to the project and spending the time to help make the CLI better.  Bug fixes and required features take priority so please don't feel discouraged if it takes a little while to hear back.

Certainly much more convenient being able to define, only once in angular-cli.json, all of the collections you'll be using for a project.
I do think more thought needs to go into name collisions. Currently the first one encountered wins. This is fine when the intent is always to override, but we can't assume that. It's possible that two separate collections define foo, which are intended for entirely different purposes, and we'd want access to both of them. Otherwise we're assuming that any schematic name in a collection is reserved and will be overridden, potentially accidentally, if used by another collection.

I see your point. The way this was intended to work is that you get override behaviour by default but you can always execute for specific collection in the same fashion like befote by passing --collection flag.
Besides from what I saw in ngrx schematics it seems to be the case that the way this is going is to use extends in schematics json declarations to pass through calls to underlying default angular schematics for stuff like component or service.
But this then only works nicely if you use ONE other schematics which delegates all the calls to underlying default. It doesnt help if you want to use more smaller / single purpose schematics from multiple libraries.

But this then only works nicely if you use ONE other schematics which delegates all the calls to underlying default. It doesnt help if you want to use more smaller / single purpose schematics from multiple libraries.

This would be my main concern. It requires some knowledge of the implementation or behavior could be unexpected.

Just sharing my pre-conceived notion on how this was going to work. When I saw it was prefixed with @schematics, I thought it was going to be similar to how @types is managed by DefintelyTyped.
Package owners create a PR to merge schematics for their package into the main repo which is then auto-published after approval. This would solve the naming conflicts and it would be nice to just see them all available schematics listed in NPM under @schematics but I'm not sure how much overhead it really takes those Microsoft guys to manage it that way. Just a thought.

Closing this PR as it is too old and does not merge properly anymore. The work has been tracked locally in https://github.com/angular/angular-cli/issues/12157 (which is a transfer from the issue from devkit).
It's something we want to support but needed to do some cleanup first. Now that 7.0 is out and that cleanup is done, we'll track it in our internal Jira and expect updates on the issue #12157.


How to use env.render() to visualize environment transitions frame by frame?

rng = jax.random.PRNGKey(0)
rng, key_reset, key_act, key_step = jax.random.split(rng, 4)

# Instantiate the environment & its settings.
env, env_params = gymnax.make('FourRooms-misc')

# Reset the environment.
obs, state = env.reset(key_reset, env_params)

while True:
    # Sample a random action.
    action = env.action_space(env_params).sample(key_act)

    # Perform the step transition.
    n_obs, n_state, reward, done, _ = env.step(key_step, state, action, env_params)
    print(f"action: {action}, reward: {reward}, done: {done}")
    env.render(n_state, env_params)

I tried this simple example. The matplotlib figure is never shown. It is stuck and never opens.
Follow-up: Why is gymnax using matplotlib for rendering and not pygame (as gym) ?

P.S. I understand that I can use the Visualizer to animate a sequence of transitions, but that seems like an overhead when you just want to get the agent's view during interaction with the environment.

Curious about this as well. I tried running the visualizer script and it doesn't seem to visualize anything but rewards + steps. Not the environment itself.


Add links to language specific libraries and alternative databases in the README file

Other projects on GitHub provide language specific front-ends to crawler-user-agents, which people visiting the GitHub page for this project may not know about:

https://github.com/biola/Voight-Kampff (Ruby)
https://github.com/Hentioe/isbot (Ruby)

I suggest the README should list both of these so that people can find them easily.
This project is also one of a number of different projects on GitHub with databases of crawlers. Other projects may be more suitable to their needs than this one.
I've listed some other projects that allow people to identify crawlers by user agent below. These are the projects I can find that have good quality, comprehensive databases, and which seem to be being actively maintained. Others obviously exist but these appear to be the good quality ones.

https://github.com/gorangajic/isbot (Node.JS)
https://github.com/JayBizzle/Crawler-Detect (PHP)
https://github.com/mimmi20/BrowserDetector (PHP)
https://github.com/browscap/browscap (has extremely extensive JSON database of UAs including a crawlers section)

I'd suggest that these would also be useful additions to the README.

I agree with you, that would be useful.
Could you propose a pull request?
Thanks!


ImageFiltered with matrix filter clips its output

The following code puts up a widget and rotates it using 2 different methods - a Transform widget and an ImageFiltered widget with an ImageFilter.matrix filter.
The two behave very similarly, but the output of the ImageFiltered widget is clipped to the original bounds of the transformed child.
Gist: https://gist.github.com/flar/da94ae35e8b86184b404000dfda68313

Hi @flar
In your gist, I couldn't find the code for ImageFiltered.
Can you please update the gist with complete example?
Thank you

ImageFiltered is a built-in widget.

@TahaTesser : FYI, ImageFIltered is in https://master-api.flutter.dev/ but not in https://api.flutter.dev/ yet.

Fixed by https://github.com/flutter/engine/pull/16960

Fixed by https://github.com/flutter/engine/pull/16960

The first fix in https://github.com/flutter/engine/pull/16960 failed because it was rendering the children with the wrong bounds for their savelayer.


cmd/go: stamp the pseudo-version in builds generated by go build

NOTE: The accepted proposal is https://github.com/golang/go/issues/50603#issuecomment-2181188811.

cmd/go embeds dependency version information in binaries, which is very useful. From Go 1.18 onwards, cmd/go also embeds VCS information in binaries, which makes it even more useful than it was before.
As #37475 mentions, people place version information in binaries using -ldflags='-X foo=bar', which requires an additional build wrapper. The new VCS stamping feature of cmd/go should alleviate the need for external wrapper, but I am afraid it comes short.
The version information, in the sense of Go's pseudo version is not recorded for the main module when doing go build:
: emerald:ver; go build
: emerald:ver; go version -m hello | grep 'mod.*hello'
	mod	mgk.ro/hello	(devel)
: emerald:ver;

The version is recorded as expected when doing go install:
: emerald:ver; go install robpike.io/ivy@latest
go: downloading robpike.io/ivy v0.1.124
: emerald:ver; go version -m `which ivy` | grep 'mod.*ivy'
	mod	robpike.io/ivy	v0.1.12	h1:qI7dnEiXhorB+za07W6qX3sG+IvBK4EUl38vUHAf53Q=
: emerald:ver;
: emerald:ver;

I am afraid this limitation of cmd/go will continue to force people to use external build wrappers that set -ldflags, which is rather unfortunate.
I am not the first to want main module version information in binaries, this has been already asked for in various issues, for example in #29814, which was closed as a duplicate of #37475, but it really wasn't a duplicate, as #37475 is about VCS information, and #29814 is about semantic versioning. Other examples of people asking for this feature are mvdan/sh#519 and https://github.com/golang/go/issues/29228#issuecomment-449554128 where various workarounds were proposed.
Speaking of workarounds, the only workaround that I know that currently works would be to create a local module proxy and pass GOPROXY to go install, but that is an extremely high-overhead workaround, and go install is not a replacement for go build anyway, since go install comes with some rather severe limitations regarding how vendoring works and what you can put in go.mod, and go install doesn't support controlling GOBIN when cross-compiling.
I realize that Git tags are a local concept, and by doing the "wrong" git operations one could come up with a different pseudo-version for the same source code. I am afraid I don't have any solution or suggestion regarding this git misfeature, except to note that even in this case the hash information is recorded correctly, and in every case by the virtue of having access to the local source code the programmer can always do some local operation that has the potential to cause a version mislabeling. Git is just more prome to do this by accident, but the ability is there, always.
I don't have any stats to back this up, but from my experience most corporate source code is built by go build, not go install, and it would be great if somehow Go's notion of versioning would be stamped by go build.
CC @bcmills @mvdan @rsc

At least speaking personally, for cases like https://github.com/mvdan/sh/issues/519, my intent is to show something like devel ${GIT_SHA} when someone does a local Go build out of a git checkout. So what 1.18 is currently shipping with is enough for my needs.
It's true that something like a proper module version might be more useful; a git commit hash doesn't give any hint as to how old a version is, whereas a semver version prefix or a timestamp can give a starting point. So, in principle, I agree with you: 1.18 is a big step forward, but it's still unfortunate that the main module version remains as (devel) for local builds.
However, in practice, I still agree with Jay's comment in https://github.com/golang/go/issues/29228#issuecomment-755332642; we shouldn't make such a "locally inferred version" look like a normal version, because it's reasonably likely to be wrong or cause confusion with users.

in every case by the virtue of having access to the local source code the programmer can always do some local operation that has the potential to cause a version mislabeling.

Could you give some examples? I can only think of very unlikely scenarios, such as manually corrupting the module download cache after downloading some dependencies. That cache is read-only by default, and go mod verify exists to double-check the contents too.
With the main module in a git checkout, I can think of multiple scenarios which seem more likely:

What if I've made a commit or tag but not pushed it?
What if I've edited some files and not committed them?
What if two people on two computers make the same tag with different code - would they end up with the same exact module version for different software? If one of them pushes their tag to the internet, would the other's computer be affected by the mismatch?

I think that, if we are to implement something like this, the versions must be somehow different from the canonical and unique versions that get computed from fully published commits and tags. As a simplistic example, imagine that tagging v1.2.3 locally results in a build whose main module version is devel v1.2.3, but when pushed and go installed, gets the version v1.2.3.

we shouldn't make such a "locally inferred version" look like a normal version, because it's reasonably likely to be wrong or cause confusion with users.

To add a more concrete example: if we made the change proposed here, and locally inferred versions looked like fully published versions, I would have a harder time trusting the output of shfmt -version when my users report bugs. I would have to update the issue template to also ask: did you build from a modified git checkout?

Could you give some examples? I can only think of very unlikely scenarios, such as manually corrupting the module download cache after downloading some dependencies. That cache is read-only by default, and go mod verify exists to double-check the contents too.

I was thinking of the case where since Go itself doesn't expose its own concept of a version to the program, the users themselves are forced to create their own concepts of a version, either through things like VERSION files, or through some build wrappers. By definition, any such concept is under user's control, and the user can and will make mistakes. In fact, from experience, users try to naively use git tags for this which then fail for precisely the reasons you just explained.
Let me rephrase my point. Go can't enforce any useful properties for the user's notion of a version because it doesn't know about it, and as such if we make userVersion==moduleVersion, the fact that Go can't enforce any properties is neither better nor worse for the user. The user is on the hook for doing the right thing in both case. In one case the user must properly maintain their VERSION, and in the other case the user must properly maintain their git checkouts.
The user does gain something in the latter case though. They don't have to create build wrappers.

With the main module in a git checkout, I can think of multiple scenarios [which might fail ... ] I think that, if we are to implement something like this, the versions must be somehow different from the canonical and unique versions that get computed from fully published commits and tags. [...] As a simplistic example, imagine that tagging v1.2.3 locally results in a build whose main module version is devel v1.2.3, but when pushed and go installed, gets the version v1.2.3.

I very much agree with this, with one caveat. If the locally checked-out version is identical to a published release, I would expect the version to match the release. If the locally checked-out version can not be guaranteed to match any release, then yes, it should be published with something like devel v1.2.3 (which matches what Go does, but why not v1.2.3-devel or v1.2.3-unknown, which is semver-compatible?`.
Unfortunately, I can't imagine how this would work without internet access, and quite often a prerequisite of automated systems running go build is to not go to the Internet.

Hold on, another thought. If we always add the commit hash to the main module version for local builds, essentially always making them a Go pseudo-version, then they will always be different from the published version, so there's no potential for confusion there.
Even better, in semver terms these builds will sort before the published version, which is probably what people want.

The main caveat here, I think, is unpublished tags. If I create a local, unpublished tag for, say, v1.1000.0, then my pseudo-versions will be v1.1000.0-0.2022…, but everyone else's pseudo-versions may be on an arbitrarily lower version (say, v0.8.3-0.2022….
That may or may not be a significant issue, though: if we always use a pseudo-version, we'll at least have the commit hash as a common point of reference even if the base versions differ.

@4ad right, a local build can't always know what is or isn't published, as requiring a network roundtrip takes us back to square one.
Your idea of trying to stick to semver, and always using some form of pseudo-version which includes a hash, sounds good. With one caveat, though: the commit hash isn't enough to make the version unambiguous, because I can have infinite kinds of uncommitted changes that do not change the HEAD commit hash.
@bcmills good point about tags still messing with pseudo-versions, but at least if we always include a timestamp and some form of unique hash, then I think we're good. With the caveat above about uncommitted changes :)

We do have another hash available to us, though, which changes whenever any input Go code changes: the build IDs used for the build cache. I seem to recall that one such ID is embedded into binaries, too.
Not ideal, as such a hash also includes build parameters like GOOS or -tags, which don't normally affect versions. But at least it fixed the problem with uncommitted files in VCS.

Yes, uncommitted changes should be explicit in the pseudo-version, but I think we can suffix +, just as we do with Go itself, no?

the new buildinfo already records whether the workspace is clean with vcs.modified=true|false

we could use one of +local (for clean builds) or +dirty (uncommitted changes, implies local) as the semver build id, attached to a pseudoversion which should make the situation clear enough?
So main will always have a version like
vX.Y.Z-timestamp-commit+local
vX.Y.Z-timestamp-commit+dirty

What is the main motivation of encoding the local version in pseudo-version style rather than keeping those extra info (timestamp?) as extra metadata fields - if it's not guaranteed that they are always available in the origin or proxies?
It seems like the vcs.time is already there in the build info metadata.

BTW, I feel like the main module's version isn't sufficient to describe a tool's behavior in certain cases - go version used to go build, third-party tools dependencies, and go build's behavior change (go.work left over somewhere accidentally?) can affect a tool's behavior. So when triaging issues, I hope we develop best practice using go version -m or richer build info dump rather than relying on the main module version string.

What is the main motivation of encoding the local version in pseudo-version style

The main motivation is that go install does it, and many people expect to have a notion of a program's version available and want it, and because they don't have it with go build, they rely on build wrapers or other workarounds, which are undesirable in the broader Go ecosystem.

encoding the local version in pseudo-version style rather than keeping those extra info (timestamp?) as extra metadata fields

Emphasis mine.
It's not rather than, It doesn't replace the existing metadata fields. If you want to read the metadata, you should read it from those fields instead of parsing the pseudo-version. However, that metadata is useful in disambiguating builds produced by go install from published releases. Presumably we could come with some other kind of metadata for the same purpose, but since pseudo-versions are a de-facto standard in the Go ecosystem, why not reuse it?

I feel like the main module's version isn't sufficient to describe a tool's behavior in certain cases - go version used to go build, third-party tools dependencies, and go build's behavior change (go.work left over somewhere accidentally?) can affect a tool's behavior.

This sounds like an argument to always use the build ID as the version suffix instead of the VCS hash.

So when triaging issues, I hope we develop best practice using go version -m or richer build info dump rather than relying on the main module version string.

I hope so too, but again, I think that discussion is out of scope for this thread, which is more about bringing go build in line with go install and providing a solution for users that avoids build wrappers.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

As a kind of experience report, I'm using custom build-scripts for years, solely to embed version information of the main module into the executable. When building, I attach the following information:
type BuildInfo struct {
	// Major, Minor, Patch contain the semantic version components.
	// In case of an unofficial build, this version is from a previous commit on the same branch.
	Major, Minor, Patch int
	// If true, a version-tagged commit was built.
	OfficialBuild bool

	// CommitHash is the full hash of the git commit.
	// Note that the actually built source-code is different if LocalChanges is true.
	CommitHash string
	// CommitTimestamp is the timestamp of the git commit.
	// Note that the actually built source-code is different if LocalChanges is true.
	CommitTimestamp time.Time
	// BuildTimestamp contains the timestamp when the project was built.
	BuildTimestamp time.Time

	// LocalChanges specifies if the project directory differed from the commit due to local (uncommitted) changes.
	LocalChanges bool
}

With this kind of information, I'm able to build version-strings however I like. Usually I try to match go's pseudo-version strings, but when I need to stay compatible with the version-scheme from other, non-go projects, I can do so as well.
// VersionString returns the project's semantic version number without a leading 'v'.
// Patterns:
//    <major>.<minor>.<patch>
//        Built from an officially tagged commit (without local changes)
//    0.0.0-<buildTime>
//        Unofficial build. There are no tagged commits yet.
//    <major>.<minor>.<patch*>-<buildTime>
//        Unofficial build. The commit was not tagged, or there were local changes.
//        The used patch-version is +1 compared to the last tagged commit.
//    The build timestamp (yyyymmddhhmmss) is the UTC time when the application was built / ctgover generated the version number.
func (b *BuildInfo) VersionString() string {
	preRelease := ""
	if !b.OfficialBuild {
		buildTime := b.BuildTimestamp.Format("20060102150405")
		preRelease = "-" + buildTime
	}
}

The version is printed when the application is started with a -version command-line flag. But I guess go-tools could/should show the same version string.
I don't have anything against adding a build ID, but it wouldn't really solve my problem. My use cases are:

Identify the source-code / git-commit that was built
Identify the application's version (for example to detect available updates)
Identify when the application was built (quickly find out if it super old)
Compare if two applications are the same, and which one is newer

The previously raised issue that git-tags might only be local was never really an issue in my experience. Version-tags aren't made lightheartedly and are always immediately pushed to the server in the projects I work on.
I really hope we can this kind of information into a go-executable one day, because I would finally be able to get rid of all my build- and tool-scripts.

It sounds like @mvdan and @bcmills have some hesitation around the fact that these pseudo-versions would not correspond to any publicly available version, even though they look like those. That does seem like a reason not to do this.
We now have Git VCS info separately in the builds (as of Go 1.18; try go version -m). Do we need to add a second way to record that information?

It sounds like @mvdan and @bcmills have some hesitation around the fact that these pseudo-versions would not correspond to any publicly available version, even though they look like those.

We can make it unambiguously distinct, for example instead of v1.2.4-0.20191109021931-daa7c04131f5 we could use v1.2.4-0.unpublished.20191109021931-daa7c04131f5 or something like that.

We now have Git VCS info separately in the builds (as of Go 1.18; try go version -m). Do we need to add a second way to record that information?

No, we certainly only need one way to encode VCS info. The suggestion to put VCS info in the metadata field of the pseudo-version was to match the go install behavior, but putting something else there, for example the build id is probably better. The build id also works, and is meaningful when you might not have VCS info, like from a tarball, which is a pretty common case where you'd use go build for.

We can make it unambiguously distinct, for example instead of v1.2.4-0.20191109021931-daa7c04131f5 we could use v1.2.4-0.unpublished.20191109021931-daa7c04131f5 or something like that.

With replace statements in go.mod and the new workspace mode in Go 1.18 it is possible to build Go programs that include local versions of modules besides the main module. For those modules the go tool also lists (devel) for their version.
The new build vcs metadata only helps identify the main module. Adding vcs metadata for all local modules seems valuable and not currently supported. The format suggested above by @4ad would be more informative than (devel). Maybe also including a dirty flag if there are uncommitted local edits.

The new build vcs metadata only helps identify the main module. Adding vcs metadata for all local modules seems valuable and not currently supported.

This may be true, but the concern above seems to be adding vcs metadata that looks like a pseudo-version. It need not, and it probably should not. We can always add that separately; maybe that should be a different proposal. (I think this is the first comment to bring up VCS info for replaced modules that point to other local repos.)

A thought: if we're only concerned about having a reliable way to always get some useful version for the main module, I think it could be an API of its own, like debug.MainVersion() string. It could first try to get the main module version from https://pkg.go.dev/runtime/debug#ReadBuildInfo, otherwise fall back to VCS information, and otherwise fall back to something that should always work, such as the binary's build ID.
I personally will be implementing logic like that to replace -ldflags=-X=main.version=... with a default of var version = "(devel)" in my projects, essentially copy-pasting 20 or so lines. And I think it should be useful to other projects as well, at least as a sane default.
Another option, if we want this to also work for library modules, would be debug.OwnVersion, which would do the equivalent but for the module containing the package that's making the function call. Perhaps that would cover @ChrisHines's needs. I maintain some libraries and I admit that reliably knowing my own version could help in terms of logging or capturing debug information.
If the above sounds interesting, I'll happily develop the idea further and create a new proposal. I realise it's not the same as this proposal, but I also think it could be a different solution to the same end-user problem :)

@mvdan I would very much like to see something like that to replace the boiler place build lines that exist in code at work.

We use the semantic version of the binaries in order to compute API compatibility between different binaries. I am afraid that if your debug.MainVersion() doesn't always return some string that is compatible with semver, we will still have to resort to -ldflags=-X=....
Now, one might object to using the binary version in this way and perhaps recommend using a separately maintained API version instead that is separate from the binary version. I would tend to agree except this is outside my control. I do not have the operational liberty to change this.

@4ad the "VCS fallback" mentioned in my proposed API could still resemble a pseudo-version, in the sense that it could give you some semver information related to the last known compatible VCS tag. The reason I think it's less likely to cause confusion with real and published pseudo-versions is that the API docs could explicitly warn users against assuming that the version is a valid module version.
Put another way, my worry with the original proposal here is that, currently, the module versions embedded into binaries are documented and likely assumed to be valid and published. Changing that could be confusing or silently break programs, whereas a new API can avoid the "module version" terminology altogether, and isn't changing existing behavior that could break any programs.

I see, yes. That would work for us.

provided there's a way to retrieve it from outside the binary

Do you mean via a cmd/go command that takes a path to a binary, or via a Go API that takes the path?

I'd be ok with either, I would prefer it to be in cmd/go, so I wouldn't have to write another tool, but as long as there's an API I can use, I'm happy.

If I check out a tagged version of source code, let's say<EMAIL_ADDRESS>and go build from the cloned, unmodified
repo, what will be the pseudo-version like? v1.5.2, v1.5.3-...., v1.5.2-...?
If that is not v1.5.2, do we want the go command to report an error if someone tries to go install with the special pseudo-version? Or, should the go module proxy serve data as if it's like a normal pseudo-version?

It would be a "fake local" version similar to a pseudo-version; we haven't defined what the format of that would be yet. I think we're all in agreemnet that it shouldn't look like a real pseudo-version, meaning that the format should be distinctly different, such as by containing a special suffix. That would then allow go install or the module proxy to outright reject using those module versions, because they're not valid module versions.

@hyangah, we do have some logic today to convert versions with +build metadata to canonical pseudo-versions.¹
I suspect we would reuse that same logic, so a checkout from v1.5.2 would probably show as a v1.5.3-0.… pseudo-version.
¹https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/modfetch/coderepo.go;l=482-492;drc=fa4d9b8e2bc2612960c80474fca83a4c85a974eb

Currently BuildInfo.Main.Version can be trusted since it is only set for pristine builds pulled from a repo (otherwise "(devel)"). Currently these pristine builds more or less require module proxy infrastructure (a significant barrier for many, especially private developers/repos).
I'd prefer to keep a single definition for the version stored in BuildInfo.Main.Version (known version pulled from a repo). I think it would be better to provide an easy way to build a pristine private module without needing module proxy infrastructure. Eg:
go install -local<EMAIL_ADDRESS>This would keep the version definition the same and enable many developers who develop private modules locally to output pristine module builds. It does make it easier for someone to "fake" a version with a local tag, but this is already possible for sufficiently motivated developers. I'd prefer to optimise for easy of use.

The main argument, at least as far as I understand, is that we might stamp the build with a tag that does not mean the same thing locally that it means in the published repo.
But I suppose that's also true of tags that could be moved in a private upstream repo (and fetched directly); as long as we also stamp the commit hash and/or module checksum for the main module, it's not necessarily a major impediment.

The argument for is, more or less, that many binary maintainers will build their binaries from within their repo (for example, to pick up local replace directives), and that giving those binaries a version that sorts in with the versions stamped when installed outside of a module makes it easier for maintainers to identify exactly when a problem may have been introduced or resolved.

Talked to @bcmills and @matloob. It sounds like this is OK as long as it does not slow down builds too much.

FWIW,  I think it would be very helpful to do something here. Based on my experience and what I've seen from others, it is not rare for teams working on closed-source Go to do their official builds via 'git clone' followed by 'go build' (or similar), without ever taking the time make their own code "go get'able" (or to at least start out that way until the Go code base grows; I think this is especially true in multi-language environments).
It would be nice to converge on how this would be formatted.  I pulled together some related comment snippets from above (from a very quick re-read/skim, so apologies if I missed something, or if too snippetized):
From @4ad:

If we always add the commit hash, and some other metadata to the main module version for local builds, essentially always making them a fully qualified Go pseudo-version, then they will always be different from the published version, so there's no potential for confusion there.

and:

why not v1.2.3-devel or v1.2.3-unknown, which is semver-compatible?).

and:

we could use v1.2.4-0.unpublished.20191109021931-daa7c04131f5 or something like that.

Later from @seankhliao:

we could use one of +local (for clean builds) or +dirty (uncommitted changes, implies local) as the semver build id, attached to a pseudoversion which should make the situation clear enough?
So main will always have a version like
vX.Y.Z-timestamp-commit+local
vX.Y.Z-timestamp-commit+dirty

From @chrishines:

Maybe also including a dirty flag if there are uncommitted local edits.

From @bcmills:

a checkout from v1.5.2 would probably show as a v1.5.3-0.… pseudo-version.

Does anyone object to adding this?

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

I don't oppose this, though I'd like to understand what version format is exactly being proposed, like @thepudds mentioned.

Giving this some more thought, I think we should stamp exactly the version that would be resolved if the repository were published upstream as-is.
The VCS stamp should already provide the commit hash and indicate whether the working tree is dirty, so if the meaning of that version changes it's more-or-less exactly as if the repo were published, the package built with GOPRIVATE set, and then the tag were moved to refer to some other commit.

Why not just add vcs.tag to buildinfo and let people use it as they see fit ?

@kgersen please read the thread before commenting on it.

@bcmills I've thought about it again and I've come around to seeing that we already can't always rely on stamped module versions when trusted module proxies aren't involved, as VCS tags can change under the hood. So I am fine with just stamping what's available locally no matter what, as long as we also stamp VCS information.
I think my only slight worry then would be: programs wishing to show their information should always print the VCS info (commit, date, dirty, etc) alongside the module version, because not doing so could potentially lead to confusing edge cases for authors such as tags having been added or modified locally. We should clarify that in the documentation.
Thinking outloud, we also don't need to worry about "what if VCS information isn't stamped?", because if that's the case, then we're not stamping the locally-inferred module version either.

@bcmills Re: https://github.com/golang/go/issues/50603#issuecomment-1069531971: Given the recent change that makes the vcs version stamping optional (-buildvcs=auto) depending on the presence of the vcs cli tool, if this feature is implemented in that way, I think it's better to add an extra low cost tag that indicates the binary was built with go build.
I was initially excited by this proposal and thought this would help #46880 by providing a convenient way to build an unstable version of gopls. Then, realized that the version string will be a v0.0.0- prefixed pseudo version because our dev branch won't have any sensible tag. In fact, this kind of repo setup (release in a separate branch) makes our automated gopls upgrade logic slightly more complicated. A reliable way to add an extra tag or suffix that clearly indicates the binary was built in a different way will help us handle the version comparison a bit better.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Any chance we can get this in 1.19?

@amnonbc the 1.19 freeze began over a month ago, so I'd say it's very late at this point, even if someone had already begun work on it - which doesn't appear to be the case.

It would be nice if it would solve these edge cases:
git tag -sm"v1.2.3" v1.2.3
go install .
app version // outputs (devel) expecting v1.2.3

git tag -sm"v1.2.3" v1.2.3
git push && git push --tags
go install example.com/app@latest
app version // outputs v1.2.3

any chance we can get this in 1.20?
Or failing that, in 1.21?

@amnonbc there is no need to ask every cycle. If there was progress, you would see it here. The only other way to make it happen is to volunteer yourself and learn the codebase well.

@amnonbc there is no need to ask every cycle. If there was progress, you would see it here. The only other way to make it happen is to volunteer yourself and learn the codebase well.

Fair enough. I hope to have some time to look at this over the Xmas holiday.

I think my only slight worry then would be: programs wishing to show their information should always print the VCS info (commit, date, dirty, etc) alongside the module version, because not doing so could potentially lead to confusing edge cases for authors such as tags having been added or modified locally.

For me, the VCS info, especially the tag, plus the commit, is the single piece that I‘m looking for in this feature. If the tag is recorded as VCS info or as pseudo version wouldn‘t matter as long as I can retrieve it to remove the need for ldflags. That in turn simplifies the build process and e.g. allows to use static build config with tools like gokrazy.

Here's something I think we never covered - would this stamping from VCS info always happen, or only when -buildvcs is enabled, be it via -buildvcs=true or when the default -buildvcs=auto finds the git tool and .git data to be present? I ask this in the context of https://github.com/golang/go/issues/53976#issuecomment-1711440904.

Expanding on the comment by @maja42, another use-case is vulnerability scanners.  I think all these scanners work by examining the artifact, e.g. a golang binary, and extracting enough information to derive a CPE for each distinct application/library/module, and then looking up any vulnerabilities for those CPEs in whatever vuln database is used.  If the scanner can't derive a CPE for a given component, then it can't lookup vulns for that component.
Trivy currently uses debug/buildinfo to derive CPEs for the dependencies, but does not look at the "main" module, possibly because it rarely sees usable values for the "main" module (pure speculation on my part).
If the debug/buildinfo fields are the canonical place to put this kind of name-and-version information, then populating it in more cases would allow the scanners to report more vulns.

Thank you for all your ideas. This is definitely an important feature. After considering all of your ideas and discussing with @matloob, we have landed upon this format:
v[tag]-[devel]-[timestamp]-[commit]+[optional dirty]
v[tag]
Tag information.
E.g. v1.2.4
[devel]
Differentiates between published versions from a local development version. We currently use devel in other places so it makes sense to continue using it.
[timestamp]
Timestamp in YYYYMMDDHHMMSS format (UTC)
E.g.<PHONE_NUMBER>1931
[commit]
First 12 characters of commit hash.
E.g. daa7c0413123
[optional dirty]
dirty: there are uncommitted changes in the build.
A missing dirty label indicates that the build is ‘clean’ and has no uncommitted changes.
Some examples:

V1.2.3-devel-20240620130020-daa7c0413123+dirty

v1.2.3-devel-20240620130020-daa7c0413123

Semantic versioning comparison:
Local builds would compare less than published builds
E.g. V1.2.3-devel-20240620130020-daa7c0413123+dirty < v1.2.3

If you have any feedback, please let us know!
We will try to get this in 1.24.

The proposed format makes sense to me when either the work tree is dirty or the currently-selected commit doesn't exactly match a tag.
It's not clear to me from the most recent comment whether there would also be a special case to use the regular version number alone when the current commit exactly matches a tag. Ideally I'd like for that case to be indistinguishable from the treatment of libraries, but I don't know if there are hurdles that make that infeasible.
If the outcome were to use the proposed format in the dirty or not-tagged case but to use the tag-derived version number when at tag exactly matches then I think that would be sufficient for the codebase I help maintain in my day job to drop its own redundant version number tracking and use the toolchain-generated version information exclusively, which would be great because we'd then get more reliable information for non-release builds (that are always just called "v1.2.3-dev" for us today).

One potential caveat:
Some version constraint systems use lexical ordering to decide which is the newest between two prerelease versions that have the same base version. In that case v1.2.3-devel-anything would sort after v1.2.3-alpha-anything or v1.2.3-beta-antyhing.
I don't think that's a blocking concern -- it's questionable whether it's ever meaningful to sort development builds relative to release builds anyway -- but wanted to raise it anyway since it was a hazard I've run into in the past in a different context.

What happens when there's no tag at the current commit?
Sorting before seems a bit weird, especially if there are local changes layered on top of an existing tagged/release version?
The separator used is -, but semver uses . to separate build identifier components, any specific reason for using -?

From https://github.com/golang/go/issues/50603#issuecomment-1069531971
I thought we'd use the exact tag as the version, with extra build setting info (e.g. VCS info or lack of it, install-vs-build, etc). I am still in favor of the idea because:

It is human who ultimately consumes the version string. Longer strings are less user friendly. Most products use v1.2.3 form of versioning in the release notes, public tags, and announcements. It will be less obvious for users to connect v1.2.3 release note and v1.2.3-devel-... in the build info.
The version info is also useful for tools (e.g. vuln scanners) written in different languages and targeted for language-agnostic services. Building more go specific rules beyond the general semver rules can result in bugs (e.g. false positive/negative in vuln scanning service)
It's unclear what we want to achieve by trying to encode all build details in the version string rather than using the build info setting field.

More specific example:
Let's assume we found a vulnerability in a binary built from a clean checkout of v1.2.3, and it's fixed in v1.2.4. All release note, bug triaging, etc are done with this short tag v1.2.3 most likely, but the released binary has v1.2.3-devel-20240620130020-daa7c0413123 since go build was used. That can be confusing.
When creating a CVE, we should use v1.2.3-devel-20240620130020-daa7c0413123 as the vulnerability introduction version, but use v1.2.4-devel-2024... as the fix version. This is less user-friendly. Moreover, I heard version range comparison involving pseudo versions can be complex. (@golang/vulndb, @neild)
The version in the build info is also used by the Go telemetry. To collect the telemetry, the version string should be explicitly listed in the configuration.  I don't think the binary with version v1.2.3 and the binary with v1.2.3-devel-20240620130020-daa7c0413123 are different enough to warrant separated tracking.

What happens when there's no tag at the current commit?

I guess v0.0.0 will be used?

The separator used is -, but semver uses . to separate build identifier components, any specific reason for using -?

Could you expand on that? - is currently used in pseudo versions.

The separator used is -, but semver uses . to separate build identifier components, any specific reason for using -?

Could you expand on that? - is currently used in pseudo versions.

It should be one dash followed by dot separated components: https://semver.org/#spec-item-9

The current pseudoversions use different base versions based on existing tags in the current of parent commits:

vX.0.0-yyyymmddhhmmss-abcdefabcdef is used when there is no known base version. As with all versions, the major version X must match the module’s major version suffix.
vX.Y.Z-pre.0.yyyymmddhhmmss-abcdefabcdef is used when the base version is a pre-release version like vX.Y.Z-pre.
vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdefabcdef is used when the base version is a release version like vX.Y.Z. For example, if the base version is v1.2.3, a pseudo-version might be v1.2.4-0.20191109021931-daa7c04131f5.

The dot separator (.)0. is used to ensure these sort before any user provided build identifiers.
Given that we already have existing pseudoversions that can identify commits, I'm not sure why we need a separate format for local builds, beyond marking it as either a local clean or dirty build (maybe build metadata +clean vs +dirty?)

It's not clear to me from the most recent comment whether there would also be a special case to use the regular version number alone when the current commit exactly matches a tag.

I see your point. It would be useful to drop the pseudo version if the current commit matches a tag. My understanding is that they may need to be separate. A local build might inherently be different than one from the module cache and such we don't want to confuse the two. I will discuss more with @rsc and @matloob and circle back.

v1.2.3-devel-anything would sort after v1.2.3-alpha-anything

Interesting point. Like you said, I don't think it would be meaningful to sort a local build against other pre-release versions, but let's add a -0 to have it be less than any pre-releases. So we have v1.2.3-0-devel.

What happens when there's no tag at the current commit?

vX.0.0 if there is no such tag.

Sorting before seems a bit weird, especially if there are local changes layered on top of an existing tagged/release version?

Good point! Let's have it sorted after. Upon further investigation, copying the psuedo-version behavior from go install makes sense here which bumps the version if the commit is newer than the last release.
https://cs.opensource.google/go/go/+/master:src/cmd/vendor/golang.org/x/mod/module/pseudo.go
So we will perform this operation:
vX.Y.(Z+1) if a tag exists.

The separator used is -, but semver uses . to separate build identifier components, any specific reason for using -?

This we're not completely sure on. But I suppose a combination of '.' and '-' makes more sense.
Taking into account the above points, maybe instead we should do:
v[X.Y.(Z+1)]-0.[timestamp].devel-[commit]+[optional dirty]

Given that we already have existing pseudoversions that can identify commits, I'm not sure why we need a separate format for local builds

I agree with you. I think it makes sense to closely follow the existing structure from: https://cs.opensource.google/go/go/+/master:src/cmd/vendor/golang.org/x/mod/module/pseudo.go
@hyangah
I suppose it comes down to the intent of how these pseudo-versions will be used. It's not clear to me if there should be a clear separation between a local build and one based on the module cache. If we drop the pseudo version when the current commit matches the tagged version, then that might clear up some confusion.
Let me discuss this more in depth with @rsc and @matloob and I will update when I have a clearer answer.
Thanks for the help guys.
I will update my original comment to reflect these changes.

I want to reiterate what @hyangah said - as of 2022, and when the proposal was accepted, we had already reached consensus that a local build of a commit on a semver tag should result in a module version reflecting just that semver string. See https://github.com/golang/go/issues/50603#issuecomment-1070789161 for example. I don't think new information has come to light since then, so I'd be very confused if we suddenly decided to implement something else.

Further, if a proposed pseudo-version of a clean local commit with a semver tag is syntactically different from the semver tag, then how does that affect [version.Compare`](https://pkg.go.dev/go/version#Compare)? It should return `0` imo, but I have no idea how one would actually implement that.

@zpavlinovic
how does that affect version.Compare?

I believe version.Compare only compares go versions.
I think you meant semantically comparing module versions?
If we cannot guarantee the same version stamping with @matloob's concerns then it might make sense to add a +build suffix?
i.e. v1.2.4+build
This would compare equally to v1.2.4 but imply that they were built differently.

It might also be that these issues don't matter because the version is not meant treated as 100% accurate.

That is my understanding from the previous consensus. go install pkg@version via a GOPROXY blindly trusts the info from the proxy to produce a module version. Similarly, with GOPROXY=off, we blindly trust the info from the original VCS state, which can easily be altered in many cases. Blindly trusting the local VCS state does not seem any worse in this respect - if anything, it's consistent.
I don't have a strong opinion on a suffix like +build or +local to distinguish local builds, but I worry it could easily confuse users and cause issues for module developers who now may need to deal with this suffix inconsistency. If the produced build is otherwise equivalent to go install pkg@version with GOPROXY=off, then I definitely think the resulting module version should be the same.
It's also worth noting that one could often use the presence and contents of the stamped -buildvcs metadata to detect that a build was made locally and a module version was derived from it. If we only stamped a VCS-derived module version for a local build when -buildvcs was enabled, then a developer could use the presence of the VCS information to tell that a module version was derived from the local VCS state. That is what I would find most intuitive as both a user and developer.

I too am confused why we would define a new pseudo-version syntax instead of using the existing algorithm and derivation code. Let's talk more about this next time we meet, @matloob and @samthanawalla.

@rsc @matloob and I discussed this today.
I have revised my original comment to reflect the decision we came to. See #50603 (comment)
When the current commit matches a tagged version we will use v[tag].
When the current commit does not match a tagged version or there are uncommitted changes, we'll use the existing pseudo version format.
(We dropped the devel and the +build)

@DavidGamba
Are uncommitted changes only considered for the directory where the go.mod lives?

We were planning to rely on what the VCS state is, I.e. git status.
I don't think it makes sense to only consider the directory where go.mod lives because it introduces additional states to consider which I think may make the version info more confusing. But I could be wrong.
However as a compromise, would v[tag]+dirty work for your use case?
If your current commit matches a tagged version but you have uncommitted changes, you would get v[tag]+dirty instead of [pseudoversion]+dirty.

I would prefer to be able to push a binary as is from my machine if there are no changes in the the given go module. Other than a go.work file and possible env vars there shouldn't be any dirty files affecting the go binary itself so marking the binary as dirty when there are no changes in the module itself seems overly cautious.

it introduces additional states to consider

I am not sure I know enough about Go to know anything else other than the go.work and env vars that introduce additional states. I would love to learn a bit more about what else affects a go module.
At the end of the day, having the version stamped will be a win even if I can only get the non-dirty version out of CI or a clean clone.

By states I meant to say version control states.
I do get your point but a tag is more a property of the repo and not just the main module. Changes to the repo as a whole will reflect accordingly in the stamped version.
While it may be overly cautious, I don't think we will support this use case as of now. But that could change in the future if necessary.
Updated #50603 comment to include v[tag]+dirty use case.

@DavidGamba I would be interested in understanding your use case better. Our expectation is that those planning to do a build of a go program at a given version would check out the appropriate version and do a clean build. Our plan is to reuse the vcs.modified field in the buildinfo in determining whether a build is clean. That would help avoid doing extra work for what we believe is an uncommon case. But if it isn't an uncommon case we'd like to know.

vcs.modified seems to be set here. My understanding of the code is that this value is false by default unless one of known versioning systems is used. For those systems, status command is used to get the value for modified using the current working directory.

I would prefer to be able to push a binary as is from my machine if there are no changes in the the given go module. Other than a go.work file and possible env vars there shouldn't be any dirty files affecting the go binary itself so marking the binary as dirty when there are no changes in the module itself seems overly cautious.

The more and more I think about this, the more I get the feeling that having a completely precise solution is either extremely hard or impossible.
If a module has a replace directive pointing to a local directory outside of the module, then changing that replacing directory content could result in a different binary. To make things more complicated, this replacing directory might be outside of a repo where the module is.
It seems to me that the current approach is making a decent compromise. It will cover the more common case where the replacing module is in the same repo. Of course, it might add +dirty if part of a repo completely unrelated to module is being changed.
Regarding monorepo, it seems that the current approach will always have vcs.modified set to true. An example is svn (it does not have a Status method so computing modified will be skipped). It would be good to verify that.

My use case is not a major use case since official builds will come from CI. It is just in those cases where you want to push something out that doesn't have a pipeline yet. Cloning a clean repo for those is not a major inconvenience and worst case the binary will just have the +dirty label.

Would someone mind summarizing exactly where this new version info will show up in runtime/debug.BuildInfo?
Is it runtime/debug.BuildInfo.Main.Version?
(Sorry if this is spelled out above – I did some re-skimming and some Ctrl-F, and I saw a couple of suggestions, I’m not sure I saw a definitive statement).

@thepudds
Is it runtime/debug.BuildInfo.Main.Version?

Yes! No worries, there's a lot of comments.

https://go.dev/cl/596035 is merged which adds version stamping for git only. This will come out in 1.24.
I have not looked into other VCS like hg(Mercurial), svn(Subversion), bzr(GNU Bazaar), and fossil and unsure whether they will be added by 1.24.
I will leave this issue open for now.

Thanks @samthanawalla, I just gave it a try and it seems to be working as advertised!
I'm still slightly surprised at the appearance of +dirty when we already track this information via vcs.modified. Why duplicate the information when it is already there? It doesn't give me 100% assurance that the lack of +dirty means the version is to be trusted anyway, as a local git tag can be modified, as discussed before. Personally I would omit this feature - it wasn't in the original design, and I still don't understand why it has been added.
I also notice that the version stamping does not happen with -buildvcs=false. That's probably reasonable, but we should document this properly. I had asked this question some time back in https://github.com/golang/go/issues/50603#issuecomment-1711441610 but the proposed design wasn't clear before we had an implementation.

@mvdan
Awesome, glad to hear!
While vcs.modified technically captures this information, the decision to surface it within the version is driven by making it immediately visible to those who primarily focus on the version. It's not necessarily motivated by trust but rather transparency and better 'book keeping'. It more directly conveys the relationship between tag information and how VCS changes can influence the build.
Does +dirty create any problems for tooling? My understanding is that it can easily be chopped off for those who don't need it but is useful for those who may intentionally or unintentionally ignore vcs.modified and only look at the version.
If there are specific use cases where +dirty causes issues for tooling then we can still change that as there is plenty of time till the 1.24 release. However we believe the enhanced visibility it provides into the build's status outweighs any potential drawbacks.
Of course, we're open to hearing further feedback and specific examples :)

I also notice that the version stamping does not happen with -buildvcs=false

Yes correct. Sounds good I will be sure to document that aspect as well.

I don't feel strongly about the presence of a +dirty suffix, nor do I have a specific use case that gets broken by it. Like you say, it can be chopped off fairly easily. Although I could say almost the same about adding it myself from vcs.modified - this is more a matter of what the default behavior should be. I don't think choosing to be explicit and verbose by default is wrong per se.
However, I do find it an odd default because I often end up with +dirty builds when the binary is identical. For example, I regularly capture cpu or memory pprof files, and I sometimes leave them around for a while as they are harmless. Because I don't explicitly gitignore them, they make my local binaries +dirty, even though they don't participate in the build process at all.
Another similar scenario that I'm running into is building binaries for many platforms at once. I tend to build the binaries in the local directory, inside the module, to then upload them as release archives. And once again they are not gitignored - which is fine, as I delete them soon after, and they don't participate in the build. But once again, +dirty shows up for any build after the first one:
$ GOOS=linux GOARCH=amd64 go build -o binary-linux-amd64 ./cmd/cue
$ GOOS=linux GOARCH=386 go build -o binary-linux-386 ./cmd/cue
$ ./binary-linux-amd64 version
cue version v0.11.0-0.dev.0.20240819151828-81d6f8bfcd61

go version devel go1.24-527610763b 2024-08-15 23:43:00 +0000
      -buildmode exe
       -compiler gc
  DefaultGODEBUG asynctimerchan=1,gotypesalias=0,httpservecontentkeepheaders=1,tls3des=1,tlskyber=0,x509keypairleaf=0,x509negativeserial=1
     CGO_ENABLED 1
          GOARCH amd64
            GOOS linux
         GOAMD64 v3
             vcs git
    vcs.revision 81d6f8bfcd61eeff2ec60ac71c8cc9867e6853e9
        vcs.time 2024-08-19T15:18:28Z
    vcs.modified false
cue.lang.version v0.11.0
$ ./binary-linux-386 version
cue version v0.11.0-0.dev.0.20240819151828-81d6f8bfcd61+dirty

go version devel go1.24-527610763b 2024-08-15 23:43:00 +0000
      -buildmode exe
       -compiler gc
  DefaultGODEBUG asynctimerchan=1,gotypesalias=0,httpservecontentkeepheaders=1,tls3des=1,tlskyber=0,x509keypairleaf=0,x509negativeserial=1
     CGO_ENABLED 0
          GOARCH 386
            GOOS linux
           GO386 sse2
             vcs git
    vcs.revision 81d6f8bfcd61eeff2ec60ac71c8cc9867e6853e9
        vcs.time 2024-08-19T15:18:28Z
    vcs.modified true
cue.lang.version v0.11.0

Arguably this is all an issue affecting vcs.modified as well, which can be seen by cue version above printing the buildingo setting lines as well. I would agree with that - if any files make VCS "dirty", but go list can tell that they do not participate in the build (not known source files, not used for go:embed, etc), then they shouldn't make built binaries "dirty".
Even though this was already an issue for vcs.modified, I honestly didn't really care too much before this point. Now that it's causing me +dirty suffixes in locally built module versions more often than not, it is causing me some issues. So I'd be fine with keeping +dirty suffixes as long as them and vcs.modified did not care about the dirtiness of files which do not participate in the Go build.
Speaking of... what if I had a new uncommitted Go file which did participate in the Go build, but was gitignored, so it wouldn't show up in git status? While this is technically not "VCS dirty", I would argue it should still mark the binary version and vcs.modified as dirty, because the Go tool can tell that it built a source file which is not tracked by VCS at all. Does this happen today?

@samthanawalla Thanks for this feature! This will help simplify the future release workflow of vscode go release greatly.
One more tuning request: I noticed that some projects use the tools.go hack to pick govulncheck or gopls versions. (note: imo, listing tools like gopls to tools.go is always a mistake, but listing tools like govulncheck in tools.go is understandable)
However, tools built this way can be very different from the tools built with go install <tool>@<version> or from a clean checkout of the tool's source code.
For example,
$ cat go.mod
module xxx

go 1.21.0

require (
	golang.org/x/tools/gopls v0.16.2-pre.1
	golang.org/x/vuln v1.1.0
)
...
$  gotip build golang.org/x/tools/gopls

This gopls binary is very different from<EMAIL_ADDRESS>$ gotip install<EMAIL_ADDRESS>$ gotip version -m ~/go/bin/gopls > install.txt
$ gotip version -m ./gopls > unclean.txt
$ diff install.txt unclean.txt
1c1
< /Users/hakim/go/bin/gopls: devel go1.24-f38d42f2c4 Wed Aug 21 01:11:27 2024 +0000
---
> ./gopls: devel go1.24-f38d42f2c4 Wed Aug 21 01:11:27 2024 +0000
7,8c7,8
< 	dep	golang.org/x/mod	v0.19.0	h1:fEdghXQSo20giMthA7cd28ZC+jts4amQ3YMXiP5oMQ8=
< 	dep	golang.org/x/sync	v0.7.0	h1:YsImfSBoP9QPYL0xyKJPq0gcaJdG3rInoqxTWbfQu9M=
---
> 	dep	golang.org/x/mod	v0.20.0	h1:utOm6MM3R3dnawAiJgn0y+xvuYRsm1RKM/4giyfDgV0=
> 	dep	golang.org/x/sync	v0.8.0	h1:3NFvSEYkUoMifnESzZl15y791HH1qU2xm6eCJU5ZPXQ=
12c12
< 	dep	golang.org/x/vuln	v1.0.4	h1:SP0mPeg2PmGCu03V+61EcQiOjmpri2XijexKdzv8Z1I=
---
> 	dep	golang.org/x/vuln	v1.1.0	h1:ECEdI+aEtjpF90eqEcDL5Q11DWSZAw5PJQWlp0+gWqc=
18c18
< 	build	DefaultGODEBUG=asynctimerchan=1,gotypesalias=0,httplaxcontentlength=1,httpmuxgo121=1,httpservecontentkeepheaders=1,panicnil=1,randseednop=0,tls10server=1,tls3des=1,tlskyber=0,tlsrsakex=1,tlsunsafeekm=1,winreadlinkvolume=0,winsymlink=0,x509keypairleaf=0,x509negativeserial=1
---
> 	build	DefaultGODEBUG=asynctimerchan=1,gotypesalias=0,httplaxcontentlength=1,httpmuxgo121=1,httpservecontentkeepheaders=1,randseednop=0,tls10server=1,tls3des=1,tlskyber=0,tlsrsakex=1,tlsunsafeekm=1,winreadlinkvolume=0,winsymlink=0,x509keypairleaf=0,x509negativeserial=1

Once the tool dependency proposal #48429 is implemented, some users may attempt to pick a specific version of govulncheck (or gopls) and such unexpected and untested versions of tools may appear more often. Currently golang.org/x/telemetry uses the main module's version string as the tool's version. The crash reports and counters from such untested versions are not distinguishable, and can add much noise.
Is it possible to use a different version string (+dirty) or add an extra build setting info if a tool is built this way? That will help us filter out telemetry from unexpected builds of tools.

@hyangah I had a similar (though slightly different concern) that the build with go build would get a different build list from the one using go install. I think once a build is being done outside of the go install pkg@version context, the version of the installed binary's module tells us a lot less about the dependencies used to build the binary.
What do you think about adding a buildinfo field for the module path of the main module (or whether the build was done from a workspace, or from a pkg@version context) and telemetry could treat the binary different depending on which it is?

@mvdan I see your point. Multiple sequential builds will create a +dirty tag because of the binary that gets created which does not seem ideal. I will see about making an exception for that.
As far as the dirtiness of files which do not participate in the Go build affecting +dirty, we discussed that above: https://github.com/golang/go/issues/50603#issuecomment-2195420749
We think the most common case is a clean build from CI. Otherwise you can clone & build from a clean repo.
Yes an uncommitted file that is gitignored will not have a +dirty tag. This is a drawback of the current implementation. However if this is an uncommon situation, then perhaps we may need to compromise somewhere.

@samthanawalla @matloob I feel like whether the builds happen locally or in CI is a red herring. Whether I do the builds locally or in CI, placing the binaries inside the same cloned repository seems perfectly fine to me. They don't affect the build in any way, nor do they touch any committed files.
git describe --always --dirty agrees with me here, for what it's worth; it only adds a -dirty suffix if I modify or delete any tracked files, or if I git add any new files. Any new untracked files, even if they are not gitignored, do not cause a -dirty suffix. So our notion of "dirty" seems to misalign with git's, and git is easily the most common VCS system people are using.
And as explained before, I think it's a mistake for go build to not mark a binary as dirty if a gitignored Go file is present in the build. I just tested this, and the resulting build was not marked as "dirty", even though it definitely built different source code than what is committed.
I realise my arguments are against vcs.modified; your addition of +dirty simply follows vcs.modified. I think both follow a flawed notion of "dirtyness" that is not useful to Go developers and can be confusing to Go users. I think we should adjust it so that:

A build is dirty when there are new and VCS-ignored files which contribute to the build (e.g: Go files part of a built Go package, or any embedded files, etc).
A build is not dirty when there are new and non-VCS-ignored files which do not contribute to the build (e.g: built Go binaries, or pprof files, etc).

That is, Go builds should only be marked as "dirty" if we can tell that they used a different set of source files compared to what is committed. That is honestly what I thought vcs.modified already was, and I think it would be a much better definition than what we currently have. As currently implemented, I'm afraid that I'll have to strip or ignore vcs.modified build settings and +dirty version suffixes, because they'll often confuse users for no benefit.

@mvdan
Conclusion from the contributor bi-monthly tools meeting:
While we'd ideally like a completely precise solution for determining dirtiness, it looks like that would require some extensive modifications to the build system (we don't track all files that contribute to the build right now.) This might also introduce significant overhead and slow down builds.
Given the potential complexity and impact, let's move this discussion to a dedicated proposal for refining vcs.modified.

Sorry to piggy back on this issue :
The embedding of VCS information in the binary doesn't work when built from a git WORKTREE.
It would be somewhat convenient, a worktree seems to have a /.git file (not folder) containing :
gitdir: /path/to/a/subfolder/of/the/.git/folder/
Would be awesome if it were to be handled :) Thanks !

@folays that is https://github.com/golang/go/issues/58218.

This work related to the original issue is completed.
Separate proposals will be needed for:

https://github.com/golang/go/issues/50603#issuecomment-2300983645 add BuildInfo if a binary was built locally.
https://github.com/golang/go/issues/50603#issuecomment-2315888855 changing vcs.modified
Supporting the VCS Subversion since tags were never really supported

@samthanawalla This new capability seems noteworthy enough that it should be mentioned in Go 1.24 release notes, is that right? Reopening as a release blocker to track that. Thanks.

The RC is planned for next week, and we need a full draft of the release notes before then. Please prioritize writing the release notes for this. Thanks!

I was testing this with a project and was a bit surprised that using gotip run on a package in the current module, i.e. gotip run ./cmd/example while in the module root, still gets (devel). gotip build correctly gave me the pseudo-version. Is this an oversight, outside the scope of this, or intentional? A search in this issue for go run and gotip run didn't find any results.

@DeedleFake This is intentional.
Whether we load version control information is controlled by the -buildvcs flag. In the default -buildvcs=auto mode we only load verscion control info when we're producing an artifact (go build, go install) or explicitly providing information to the user (go list). See also https://github.com/golang/go/issues/52338#issuecomment-1104144397 for why we don't get version control information in go run.
You could set -buildvcs=true to force version control information to be populated.


Directed View should be invalidated when the module changes (like flatten)

Closing, as this should be fixed by #136


SAK-43579 - Rubrics: Ability to search rubrics and shared rubrics

https://jira.sakaiproject.org/browse/SAK-43579

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- rubrics/tool/src/main/frontend/webcomponents/js/sakai-rubrics-manager.js  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 2

Complexity increasing per file
==============================
- rubrics/tool/src/main/frontend/webcomponents/js/sakai-rubrics-manager.js  2

See the complete overview on Codacy


OmniLight does not fade out towards range end

Godot version:
v3.2.beta.custom_build.318c69351
OS/device including version:
Linux (Solus 4.0)
Issue description:
In the current master branch the OmniLight does not fade out towards the range end. Instead the whole lighted area seems to have the same light intensity.
(It can be improved with the attenuation value. However regardless of the settings it does not fade out completely.)
Steps to reproduce:
Add an OmniLight above a big enough plane mesh to cover the whole range. Leave everything else on default.
Minimal reproduction project:
Project: omni_bug.zip
Image from the project:

It seems like this behaviour was introduced by #34527


[navigation-refactor] Change navigate to goBack after saving on paypal me page

Details
Change navigate to goBack after saving on paypal me page. Navigates was pushing the screen after deep linking to this page. We need to use goBack to make it work as expected
Fixed Issues

$ https://github.com/Expensify/App/issues/23089
PROPOSAL:
Tests

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

go to Paypal page using link https://staging.new.expensify.com/settings/payments/add-paypal-me
add or edit username and click on save button
click back button from Payments page
user should be redirect to setting

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

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

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://github.com/Expensify/App/assets/67908363/3bfe8e81-f703-4efa-a866-b15bc8803023

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

@narefyev91 Can you please review and test this PR?

@narefyev91 Can you please include videos that you have tested on all platforms? thanks!

@narefyev91 Can you please include videos that you have tested on all platforms? thanks!

Done

@bondydaa should be all good and ready for you 🚀

is it okay to merge even though there is no reviewer checklist?

oh 🤦 nvm i can't read https://github.com/Expensify/App/pull/23086#issuecomment-1640300143

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/bondydaa in version: 1.3.43-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/bondydaa in version: 1.3.43-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/bondydaa in version: 1.3.44-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/jasperhuangg in version: 1.3.43-7 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


armkeyvault: KeysClient ListPager doesn't provide all information for a key

Bug Report

import path:. .../azure-sdk-for-go/sdk/resourcemanager/keyvault/armkeyvault@v1.3.0/keys_client.go:261

output of go version: go1.21.1 linux/amd64

What happened?
I was using KeysClients method NewListPager to get a retrieve all keys that we have in a certain key vault. But the returned keys of the key pages miss many information. E.g., Kty was always nil.
Now I realized that using the KeysClients method Get I get all informaiton about one specific key. But why do  I not get all the key information via the list pager and, in particular, why the list pager method doesn't say anything about it in the comment that some fields won't be filled?

What did you expect or want to happen?
Either fill out all information or comment the methods appropriately to give advice to be cautious.

Thanks in advance!

Hi @lebogg,
Per Key Vault documentations this is an expected behavior when retrieving a list of all the keys in a Key Vault instance (documentation) . When you use NewListPager to retrieve all keys that you have in a specific key vault you will be returned:
"the keys in the Key Vault as JSON Web Key structures that contain the public part of a stored key. The LIST operation is applicable to all key types, however only the base key identifier, attributes, and tags are provided in the response. Individual versions of a key are not listed in the response."
In order to acquire all information about one specific key you will need to iterate through the returned list of keys and send a separate request for each key. GetKey func.
It should look something like this once if you already have a resp with all keys returned from NewListPager:
for _, key := range resp.KeyProperties {
            getKeyResp, err := client.GetKey(context.Background(), *key.Name, nil)
            if err != nil {
                log.Printf("Failed to get key: %v", err)
                continue
            }
        }

Please let me know if you have any further questions!

Ok, I now understand that you don't want to return all values in the respective list function and I can totally respect that. But tbh I find it strange that I don't get this information in the SDK, e.g. in the comment of the function, but I have to go the rest api documentation page to find out the actual behavior.
Thank you @MBSolomon


Separating prefixes

Here's a script identifying prefixes based on very simple rules. A few notes:

There are many"documentation best practices" in there, probably for such a simple task it is overkill, but I wanted to give an example
Now when we have a concrete example, we can talk which parts of the repository should be written in Polish, and which in English. It feels stupid to talk about Polish grammar and words in another language

I think that here, in public and in English, we should discuss only those subject that might be important for potential contributor. Polish grammar should be discussed in Polish, as it's hermetic.


Add *.props as a recognized file extension for XML

Several MSBuild file extensions where already there including *.targets.
*.props is becoming increasingly important especially with .NET SDK projects using Directory.Build.props so frequently.

@AArnott,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

Thanks @AArnott !


Remove remove_skos_decls function from serializer pre-commit

Fixes #1010.
The function corrupted binary files like PDFs and PNGs because it was called on any file, even those skipped by the serializer. Removing this function rather than modifying the call since we are going to remove it anyway as part of #934.

Closing - updates from an earlier PR were inadvertently included here. I'll merge from develop and submit a new PR.


Enable QAT for model layers without quantized versions

What does this PR do?

Adds method_to_quantize and modules_to_skip parameters to QuantizationAwareTraining
Enables QAT for model layers without quantized versions
Fixes #8068

Before submitting

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

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

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

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

I'd appreciate any thoughts on how to more thoroughly test the new QAT parameters

All qconfig attributes get stripped from the model during the torch.quantization.convert() call in on_fit_end, so I think we'd need a second callback hook inserted just before that in order to inspect and verify the changes specified by modules_to_skip were applied as expected
Similarly, method_to_quantize only affects the quant/dequant wrapper, so it seems difficult to observe externally

Right now test_non_quantizable just takes a challenging model and proves that it can run a partially-quantized forward prop during and after training

There is a failing test. Can you take a look?

@abefetterman mind check the failing tests? :rabbit:

Closing this PR as it has become stale. We would agree to merge this if somebody wants to take over the authorship. Thank you for your time!


DataArray.swap_dims doesn't accept inplace=True, despite documentation

The DataArray.swap_dims docstring lists an inplace parameter, but it is not implemented.

Good catch -- we should remove the inplace parameter from the docs.


Roll Flutter Engine from 63fdf8a6701c to 5af525268057 (2 revisions)

https://github.com/flutter/engine/compare/63fdf8a6701c...5af525268057
2023-08-26<EMAIL_ADDRESS>Roll Skia from e67d9439a8c4 to ac39b12fd835 (1 revision) (flutter/engine#45133)
2023-08-25<EMAIL_ADDRESS>Roll Skia from 40f4e01fca40 to e67d9439a8c4 (4 revisions) (flutter/engine#45132)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jimgraham@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


unifi7: fix download url

Description of changes
The unsuffixed URL returns 404 now. Change to the URL linked to in the release page:
https://community.ui.com/releases/UniFi-Network-Application-7-5-187/408b64c5-a485-4a37-843c-31e87140be64
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Closed by #276171.


tf_upgrade_v2 fails to deal with set_session

System information

Linux Ubuntu 16.04:
TensorFlow 2.0
Python 3.6

I use tf_upgrade_v2 to convert my script from TF1.14 to 2.0. But the converted script run into an error.
Traceback (most recent call last):
  File "test_mspeech_origin.py", line 23, in <module>
    set_session(tf.compat.v1.Session(config=config))
  File "/usr/local/lib/python3.6/dist-packages/keras/backend/tensorflow_backend.py", line 400, in set_session
    '`set_session` is not available '
RuntimeError: `set_session` is not available when using TensorFlow 2.0.

Finally I changed the code manually to make it work.
sess = tf.compat.v1.Session(config)
tf.compat.v1.keras.backend.set_session(sess)

Is there anything going with set_session when use tf_upgrade_v2?

@PhanatosZou
We see that with respect to this issue there is existing discussion, please refer to this

Also please refer to this link and let us know if it helps

@Saduf2019 Seems like a possible way to make it work is to downgrade to a lower version. Would it be fixed in TF2.0 or further versions?

set_session is deprecated too with TF 2.X. So you have to use compat.v1 for using it in TF2.


[feat] Zone Analytics

Resolves #41

Are you also able to submit tests for this? Refer to https://github.com/cloudflare/cloudflare-go/blob/master/user_test.go for guidance.

@elithrar done

Just to be a huge pain: a couple more comments related to #78. Otherwise: LGTM!

@elithrar done 👍

LGTM. @jamesog @Tenzer ?

As long as we open a new issue stating that we need to add support for the extra parameters, it's good to me.

In order to avoid breaking the API more than we need to, we should
implement the optional params before merging.
No rush on that work at all however (enjoy your long weekends!)
On Sat, May 28, 2016 at 3:30 PM Jeppe Toustrup<EMAIL_ADDRESS>wrote:

As long as we open a new issue stating that we need to add support for the
extra parameters, it's good to me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cloudflare/cloudflare-go/pull/77#issuecomment-222332680,
or mute the thread
https://github.com/notifications/unsubscribe/AABIcG5cKHZabmYqV1W_nSFx8_nl5zwrks5qGMITgaJpZM4IoVfL
.

@elithrar @Tenzer Thoughts?

I think that looks great. In it goes :-)


HDDS-2467. Allow running Freon validators with limited memory

What changes were proposed in this pull request?

Freon validators read each item to be validated completely into a byte[] buffer.  This allows timing only the read (and buffer allocation), but not the subsequent digest calculation.  However, it also means that memory required for running the validators is proportional to key size.  I propose to add a command-line flag (-s / --stream) which, when specified, makes Freon calculate the digest while reading the input stream.  This changes timing results a bit, since values will include the time required for digest calculation.  On the other hand, Freon will be able to validate huge keys with limited memory.
Reduce the memory requirement of the non-stream version by allocating a buffer exactly the size of the key.  This adds a bit of overhead in time, since key info needs to be fetched, too.  But it eliminates ByteArrayOutputStream, which allocates incrementally larger and larger buffers.  The latter can lead to memory requirement twice the actual key size in the worst case (since 2^n > 2^n-1 + 2^n-2 + ...).
Get rid of code duplication between SameKeyReader and OzoneClientKeyValidator.
Allow OzoneClientKeyGenerator to create > 2GB keys.

https://issues.apache.org/jira/browse/HDDS-2467
How was this patch tested?
Created and validated keys using Freon.  Verified that even 2.5GB key can be created and validated with --stream.  Verified that streaming is forced for such a large key, since it won't fit any array.