Threat model

Currently the wording used in the documentation is some hardening and partially hardened without sacrificing usability. I think such unspecific descriptions are a bad practice. I think one thing to better the documentation and sharpen the general direction of the development would be to define a threat model.
This is especially important if the OS is to be accessible to a broader audience. One thing which for instance is clear, is that secureblue does not feature any anonymity features.
What else does secureblue not protect against, will never protect against? And protection against what is the goal?
Some of my thoughts:

The Browser, arguably the scariest endpoint in everyday use,  is addressed by including a more frequently updated Chromium version. But no further hardening is configured. (disalbing JiT, disabling WASM, WebGL etc.) One idea could be to include Firefox with a hardened user.js to greatly increase browser security.

One other possible thing which could be a part the threat model is protection against physical access. For me personally this is even the most important feature of my daily device. (maybe other than browser sec). The current features for this are inconsistent. For instance there are proper kernel parameter set but no PAM hardening is configured. And there is not any mentions how to harden grub. Another thing to consider would be the inclusion of USBGuard.

In general i think the list of features is really good and extensive. One rule of security is to allways consider the balance between protection and "ease of use". And i think the approach of secureblue does that really well. Not unlike great projects like GrapheneOS. Sorry for the long text :-). I just think having a clear threat model would help shaping the project a lot!

Great points, I'll respond to them individually:

Currently the wording used in the documentation is some hardening and partially hardened without sacrificing usability. I think such unspecific descriptions are a bad practice. I think one thing to better the documentation and sharpen the general direction of the development would be to define a threat model.
This is especially important if the OS is to be accessible to a broader audience. One thing which for instance is clear, is that secureblue does not feature any anonymity features.
What else does secureblue not protect against, will never protect against? And protection against what is the goal?

This is true and I'll work on improving the documentation there. To be clear though, the goal of this project is akin to GrapheneOS and Kicksecure. Specifically, to increase defense against the exploitation of both known and unknown vulnerabilities.

The Browser, arguably the scariest endpoint in everyday use,  is addressed by including a more frequently updated Chromium version. But no further hardening is configured. (disalbing JiT, disabling WASM, WebGL etc.)

Agreed. Additional mitigations to chromium are in-scope for this project, they just need to get done. The ideal solution would be to build, package, and copr an rpm build of Vanadium.

One idea could be to include Firefox with a hardened user.js to greatly increase browser security.

Even if user.js changes had a significant impact on security (and to my understanding they are mostly just "privacy" changes), no quantity of user.js changes brings Firefox up to par with Chromium's security features. https://madaidans-insecurities.github.io/firefox-chromium.html

One other possible thing which could be a part the threat model is protection against physical access. For me personally this is even the most important feature of my daily device. (maybe other than browser sec). The current features for this are inconsistent. For instance there are proper kernel parameter set but no PAM hardening is configured. And there is not any mentions how to harden grub. Another thing to consider would be the inclusion of USBGuard.

PAM hardening and GRUB hardening are in-scope, they just needs to be worked on. USBGuard is in-scope as well so long as it's disabled by default.
I've added the following Roadmap issues to track each of your suggestions. If you start working on one of them, please let me know and I'll assign it to you:
https://github.com/orgs/secureblue/projects/1/views/1?pane=issue&itemId=45562530
https://github.com/orgs/secureblue/projects/1/views/1?pane=issue&itemId=45562531
https://github.com/orgs/secureblue/projects/1/views/1?pane=issue&itemId=45562532
https://github.com/orgs/secureblue/projects/1/views/1?pane=issue&itemId=45562559

Please note that Madaidans Article is now pretty old. Many issues still persist, but 3 or so of the linked ones where closed 5mo ago, due to being solved.
I tried the distro and I am very thankful for your efford!
But I too have a problem with its usability.
It is not clear if these user namespaces are still a real problem. In this thread two Podman developers said that they don't see it as a security risk. Do with that what you want, these where not yet in depth answers, but just so you know.
Flatpak uses Bubblejail, which ironically Madaidan recommends. Why disable it, how are users supposed to get their apps? Flatpaks have the possibility to be very secure and easily sandboxed. Isolate from the core system, thus allowing independend and hourly updates (setting in ublue afaik). Flatpaks are great and if you want it or not, the future of the Linux Desktop. Fedora will not develop Libreoffice anymore, just as an example.
I see that this could be some kind of ChromeOS, but this is simply not what normal (especially Linux) users use their Desktop like. A Browser, even if it has webapps (another thing against Firefox), is no replacement for real Programs like

GIMP, Inkscape, Krita, ...
Libreoffice, ...
KDEnlive
Thunderbird Mail
...

Using Chromium or Electron for everything puts intense trust in Google and I understand that many people dont like this. Also, Chrome will disable Adblocking soon, what then? I was never hacked through Firefox and I don't really value these dangers high.
In my eyes and the ones of other people, its better just to use noscript, have a hardened Firefox (which decreases the attack surface), official Fedora Build with full SELinux Profile and ublue codecs and all. It works, you can load DRM on demand, which is also a security point in my opinion, you can use Noscript and UBlock forver, and it really is secure enough.
RPM Firefox from Fedora is also the fastest, apart from the single binary from Mozilla, I benchmarked them all basically. It is also said to be more secure than the Flatpak, so keeping it preinstalled... should be an option.
I see how this softens the security already, but this is not Android/GrapheneOS (where I run Mull too, as Vanadium sucks for UX). You cannot simply install any app you want.

So my ideas:

keep firefox
keep flatpak
keep flatpak autoupdates
maybe preinstall the flathub-verified subset by default, this is "the most secure" probably. Some projects are perfectly fine though and not in there, like VLC, which just repackages the binaries

Some other nice tools or settings to try out would be bubblejail and SELinux Confined Users.
For bubblejail maybe contact @rusty-snake, they seem to know the project and made an RPM spec file that builds fine locally but not on COPR for some reason. This is my experimental COPR using their spec files

Thanks for your comments. I'll respond to them individually:

Please note that Madaidans Article is now pretty old. Many issues still persist, but 3 or so of the linked ones where closed 5mo ago, due to being solved.

Regardless, that article is not the only reference point here. See also the grapheneos article https://grapheneos.org/usage#web-browsing
This project will not switch to firefox unless/until GrapheneOS does.

I tried the distro and I am very thankful for your efford!

Thanks, though do note that technically this isn't a distro. The distro is still Fedora :)

But I too have a problem with its usability.
It is not clear if these user namespaces are still a real problem. In this thread two Podman developers said that they don't see it as a security risk. Do with that what you want, these where not yet in depth answers, but just so you know.

Aside from the fact that Podman devs aren't the ultimate source of truth here, that isn't an accurate summary of what they said. They acknowledged a limited source of risk.
The real solution here is to use bubblewrap-suid and then re-enable flatpak. But that will require it to be built, packaged, and copr'd.

Flatpak uses Bubblejail, which ironically Madaidan recommends.

That's not correct, flatpak uses bubblewrap. Bubblejail is an experience on top of bubblewrap.

Why disable it, how are users supposed to get their apps?

Because out of the box it depends on unprivileged usernamespaces, it can be reenabled in this project once we have a copr for bubblewrap-suid. It should be straightforward. If you want to work on it let me know and I can assign the Roadmap item to you.

I see that this could be some kind of ChromeOS,

The goals of this project are not like ChromeOS.

GIMP, Inkscape, Krita, ...

GIMP is already included in this project. If you want to add other default apps, please submit a pull request.

Using Chromium or Electron for everything puts intense trust in Google

No, it doesn't. They are both open-source projects. And all that is aside from the fact that anything "degoogle" related is out of scope for this project.

Chrome will disable Adblocking soon, what then?

This is not accurate. MV2 support is going away, and that's a good thing. MV3's permissions model is significantly stronger and does not prevent adblocking. Ublock origin lite works well, and built-in adblockers like in brave work well also.

But I see a privacy vs. Security issue here. One could say Thunderbird is less secure than some random webmail through Chromium. Or maybe some Electron app. But I suppose Thunderbird is local, very private and allows addons like Ublock.

Again, anything "privacy" related is not in-scope for this project. This project is about security, not privacy.

In my eyes and the ones of other people, its better just to use noscript

Noscript has a massive usability impact and has more to do with "privacy" than security.

have a hardened Firefox (which decreases the attack surface)

There isn't any amount of user.js tweaking that brings firefox up to par with chromium security.

this is not Android/GrapheneOS

The stated goal above of this project is similar to GrapheneOS, so this is not accurate.

So my ideas:

keep firefox

This project will not switch to firefox unless/until GrapheneOS does.

keep flatpak

This will not be done unless/until we have a bubblewrap-suid copr available. If you are working on that please let me know and I'll assign you the ticket.

keep discover, remove the rpm-ostree backend as these go automatic and slow it down a lot

Not in scope or desirable.

if nix could work, this could be an alternative. But this involves having it in /var/nix and linking it to /nix or something similar, which may be out of scope

The nix installer is already available in the justfiles. Type "just" in the terminal

Some other nice tools or settings to try out would be bubblejail and SELinux Confined Users, but this is a Desktop Task, I think GNOME works already? Plasma just seems to do weird things.

Bubblejail is a usability nightmare. Again, the solution here is to re-enable flatpak after including bubblewrap-suid via a copr:
https://github.com/orgs/secureblue/projects/1?pane=issue&itemId=45665263

Okay so I see your points
Discover would be used as a GUI store for installing Flatpaks, managing them, and also managing KDE plugins and firmware updates!
I will look at the rest. Thanks for your answers

bubblewrap-suid is nothing more than but bubblewrap + chown root:root (better safe than sorry) + chmod u+s.
Just pick https://src.fedoraproject.org/rpms/bubblewrap/blob/rawhide/f/bubblewrap.spec, add chown+chmod and change the name, description, ....

Hey! Thanks everyone for contributing in this discussion. :smile:
@trytomakeyouprivate

It is not clear if these user namespaces are still a real problem. https://github.com/containers/podman/issues/20720 two Podman developers said that they don't see it as a security risk. Do with that what you want, these where not yet in depth answers, but just so you know.

https://www.cve.org/CVERecord?id=CVE-2022-0185

I see that this could be some kind of ChromeOS, but this is simply not what normal (especially Linux) users use their Desktop like.

keep discover, remove the rpm-ostree backend as these go automatic and slow it down a lot

Based on a immutable system (OSTree) does not mean you cannot install programs. Even if Flatpak will be disabled in this project, users can still install packages from dnf repositories as well as copr repositories va rpm-ostree. Apart from rpm-ostree being fundamental for this project to even work, keeping your system immutable decreases attack surface greatly an even opens up future possibilities like attestation / intrusion detection akin to Graphene OS

keep flatpaks

I agree that for secureblue to be usable by a broader userbase some graphical installer needs to be present. Also, an immutable system and all installed apps running in their own sandbox is the best approach and OSTree along flatpak is the closest match on desktop Linux as of now. But i agree with @qoijjj  that bubblewrap-suid is probably the only approach since i also disagree with enabling unprivileged user namespaces.
As for the browser issue:
@qoijjj
I agree with sticking to chromium going further. But porting Vanadium seems like a task of immense complexity since the Vanadium patches done to Chromium like for instance disabling JIT V8 are Android Specific. But i do not know of any better solution. Maybe the easiest would be to just include Brave.
Also i think i would be interested in looking into creating the bubblewrap-suid  copr repository, but i do not have any experience working with rpm.

also: maybe move this to discussions?

@34N0 The idea is this: Discover is the GUI appstore. In theory you could use flathub.org, and install via terminal, but a GUI store seems better. Also as I said it handles plasma extensions and firmware updates, so it is important.
I wanted to find out a way to automate firmware updates since a while, because:

they are damn important
not included in automatic updates
they always require a reboot (KDE 6 may be able to let apps block this until their work is closed, but until then this would mean random data loss)

So a system like on GrapheneOS for the updates would be needed:

detection for metered connection (by default every connection is set to unmetered, so phone hotspot would be used!)
detection of AC state
detection of battery state at e.g. 50%
This could be done via a udev rule afaik, this enables a systemd target which is a dependency for automatic firmware updates to run.

If this is not working, a GUI appstore is needed.
I agree that an immutable system without layering might have advantages, even though I would not want to use it currently. But removing the extra packages "plasma-discover-rpm-ostree" and "gnome-software-rpm-ostree" would remove this ability from the GUI stores, remove annoying delays and allow users to only install flatpaks.
You could add the verified flathub repo:
flatpak remote-add --user --subset=verified flathub-verified https://flathub.org/repo/flathub.flatpakrepo

but this also lacks many apps currently, for example VLC, Brave, Element, QGis, Signal Desktop, Briar, Fluffychat, Pidgin, Inkscape, Calibre, Zotero, ...

Okay so I see your points
Discover would be used as a GUI store for installing Flatpaks, managing them, and also managing KDE plugins and firmware updates!

Yes, discover can be added back after flatpaks are

Do you think Vanadium patches can be directly applied to Chromium? This would indeed be very interesting.

Not all of them but some

also: maybe move this to discussions?

Instead, let's move each sub-conversation into the following tickets so we can split up and organize the conversations
bubblewrap-suid: https://github.com/secureblue/secureblue/issues/11
bubblejail: https://github.com/secureblue/secureblue/issues/22
chromium/vanadium: https://github.com/secureblue/secureblue/issues/14
usbguard: https://github.com/secureblue/secureblue/issues/15
grub hardening: https://github.com/secureblue/secureblue/issues/16
pam hardening: https://github.com/secureblue/secureblue/issues/17
I'll respond regarding each topic separately above and tag who I'm responding to. If there's any topic that's missing an issue, please open a new one.
Also, if you're working on any of these items, please tag me in the issue so there isn't duplicate work.

@trytomakeyouprivate additionally, I've responded to you here: https://github.com/secureblue/secureblue/issues/26


correct copyright year of file pkg/ddc/alluxio/worker.go

Ⅰ. Describe what this PR does
This PR is to correct the CopyRight year of file pkg/ddc/alluxio/worker.go. It should be 2020 instead of 2022.
Ⅱ. Does this pull request fix one issue?

NONE
Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
NONE
Ⅳ. Describe how to verify it
Use command git log --diff-filter=A --pretty=format:"%ai" -- pkg/ddc/alluxio/worker.go to check the correct time.
Ⅴ. Special notes for reviews
NONE

/lgtm


Would like to be able to disable gravatar

Would ideally be part of a bigger issue to customize the header, but in the meantime can have an option to disable the gravatar?

Just saw the note for no feature requests, will post on the mailing list.


Figure out how to deal with all the garbage that gets created (basically just memory golfing)

From testing it on a relatively-large (>30 recommended shards) bot, it seems that we're quite wasteful with RAM to an extent - wasting ~300MB of RAM that gets GC'd quite often

I'm guessing most of that data comes from the buffers we allocate to decompress websocket payloads. We could probably keep a pool of them (IIRC vertx buffers use unpooled ByteBufs by default), but I'm not sure how effective this would be (aka needs testing).

Closing this since #113 was merged


Created README for Windows

Added README for installation of EVA on Windows Machines

We have merged these changes through another PR.
Windows Readme doesn't seem relevant


Typo in README.md

How to Start the Practice Excercise - "excercise" should be spelled "exercise" :)

Good catch! Noted.


Descending sort only works with first field

This doesn't work:
sort: [
  "field1", {"field2": "desc"}
]

This does:
sort: [
  {"field1":"desc"}, {"field2": "desc"}
]

My field1 is
selector: {
  field1: { $eq: "literal" }
}

so I'm not sure whether it actually sorts by both.
I would omit field1 from the selector but then it doesn't work at all (error), saw an issue on that here already.

I’m not actually sure if Mango supports mixed ascending/descending, but we should check pouchdb-find’s output compared to CouchDB 2 to confirm. This could definitely be a bug.

On Nov 4, 2016, at 8:55 AM, Martynas<EMAIL_ADDRESS>wrote:
This doesn't work:
sort: [
"field1", {"field2": "desc"}
]
This does:
sort: [
{"field1":"desc"}, {"field2": "desc"}
]
My field1 is
selector: {
field1: { $eq: "literal" }
}
so I'm not sure whether it actually sorts by both.
I would omit field1 from the selector but then it doesn't work at all (error), saw an issue on that here already.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/nolanlawson/pouchdb-find/issues/225, or mute the thread https://github.com/notifications/unsubscribe-auth/AARUwosnNollG92BQLX3aFZoNUSDEOqUks5q61VegaJpZM4Kpsnk.

This issue was moved to pouchdb/pouchdb#6258


Add conversions between Color3 and Color3uint8

BasePart.Color was being incorrectly serialized as a Color3 instead of a Color3uint8 in the XML format, as per rojo-rbx/rojo#443. This PR adds conversions between these two types mainly to address this issue, but also because they will likely be useful in the future.

(Workflow issue is known; I'll be updating our clippy version to fix this)


fixed the QS bucket links

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

See that the S3 bucket name was changed.  Will update again and resubmit

Didn’t see that .  Just updated the PR.
On Thu, Aug 25, 2022 at 8:19 AM annaone @.***> wrote:

@.**** commented on this pull request.
Hi Josh - isn't the prefix supposed to be
"quickstart-cisco-meraki-vmx-cloudwan" per the updates Shivansh made to the
S3 bucket (
https://s3.console.aws.amazon.com/s3/buckets/aws-quickstart?region=us-east-1&prefix=quickstart-cisco-meraki-vmx-cloudwan/&showversions=false
)?
—
Reply to this email directly, view it on GitHub
https://github.com/aws-quickstart/quickstart-cisco-meraki-vmx-cloudwan/pull/18#pullrequestreview-1085433842,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARW2ZFUAQUD46RW4R5CXXDV25XGXANCNFSM57QLXXKA
.
You are receiving this because you authored the thread.Message ID:
<aws-quickstart/quickstart-cisco-meraki-vmx-cloudwan/pull/18/review/1085433842
@github.com>


Persisted machine migration across XState versions

Please treat the serialized format as a part of your public API.
This is more of a plea/headsup/feature request.
I just got bitten by an XState machine format change from back in August.

I'm persisting XState 4.6.x machines in PouchDB.
This change, introduced in XState 4.7.0, adds an _event property to the state object: "Use SCXML.Event wherever possible"

This caused two issues upon trying to update XState:

Unfortunately for me, PouchDB forbids the storing of objects under a key a leading underscore, i.e. _event is an invalid top-level key, so new machines created with the latest version of XState simply wouldn't persist to the db. I don't expect XState to change format because of a restriction like this in PouchDB, however I do feel like this should not have happened without a major version bump.
Secondly, the new version of XState would crash with Cannot read property 'data' of undefined when trying to deserialize state saved from the old version, because this new _event property is missing: https://github.com/davidkpiano/xstate/blob/7ce4e93cda2a8cad00842725a12e9e7b731f2c24/packages/core/src/State.ts#L232

Request
Ideally:

Breaking changes to the serialized format should be done across a major semver version bumps.
XState should give some consideration & explicit testing to identify issues with backwards/forwards compatibility of the serialized format.
XState could support running something akin to db "migrations" when the serialized format changes.

I think this would be appropriate, given that serialization (and deserialization?) is stated as one of the key goals:

My hacky workaround is to wrap all reads and writes to the db with custom serialize/deserialize to rename the keys and add the _event property by calling toSCXMLEvent on the event property. This is inconvenient and a bit haphazard because I need to wrap every location that reads from the db, but it seems to work. Included my workaround code below in case someone else experiences this issue.
import mapKeys from 'lodash/mapKeys'
import { toSCXMLEvent } from 'xstate/lib/utils'

export function serialize (state) {
  const s = JSON.parse(JSON.stringify(state)) // ensures no magic objects
  return mapKeys(s, (value, key) => { // swap keys with leading _ to leading $
    if (key[0] === '_') {
      return `$${key.slice(1)}`
    }
    return key
  })
}

export function deserialize (s) {
  const r = mapKeys(s, (value, key) => {
    if (key[0] === '$') { // swap keys with leading $ to leading _ (reverse of serialise)
      return `_${key.slice(1)}`
    }
    return key
  })
  // add missing _event if not there
  if (r.event && !r._event) {
    r._event = toSCXMLEvent(r.event)
  }
  return r
}

Sorry that we have overlooked this, definitely something that we should have on our minds when releasing new minor/patch versions. @davidkpiano we could prepare different test machines that we could try to serialize from now on with each version and provide those serialized values as test inputs for rehydration, WDYT? @timoxley you seem to be interested in the stability in this regard, would you be interested in helping us out with it?

I don't expect XState to change format because of a restriction like this in PouchDB, however I do feel like this should not have happened without a major version bump.

I'm not sure if the part about major version bump for smth like that is true - this is really hard to predict, there are too many existing systems that you could integrate XState with like this and it's impractical to expect from us not to add any new properties. I believe though that we should be able to rehydrate using data that is missing newly added properties and we've not thought about this when developing the latest version.

I think this would be appropriate, given that serialization (and deserialization?) is stated as one of the key goals

It only mentions serialization/deserialization of machine definitions, not states. It's an important trait of XState though and we probably should add it to this list as an additional goal (or extend the one you have mentioned).

My hacky workaround is to wrap all reads and writes to the db with custom serialize/deserialize to rename the keys

I wouldn't call this a hacky workaround. It seems like a proper solution for the problem - given the fact that your db has such constraints to which you have to adjust this data.

I will be adding JSON Schema soon for the:

machine definition
state object
event object

The JSON-serialized machine, state, and event will be tested against this schema moving forward.

I'm quite interested in first class support for state serialization/deserialization.
In my system, I find it interesting to be able to persist (also in CouchDB, as it happens) the state of some data types. Being able to reconstruct a typed state object and further on a service/machine is very appealing.
I'm still hesitating between a simple union type, disconnected from whatever I do with XState, but if I could simply persist the serialized version of the state, it would be quite cool :)

We are using XState on the backend (including history functionality) and are offloading state to a DB. When upgrading, introduction of _event property broke our build.
Is this the recommended way for handling offloading / rehydration? Or is there some other more "future proof" way?

@alizbazar Not sure how the addition of properties to a JSON object could break the build - how exactly are you storing it in the database? For example, in Postgres, if you have a column of type json / jsonb, you can just store the JSON state as-is without problems.

Not sure how the addition of properties to a JSON object could break the build

@davidkpiano please see the issue description

Ah never mind - sorry, forgot the original issue. However, IMO it's best to avoid blindly storing JSON objects as the top-level objects, because there is no guarantee that the object won't have top-level underscored properties. Storing it as:
{ state: jsonStateToPersist }
would solve it.

The bigger problem is the incompatibility between serialised formats causing a crash on deserialisation.

@davidkpiano  is your idea that jsonStateToPersist was acquired via JSON.stringify(state)?
Previously, we only stored state.value and state.context, but then for supporting history we also started storing state.history.value and state.history.context and state.historyValue.
If we were to store JSON.stringify(state) and then used that for rehydration, would this be backwards compatible for the future?
Just FYI here's our simplified code for serialization / deserialization:

If we were to store JSON.stringify(state) and then used that for rehydration, would this be backwards compatible for the future?

Yes, although you can store state.toJSON() as well.

If we were to store JSON.stringify(state) and then used that for rehydration, would this be backwards compatible for the future?

Yes, although you can store state.toJSON() as well.

I store as state.toJSON() or JSON.stringify(state) but it throw an error:
UnhandledPromiseRejectionWarning: TypeError: Converting circular structure to JSON
@davidkpiano

@minhnguyenjirnexu Please share a code example, it's impossible to know what your problem is just by posting the error.

Thanks @davidkpiano, Just resolve it with this solution Solution URL. And now it worked.

Exporting to SCXML as the Standard spec should work too, right? I just found out about XState, but haven't found the docs on how to import/export from the SCXML standard yet.

Closing as the original problem no longer exists in XState v5. Please make a new issue for any related issues. 🧹


distro/rhel8: enable autoregistration for all Azure images

COMPOSER-1866 reported that Azure SAP images should also have rhsm autoregistration enabled. Since all Azure images except for the SAP one already have autoreg enabled, we can just move the config into the default image config that's inherited by all azure-related image config.
Signed-off-by: Ondřej Budai<EMAIL_ADDRESS>This pull request includes:

[ ] adequate testing for the new functionality or fixed issue
[ ] adequate documentation informing people about the change such as

[ ] submit a PR for the guides repository if this PR changed any behavior described there: https://www.osbuild.org/guides/

@ondrejbudai I'm not really sure it is correct to make the change for 8.7+ images. I think that we should check with the Entitlements team, since they requested that redhat-cloud-client-configuration is installed on EC2 images, instead of directly configuring RHSM (see https://github.com/osbuild/osbuild-composer/pull/3081). I expect that it may be desirable to use the same approach also for Azure images...

Let's then wait with this PR until we have guidance from the RHSM team. ;) Thanks, Tomáš, for keeping an eye on this!

Implemented in #3233


Add numerical_grad_dtype to FunctionTestCase and LinkTestCase

This is needed in #7804, to avoid default float64 casting in cuDNN-backed F.n_step_rnn which only supports float32.

Jenkins, test this please.

Jenkins CI test (for commit d1e4f719294c2cb7a60231ab5bcdf2257f83d6f4, target branch master) failed with status FAILURE.

Jenkins, test this please.

Jenkins CI test (for commit d1e4f719294c2cb7a60231ab5bcdf2257f83d6f4, target branch master) failed with status FAILURE.

Jenkins, test this please.

Jenkins CI test (for commit d1e4f719294c2cb7a60231ab5bcdf2257f83d6f4, target branch master) failed with status FAILURE.

Jenkins, test this please

Jenkins CI test (for commit d1e4f719294c2cb7a60231ab5bcdf2257f83d6f4, target branch master) failed with status FAILURE.

jenkins, test this please

Jenkins CI test (for commit d1e4f719294c2cb7a60231ab5bcdf2257f83d6f4, target branch master) failed with status FAILURE.

Cant test ChainerX properly

Jenkins, test this please

Jenkins CI test (for commit d1e4f719294c2cb7a60231ab5bcdf2257f83d6f4, target branch master) failed with status FAILURE.

From Jenkins
E       TypeError: Parameterized test failed.
E
E       Base test method: TestClip.test_double_backward_cpu
E       Test parameters:
E         dtype: <class 'numpy.float32'>
E         shape: ()
E         x_min_max: (-1, None)
E
E
E       (caused by)
E       TypeError: Function `<property object at 0x7fb32a5004a8>` (Clip) has a bug.
E
E       Please report this error to the issue tracker with the stack trace,
E       the information of your environment, and your script:
E       https://github.com/chainer/chainer/issues/new.
E       Dtype of data and grad mismatch
E       grad: float64 != data: float32

@emcastillo
F.clip and F.clipped_relu are being handled in #7843 and #7842 respectively.

Ok! thanks :)


nerdfonts: fix build on MacOS

Motivation for this change
Nerdfonts does not build on MacOS due to incomplete patch script.
Things done

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

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

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

@GrahamcOfBorg build nerdfonts

This is superseded by https://github.com/NixOS/nixpkgs/pull/84858 and can be closed if https://github.com/NixOS/nixpkgs/pull/84858 is merged.

https://github.com/NixOS/nixpkgs/pull/84858 is now merged so this is no longer needed.


[Feature] ItemCreator

ToDo ItemCreator

[ ] Create a new tab that will function as an item creator screen in the purchase screen.
[ ] Have an extra button to add to the creation screen a basket of items (gear etc, the items that want to be merged to a new item)
[ ] Identify main items and modification items.
[ ] When selecting a main item showing a modification area related to the item type (weapon, armor, etc) show item specific item creator
[ ] Have ability to select attributes or values that should be modified in the new item
[ ] Track modification points
[ ] Provide option if modification points are allowed to be overspent
[ ] Option for created items not to be made world items, create new item in the world if option is picked.
[ ] As GM default to creating world items if no actor is selected independently of the option

Linked to
#41

Here an example ui


Explain how dates are determined

Closes #47
I also needed to know how this plugin determined dates and had to dig a bit more. I feel like this should be in the README.
Relevant source:
https://github.com/gjtorikian/jekyll-last-modified-at/blob/master/lib/jekyll-last-modified-at/determinator.rb#L27

LGTM ! :)

Thanks!


Adding me followers endpoint

Adding a method to get the authenticated user's followers.

One test is failing because of failed authorising (access token). This was already the case for me locally before making changes.

Thanks, I've to get into that authorization issue. Probably something with the access token and stuff like that.


How to check if a key is a file or a folder in filer api?

请问，使用filer api，如何判断一个 key 是文件还是目录?

what is "a key"?

eg: http://host/path/to/something. How to check if /path/to/something is a file or a foler?

Suppose by filer API you mean filer http API. Maybe send a HEAD request to http://host/path/to/something/. If the status code is 404, it is not a folder.

added a fix so that you can check http://host/path/to/something/ http status code. If it is 404, it is not a folder.

that's pretty good. thank you very much.


Posting gzip text file to improve performance

Hi David
First off thanks for the amazing software. I am using this to extract tokens from 2 Million plus text files  of 200K average size. I was looking at compressing the files to improve bandwidth usage. I followed Gzip Filter for jetty configuration  with no success.  I went as far as getting the following error.   TaggerRequestHandler requires text to be POSTed to it. I was wondering if zip files could be decompressed within this handler. Unfortunately I am not a proficient java programmer to attempt such changes.

There's some info here: http://signaldump.org/solr/qpod/33137/applying-gzip-compression-in-solr-5-1

Thanks for the quick response. I actually looked at this information but was wary about the No .war changes in version Solr 5.3 and later and I am using Solr 5.4.1
UPDATE
If I apply the configurations suggested in  GzipFilter configuration    and set my http headers to {'content-type':'text/plain','transfer-encoding': 'gzip','accept-encoding':'gzip,deflate'}   I don't get the error    TaggerRequestHandler requires text to be POSTed to it.  but no tags are return if I my post data is gzip compressed.


rateLimit return by GitHub Enterprise meant to be 'null'

We use GitHub Enterprise and heard that it doesn't have the rate limit. Is this why I always got 'null' returned and causes collector mission abort?
2018-07-24 18:38:06,587 INFO  c.c.d.collector.GitHubCollectorTask - Rate limit is null
2018-07-24 18:38:14,171 ERROR c.c.d.collector.GitHubCollectorTask - GraphQL API rate limit reached. Stopping processing
2018-07-24 18:38:20,643 INFO  c.c.d.collector.CollectorTask - Repo Count              0     1400s
2018-07-24 18:38:22,763 INFO  c.c.d.collector.CollectorTask - New Commits             0     1402s
2018-07-24 18:38:23,282 INFO  c.c.d.collector.CollectorTask - New Pulls               0     1403s
2018-07-24 18:38:23,573 INFO  c.c.d.collector.CollectorTask - New Issues              0     1403s
2018-07-24 18:38:23,767 INFO  c.c.d.collector.CollectorTask - Finished                      1403s

And if I mark these lines off in GitHubCollectorTask.java, the collector works as expected!
if (!isUnderRateLimit(repo)) {
    LOG.error("GraphQL API rate limit reached. Stopping processing");
    continue;
}

version: 2.0.5-SNAPSHOT

The same observation from other github java lib:
https://github-api.kohsuke.org/apidocs/org/kohsuke/github/GitHub.html#lastRateLimit--

null if either there is no rate limit (for example GitHub Enterprise) or if no requests have been made.

@bryan0817 Do you still have this issue?

yes, the problem is still there.

@rvema The problem is still the same, I always get null returned from this line gitHubClient.getRateLimit(repo);. Probably my company has special deal with GitHub?

@bryan0817 the proper fix might be to add a flag in the properties file that is used to skip this logic if the rate limit isn't enabled for a users instance of Github. Is that something you can contribute?


Support onboard sensors over I2C, SPI buses and Multi Socketcan interface over Rddrone fmuk66

Added Support for following sensors and multiple socketcan interfaces for rddrone_fmuk66 board-

I2C based sensors - bme280 and bmm150
SPI based sensors - fxas21002, fxos8700
Code to support 2 Parallel SOCKETCAN interfaces.
Ensured enabling 3.3V supply for sensors earlier than Sensor Init
Add support for servo motors (PWM outputs)

Does this fix Issue https://github.com/zephyrproject-rtos/zephyr/issues/45218

@mmahadevan108 .. Yes it does resolve #45218

You need to take a look at your Git commit logs and adjust them to match the style used in the rest of the in-tree commits.
You need a linear history, no merge commits.
Please split this PR in multiple PRs, each dealing with a subset. The proposed changes to the network headers and SocketCAN support will not be accepted as-is.

Thanks for the help, we will get this cleaned up.


DisplayStyle API cleanup/promotion

A DisplayStyleSettings has subcategory appearance overrides, planar clip mask settings, and model appearance overrides, all implemented similarly with somewhat tricky copy-pasted code to keep in sync with JSON representation.
Implement all in terms of a Map that automatically synchronizes the JSON representation.
Document and promote all to public.
Also clean up and promote APIs for planar clip masks, context reality models, and spatial classification.
See changes to NextVersion.md for a summary.
TODO: No tests exist for any of the existing APIs. Add some. Added.
TODO: The Map API suffices (set, delete, get, has) but half a dozen helper methods also exist; deprecate them? Not now.
TODO: ContextRealityModel-related APIs need work. Done.

/azp run


Make ttl file available within the documentation

@vijoc, the structure of the repo has changed since I worked on it. That why https://alikucukavci.github.io/FSO/ontology.ttl is not working.
We need to discuss what happened before I do changes to the structure.

Yeah I'm on it.


implemented the device contact sensor and basic test.

The contact sensor implements a non-generic IBandContactSensor rather than the generic IBandSensor<T> like every other sensor.

@peted70 I've resolved the conflicts

@peted70 I've resolved the conflicts

Hi @rrreynolds,
Firstly, thanks for the contributions much appreciated.
One suggestion I'd like to make about the contact sensor is that ideally the fake sensors should implement and respect the correct update intervals (I didn't have time to implement that yet). It looks like you created a FakeContactSensor class to deal with the differing update frequency? Unless I am misunderstanding the intent it might be better to stick with the FakeBandSensor base class. and have it update with a frequency that makes sense for that sensor (happy to try an implementation of this if my explanation is not clear). Let me know if I missed anything there?
Cheers,
Pete D

Hi @rrreynolds,
Firstly, thanks for the contributions much appreciated.
One suggestion I'd like to make about the contact sensor is that ideally the fake sensors should implement and respect the correct update intervals (I didn't have time to implement that yet). It looks like you created a FakeContactSensor class to deal with the differing update frequency? Unless I am misunderstanding the intent it might be better to stick with the FakeBandSensor base class. and have it update with a frequency that makes sense for that sensor (happy to try an implementation of this if my explanation is not clear). Let me know if I missed anything there?
Cheers,
Pete D

Having dug a bit deeper I understand why you made that change.

Having dug a bit deeper I understand why you made that change.

Glad to hear that Pete. Sorry it wasn't clear initially. I'll try to provide a better description when making changes like that.

Glad to hear that Pete. Sorry it wasn't clear initially. I'll try to provide a better description when making changes like that.

Would you mind taking a quick look at this alternative implementation here https://github.com/BandOnTheRun/fake-band/pull/10 and let me know if it covers everything? (I noticed some mistakes in my code and a way to avoid some code duplication in your pull request). No worries if you can't check it - just didn't want to make changes to your code without getting your blessing.
Here's what I did:
Changed FakeDeviceContactSensor to inherit IBandContactSensor and FakeBandSensor (this avoids some code repetition).
Fixed Timeout logic in the unit tests.
Fixed FakeBandClient_TestValueReceived_ConnectContactAndReceiveOneValue unit test (this was broken). (Also set the reporting interval of the sensors in the tests to 500ms to avoid waiting for 30s - might need more control over this moving forwards when the sensor supported intervals are implemented).
Cheers,
Pete D

Would you mind taking a quick look at this alternative implementation here https://github.com/BandOnTheRun/fake-band/pull/10 and let me know if it covers everything? (I noticed some mistakes in my code and a way to avoid some code duplication in your pull request). No worries if you can't check it - just didn't want to make changes to your code without getting your blessing.
Here's what I did:
Changed FakeDeviceContactSensor to inherit IBandContactSensor and FakeBandSensor (this avoids some code repetition).
Fixed Timeout logic in the unit tests.
Fixed FakeBandClient_TestValueReceived_ConnectContactAndReceiveOneValue unit test (this was broken). (Also set the reporting interval of the sensors in the tests to 500ms to avoid waiting for 30s - might need more control over this moving forwards when the sensor supported intervals are implemented).
Cheers,
Pete D

#10 looks good to me. Thanks.

#10 looks good to me. Thanks.


Trust: Folder name should have validation

Testing #122252

Edit a folder name in the trust editor
Clear the input box
Press Enter

🐛 Folder gets deleted and there's no turning back 🙈
We should just have some validation like the Explorer:

duplicate #122412


Where can i get and customize the theme of the rest of the account pages

I downloaded the Keycloakify starter project (version 9.1.4 and updated its dependencies). The project came with account and login folder which has the code and implementations for account and login pages to customize and it works fine.
Now i wish to customize the rest of the pages on the account page. Pages like the session,  authenticator, applications, device activity and more. I can`t seem to find these pages on the keycloakify project or how to build or implement these page on the docs.

I can create a new page using react on the project but i need the implementation that works with the above mentioned pages.
Please if i can get a quick response to this i will really  appreciate. thanks.

Hello @johnifemezuo,
Don't worry, you can implement the missing pages. Just follow the instruction here: https://docs.keycloakify.dev/limitations
Hopes it helps,

Thanks for the quick reply @garronej i will check it out and reply back on my progress.

@garronej after reading the docs. it recommended this code to run npx -p keycloakify download-builtin-keycloak-theme to install all the other implemented page i need but  they are in  ftl. any recommendation on how to convert these ftl pages to react.

Hello @johnifemezuo,
I encourage you to read the doc carefully again.
The commend you are referring to is for copy pasting pages that have already be converted to React in your project.
You are not in this cases. The pages you need aren't implemented yet.
Read carfully, you'll find all the information you need to implement them. It's not hard. Just a bit boring

Hey @garronej , thanks for your work on this so far! The dev setup is really nice to use.
However, I am struggeling with the same issue as the OP (disclaimer: not too familiar with react unfortunately).
You mentioned the instructions on the Limitations page in the docs and I've seen the section about self-implementation. It's still unclear to me how to move forward at this point.
As far as I understand, we need to basically convert existing .ftl files, for example the totp.ftl to a proper react component, along the lines of the provided example page MyExtraPage1.tsx. In case of the Authenticator page (totp.tpl), I am unclear about how to access the data required for the page. Could you maybe roughly outline how this is supposed to work?
Or... is there a simpler way of using a fallback or something, if the exact styling doesn't matter too much?
Better yet, are these pages going to be implemented any time soon?

Hey @brueckner,
You've grasped the key ideas!
The data are automatically available on the windows.kcContext.
You just need to extends the typings if you want type safety.
In the doc I give a PR as an example that adds support for a page. You can use this as a reference to help you move forward with this.
You can also try GPT4 for converting ftl into react if you provide enough context.


Wrong /etc/fstab order due to toposort in fileSystems

Describe the bug
mergerfs is a unionfs that merged different filesystem together (logically). It depends on the actual underlying filesystems and needs to be mounted after the actual underlying filesystems.
On NixOS, I adds mergerfs to my fstab using fileSystems option.
However, in /etc/fstab, the mergerfs always appear before the actual filesystem.
Steps To Reproduce
This is my fileSystems configuration:
fileSystems."/srv" =
  { label = "01";
    device = "/dev/disk/by-uuid/279044c5-dfe2-448e-98eb-4a7e91403640";
    fsType = "ext4";
  };

fileSystems."/srw" =
  { label = "00";
    device = "/dev/disk/by-uuid/5227801a-1d5d-4bde-bd20-1e53d3be3f14";
    fsType = "ext4";
  };

fileSystems."/mnt/waka" =
  { label="9";
    device = "/svr:/svw";
    fsType = "fuse.mergerfs";
    options = [
      "allow_other,use_ino,cache.files=partial,dropcacheonclose=true,category.create=mfs"
    ];
  };

I rebuild it and the fstab becomes:
 /svr:/svw /mnt/waka fuse.mergerfs allow_other,use_ino,cache.files=partial,dropcacheonclose=true,category.create=mfs 0 2
 /dev/disk/by-uuid/279044c5-dfe2-448e-98eb-4a7e91403640 /srv ext4 defaults 0 2
 /dev/disk/by-uuid/5227801a-1d5d-4bde-bd20-1e53d3be3f14 /srw ext4 defaults 0 2

This is problematic because as I said, mergerfs depends on the actual underlying filesystems and needs to be mounted after the actual underlying filesystems.
I dig into NixOS source code and find this when NixOS builds the /etc/tab:
https://github.com/NixOS/nixpkgs/blob/2ab832c051636f24f4aa09d466d3db7979bdf2b2/nixos/modules/tasks/filesystems.nix#L14
and the fsBefore did this:
https://github.com/NixOS/nixpkgs/blob/4e97bedf93d8bd35e12a5b99f66aaa811e74eb83/nixos/lib/utils.nix#L17-L40
So I figured the special device option of mergerfs that tricked this fsBefore, which means there is no way I can get the mergerfs entry to appear after the actual filesystem in /etc/fstab.
There also seems to be a depends option but somehow I cannot really use it. (Sorry, I'm still new to the nix language and how NixOS works).
Expected behavior
A hack or a general solution to make the mergerfs appear after the actual filesystems in /etc/fstab.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Notify maintainers

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.10.76, NixOS, 21.05.3980.f0869b1a2c0 (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4pre20211006_53e4794`
 - channels(root): `"nixos-21.05.3980.f0869b1a2c0, nixos-unstable-21.11pre326640.e544ee88fa4"`
 - channels(yqmmm): `"home-manager-21.05, nixos-unstable-21.11pre306621.439b1605227"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

I think exposing the fileSystems.<name>.depends would make it work for me. (Haven't figured out why depends is not exposed in options yet)

Wait, so the root cause is actually that config.fileSystems, a set in the nix expression language, is sorted by key, so "/mnt/merged" is before "/svr" and "/svw".
So the terrible hack is to rename them in a lexicographic order that I want...

Ok. So fileSystems.<name>.depends is on unstable.
I'm gonna close this issue. Leaned a lot though


Browserify bundle failing when requiring signalPayloadProvider and actionMutationsProvider

The errors I specifically get when trying to bundle my application is this:
Error : undefined
Cannot find module 'cerebral/providers/signalPayloadProvider' from '/Users/aprice/Projects/stem-py/node_modules/cerebral-module-devtools/node_modules/cerebral-module-signal-store'
Error : undefined
Cannot find module 'cerebral/providers/actionMutationsProvider' from '/Users/aprice/Projects/stem-py/node_modules/cerebral-module-devtools/node_modules/cerebral-module-signal-store'

Looking at the node_modules folder, cerebral just isn't there. And looking at the package.json, cerebral is not in dependencies (although it is in devDependencies and peerDependencies).
I was not having this issue until this morning.

as mentioned on discord, just make sure you are running latest<EMAIL_ADDRESS>or stable<EMAIL_ADDRESS>Signal store will not have cerebral in its node_modules, because it doesn't directly depend on it. it just uses one from your project dependency (see peerDependency)

ouch, can you tell which version of cerbral do you use? seems we really made 'signal-store' incompatible with 0.33 :(

I've been using 0.33.31.

please define strict version of devtools to 0.6.3 and signal-store 0.1.7 (you will  have to define signal-store module in your package.json) until we find a way to fix it

Okay, I tried<EMAIL_ADDRESS>and<EMAIL_ADDRESS>and that seems to have fixed things for now. I can successfully build my app and use devtools. Thanks for pointing me in the right direction.

<EMAIL_ADDRESS>is out to address this problem.

perfect @Guria its working now


Fix git credentials

Before "credentials" was a file path, like "/dev/shm/credentials/app", and we exported the data using "cat" command.
But now it is a real auth token, so we don't need to "cat" anymore.

/lgtm


Resource provider don't allow to use pages and panels with equal suffixes

Resource provider should allow to use Panels and Pages with any unique names.
Example: LoginPanel and CustomerLoginPanel should work in the same time.

Fixed. Will be available on version 0.1.10 or later.


openlp:  2.4.6 -> 3.1.2

Description of changes
looking for additional maintainers: I don't use OpenLP any more. I can stay a maintainer and help with non-trivial updates, but it would be very helpful to have someone using it, who notices updates and breakages.

Major version update to 3.1.2
Fixes #296477 and  #312624.

Things done

Built on platform(s)

[x] x86_64-linux (NixOS)
[ ] 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/). Functinality tested:

[x] songs
[x] bible verses
[x] pdfs
[x] presentations via libreoffice
[x] pictures
[x] videos
[x] custom slides
[x] web remote

24.11 Release Notes (or backporting 23.11 and 24.05 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.

I added the backport label because the old package was broken (https://github.com/NixOS/nixpkgs/issues/296477).
This did not show up in Hydra, since so far meta.hydraPlatforms = [ ] was set. I had thought that the package in lib.nix would be built, but I think it wasn't because it appears nowhere in nixpkgs, except as a passthrough of the frontend package.

@Green-D-683 @matj1 I would also appreciate your reviews, even if I can't formally request them.
Since you use OpenLP (I assume), it would be of great help if you could test whether the application works. Especially the libreoffice integration could be fragile.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/help-overriding-python-library-in-nixos-home-manager/38042/2

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/openlp-update-to-3-1-2-looking-for-reviewers-and-co-maintainers/46034/1

This will need rebasing for https://github.com/NixOS/nixpkgs/pull/330855. Good luck with getting a co‐maintainer on board; it would be good to see this actively maintained again!

@aucub Why did you close this?


Activate power mode when typing faster than x keys per second

Sounds cool if we can let power mode auto kicks in when kps is > x. It should deactivate when user slows down typing. What do you guys think? :-)

@JoelBesada anything on that matter :D ?

The #264 provides a way to achieve this.

Closing as this can be achieved by using the new Flow functionality.
https://github.com/JoelBesada/activate-power-mode/wiki/Flow


Remaining questions and proposed design

VM-side

How does one account send native coins to another account? Just using call? Is there a "receivable" function on the other end? Is there a way to transfer a balance without a call, i.e., a "simple send" tx type? (probably not, it doesn't make sense in the context of AA)
How do we pass input into a called function? Do we only allow calling a single entrypoint function? Do we use argc/argv or stick with using IO syscalls like now.
How do we return a value back from a call? Do we want to support this? Add an opcode or two?
Do we consume all remaining gas on failure?

Host-side
Encompasses everything the node (i.e., go-spacemesh) needs to implement.
Transactions
This design is maximally "abstracted," i.e., it puts as little logic as possible in the host and as much as possible in the VM.
There are only two transaction types: self spawn and wallet call.
Type 1: Self spawn
Self spawn allows a funded but unspawned wallet account to be spawned, same as in the existing VM. The transaction specifies the principal address, template address, and immutable state (init params). The wallet template has a self_spawn() method. The host passes the entire tx into this method. The method can either fail, or else internally spawn the template. The spawned wallet program address must be the hash of the template address and the immutable state.
tx := (principal, nonce=0, gas_price, template_address, immutable_state, signature)
spawned_program_address := HASH(template_address, immutable_state)

Type 2: Wallet call
Everything else is a call into a method in a spawned wallet program. We use the term "wallet" loosely, and we don't cleanly differentiate between wallet programs and non-wallet programs. Effectively a wallet program is any program that implements the "spend" and "proxy" methods described here (you can think of "wallet" like a Rust trait; a template may implement many traits, and a particular wallet may implement a subset of these methods, or additional convenience methods). Here are some examples of functionality wallet apps will likely provide:
Send
To send native coins from their wallet, the user generates a tx with their wallet program as principal. The tx is passed to the "spend" method on the wallet program, which either effectuates a send or fails.
tx := (principal, nonce, gas_price, ENCODE("spend", recipient, amount), signature)

Call/proxy
To use a wallet's funds to pay gas for a call to another program, the user again generates a tx with their wallet program as principal. The tx is passed to the "proxy" method on the wallet program, which either effectuates the call to another program, or fails.
tx := (principal, nonce, gas_price, ENCODE("proxy", recipient, amount, input), signature)

Deploy
To deploy a new template, the user passes the template code to the wallet program, which uses a VM opcode to deploy a new template. The deploy opcode returns the newly-deployed template address, which is calculated as the hash of the template code. The deploy opcode fails if there's already a template deployed to this address. There's no verification of the template code at deploy time. The deploy opcode charges gas based on the size of the code.
tx := (principal, nonce, gas_price, ENCODE("deploy", template_code), signature)
template_address := HASH(template_code)

Spawn
To spawn a program from an existing template, the user passes the template address and immutable state (init vars) to the wallet program, which uses a VM opcode to spawn the program. The spawn opcode returns the newly-spawned program address, which is calculated as the hash of the template address, the principal address, and the nonce. The spawn opcode fails if there's already a program spawned to this address, or if the template init code fails to run on the input immutable state. The spawn opcode charges gas based on the template init code execution, i.e., same as a cross-contract call.
tx := (principal, nonce, gas_price, ENCODE("spawn", template_address, immutable_state), signature)
program_address := HASH(template_address, immutable_state, principal, nonce)

Accounts
There are three kinds of accounts.
Stubs
A stub is simply an account that has received funds but hasn't been spawned yet.
Templates
A template contains only code. Funds sent to a template account are effectively burned and cannot be moved. (Note that we cannot prevent funds from being sent to a template address before it's deployed, but once we know an account is a template we can prevent additional funds from being sent there.)
Programs
A program account contains a balance, a nonce, a state tree, and a link to an associated template address.
Questions

We need to finalize how wallets handle nonces. Note that the nonce is not fully abstracted into the VM since Spacemesh miners need to be able to read it for tx ordering.

See https://community.spacemesh.io/t/proposed-athena-design/433

Nothing to do here, conversation is in the forum at the above link


Searching for URLs results in buggy highlighting

Zulip's search highlighting unfortunately does not handle URLs correctly.
See example here, where I've sent a message containing a URL and then searched for that URL:

To fix this, we'll probably need to add some custom checking for whether something is a URL and modify the query we send in to the Postgres full-text search to somehow exclude the title matches.

This was fixed a while ago, I think in 2f09866364b2bf991ef611af27a9b3d9642f0eda.
I think that this would be a good test case to have, though, so I'm leaving this open but retagging it as a test coverage issue.

Didn't 2f09866 already add a test case for this?

@cory2067 I think what @timabbott wants is a search query that is just a link.

Yep, that's correct.


Validator DevOps best practices

New guide to go over some devops best practices

@barbaraliau yes, it's a starting doc and can get expanded the more we build our devops best practices

@barbaraliau yes, it's a starting doc and can get expanded the more we build our devops best practices


Featurization issues

MIGPUMA has joint meaning with MIGSP; same for POWPUMA/POWSP.
Why does RELP come up so much in the ridge models? What does it mean in practice?

CITWP, YOEP, JWMNP: mean-coding blanks might not be the right thing, since blank means the person was born in the US / doesn't work
MLP* (when served in military) could probably be simplified; VPS does that
NWAB, NWAV, NWLA, NWLK, NWRE are recoded into ESR
RELP (relationship to reference person) is kind of a weird feature
hierarchical featurization for ANCP / FODP / INDP / NAICSP / OCCP / SOCP?

for NAICS/SOC see https://www.census.gov/people/io/methodology/indexes.html

merge ANC1P/ANC2P, RAC1P/RAC2P/...?
re-featurize JWAP/JWDP to be circular?
Things that refer to specific in-US places: MIGPUMA, MIGSP, POBP, POWPUMA, POWSP
POVPIP: pretty sharp featurization difference between 500 and 501


difference between  wavfile and soundfile?

audio_path = 'voxceleb1/id10270/8jEAjG6SegY/00005.wav'
sample_rate, audio0  = wavfile.read(audio_path)
print(audio0) # [ 65  63 123 ... 162 169 119]
audio0, sample_rate  = sf.read(audio_path)
print(audio0) # [0.00198364 0.00192261 0.00375366 ... 0.00494385 0.00515747 0.00363159]

Here the scale is dfferent. Does it affect the performance of the model because the input feature changes? (I also notised that wavfile is faster than soundfile, but the latest code adopt soundfile)

wavfile.read() does not apply any normalization, whereas soundfile.read() applies normalization. You need to normalize the data returned by wavfile.read() as: audio0 = audio0/32767. to get similar output as soundfile.read().

import numpy as np
a = [65,  63, 123, 162, 169, 119]
np.array(a)/32767.

output:
array([0.0019837 , 0.00192267, 0.00375378, 0.004944  , 0.00515763, 0.0036317 ])
which is the output of soundfile.read()

I am not sure if it affects the performance. @joonson will be able to answer this better.
Yes, wavfile.read() is faster than soundfile.read()

@seacj I have reproduced similar results using wavfile.read() without any normalization, so it seems that it doesn't affect the performance.

@seacj I have reproduced similar results using wavfile.read() without any normalization, so it seems that it doesn't affect the performance.

Thank you. That's right.


[Wallets] CLN: fix pending state check

Codecov Report

Merging #1770 (d23feff) into main (e39241a) will increase coverage by 1.09%.
The diff coverage is 0.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main    #1770      +/-   ##
==========================================
+ Coverage   48.85%   49.94%   +1.09%
==========================================
  Files          47       47
  Lines        7091     7912     +821
==========================================
+ Hits         3464     3952     +488
- Misses       3627     3960     +333

Impacted Files
Coverage Δ

lnbits/wallets/cln.py
17.35% <0.00%> (-0.30%)
:arrow_down:

... and 10 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Runtime: metrics_sql parser

The parser transforms input metrics_sql into a regular SQL query. In addition to features listed in the docs following features are also supported/changed:

No need to specify AGGREGATE clause. Can simply do SELECT dim, agg FROM metrics_view.
No need to specify GROUP BY clause if selecting measure and dimension both. GROUP BY is implicitly added.
WHERE, HAVING and ORDER BY clauses can reference any dimension from the metrics_view and not just the selected dimension.
Ability to specify custom aliases.
Supports date_trunc function.
Operations on selected dimensions and measures similar to filter clauses.

@k-anshul you adding docs or want me to do it?

@mindspank Haven't started on the docs yet. Could you please take it ?
Thanks.


debug50 connection issue

everytime I try to run debug50 for any program I recieve an error message like this. I've tried restarting, but nothing seems to work.

Version: 1.91.1
Commit: f1e16e1e6214d7c44d078b1f0607b2388f29d729
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36
Embedder: codespaces

/question please contact your course support channel.

We closed this issue because it is a question about using VS Code rather than an issue or feature request. Please search for help on StackOverflow, where the community has already answered thousands of similar questions. You may find their guide on asking a new question helpful if your question has not already been asked. See also our issue reporting guidelines.
Happy Coding!


Crash when typing during autocomplete of max() within match statement

Godot version
4.0 beta 2; also in v4.0.beta.custom_build.28f642097 (latest master windows build from github actions)
System information
Windows 10
Issue description
in the following script, when i type the ... max(0, statement as noted in the comment block below, the editor immedately crashes.
The script
extends Node3D

var actor_ap_attack:Array = [0]

func vm_execute(program:Array):
	for cmd in program:
		var actor_id:int = cmd[0]
		var opcode:String = cmd[1]
		match opcode:
			'ADD_AP_ATTACK':
				var delta_ap:int = cmd[2]
				actor_ap_attack[actor_id] = max(0, actor_ap_attack[actor_id]+delta_ap)
				# THE CRASH: insert a blank line following this comment block, immediately before
				#            the next match clause, and type the following:
				#
				#            actor_ap_attack[actor_id] = max(0,
			'ADD_AP_MOVE':
				pass

Console output and backtrace
Godot Engine v4.0.beta.custom_build.28f642097 - https://godotengine.org
Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1060 6GB

Project is missing: e:/dev/godot/bug_gpuparticles3d_error_spam_not_multimesh/project.godot
Editing project: e:/dev/godot/bug_autocomplete_max_crash

Godot Engine v4.0.beta.custom_build.28f642097 - https://godotengine.org
ERROR: Condition "!windows.has(p_window)" is true.
   at: VulkanContext::window_resize (drivers\vulkan\vulkan_context.cpp:1496)
Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1060 6GB

ERROR: Condition "font.is_null()" is true.
   at: LineEdit::_shape (scene\gui\line_edit.cpp:2202)
ERROR: Condition "font.is_null()" is true.
   at: LineEdit::_shape (scene\gui\line_edit.cpp:2202)
ERROR: Condition "font.is_null()" is true.
   at: LineEdit::_shape (scene\gui\line_edit.cpp:2202)
ERROR: Condition "font.is_null()" is true.
   at: LineEdit::_shape (scene\gui\line_edit.cpp:2202)
WARNING: FBX file import is enabled in the project settings, but no FBX2glTF path is configured in the editor settings. FBX files will not be imported.
     at: _editor_init (modules\gltf\register_types.cpp:100)
ERROR: Condition "ret.type != BOOL" is true. Returning: false
   at: Variant::in (core\variant\variant_op.cpp:1107)
ERROR: Condition "ret.type != BOOL" is true. Returning: false
   at: Variant::in (core\variant\variant_op.cpp:1107)
ERROR: Condition "ret.type != BOOL" is true. Returning: false
   at: Variant::in (core\variant\variant_op.cpp:1107)
ERROR: Condition "ret.type != BOOL" is true. Returning: false
   at: Variant::in (core\variant\variant_op.cpp:1107)
ERROR: Condition "ret.type != BOOL" is true. Returning: false
   at: Variant::in (core\variant\variant_op.cpp:1107)
ERROR: Index p_index = 1 is out of bounds (size() = 0).
   at: List<struct PropertyInfo,class DefaultAllocator>::operator [] (.\core/templates/list.h:521)

================================================================
CrashHandlerException: Program crashed
Engine version: Godot Engine v4.0.beta.custom_build (28f642097a7986867e4fb7d697764efb4db753bf)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[0] oidnUnmapBuffer
[1] oidnUnmapBuffer
[2] oidnUnmapBuffer
[3] oidnUnmapBuffer
[4] oidnUnmapBuffer
[5] oidnUnmapBuffer
[6] oidnUnmapBuffer
[7] oidnUnmapBuffer
[8] oidnUnmapBuffer
[9] oidnUnmapBuffer
[10] oidnUnmapBuffer
[11] oidnUnmapBuffer
[12] oidnUnmapBuffer
[13] oidnUnmapBuffer
[14] oidnUnmapBuffer
[15] oidnUnmapBuffer
[16] oidnUnmapBuffer
[17] oidnUnmapBuffer
[18] embree::TaskScheduler::wait
[19] embree::TaskScheduler::wait
[20] embree::TaskScheduler::wait
[21] embree::TaskScheduler::wait
[22] embree::TaskScheduler::wait
[23] embree::TaskScheduler::wait
[24] embree::TaskScheduler::wait
[25] oidnUnmapBuffer
[26] embree::TaskScheduler::wait
[27] embree::TaskScheduler::wait
[28] embree::TaskScheduler::wait
[29] embree::TaskScheduler::wait
[30] <couldn't map PC to fn name>
[31] <couldn't map PC to fn name>
[32] <couldn't map PC to fn name>
[33] <couldn't map PC to fn name>
[34] <couldn't map PC to fn name>
[35] embree::TaskScheduler::wait
[36] BaseThreadInitThunk
-- END OF BACKTRACE --
================================================================

Steps to reproduce

open the MRP in the editor.
open Node3D.gd
type in the line of code as noted in the comment block.

Minimal reproduction project
bug_autocomplete_max_crash.zip

I can't reproduce it, seems like #67389 fixed it.

I can confirm this is fixed now. I tested in Beta 2 and Beta 14 and I could not reproduce in Beta 14
Closing as fixed by https://github.com/godotengine/godot/pull/67389


Release nodejs-common v0.21.1

This pull request was generated using releasetool.

Codecov Report

Merging #207 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #207   +/-   ##
=======================================
  Coverage   97.18%   97.18%
=======================================
  Files          11       11
  Lines        2239     2239
  Branches      146      146
=======================================
  Hits         2176     2176
  Misses         34       34
  Partials       29       29

Continue to review full report at Codecov.

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

Release is at https://github.com/googleapis/nodejs-common/releases/tag/v0.21.1


Questions about "INTERNAL_SERVICE_ERROR" event

Hi AVS team,
SDK 1.10/1.11 .  ARM based embedded linux system.
I found something strange in Listening or Speaking state, AVS often receive "INTERNAL_SERVICE_ERROR" message and 500 result in these state.
While it happens in Listening state, it will jump to Idle directly and will not listen input audio.
While it happens in Speaking state, it will not play any audio and jump to Idle.
Could you advise if there is any missed or something wrong to get this status ?
I have a debug9 log for reference, you can just search this exception keyword in the log.
internal_service_exception.zip

Hi @zeusshuang,
The exception you are seeing is because you are being throttled. I have contacted the cloud team and they mentioned that the requests coming from your devices are within expected values, so they are investigating. We will update the ticket when there is further information as to why the throttling is occurring.


Add a va_arg intrinsic

fn va_arg<T>(va_list: *mut u8) -> T;

translates to
va_arg i8* va_list, T

This is useful for C interop. va_arg can theoretically be implemented in user code but that's a lot of work.

It's not possible to implement this in user code without some kind of reflection/type information.

I believe #2137 addresses this.

Closing in favor of https://github.com/rust-lang/rust/issues/44930.


VIM, windows – document navigation don't work on cyryllic texts in Windows but works in Linux

Good morning!
Describe the bug
Recently I installed gvim (bug happens in usual vim too) on windows 10 and started vimtutor. My home language is Russian and vimtutor was translated by default.
After entering lesson 2.1 I found out that I can't use dw to delete words. Using this command I can delete 1 or sometimes 2 letters in a word. I can't delete the whole word as vimtutor says.
To Reproduce

Start Russian vimtutor or type some text using cyrillic letters (for example, "Несколько слов рафинад в этом предложении автокран излишни.").
Move the cursor to the beginning the cyrillic word and type dw.

Expected behavior
dw should delete the world "Несколько" in the example line above. Instead, it deletes only the letter "Н" (En).
Environment (please complete the following information):

Vim version 8.2
OS: Windows 10  2004.
Terminal: CMD and GUI.

Additional context
I continued my research and found out that console version of vim in windows 10 has the same problem: I can't edit texts with cyrillic symbols.
Then I loaded my OpenSUSE i3 system and launched vimtutor there (vimtutor in OpenSUSE was also in Russian). Suddenly, all commands worked correctly and I could complete vimtutor (even if it mostly contains cyrillic characters).
I asked about the problem on SA but got no answer: https://stackoverflow.com/questions/68360134/vim-document-navigation-dont-work-on-cyryllic-texts-in-windows-but-works-in-l

Vim version 8.2

What is the patch number? Could you try the latest version (at least 8.2.2912 or later)?

Check if you have encoding set to utf-8.

Check if you have encoding set to utf-8.
"Old" versions of vim for windows didn't use UTF-8 as default encoding and that causes the issue you have. Either download and use most recent vim for windows (https://github.com/vim/vim-win32-installer/releases) or add
set encoding=utf-8

as a very first line of your vimrc.

Thank you very much for your answer, everything works correctly after editing vimrc!


Initialize Data Module

Is your feature request related to a problem? Please describe.
Creating the initial pass of the data loading / data processing module.
Describe the solution you'd like
Some initial module which can take in a CSV and spit out an object containing a dataframe and some time interval value. Should leave room for implementing additional cleaning / processing functionality in the future.

 Data V1 Implementation

Dataset Metadata will be a metadata class for a dataframe so that we can have multiple dataframes as discussed today.


use dat-registry module, closes #660

Uses the dat registry module instead of township client (#660)
Updates some auth tests/config based on latest datproject.org repo updates.

Might add back server option to be registry or something with some help text instead.

Going to merge so I can fix the rest of the tests. Failing tests are from other upstream error message changes.


Update AirMozilla test case

The existing AirMozzilla test case currently fails for thumbnail and categories

Seems to have fixed itself


There are race conditions in the tests/backburner?

I am seeing random test failures occasionally when I run them locally. Not sure what the cause is.

with timer tests, if you tab out. They may re-order in dubious ways. (browser crappiness :()  The tests are stricter then app code.


import error in apiai module

I am getting the following error while trying to run the example for text input
File "/Library/Python/2.7/site-packages/apiai/init.py", line 36, in
from .requests.query          import Entry
ImportError: No module named requests.query
I think there is a mistake in the module, could it be checked?

Hello,
I was fix this issue already, please update library from pip.


Make StreamField lazily prepare its contents

StreamFields should not go and grab related objects from the database as soon as they are loaded, as the StreamField may not be used. For example, getting a list of Page titles for a menu does not require the StreamField content. For example, http://digitalready.tas.gov.au/resources/ will load the all the images in all the StreamFields for every linked resource on that page, even though the StreamField is never used.
This commit adapts some code from django-json-field, which itself apapts some code from Django.
There is a bit of nasty code to get StreamField.contribute_to_class working properly. I would fix it in the correct manner by making a new Metaclass for StreamField to unoverride the contribute_to_class override done by the SubfieldBase Metaclass, but it is 11:30 at night on a Friday. Ignoring that bit of code, what are your thoughts?
Fixes #1200

It would also seem that there are no tests for StreamFields. I added a test for the lazy nature of StreamFields, but not for the rest of the StreamField behavior.

Hi @timheap,
I've only had a quick look at your code, but it looks like things could be a fair bit neater if you implement the 'laziness' at the level of StreamBlock / StreamValue rather than StreamField - that way, there would be less hacking around with Django internals, a decent body of tests to add to, and neater behaviour with nested blocks (as it would only unwrap one level at a time).
The idea is that the JSON deserialization would (probably) happen up front, but it would remain as primitive values (e.g. an ID rather than a Page object for a PageChooserBlock) until you retrieve a specific item from the StreamValue.
I was confused for a moment, because it looks like StreamValue.__getitem__ already includes some lazy evaluation logic (self._bound_blocks[i] is being populated on request):
https://github.com/torchbox/wagtail/blob/master/wagtail/wagtailcore/blocks/stream_block.py#L254-260

but it turns out to be missing the key ingredient that would actually make it useful, because self.stream_data[i] has already been fully expanded into 'rich' object representations by that point, thanks to this bit of code:

https://github.com/torchbox/wagtail/blob/master/wagtail/wagtailcore/blocks/stream_block.py#L177-181
Hopefully, then, all it needs is some re-plumbing of the StreamValue constructor so that it accepts the primitive values (and calls to_python on them as part of the __getitem__ code) rather than the rich ones. I'll have a go at making this fix next week, if you don't beat me to it :-)

Closing in favour of #1337. Thanks, @gasman.


Could not find Gitter roomID

Describe the bug
I try to bridge Telegram chat with Gitter room. Matterbridge successfully connects to Telegram but can't connect to Gitter. User is already in the specified room.
Why can't it find roomID?
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Successfully connect to the Gitter room, user already is in the room.
Screenshots/debug logs
matterbridge_1  | time="2019-11-30T08:56:33Z" level=info msg="Running version 1.16.3-dev 173a38a" prefix=main
matterbridge_1  | time="2019-11-30T08:56:33Z" level=info msg="WARNING: THIS IS A DEVELOPMENT VERSION. Things may break." prefix=main
matterbridge_1  | time="2019-11-30T08:56:33Z" level=info msg="Parsing gateway flask-user" prefix=router
matterbridge_1  | time="2019-11-30T08:56:33Z" level=info msg="Starting bridge: gitter.flask-user-bridge " prefix=router
matterbridge_1  | time="2019-11-30T08:56:33Z" level=info msg=Connecting prefix=gitter
matterbridge_1  | time="2019-11-30T08:56:34Z" level=info msg="Connection succeeded" prefix=gitter
matterbridge_1  | time="2019-11-30T08:56:34Z" level=info msg="gitter.flask-user-bridge: joining Flask-User/community (ID: Flask-User/communitygitter.flask-user-bridge)" prefix=gitter
matterbridge_1  | time="2019-11-30T08:56:34Z" level=fatal msg="Starting gateway failed: Bridge gitter.flask-user-bridge failed to join channel: Could not find roomID for Flask-User/community. Please create the room on gitter.im" prefix=main

I can do it if I make request manually using for example Postman:

Environment (please complete the following information):

OS: Linux, Docker image 42wim/matterbridge:latest built from this commit
Matterbridge version: 1.16.3-dev 173a38a

Additional context
My config:
[telegram]
[telegram.flask_user_bridge_bot]
Token="123:qwertyASnbqnwmejkzxcyuqwe"
RemoteNickFormat="[{PROTOCOL}] <{NICK}> "
MessageFormat="Markdown"

[gitter]
[gitter.flask-user-bridge]
#You can get your token by going to https://developer.gitter.im/docs/welcome and SIGN IN
Token="qweuxcnqwe129387chk"
RemoteNickFormat="[{PROTOCOL}] <{NICK}> "

[[gateway]]
name="flask-user"
enable=true

[[gateway.inout]]
account="telegram.flask_user_bridge_bot"
channel="-1001192489017"

[[gateway.inout]]
account="gitter.flask-user-bridge"
channel="Flask-User/community"

I've looked into the library we use and it uses this call to find the room:https://api.gitter.im/v1/rooms?q=Flask-User/community which shows up empty.
Information here: https://developer.gitter.im/docs/rooms-resource
Seems to be a gitter API issue, could you open an issue there?

I'll think about maybe using a workaround so you can add an ID explicitly

I created an issue in Gitter repo: https://gitlab.com/gitlab-org/gitter/webapp/issues/2384
Let's see what they answer.

@and-semakin seems to be fixed upstream now according to the issue? Can you confirm?

Confirm. It was a bug in Gitter search subsystem.


wazero: updates to 1.0.0-pre.3

This updates wazero to 1.0.0-pre.3. Note: wazero 1.0 will require Go 1.18+
Notably, this improves performance and changes host function syntax.

Thank you!


please update vim (and xxd)

The vim version in w64dk is 9.0, from 2022 judging by the ouitput of vim --version.
I'm not familiar with the vim release process, but I'd think a newer version would be more in-line with the "latest" w64dk policy with gcc, binutils, etc.
At the very least, xxd (from the vim source code) gained colored output sometime in 2023, which works nicely on windows too (tested by compiling latest xxd.c on its own, which compiles cleanly in w64dk).
EDIT:
Hmmm... I see the latest official version is 9.0 at http://ftp.vim.org/pub/vim/unix
So I guess that's why.
Anyway, while it's trivial for anyone to compile a newer xxd, it would still be nice to include it in w64dk - assuming it's completely stand-alone and not used by other vim sources. I compiled this https://github.com/vim/vim/blob/master/src/xxd/xxd.c

There are a couple light blockers, and I'm not so personally motivated to figure them out right now. Despite adopting Vim in 2017, I feel completely at home with Vim 7.x+ (2006-ish), so it's all the same to me. (If C/C++ filetype/indent/syntax improved, like being able to parse C99, that would be something…)
The main blocker is that Vim 9.1 breaks Windows XP support, enough that it needs to be patched, and I still need to write that patch. Since Vim's Windows support is solid, this can be worked out natively in w64devkit itself, in case anyone would like to take a crack at it using the i686 release (on any Windows system, as the problems thankfully appear at compile time).
Vim 9.0 was the last release before Bram passed away. My understanding is that despite the size, age, and scope of the project, he didn't delegate much, leaving contributors scrambling to re-organize. They lost access to the original FTP server (that's why it still only lists 9.0), and releases are now distributed differently. In effect it's been like a fork. When 9.1 was announced, the website didn't list a source tarball at all, and it suggested there would be no further source artifacts, which made me hesitate. That has since been corrected.
If going forward requires selecting a fork, then I figure I should also consider the other obvious fork, Neovim. I haven't put any time into this, partly because I speculate serious problems: New dependencies, non-trivial cross-compilation (CMake), and probably hopeless regarding XP support.
While I'm at it, I'll mention a few extras. The recent disorganization is nothing new, and Bram was never particularly organized about the project:

The sources page was last updated in 2018, listing 8.1 as the latest release: https://www.vim.org/sources.php

DNS has been busted for as long as I can remember: https://vim.org/

For as long as I can remember, the official download page has hosted malware ads with fake download buttons (screenshot taken today):

Thanks for the info. I know that Bram passed away, but I wasn't aware the releases are in some dissarray - and I now see the latest official release seems to be 9.1 from 2024.

There are a couple light blockers, and I'm not so personally motivated to figure them out right now.

Fair enough. Obviously if that's not a trivial version change at the docker file then someone needs to put in the time to handle it.
For what it's worth, one feature which personally I find very useful, and which is available at the latest vim (tested from https://github.com/vim/vim-win32-installer/releases which is linked from the main vim website) - but not in vim from w64dk, is support for mouse wheel scroll on Windows.
This works apparently out of the box on Windows even without a ~/.vimrc config (vim -u NONE myfile.c - then scroll the mouse wheel).
It's not an issue to grab a more recent vim from elsewhere for more vim/xxd features, like the link I posted (which I think is what I'll do, now that I know recent vim has mouse wheel scroll).
So this is just an FYI that there are at least two nice improvements with recent vim compared to the w64dk build, though I guess there are more.

Neovim has a nasty point that it requires new Windows API functions which are even absent on Windows 7 (let alone XP).

In other improvements, I've started using some c23 features (#elifdef) and vim 9 doesn't highlight them properly. This is fixed upstream.
Not particularly important, I only mention it as a minor motivation.

I managed to get vim 9.1 compiling using w64devkit i686, it seems some features that are unavailable on windows XP were assumed to be present. There are a few things to patch, but it's not that much. I don't know if I did it all correctly, though.
They are:
os_win32.c: In function 'decode_mouse_wheel':
os_win32.c:1542:49: error: 'MOUSE_HWHEELED' undeclared (first use in this function); did you mean 'MOUSE_WHEELED'?
 1542 |     int     horizontal = (pmer->dwEventFlags == MOUSE_HWHEELED);
      |                                                 ^~~~~~~~~~~~~~
      |                                                 MOUSE_WHEELED

Inside winbase.h, it's defined like this:
#if (_WIN32_WINNT >= 0x0600)
#define MOUSE_HWHEELED 0x8
#endif

I just defined it myself in os_win32.c.
There are a few calls to GetFinalPathNameByHandleW in resolve_reparse_point:
os_mswin.c: In function 'resolve_reparse_point':
os_mswin.c:1808:12: error: implicit declaration of function 'GetFinalPathNameByHandleW' [-Wimplicit-function-declaratio ]
 1808 |     size = GetFinalPathNameByHandleW(h, NULL, 0, 0);
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~

I simply stubbed the implementation out, and made it return NULL.
The last error was:
iscygpty.c: In function 'is_cygpty':
iscygpty.c:119:33: error: 'FILE_NAME_INFO' undeclared (first use in this function); did you mean 'CERT_NAME_INFO'?
  119 |         const int size = sizeof(FILE_NAME_INFO) + sizeof(WCHAR) * (MAX_PATH - 1);
      |                                 ^~~~~~~~~~~~~~
      |                                 CERT_NAME_INFO

This function is:
// Check if the fd is a cygwin/msys's pty.
int is_cygpty(int fd)
{
#ifdef STUB_IMPL
    return 0;
#else
    HANDLE h;

Conveniently, there's already a define present to just stub it out, so I just defined it.
Judging by the comment, it doesn't matter for w64devkit anyway.
I did not try the resulting build on Windows XP, I hope there are no runtime problems. I don't currently have the means to test, so I will leave that to someone else.

I'd be happy to submit a patch, but unfortuantely I don't understand the hunks are generated, and how to use diff to do that. If @skeeto could tell me some insights on that, I'll do it.

I'd be happy to submit a patch, but unfortuantely I don't understand the hunks are generated, and how to use diff to do that.

WinMerge?, or using diff
# -r recursive compare any subdirs, -N treat absent files as empty, -a treat as text, -u output NUM (default 3) lines of context
diff -Naru file_or_dir_original file_or_dir_new > patch.patch

Thanks for digging in, @Peter0x44! Quilt shines here, but unfortunately
it's Bash and Perl, so porting to native Windows is impractical. (I like
it so much I've considered rewriting a more portable implementation.) To
generate the patch purely with w64devkit, unpack a fresh Vim 9.1 source
tree adjacent to the source tree you modified, then one level up:
$ diff -ruN a/ b/ >vim-9.1-windows-xp.patch

Here I've named them "a" and "b" to match Git's naming style, which is the
style I prefer. I usually cut down on context (-U1 or -U2), which overall
reduces "merge" conflicts, with trade-offs. I don't like that diff adds
file timestamps, which "git diff" doesn't do, and the most practical way
to remove them is editing the final patch by hand. "git diff" appends a
context line (i.e. what function is being changed) to the hunk headers,
which is great when reviewing code, but less important here. I'll probably
regenerate your patch after I accept it, so don't worry about fixing it
up.
 Or even "git format-patch" for
something very formal. Alternatively start from the Vim Git repo on the
proper tag. Though note that the upstream source artifact is not straight
out of a Git commit, but generated through "make unixall". That shouldn't
affect this patch, though.

"git show" to generate a patch with the commit message. Or even "git format-patch" for something very formal.

Can the output of git show be applied to some git repo? I don't thitnk I'm familiar with a git command for that.
The two methods I know (other than diff/patch) to generate a git diff which can be applied are either git diff [maybe-some-commit] > my.diff which can then be applied using e.g. git apply < my.diff, or git format-patch HEAD~N --stdout > my.patch (where N is the number of commits to inlcude), which can then be applied e.g. using git am < my.patch.
But largely this is probably inconsequential. It seems the required diff is small (nice work!), so any form would be fairly trivial to apply or automate.

Can the output of git show be applied to some git repo?

"patch" ignores everything before the patch header (+++/---), so patches
may begin with free-form prose explaining their purpose. That means piece
of text can simultaneously be a mail message and a patch, and this effect
is used by old-school open source mailing lists (e.g. the kernel mailing
list). Take a close look and notice that patches aren't "attached" (in the
MIME sense), but simply dumped into the message body below the prose. The
whole message, headers and all, can be applied as a patch.
Following this, the output of "git show" is a valid patch. It doesn't
preserve Git metadata the way "git format-patch" and "git am" do, but that
doesn't matter here.

Following this, the output of "git show" is a valid patch.

Right. Thanks. Indeed the output of git show can be applied using git apply (obviously without the commit message, because git apply applies a diff and not a git commit), but git am refuses to take it, and I think that's what I recalled. Thanks again.

Digging into some of the details you found, looks like Vim has officially
dropped XP support starting in Vim 9.1, with a decision made in September
2022:
https://github.com/vim/vim/commit/27b53be3
From what I see in that commit, even after fixing compile-time issues,
there are probably more at run-time. Without upstream support, it will be
difficult to maintain XP support here going forward, requiring ever more
extensive patching with each Vim release, effectively forking it. It seems
I'll need to stick with Vim 9.0 until w64devkit drops XP support — which
will happen eventually, after more components in the distribution drop XP
support. Vim 9.1+ is just not important enough to do that now.
As an alternative, if there are Vim 9.1+ features you'd like, perhaps we
can backport them as patches. That's more practical than patching for XP.
In the simple cases the relevant commit is the patch as-is. For instance,
upstream C23 changes should somewhere in here:
$ git log -p --reverse v9.0.0000..master -- runtime/syntax/c.vim
I'm not seeing anything about #elifdef nor nullptr, though. But suppose
you really want syntax highlighting for __inline:
$ git show 63c39e4e >path/to/w64devkit/src/vim-__inline.patch
Also COPY and "RUN cat vim-*.patch | patch -p1" directives in Dockerfile
to pick this up, like other tools already have.

Without upstream support, it will be difficult to maintain XP support here going forward

Agreed.

It seems I'll need to stick with Vim 9.0 until w64devkit drops XP support

As an alternative, if there are Vim 9.1+ features you'd like, perhaps we can backport them as patches.

Personally I don't think this is worth the effort. Nevertheless, the features which I find most useful so far in upstream is mouse wheel scroll support, and colors in xxd, but I don't see the value in putting (my) time into bvackporting it when I can use an upstream binary. I did initially compile only xxd, but when I got the whole upstream vim, then I use its xxd as well.
I can think of two alternatives to this:

Drop vim completely in w64dk. Windows vim releases are available elsewhere. I've switched to upstream binary, and so far (few days) been very happy with it..
Keep the 32 bit w64dk vim at version 9.0 without further updates (as has been the case since the first w64dk release, I think), and track upstream with the 64 bit build. I'd think this shouldn't require meaningful effort, other than "standard" level of effort when updaing to a new version.

As an alternative, if there are Vim 9.1+ features you'd like, perhaps we can backport them as patches.

I don't think this is worth the effort, I didn't realize XP had been dropped deliberately.
That's a disappointing outcome, I don't understand the modern obsession of deleting code you don't "personally" need for its theoretical "maintainance cost". The commit really did not simplify much code in a useful way...
Does simply reverting this commit work correctly, as of now? It doesn't seem likely upstream will be convinced to keep this support, but an editor being the "straw breaking the camel's back" on this issue feels too anticlimatic.

Not related to vim or w64devkit, but another case I noticed that dropped windows XP support recently:
https://github.com/glfw/glfw/issues/2505


How i can measure distance between phone and beacon ?

I've see at evothings/phonegap beacon plugin that you can  measure distance between phone and beacon.Is there a way to measure distance using this plugin?

You'd have to refer to the actual plugin documentation.  What I've made is only a wrapper to the original plugin.  It can do whatever the original plugin can do.
Regards,


Add testing with Azure pipelines

See https://github.com/mne-tools/mne-python/blob/master/azure-pipelines.yml

Github actions works well. Closing this.