Name issue with Scalar Introspection

What did you do?
We have two scalars named Date and Time that we use in a few places. We also have a test which introspects our types and makes sure we're documenting them all. Introspection of these types seems to be doing something odd with names, possibly calling the object name (clashing with php's date() and time())
What did you expect to happen?
With the following query:
{
  __schema {
    types {
      name
      description
    }
  }
}

We would expect the result for Date to be:
 [
   "name" => "Date"
   "description" => "A date in YYYY-MM-DD format."
 ]

and the result for Time to be:
[
  "name" => "Time"
   "description" => "Representation of a time in 24H format (e.h. 19:00)."
]

What actually happened?
We are seeing the following responses for Date:
 [
   "name" => null
   "description" => "A date in YYYY-MM-DD format."
 ]

and for Time:
[
  "name" => "1531475584"
   "description" => "Representation of a time in 24H format (e.h. 19:00)."
]

The query for Date also includes the following error:
[{"message":"date() expects at most 2 parameters, 4 given","locations":[{"line":4,"column":13}],"path":["__type","name"]}]

What version of this project are you using?
I've created a branch of the project which includes a test which breaks due to this issue:
https://github.com/digiaonline/graphql-php/compare/master...cgrice:bug-with-scalar-introspection
There's a commented out piece of code in the IntrospectionProvider which fixes the test, but I'm not sure this is the best approach! I couldn't find the piece of code which is directly causing the issue.

Thanks for reaching out @cgrice! We will certainly have to take a look at what’s causing this. Any chance you could also provide the code that is defining these types? Thank you in advance.

Feel free to join us on Slack if you wish to be involved in this project. https://digiaopensource-slack.now.sh #graphql-php

Oh I see what’s going on. You cannot name the function that produces your custom scalar types like that, unless you namespace them.
I also now see that it’s a but misleading to call the scalar type functions e.g. String(), I actually think we should suffix them with Type.

Not sure what you mean, sorry! The example in the issue doesn't define any functions, just a scalar in the SDL.
Have just realised you can do this with any stdlib function and the resolver will attempt to call it, by the way. For example, if i call a scalar Phpinfo I get:
[{"message":"phpinfo() expects at most 1 parameter, 4 given","locations":[{"line":4,"column":13}],"path":["__type","name"]}]


producer authority (WTMSig Block Signing) support

Change Description
This PR implements support for producer_authority and therefore WTMSig Block Signing ( EOSIO/eos#7404 ) in the eosio.bios contract.
This depends on a version of eosio.cdt which has incorporated EOSIO/eosio.cdt#570
Deployment Changes

[ ] Deployment Changes

API Changes

[x] API Changes

setprods in eosio.bios now expects a serialized vector of producer_authority structures and is not backwards compatible with the previous serialized vector of producer_key structures.
Documentation Additions

[ ] Documentation Additions

Replaced by #349.


Fix CPUs/OPS do not update after hitting limits

Attempt at fixing #2339
This is a WIP.
Before:

After:

Never been an issue, would be great to ensure issues you're fixing are actual globalized issues and not random issues caused by your setup

I don't think you should have the limit check and error call in that function. It should just update the numbers.

Never been an issue, would be great to ensure stuff that you fix are globalized issues and not random issues from your server setup only.

I don't think you should have the limit check and error call in that function. It should just update the numbers.

Okay, I'll change that when I get a chance.

Tested on my private server, seems to work.

You overwrote all of the event changes when fixing merge conflicts

You overwrote all of the event changes when fixing merge conflicts

Not sure how that happened, I'll fix this soon.

Works on my test server, but this time does not overwrite the entire event system.


chore(skip-chaos-pods): ignore chaos-pod to be targeted if appLabels are empty

Signed-off-by: shubhamchaudhary<EMAIL_ADDRESS>

/run-e2e-all


Cleaner method handling button operations in advanced search

Purpose or Intent
Cleanup repeated parts of code in method adv_search_button handling button operations in advanced search
Steps for Testing/QA
does not change UI, behaviour is still the same
@martinpovolny

@miq-bot assign @martinpovolny

@romanblanco : looks good except the 2 new methods should be private


Testing Rectangle Inclusion in Sparsity Maps

The IndexSpace::contains_all method is currently unimplemented in the case where the index space has a sparsity map.
https://gitlab.com/StanfordLegion/legion/-/blob/master/runtime/realm/indexspace.inl#L546-547

Implemented in commit 40cd40df.  @lightsighter do you have any test cases on your side that you'd like to run?

Pushed my change to Legion that needed this feature:
https://gitlab.com/StanfordLegion/legion/-/commit/55ae9e49bdce1255a76d8b760d1002a2003db990
Technically this code might not be necessary if Realm guarantees that after tightening an index space it will always remove a sparsity map if the IndexSpace could be represented simply by the bounding box rectangle. We already know that the IndexSpace objects have the same number of points, and at least one of them does not have a sparsity map.
The harder part for congruence testing is actually this bit of code that has to diff two different sparsity maps against each other, but there is no contains_all for comparison between two sparsity maps:
https://gitlab.com/StanfordLegion/legion/-/blob/55ae9e49bdce1255a76d8b760d1002a2003db990/runtime/legion/region_tree.inl#L1264-1360

if Realm guarantees that after tightening an index space it will always remove a sparsity map if the IndexSpace could be represented simply by the bounding box rectangle

Yes, Realm guarantees that for a t
IndexSpace<N,T> is1 = is2.tighten(true /*this is the default*/);
is1.dense() <=> (is1.volume() == is1.bounds.volume())

but there is no contains_all for comparison between two sparsity maps

The lack of contains_all for two potentially-sparse IndexSpace's is intentional - it's expensive enough that it's not provided as a simple query.  Eventually the interference test will cover this, but for now, you can compute a difference and check if it's empty.

Ok, that makes the test for index space expression congruences cleaner, but it also wipes out the test for contains_all. :)
https://gitlab.com/StanfordLegion/legion/-/commit/80d827443b0e37c529753e9e332e8e0835e3d37c
You'll get at least one run of CI with the contains_all code though. If it passes, then I think you can close the issue:
https://gitlab.com/StanfordLegion/legion/-/pipelines/319852375

Looks like the CI passed so @streichler we can close this issue when you're ready.


[New Port Request] BoringSSL

Library name: BoringSSL
Library description:Googles fork of OpenSSL
Source repository URL:
https://github.com/google/boringssl
https://boringssl.googlesource.com/boringssl
Project homepage (if different from the source repository):
Anything else that is useful to know when adding (such as optional features the library may have that should be included):
I went ahead and tried doing it myself.I  was able to get it working up until the installation of the lib and headers. Not exactly sure how to fix it. Side Note: I had some major issues using ninja as the build system for this. Not exactly sure why, but it just never worked
CONTROL.txt
portfile.txt

Hey, I've made some more progress. BoringSSL has no install target. so I've had to create one. This is what I've ended up with.
`include(GNUInstallDirs)
install(
TARGETS crypto ssl
EXPORT  boringssl_targets
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
)
install(
EXPORT boringssl_targets
FILE unofficial-boringssl-config.cmake
NAMESPACE unofficial::boringssl::
DESTINATION share/unofficial-boringssl
)
install(DIRECTORY include/ DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})`

@TaylorSasser After playing around with OpenSSL/LibreSSL in vcpkg, this is my suggestion:

Don't export unofficial targets and let users rely on FindOpenSSL.cmake.
Patch ports/openssl-{unix,uwp,windows}/portfile.cmake line 8 to include BoringSSL.
Handle OpenSSL or LibreSSL like OpenSSL handles LibreSSL (detect the ssl.h header).

In fact, using ports/libressl as the ports/boringssl template might be a good idea.
Does the VCPKG team agree? How about tools like openssl.exe that BoringSSL does not provide?

@TaylorSasser Could you please make a PR for that, so that we can test and contribute.

I've created a PR (https://github.com/microsoft/vcpkg/pull/8440) for the Go dependency and written a port against it:
https://github.com/qis/vcpkg/tree/dev/qis/boringssl
There are several issues I see with BoringSSL:

It does not support UWP due to usage of desktop-only APIs like RtlGenRandom.
It totally ignores CMAKE_C_FLAGS and CMAKE_CXX_FLAGS variables set by a MSVC toolchains.
When CMakeLists.txt is patched to honor flags set by a toolchain, /EH flags break compilation.
It uses its own gtest for tests which has the same /EH flags issues.
It uses Go for codegen.

I'll submit a PR for BoringSSL if Go is added to vcpkg, but don't want to maintain it since I use toolchains at work that can't build it.

Hi @TaylorSasser
Thanks for posting this request.
boringssl has been added to vcpkg. Please try to update vcpkg and use it.
@qis Thanks for your efforts.


feat: ini server based allocator

📚 $\text{Stack Overview}$
Pulls submitted in this stack:

#6 👈
#5
main

This comment was automatically generated by st.


TLS 1.3 PSK depends on the sequence of cipher suites

OpenSSL version：3.X
I use psk_find_session_cb() and psk_use_session_cb() to implement TLS 1.3 PSK：
The client invokes psk_use_session_cb() to set the SHA256 cipher suite.
The server invokes psk_find_session_cb() to set the SHA256 cipher suite.
Test cases：The server uses the default cipher suite
(1) The client is configured with TLS_AES_128_GCM_SHA256. The handshake succeeds.
(2) The client is configured with TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384. The handshake succeeds.
(3) The client is configured with TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256. The handshake fails. The error message "no suitable signature algorithm" is displayed.
Root cause:
The server selects the cipher suite first and does not pay attention to the cipher suite set by psk_find_session_cb(). Therefore, TLS_AES_256_GCM_SHA384 is selected, but the hash algorithm is SHA384, so tls_parse_ctos_psk() fails.
Question:
Is there any way to make use case (3) successful?

Yeah, TLS 1.3 external PSKs weren't quite designed right and aren't really suitable for a public API. PSK importers were designed to fix this, but that may be challenging given OpenSSL already exposed the unsuitable version via the PSK callback.
https://www.rfc-editor.org/rfc/rfc9258.html

Closing since this is marked as resolved.


Group names are not recognized by sss

I am not sure if this is an issue with my specific setup, but sssd version 2.9.1 and following sssd configuration does not recognize the group names:
[domain/WALDUR]
cache_credentials = False
enumerate = True
id_provider = ldap
auth_provider = ldap
access_provider = ldap
ldap_uri = ldap://#####:3893
ldap_search_base = dc=glauth,dc=com
ldap_default_bind_dn = cn=admin,dc=glauth,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = #####
ldap_use_tokengroups = False
sudo_provider = none
ldap_group_member = member
ldap_schema = rfc2307bis
ldap_access_order = filter
ldap_access_filter = (memberOf=cn=*,dc=glauth,dc=com)
ldap_user_name = preferredUsername

I noticed that if I change groupformat to "cn" in the preconfig.cfg.template, then sss manages to recognize group names without providing custom ldap_group_search_base in the sssd.conf.
https://github.com/waldur/glauth/blob/8f19f297527cf026fdf88da36058a5bd69fb6b39/systemd-conf/refresher/preconfig.cfg.template#L38
I was wondering how groups are configured on other setups and whether groupformat = "cn" should become the default configuration, given that sssd recognizes that by default.

Hi, yes, this is a thing we noticed and indeed it depends on the sssd version.
We generally speaking tried to adjust minimally wrt to upstream - https://github.com/glauth/glauth - but I think that changing to cn as a default can indeed make sense as almost 100% of deployments with Waldur are using SSSD.

Relates to glauth/glauth/issues/181.

Another issue we saw was the format of ldap_user_name in SSSD configuration.
ldap_user_name = preferredUsername vs ldap_user_name = preferred_username
Can you pls check which one is working for you?
Also, what if you use the following SSSD configuration:
[domain/WALDUR]
cache_credentials = True
enumerate = False
id_provider = ldap
auth_provider = ldap
access_provider = ldap
# ldap-server needs to resolve to the host where glauth is running
ldap_uri = ldap://ldap-server:3893
# configured glauth base
ldap_search_base = dc=glauth,dc=com
# configured glauth service user
ldap_default_bind_dn = cn=admin,dc=glauth,dc=com
ldap_default_authtok_type = password
# configured glauth service user password
ldap_default_authtok = mysecret
ldap_use_tokengroups = False
sudo_provider = none
ldap_group_member = member
ldap_schema = rfc2307bis
ldap_access_order = filter
ldap_access_filter = (memberOf=dc=glauth,dc=com)
ldap_user_name = preferredUsername


Zarf (helm) ignores strict schema decoding on deploy

Environment
Device and OS: macOS
App version: v0.34.0
Kubernetes distro being used: k3d
Steps to reproduce
Reproduction is using a k3s custom resource, so this should be reproducable on a k3d cluster easily.

Make a manifest for a k3s addon. Do not follow the schema. Example:apiVersion: k3s.cattle.io/v1
kind: Addon
metadata:
  name: test
  namespace: default
spec:
  noSchema: here

Attempt to kubectl apply the manifest. You will see an error like Error from server (BadRequest): error when creating "addon.yaml": Addon in version "v1" cannot be handled as a Addon: strict decoding error: unknown field "spec.noSchema".
Make a zarf package with this manifest, example:kind: ZarfPackageConfig
metadata:
  name: test
components:
  - name: test
    required: true
    manifests:
      - name: test
        files:
          - "addon.yaml"

Create and deploy this zarf package.

Expected result
Zarf package would fail to deploy with the same schema error.
Actual Result
Zarf package successfully deploys, resulting in a bad CR in cluster.
Visual Proof (screenshots, videos, text, etc)

Logs
❯ k apply -f addon.yaml
Error from server (BadRequest): error when creating "addon.yaml": Addon in version "v1" cannot be handled as a Addon: strict decoding error: unknown field "spec.noSchema"
❯ zarf p deploy build/zarf-package-test-amd64.tar.zst --confirm

 NOTE  Using config file /Users/mjnagel/defenseunicorns/uds-core/zarf-config.yaml

 NOTE  Saving log file to
       /var/folders/56/3lg0nwq57ld8_xv7cjm9zjgh0000gn/T/zarf-2024-05-24-13-58-03-1643861909.log
  •  Loading package from "build/zarf-package-test-amd64.tar.zst"
  •  Loading package from "build/zarf-package-test-amd64.tar.zst"
  •  Loading package from "build/zarf-package-test-amd64.tar.zst"

  📦 PACKAGE DEFINITION

kind: ZarfPackageConfig

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
metadata:  information about this package

  name: test
  architecture: amd64
  aggregateChecksum: 430e9fc32d337d679893f96627f20fe7109f448ad9fa4e24671486270b7c0d9f

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
build:  info about the machine, zarf version, and user that created this package

  terminal: hargrave.local
  user: mjnagel
  architecture: amd64
  timestamp: Fri, 24 May 2024 13:55:00 -0600
  version: v0.34.0
  migrations:
  - scripts-to-actions
  - pluralize-set-variable
  lastNonBreakingVersion: v0.27.0

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
components:  components selected for this operation

- name: test
  required: true
  manifests:
  - name: test
    files:
    - addon.yaml

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✔  Deploy Zarf package confirmed
  •  Waiting for cluster connection
  •  Waiting for cluster connection
  •  Gathering additional cluster information (if available)
  •  Gathering additional cluster information (if available)

  📦 TEST COMPONENT

  •  Loading the Zarf State from the Kubernetes cluster
  •  Loading the Zarf State from the Kubernetes cluster
  •  Starting helm chart generation test
  •  Starting helm chart generation test
  •  Processing helm chart raw-test-test-test:0.1.1716580683 from Zarf-generated helm chart
  •  Processing helm chart raw-test-test-test:0.1.1716580683 from Zarf-generated helm chart
  ✔  Zarf deployment complete
❯ k get addon test -o yaml
apiVersion: k3s.cattle.io/v1
kind: Addon
metadata:
  annotations:
    meta.helm.sh/release-name: zarf-5dd7fba6079f881e678be27187fc0f76aec9d1f8
    meta.helm.sh/release-namespace: default
  creationTimestamp: "2024-05-24T19:58:04Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
  name: test
  namespace: default
  resourceVersion: "9237"
  uid: 2f5ac0c1-562b-4af6-bdc1-a19abae204f5
spec: {}

Severity/Priority
This feels relatively important since it could lean to unknown states if operators are not built to handle non-schema adhering custom resources.
Additional Context
It appears that this may be an upstream helm issue, I was able to reproduce the same behavior just with a basic helm chart. See https://github.com/helm/helm/issues/12470 which seems to be tracking this problem. Unsure that it would make sense to do anything on the zarf side to handle this, but wanted to open the issue for tracking/discussion. Unsure if other projects like flux have encountered this issue and handled it or if everything is waiting on helm upstream.

After further reviewing the helm behavior this appears to be slightly less bad than originally expected - helm does enforce the schema for required fields/types but does not prohibit/restrict unknown fields from being added.

Updating to link a different upstream helm issue https://github.com/helm/helm/issues/13053


index page using image from about page, pulling other info too

I set  this at the top of content/english/about.md:
image: "https://storage.buzzsprout.com/variants/nft3jr170a2lo7sohle2b62ehzv4/f39677667998d4983b671c898b89f635827f90bc24d585ec289a8d3e04495b83.png"

Doing so breaks https://github.com/statichunt/iwriter-hugo/blob/adeab442cdd419459e711c8713451eb1e2b3fae7/layouts/partials/datasets/twitter-card.html#L3
Somehow, that section of code that sets og:image and the like is attempting to pull in the value of image from the about page and, because it is remote, it is not passing the fileExists test. What I feel is a bug is it pulling ANYTHING from the frontmatter of about.md.
Is this maybe because the template for index and a few other pages are not under themes/iWriter-hugo/layouts/_default/ like the templates for the about page?

On a related note, how come this theme doesn’t use the built in twitter card?
https://github.com/gohugoio/hugo/blob/master/tpl/tplimpl/embedded/templates/twitter_cards.html


Possibility to use inotify to trigger snapshots

NILFS2 is filesystem that by design creates snapshot after any data change, so it can be easily rolled back to any time without specificaly making snapshots at that time using cron... Is it possible to mimick such feature using inotify to watch file changes and make snapshots accordingly? Maybe not for every inotify event, but at least for some.

This won't be portable, AFAIK.

just use icrond to trigger zfssnap

This is outside the scope of the snapshot functionality. The inotify would be the monitor to trigger a snapshot. Since zfsnap would be the one called it is outside this software scope to add filesystem monitoring too.

The inotify would be the monitor to trigger a snapshot. Since zfsnap would be the one called

Not really. inotify is OS API that zfsnap can poll for filesystem changes.


Using CodeSandbox (Containers) to make it possible to live collaborate on decks

Hi!
I think mdx-deck is super great! 🤗 When reading the announcement of CodeSandbox Containers, I thought that it would be ideal to be able to run mdx-deck in a CodeSandbox, so multiple people could edit the deck live with each other. If possible, I would suggest that we link to an mdx-deck CodeSandbox template, that people can start work from.
(CodeSandbox Containers makes it possible to run any nodejs scripts in CodeSandbox, not just predertimed templates)
I tried giving it a go here:

But as you can see, it doesn't quite work (at least as of 30/09/18, all it shows is an nginx error). I tried to use mdx-deck --port 8000 --no-open deck.mdx to mimic the behavior of other templates that use port 8000 like Gatsby, but it didn't work.
If you think this has value to the community, I'll continue my endeavor in trying to make it work, I just wanted to hear your initial thoughts and comments first. 🙂
PS: This also has the added benefit of giving newcomers an easy entry into mdx-deck, as they don't have to install anything at all, they just have to fork the official mdx-deck sandbox.

Yeah, it should be possible for mdx-deck to work on CodeSandbox now. I have a sandbox running mdx-go (which is a similar setup) here: https://codesandbox.io/s/6jm07qw1yk
I had to go to the server control panel on the left (icon looks like three corns on the cob) and click Restart Sandbox to get it to work, if that's any help. Also started with the Next.js template as a base

Arh, maybe using the Next.js is the missing link, I'll give it a try. 🙂

Hey guys, Bogdan from CodeSandbox here!
Unfortunately 2. would be quite hard to implement - even if we'd manage to proxy the websocket port, too (which is on the list of upcoming features, but it has a pretty low priority right now - so proxy the main port to https://sandbox-id.sse.codesandbox.io and all subsequent opened ports to something like https://port.sandbox-id.sse.codesandbox.io), you would still have to be aware you're running in CodeSandbox and use the correct URL (instead of ws://localhost:port).
Another suggestion would be to:
4. Multiplex the websocket on the same port you're serving the deck - the same as, for example, webpack does with its HMR (hot module replacement) websocket.

I suspect the mdx-deck dev server could be updated to work more similarly to mdx-go (using connect and webpack middleware instead of koa), which I think would get around the issues you're seeing

@jxnblk Is this planned for version 2 ? It would be amazing

Thanks to @SaraVieira this now works!! :tada: https://mobile.twitter.com/NikkitaFTW/status/1113054141377662976

In case someone runs into the related problem of random websocket ports being assigned, and using a container such as Docker which only forwards explicit ports; the workaround (or hack) I ended up applying was:
Because mdx-deck uses random websocket ports, and we can not expose them on Docker, we need to override
mdx-deck/lib/dev.js , around line 18, with explicit hot ports (could be 1 port as well, but using 3 reduces the chance it accidentally is being used already):
  opts.hotPort = await getPort({port: [31230, 31231, 31232]})

and then forward them, along with your actual gatsby port - 8000 in this case - in docker run:
... -p 8000:8000 -p 31230:31230 -p 31231:31231 -p 31232:31232

We also need to update the default hostname to work with Docker:
in mdx-deck/cli.js, around line 91, set
  host: '<IP_ADDRESS>',


Allowed filter to be followed by relative path

As it's my first public pull request I'm open to feedback!

This followed from #33.

Thanks so much for your contribution! However, as I said, I won't be so easy to implement this feature if you just bypass the antlr syntax. Much more works required in refactoring jsurfer-core module. I just made some modification on your new test case, you can check how it fails.

Ah too bad, the new tests fail indeed. I already suspected it was too easy to be correct haha.
For me it's however not clear why a path after a filter doesn't work while it does work for  children ['<name>' (, '<name>')], indexes [<number> (, <number>)] or slices [start:end].
Also it's not clear for me where in the code I would have to change this (and how much work this would take).

I stepped through the code and I found it's indeed quite a big change to allow multiple filters or filters in the middle of a JSON path. The reason is that in your JsonPath implementation you only maintain a single JsonPathFilter that you apply at the end of the listener chain (i.e. you don't prune midway if the filter doesn't apply).
Now I am still unsure why you chose this implementation though.. but I will probably not change it anytime soon because it doesn't have too high priority for us and requires quite a bit more work considering I don't fully understand the code base yet.
But besides this I do like your implementation and it's clearly a piece of craftsmanship.

Thanks! Actually, This implementation was a workaround for the minimal use case of JsonPath filter, of course not perfect but it works and I did state this limitation in Readme.

I cracked at it for a few days. It seems to work now. See if you like it

Thanks so much for your hard work! It looks like a huge change. I need some time to investigate the impact. Will try to get back to you asap.

I hope you are managing to understand these changes. If not, shoot me your questions.

Sorry for the late reply. I just commited a new implementation which is revised from your code. Please check and see if any question.


Delete Garden + Gravestone Entrypoint and Garden Pages

Delete a garden or entrypoint
Things to think about:

Best practices for DOI when garden/entrypoint is deleted
redirects

https://support.datacite.org/docs/tombstone-pages

unblocked on backend. Not priority this week

Priority this week after Monday/Tuesday


Refactor the binding mechanism

The old binding mechanism was copying parameter values into predicates and changing plans in place. That was unclean software engineering and could introduce extra copies of parameters.
After this refactoring, Peloton is going to save parameters values in the per-connection cache, and pass that to the executor context for the evaluation in the execution.
Note: There're still two places where we're modifying the plan in-place right now: inserted tuples in the insert plan and index scan keys in in the index scan plan. We may also want to refactor those two places in the future.

Coverage decreased (-0.2%) to 52.919% when pulling fbb1310a1de4c38c17bf58f2849a62d130b8de63 on malin1993ml:binding-refactor into 375c913ea46e67f93ff2cfce044d35ab081b4487 on cmu-db:master.

@MattPerron Can you review this?


Generate Basins - D-Hydro - Determine A-H and V-H relations

Determine volume-water level relations for the Basins. Relationship between total volume and water levels within basin and water level representative outflow point:
1. Include all disposal in area: storage in calculation nodes and possible disposal nodes.
2. Also include storage in tertiary system? Modflow or possibly RR?
3. Practical point we ran into: What to do with the storage in the locations where you are just making the cut? Distribute evenly over the connected basins?
volume tool Deltares:
"c:\Program Files\Deltares\D-HYDRO Suite 2023.03 1D2D\plugins\DeltaShell.Dimr\kernels\x64\dflowfm\scripts\run_dfm_volume_tool.bat" --mdufile FlowFM.mdu --increment 0.1 --outputfile volume_curve.nc --output All

Check whether volume is becoming larger. Seems WiBo had some problems with their model


Problem changing 443 port on dnscrypt-server listening

I've find this solution on other issue.
docker run --name=dnscrypt-server -p 443:443/udp -p 443:443/tcp --net=host
jedisct1/dnscrypt-server init -N example.com -E <IP_ADDRESS>:443
to change the 443:443 to listen_port:443/udp listen_port:443/tcp
But this still have a problem here if I do change so. the service started up correctly, but the client reported Incorrect signature after startup.
Maybe the problem caused by -E <IP_ADDRESS>:443? Even if I change it to <IP_ADDRESS>:listen_port, it still have problem here.
Does any one have tested to run it on a server without 443 available?

Sorry, didn't noticed there are a repo for the server image.


'TypeError: Object.assign is not a function' in the packager

Just tried setting up a new project via react-native init today and I get this error in Xcode:
+ react-native bundle --entry-file index.ios.js --platform ios --dev true --bundle-output /Users/kriskelly/Library/Developer/Xcode/DerivedData/Autoscrolling-gbloxkveqsoptkfqzdjnuhpavcsm/Build/Products/Debug-iphonesimulator/Autoscrolling.app/main.jsbundle --assets-dest /Users/kriskelly/Library/Developer/Xcode/DerivedData/Autoscrolling-gbloxkveqsoptkfqzdjnuhpavcsm/Build/Products/Debug-iphonesimulator/Autoscrolling.app
bundle: Created ReactPackager
uncaught error Error: TypeError: Object.assign is not a function
    at transform (/Users/kriskelly/Projects/gtd-panic-react-native/react-native-drag-drop/examples/Autoscrolling/node_modules/react-native/packager/transformer.js:33:25)
    at module.exports (/Users/kriskelly/Projects/gtd-panic-react-native/react-native-drag-drop/examples/Autoscrolling/node_modules/react-native/packager/transformer.js:66:14)
    at handle (/Users/kriskelly/Projects/gtd-panic-react-native/react-native-drag-drop/examples/Autoscrolling/node_modules/react-native/node_modules/worker-farm/lib/child/index.js:41:8)
    at process.<anonymous> (/Users/kriskelly/Projects/gtd-panic-react-native/react-native-drag-drop/examples/Autoscrolling/node_modules/react-native/node_modules/worker-farm/lib/child/index.js:47:3)
    at emitTwo (events.js:87:13)
    at process.emit (events.js:169:7)
    at handleMessage (child_process.js:276:10)
TransformError: /Users/kriskelly/Projects/gtd-panic-react-native/react-native-drag-drop/examples/Autoscrolling/node_modules/react-native/packager/react-packager/src/Resolver/polyfills/prelude_dev.js: Object.assign is not a function
See logs /var/folders/p8/tsl3pzfn03zbd72b_c47tjvh0000gp/T/react-packager.log
    at SocketClient._handleMessage (SocketClient.js:139:23)
    at BunserBuf.<anonymous> (SocketClient.js:53:42)
    at emitOne (events.js:77:13)
    at BunserBuf.emit (events.js:166:7)
    at BunserBuf.process (/Users/kriskelly/Projects/gtd-panic-react-native/react-native-drag-drop/examples/Autoscrolling/node_modules/react-native/node_modules/bser/index.js:289:10)
    at /Users/kriskelly/Projects/gtd-panic-react-native/react-native-drag-drop/examples/Autoscrolling/node_modules/react-native/node_modules/bser/index.js:244:12
    at doNTCallback0 (node.js:415:9)
    at process._tickCallback (node.js:344:13)
Command /bin/sh failed with exit code 1

I think I've tracked the failure to this commit: 21bae9b294014d178b014cd53655da0ef13eab49, but not totally sure.

Ok false alarm, must have been a hiccup in the project initialization somewhere. Tried it again later on and it worked.

I just did the same, and got the same error. I'll try again, maybe an intermittent error?

I tried this a few times and eventually it just worked. I made some changes, one thing that may have triggered the fix was that I had a global install of babel. I removed that and it seemed to start working (although I haven't repeated it).  Just adding a note if anybody else hits this.

also hit this using iojs 2.x, went away after switching to node 4

+1 (got this error even after switching to node 4). any other idea?

@mhollweck Did you restart the packager after upgrading to Node 4?
Also could you just try and restart your system and see if that changes anything?

@mhollweck
I got the same issue yesterday!
Please try to check your Node Version ->
 tobiaslins$ node -v
 v2.0.2

I had an old version on it (2.0.2)
After upgrading to 5.2.0 everything was working!

The packager was warning me I was still using iojs. Running nvm alias default node fixed it because my node is 4.1.1.

+1, don't forget that the packager may run in a different terminal which is not wired to a specific node version.

@tlins is right !!
After upgrading to 5.2.0 everything was working!

had the same issue and my node was up-to-date, updating react-native-cli fixed it for me
npm install -g react-native-cli


Find a way to validate empty value (not null value)

If a user provides null value then after JSON decoded it will become default value.
For example: "" for string value.
We don't know whether the value is not provided or it's intended to be empty.

one way to solve this problem is to use a pointer.

The app is working properly now. We can change the filed using a pointer if we really need to set an empty value in the furture.


Am Facing an issue on my first sample app "Gradle task assembleDebug failed with exit code 1"

C:\src\test\test_app>flutter run -v
[  +30 ms] executing: [C:\src\flutter\] git -c log.showSignature=false log -n 1 --pretty=format:%H
[  +67 ms] Exit code 0 from: git -c log.showSignature=false log -n 1 --pretty=format:%H
[        ] 0b8abb4724aa590dd0f429683339b1e045a1594d
[        ] executing: [C:\src\flutter\] git describe --match v*.*.* --first-parent --long --tags
[  +45 ms] Exit code 0 from: git describe --match v*.*.* --first-parent --long --tags
[        ] v1.12.13+hotfix.8-0-g0b8abb472
[  +18 ms] executing: [C:\src\flutter\] git rev-parse --abbrev-ref --symbolic @{u}
[  +50 ms] Exit code 0 from: git rev-parse --abbrev-ref --symbolic @{u}
[        ] origin/stable
[        ] executing: [C:\src\flutter\] git ls-remote --get-url origin
[  +42 ms] Exit code 0 from: git ls-remote --get-url origin
[        ] https://github.com/flutter/flutter.git
[ +120 ms] executing: [C:\src\flutter\] git rev-parse --abbrev-ref HEAD
[  +55 ms] Exit code 0 from: git rev-parse --abbrev-ref HEAD
[        ] stable
[ +176 ms] executing: C:\src\android\platform-tools\adb.exe devices -l
[  +38 ms] Exit code 0 from: C:\src\android\platform-tools\adb.exe devices -l
[        ] List of devices attached
           emulator-5554          device product:sdk_google_phone_x86 model:Android_SDK_built_for_x86 device:generic_x86 transport_id:1
[  +36 ms] C:\src\android\platform-tools\adb.exe -s emulator-5554 shell getprop
[  +92 ms] Artifact Instance of 'AndroidMavenArtifacts' is not required, skipping update.
[  +12 ms] Artifact Instance of 'AndroidInternalBuildArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterWebSdk' is not required, skipping update.
[   +6 ms] Artifact Instance of 'WindowsEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[   +1 ms] Artifact Instance of 'LinuxFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerDebugSymbols' is not required, skipping update.
[ +263 ms] Generating C:\src\test\test_app\android\app\src\main\java\io\flutter\plugins\GeneratedPluginRegistrant.java
[  +47 ms] ro.hardware = ranchu
[  +74 ms] Using hardware rendering with device Android SDK built for x86. If you get graphics artifacts, consider enabling software rendering with "--enable-software-rendering".
[  +40 ms] Launching lib\main.dart on Android SDK built for x86 in debug mode...
[  +34 ms] executing: C:\src\android\platform-tools\adb.exe -s emulator-5554 shell -x logcat -v time -t 1
[  +80 ms] Exit code 0 from: C:\src\android\platform-tools\adb.exe -s emulator-5554 shell -x logcat -v time -t 1
[        ] --------- beginning of main
           02-25 07:49:40.473 I/SQLiteCastStore( 2202): [CastNetworkInfo] saved: 0, skipped: 0, [CastDeviceInfo]: saved 0, skipped 0, Paired Guest Mode DeviceInfo] saved: 0, skipped: 0.
[  +14 ms] executing: C:\src\android\platform-tools\adb.exe version
[   +8 ms] executing: C:\src\android\platform-tools\adb.exe -s emulator-5554 logcat -v time -T 02-25 07:49:40.473
[  +89 ms] Android Debug Bridge version 1.0.41
           Version 29.0.6-6198805
           Installed as C:\src\android\platform-tools\adb.exe
[   +5 ms] executing: C:\src\android\platform-tools\adb.exe start-server
[  +85 ms] Building APK
[  +44 ms] Running Gradle task 'assembleDebug'...
[   +4 ms] gradle.properties already sets `android.enableR8`
[   +9 ms] Using gradle from C:\src\test\test_app\android\gradlew.bat.
[  +24 ms] executing: C:\src\Android Studio\jre\bin\java -version
[ +280 ms] Exit code 0 from: C:\src\Android Studio\jre\bin\java -version
[        ] openjdk version "1.8.0_202-release"
           OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b03)
           OpenJDK 64-Bit Server VM (build 25.202-b03, mixed mode)
[   +6 ms] executing: [C:\src\test\test_app\android\] C:\src\test\test_app\android\gradlew.bat -Pverbose=true -Ptarget=C:\src\test\test_app\lib\main.dart -Ptrack-widget-creation=true -Pfilesystem-scheme=org-dartlang-root -Ptarget-platform=android-x86 assembleDebug
[+4466 ms] > Task :app:compileFlutterBuildDebug
[   +1 ms] [  +38 ms] executing: [C:\src\flutter\] git -c log.showSignature=false log -n 1 --pretty=format:%H
[   +1 ms] [  +77 ms] Exit code 0 from: git -c log.showSignature=false log -n 1 --pretty=format:%H
[   +1 ms] [        ] 0b8abb4724aa590dd0f429683339b1e045a1594d
[   +1 ms] [        ] executing: [C:\src\flutter\] git describe --match v*.*.* --first-parent --long --tags
[   +1 ms] [  +48 ms] Exit code 0 from: git describe --match v*.*.* --first-parent --long --tags
[        ] [        ] v1.12.13+hotfix.8-0-g0b8abb472
[   +1 ms] [  +14 ms] executing: [C:\src\flutter\] git rev-parse --abbrev-ref --symbolic @{u}
[   +1 ms] [  +45 ms] Exit code 0 from: git rev-parse --abbrev-ref --symbolic @{u}
[        ] [        ] origin/stable
[        ] [        ] executing: [C:\src\flutter\] git ls-remote --get-url origin
[        ] [  +38 ms] Exit code 0 from: git ls-remote --get-url origin
[   +1 ms] [        ] https://github.com/flutter/flutter.git
[        ] [  +85 ms] executing: [C:\src\flutter\] git rev-parse --abbrev-ref HEAD
[   +1 ms] [  +41 ms] Exit code 0 from: git rev-parse --abbrev-ref HEAD
[        ] [        ] stable
[   +1 ms] [  +27 ms] Artifact Instance of 'AndroidMavenArtifacts' is not required, skipping update.
[   +1 ms] [        ] Artifact Instance of 'AndroidGenSnapshotArtifacts' is not required, skipping update.
[   +1 ms] [        ] Artifact Instance of 'AndroidInternalBuildArtifacts' is not required, skipping update.
[   +1 ms] [        ] Artifact Instance of 'IOSEngineArtifacts' is not required, skipping update.
[   +1 ms] [        ] Artifact Instance of 'FlutterWebSdk' is not required, skipping update.
[   +1 ms] [   +5 ms] Artifact Instance of 'WindowsEngineArtifacts' is not required, skipping update.
[   +1 ms] [        ] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[   +1 ms] [        ] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[   +1 ms] [        ] Artifact Instance of 'LinuxFuchsiaSDKArtifacts' is not required, skipping update.
[        ] [        ] Artifact Instance of 'MacOSFuchsiaSDKArtifacts' is not required, skipping update.
[   +1 ms] [        ] Artifact Instance of 'FlutterRunnerSDKArtifacts' is not required, skipping update.
[   +1 ms] [        ] Artifact Instance of 'FlutterRunnerDebugSymbols' is not required, skipping update.
[  +12 ms] [ +119 ms] Initializing file store
[   +1 ms] [  +21 ms] Done initializing file store
[+1337 ms] [+1556 ms] Skipping target: kernel_snapshot
[ +100 ms] [  +66 ms] debug_android_application: Starting due to {InvalidatedReason.outputMissing}
[ +200 ms] [ +187 ms] debug_android_application: Complete
[   +1 ms] [  +20 ms] Persisting file store
[   +1 ms] [  +18 ms] Done persisting file store
[   +1 ms] [   +4 ms] build succeeded.
[        ] [  +23 ms] "flutter assemble" took 2,092ms.
[ +105 ms] > Task :app:packLibsflutterBuildDebug UP-TO-DATE
[   +1 ms] > Task :app:preBuild UP-TO-DATE
[   +1 ms] > Task :app:preDebugBuild UP-TO-DATE
[   +2 ms] > Task :app:compileDebugAidl NO-SOURCE
[  +90 ms] > Task :app:checkDebugManifest UP-TO-DATE
[   +1 ms] > Task :app:compileDebugRenderscript NO-SOURCE
[   +2 ms] > Task :app:generateDebugBuildConfig UP-TO-DATE
[   +2 ms] > Task :app:cleanMergeDebugAssets
[  +87 ms] > Task :app:mergeDebugShaders UP-TO-DATE
[   +1 ms] > Task :app:compileDebugShaders UP-TO-DATE
[   +1 ms] > Task :app:generateDebugAssets UP-TO-DATE
[        ] > Task :app:mergeDebugAssets
[ +300 ms] > Task :app:copyFlutterAssetsDebug
[   +3 ms] > Task :app:mainApkListPersistenceDebug UP-TO-DATE
[  +92 ms] > Task :app:generateDebugResValues UP-TO-DATE
[   +2 ms] > Task :app:generateDebugResources UP-TO-DATE
[   +1 ms] > Task :app:mergeDebugResources UP-TO-DATE
[        ] > Task :app:createDebugCompatibleScreenManifests UP-TO-DATE
[  +94 ms] > Task :app:processDebugManifest UP-TO-DATE
[ +300 ms] > Task :app:processDebugResources FAILED
[   +4 ms] FAILURE: Build failed with an exception.
[   +2 ms] * What went wrong:
[        ] Execution failed for task ':app:processDebugResources'.
[        ] > A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
[        ]    > Android resource linking failed
[   +1 ms]      C:\Users\USER\.gradle\caches\transforms-2\files-2.1\0a271e99b6771ad4a84318244d532fb7\core-1.0.0\res\values\values.xml:57:5-88:25: AAPT: error: resource android:attr/fontVariationSettings not found.
[   +1 ms]      C:\Users\USER\.gradle\caches\transforms-2\files-2.1\0a271e99b6771ad4a84318244d532fb7\core-1.0.0\res\values\values.xml:57:5-88:25: AAPT: error: resource android:attr/ttcIndex not found.
[   +1 ms] * Try:
[        ] Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
[        ] * Get more help at https://help.gradle.org
[        ] BUILD FAILED in 6s
[   +1 ms] 15 actionable tasks: 5 executed, 10 up-to-date
[ +455 ms] Running Gradle task 'assembleDebug'... (completed in 8.0s)
[  +10 ms] "flutter run" took 9,281ms.
Gradle task assembleDebug failed with exit code 1

#0      throwToolExit (package:flutter_tools/src/base/common.dart:28:3)
#1      buildGradleApp (package:flutter_tools/src/android/gradle.dart:431:7)
#2      _asyncThenWrapperHelper.<anonymous closure> (dart:async-patch/async_patch.dart:73:64)
#3      _rootRunUnary (dart:async/zone.dart:1134:38)
#4      _CustomZone.runUnary (dart:async/zone.dart:1031:19)
#5      _FutureListener.handleValue (dart:async/future_impl.dart:139:18)
#6      Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:680:45)
#7      Future._propagateToListeners (dart:async/future_impl.dart:709:32)
#8      Future._completeWithValue (dart:async/future_impl.dart:524:5)
#9      Future._asyncComplete.<anonymous closure> (dart:async/future_impl.dart:554:7)
#10     _rootRun (dart:async/zone.dart:1126:13)
#11     _CustomZone.run (dart:async/zone.dart:1023:19)
#12     _CustomZone.runGuarded (dart:async/zone.dart:925:7)
#13     _CustomZone.bindCallbackGuarded.<anonymous closure> (dart:async/zone.dart:965:23)
#14     _microtaskLoop (dart:async/schedule_microtask.dart:43:21)
#15     _startMicrotaskLoop (dart:async/schedule_microtask.dart:52:5)
#16     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:118:13)
#17     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:175:5)

Steps to Reproduce

Run flutter create bug.
Update the files as follows: ...
...

Expected results:
Actual results:

Logs

Your gradle cache appears to have become corrupted.  You can try removing it and trying the command again (e.g. delete C:\Users\USER\.gradle).


Trader-Joe Avalanche: Indexing Error

https://okgraph.xyz/?q=messari%2Ftrader-joe-avalanche
A determinstic fatal error occured at block 37459552: transaction 888159bb5e755ca5ae5a12c460c9e24693af9b23b6ec2875367190cf4629e1b8: attempted to divide BigInt `0` by zero wasm backtrace: 0: 0x4325 - <unknown>!~lib/@graphprotocol/graph-ts/common/numbers/BigInt#div 1: 0x7466 - <unknown>!protocols/trader-joe/src/common/handlers/handleRewardV2/updateMasterChef 2: 0x7969 - <unknown>!protocols/trader-joe/src/mappings/masterchef/rewardV2/handleEmergencyWithdraw in handler `handleEmergencyWithdraw` at block #37459552 (562f8c997c381981943987635dc842f1b2ebc4498fe12f7700d2265007e7ae87)

Will reopen this for now


Deleted comma and removed first person

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] All the files I changed are in the same world language (for example: only English changes, or only Chinese changes, etc.)
[x] My changes do not use shortened URLs or affiliate links.

Challenge: CSS Grid: Reduce Repetition Using the repeat Function
Support for the deletion of the comma:

I also decided to replace the first person part of a sentence, because of the style guide for curriculum challenges.

Try to avoid using the first person ("I", "we", "let's", and "us").

LGTM too

Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 🎉


Update Marked Version

#97: Update Marked Version

Pull request checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been reviewed and added / updated if needed (for bug fixes / features)
[x] Build was run locally and any changes were pushed
[x] Lint has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[x] Other (please describe): dependency vulnerability

What is the current behavior?

Issue Number: #97
What is the new behavior?

Updated dependency version

Does this introduce a breaking change?

[ ] Yes
[x] No

Other information

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
664

Relevant Lines:
664

💛  - Coveralls


Fix bug updating images version > 1

Description
Fix bug updating images version > 1
Fixes #THEEDGE-1481
Type of change
What is it?

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update
[ ] Refactor

Checklist:

[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I run go fmt ./... to check that my code is properly formatted
[x] I run go vet ./... to check that my code is free of common Go style mistakes

Codecov Report

Merging #509 (0dff812) into main (dd4dd2c) will increase coverage by 0.06%.
The diff coverage is 22.85%.

@@            Coverage Diff             @@
##             main     #509      +/-   ##
==========================================
+ Coverage   31.21%   31.28%   +0.06%
==========================================
  Files          33       33
  Lines        3232     3235       +3
==========================================
+ Hits         1009     1012       +3
  Misses       2126     2126
  Partials       97       97

Impacted Files
Coverage Δ

pkg/services/images.go
12.05% <15.62%> (+0.11%)
:arrow_up:

pkg/routes/images.go
28.32% <100.00%> (ø)

pkg/services/services.go
100.00% <100.00%> (+100.00%)
:arrow_up:

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 dd4dd2c...0dff812. Read the comment docs.


Unknown option --barcodeCnt

Hi,
I'm using the latest trust4 for single cell data. THis is my running command
run-trust4 -b possorted_genome_bam.bam -o S7 -t 11 --ref /data1/software/TRUST4/human_IMGT+C.fa -f /data1/software/TRUST4/hg38_bcrtcr.fa --barcode CB

and I get error message
[Wed Mar 11 11:33:50 2020] Start to annotate assemblies.
[Wed Mar 11 11:34:04 2020] Finish annotation.
[Wed Mar 11 11:34:05 2020] SYSTEM CALL: perl /data1/software/TRUST4/trust-simplerep.pl S7_cdr3.out  --barcodeCnt --noPartial > S7_report.tsv
Unknown option --barcodeCnt
system perl /data1/software/TRUST4/trust-simplerep.pl S7_cdr3.out  --barcodeCnt --noPartial > S7_report.tsv failed: 65280 at /data1/software/TRUST4/run-trust4 line 37.

Woops. sorry it seems I forgot to update the trust-simplerep script. Can you pull it again and you can add the option --stage 3 to just run the last stage. Thanks.

Thanks for the update!


Prevent secrets from sending in email

Add a method that will check the content of the email before sending, to make sure that specific strings or patterns are not included.
For example, SG API keys look like this: SG.[a-zA-Z0-9_].[a-zA-Z0-9-]
So the function could take a list of regex or specific strings to compare against. If a string is found, the mail/send should throw an exception

Do you mean that if some content of the email match the SG API Key, the method should throw an exception? Is there any other condition?

Hi @thepriefy,
The string that causes the exception to be thrown should be configurable.
Thanks!
With Best Regards,
Elmer

So an array of regular expressions and if any matches throw an exception? I'll do this issue.
Should it be configurable?

Hi, is something like this is enough?
    public function checkAgainst($patterns){
        foreach ($this->contents as $content) {
            /* @var Content $content */
            if(is_array($patterns)){
                foreach ($patterns as $pattern) {
                    if(preg_match("/".$pattern."/", $content->getValue())){
                        throw new \Exception("Mail content contains secret");
                    }
                }
            }else{
                if(preg_match("/".$patterns."/", $content->getValue())){
                    throw new \Exception("Mail content contains secret");
                }
            }
        }
    }

Since there has been no activity on this issue since March 1, 2020, we are closing this issue. Please feel free to reopen or create a new issue if you still require assistance. Thank you!


On x86, misalligned SSE accesses can occur when multithreading is enabled

Describe the bug
The dummy_thread variable in z_cstart is not always aligned to 16 bytes, e.g. when CONFIG_DEBUG_OPTIMIZATIONS=y is set.
This leads to exceptions when performing fxsave while swapping it out in swap.S.
To Reproduce

to ./samples/userspace/shared_mem/proj.conf, add following configurations:
CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_FPU=y
CONFIG_SSE=y
mkdir build; cd build
cmake -DBOARD=qemu_x86 ./samples/userspace/shared_mem ./build
cmake --build build --target all
cmake --build build --target run
protection fault occurs during swap

Expected behavior
Swapping out the dummy thread should not produce a protection fault regardless of the configuration.
Impact
This issues makes it impossible to use the debug configuration for userspace applications when newlib is enabled, since it requires SSE.
SeaBIOS (version rel-1.12.1-0-ga5cab58-dirty-20200214_052440-f7294c49af13-zephyr
)
Booting from ROM..Optimal CONFIG_X86_MMU_PAGE_POOL_PAGES 11
E: General protection fault (code 0x0)
E: EAX: 0x00125da0, EBX: 0x00009500, ECX: 0x00125b83, EDX: 0x0014b56c
E: ESI: 0x00000000, EDI: 0x00126020, EBP: 0x00000000, ESP: 0x0014b534
E: EFLAGS: 0x00000006 CS: 0x0008 CR3: 0x00125b00
E: call trace:
E: EIP: 0x00100348
E: NULL base ptr
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Current thread: 0x0014b56c (unknown)
E: Halting system

Environment:

OS: Ubuntu 19.10
Zephyr SDK 0.11.2
Zephyr 2.2.0 at least until 4008960afc05e1ca25973ebc585a9d63c10b9f14

Additional context
This might be an issue in x86_64-zephyr-elf-gcc in the SDK not aligning the struct to 16 byte on the stack. Since the contained tFpRegSetEx struct has the correct alignment attribute, my understanding is that this should not happen.
Making the dummy_thread variable static produces correct alignment.

Related issue: https://github.com/zephyrproject-rtos/zephyr/issues/17893

@nashif and @andrewboie could this be closed as a duplicate of #17893?

@carlescufi no we should leave this open, this is a statically defined object and it should be possible to set it up with the proper alignment, I'm surprised it isn't already.

We have a dummy_thread created on the interrupt stack in z_cstart(). It appears that at runtime, this is misaligned, for example with this crash:
E: General protection fault (code 0x0)
E: EAX: 0x00125da0, EBX: 0x0014b56c, ECX: 0x00125b83, EDX: 0x0014b56c
E: ESI: 0x00000000, EDI: 0x00126020, EBP: 0x00000000, ESP: 0x0014b534
E: EFLAGS: 0x00000006 CS: 0x0008 CR3: 0x00125b00
E: call trace:
E: EIP: 0x00100348
E: NULL base ptr
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Current thread: 0x0014b56c (unknown)
E: Halting system

In this case, the dummy thread object is at 0x14b55c which is not 16-byte aligned. The specified 16-byte alignment for thread->arch on x86 is being ignored here.
Two options to fix this:

Move dummy_thread to a static toplevel declaration, which we know will be aligned properly. However this memory can never be reclaimed.
Move x86's fxsave memory into a reserved region of the stack object. I like this better because it also fixes #17893 at the same time.

I'm going to pursue the second option first.

@andrewboie thanks for the preliminary investigation.
Could we then close #17893 as a duplicate of this one? That one is a low priority bug. If you decide not to close it, should this one be low too?

@carlescufi this is more serious, I'm working on it now for 2.3

Option 2 isn't working out. I posted some details in #17893.
Since this is just x86 I am looking at option 3 now.


Security: Enable users to reset the API key

As a consequence of #16, my codium API key has now been published and therefore compromised, so I would like / should reset the key.
However, at https://www.codeium.com/profile, I do not see any setting that allows me to reset my API key.
Since the usage of the codium does not incur any costs, potential abuse of the API key does not have direct drawbacks for me, this is somewhat mitigated. so I can live with the fact that my API key is leaked for the time being – but it should nonetheless be very much in the interest of codium that I (and other affected users) are able reset their API keys.

This is probably an issue for codium in general and not the codium (n)vim plugin, but I could not find a GitHub repo for the service in general, therefore reporting it here. Will open an issue at the respective repo, if you can direct me to it

We may want to add issues to github but for now we are using Discord to discuss generall issues with the product. I've gone ahead and reset your API key (which will require a relogin to now use).

I've closed this since we don't want to build this generic feature but can do it one off.


Fix forge.sh to just work when doing a manual linux install (#105)

This PR

Adds mono to forge.sh to run Forge.exe
Makes forge.sh executable

This improves the "out of the box" experience as forge now "just works" after softlinking forge.sh into the $PATH.

Thanks a lot!


Merge Trove hackathon

Motivation
The goal is to merge the modules created during the trove-hackathon into main.
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
TBA, doesn't build correctly yet, will review with team

I've gone ahead and tried my best to resolve conflicts however there are some issues with building which I assume is due to the fact that some conflicts were not resolved correctly. Ultimately I will need to go commit by commit with everyone who made changes to make sure the correct code is changed.

We can close this, I don't think we'll merge all these changes in since most of them are in now.


Why does VSCode reopen windows the way it wants and not the way they were the last time I closed it?

I cannot find an answer/solution to this issue.
Every time I reopen VS Code after a work session (or after turning the PC off and on again) the windows that open at the same time (because they were open at the same time before I closed VSCode) are sometimes full screen, other times they are reduced to the center of the screen, but this doesn't seem to have a precise pattern and above all I can't find settings that allow me to always open them all maximized (as they were when I closed VSCode last time).
How can this be solved?

The same to me...

Yeah, this feature is requested every now and then...
https://github.com/microsoft/vscode/issues/146915
Quite some time after the it is requested, it becomes a backlog candidate, and the community has 2 months to upvote the request so it actually enters the backlog.
Problem is, after so long, people often forget and the feature does not actually enter the backlog.
The above link has so far received 14 or 18 upvotes (depends on if the vscode team considers the rockets upvotes too)
If you are interested, upvote the request and if we are lucky it will enter the backlog and then some day it will be implemented by the team

Are there steps to reproduce and are virtual desktops involved?

No steps to reproduce. As I said is random (at least I don't understand the exact reason).
I'm not using virtual desktops.
I'm on Win 10 latest.

It is possible that when you leave VS Code running and shutdown Windows, we do not get enough time to persist the window state. We only store window state when VS Code exits normally, but a Windows shutdown to my knowledge only gives some time for the application to quit and then terminates it forcefully.

Ok that is good, that should store the window state properly. Does it reproduce even when you then restart VS Code without restarting Windows?

Btw if you want fullscreen windows to restore, you need to configure: window.restoreFullscreen: true in settings.

Does it reproduce even when you then restart VS Code without restarting Windows?

Sometimes.

Btw if you want fullscreen windows to restore, you need to configure: window.restoreFullscreen: true in settings.

I'll try and I'll let you know.

👍

I'm closing this to reduce pending issues. I'll reopen if that solution doesn't work.

Unfortunately the issue is still there with window.restoreFullscreen: true in settings.

Version: 1.74.2 (user setup)
Commit: e8a3071ea4344d9d48ef8a4df2c097372b0c5161
Date: 2022-12-20T10:29:14.590Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19045
Sandboxed: No

Ok. Maybe I have an hint.
Maybe, I repeat maybe, it happens to the windows that I minimize during work. And then by closing all VSCode from File > Exit those windows remained minimized as opposed to the maximized ones which reopen as such.
The minimized ones, on the other hand, reopen in the middle center of the monitor, reduced in their size, instead of full screen.

Yeah quite possible we get the wrong size values back in that case and fallback to default window bounds.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!

@VSCodeTriageBot you're dumb! Please re-open.

@bpasero


Wunderground: Entity id already exists: sensor.pws_temp_f

Home Assistant release (hass --version):
0.64.3
Python release (python3 --version):
3.5.3
Component/platform:
Wunderground
Description of problem:
Unable to have multiple weather stations defined.
Expected:
This did work.  Multiple weather stations should be handled without issue.
Problem-relevant configuration.yaml entries and steps to reproduce:
- platform: wunderground
  api_key: !secret wunderground_api_key
  pws_id: !secret home_weather_station
  monitored_conditions:
  - weather
  - temp_f
  - station_id
  - feelslike_f
  - heat_index_f
  - dewpoint_f
  - wind_mph
  - UV
  - pressure_in
  - wind_dir
  - relative_humidity
  - precip_today_in
  - alerts

- platform: wunderground
  api_key: !secret wunderground_api_key
  pws_id: !secret brian_weather_station
  monitored_conditions:
  - weather
  - temp_f
  - station_id
  - feelslike_f
  - heat_index_f
  - dewpoint_f
  - wind_mph
  - UV
  - pressure_in
  - wind_dir
  - relative_humidity
  - precip_today_in
  - alerts

Traceback (if applicable):
2018-03-02 17:38:05 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
    result = coro.send(None)
  File "/usr/local/lib/python3.5/dist-packages/homeassistant/helpers/entity_platform.py", line 260, in _async_add_entity
    msg)
homeassistant.exceptions.HomeAssistantError: Entity id already exists: sensor.pws_feelslike_f
2018-03-02 17:38:05 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
    result = coro.send(None)
  File "/usr/local/lib/python3.5/dist-packages/homeassistant/helpers/entity_platform.py", line 260, in _async_add_entity
    msg)
homeassistant.exceptions.HomeAssistantError: Entity id already exists: sensor.pws_relative_humidity
2018-03-02 17:38:05 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
    result = coro.send(None)
  File "/usr/local/lib/python3.5/dist-packages/homeassistant/helpers/entity_platform.py", line 260, in _async_add_entity
    msg)
homeassistant.exceptions.HomeAssistantError: Entity id already exists: sensor.pws_temp_f

Additional info:
This worked at one time.  My config (for this part) hasn't changed so not sure what happened.  Not 100% when it stopped working as the second weather station I was monitoring was offline until a few days ago.

Probably due to #12346. @ devs shouldn't async_generate_entity_id handle duplicate entity IDs for us? Or is it somehow due to us generating the id before getting added to hass? See https://github.com/home-assistant/home-assistant/blob/99eeb0152536dfc43ee9e775605bb543456e56ad/homeassistant/util/init.py#L73 (should append _2 after the id...)

I have the same issue.

@OttoWinter yes, since we generate the entity_ids before any device is added, hass doesn't know about the devices or their entity_ids. In this case the platform has to remember the IDs it has used on its own.

Any update?

Thank you!


Proper naming of k8s resources that get created with user sessions

This is an issue that we have with our current setup and we could potentially have with amalthea.
We should have a uniform and fool proof way of naming all the k8s resources that get created for a user session.
The requirements are:

should include some kind of hash from the username, gitlab namespace, gitlab projects, gitlab commits, gitlab branches
should be meaningful so that an admin can see the k8s resource and get some information (ideally which user it belongs to) rather than having to dig through the manifest
should be used for all k8s resources that belong to a user
should account for long usernames, project names, etc so that k8s is happy with the character limit for a resource name
avoid ambiguity in the hash by using some kind of separator character between all the things that are hashed

Questions:

What human readable parts do we include in the name - I think username and project should be enough
How many characters of the hash should be used
Do we want to include additional snippets to the resources names (i.e. like -pod, -pvc)? I was never a fan of this because it is not that easy to get a list of pods and pvc with the same k8s command. So I think we can remove these parts - the k8s commands always refer to one resource type so it is clear whether you are looking at pvcs, pods, etc.
Do want to include a git provider part in the has to account for future possible expansion to not only use gitlab?

Suggestion:
Hash the following string (including new line as separator):
safe-username
gitlab namespace (include full path here if using groups - use the same version that appears in the url)
gitlab project name (not human readable but the one that appears in the url path)
commit sha
branch

Then use the following to name the resource:
f"{safe_username[:10]}-{project_name[:10]}-{hash[:20]}"

Adressed with rolling out amalthea. Will reopen if needed.


Error in running command documentation?

I can't run the program using " anadi " in my terminal...but "./anadi.sh"  works perfectly ....could change the documentation if it also works for everyone else?

The script anadi.sh should be copied in xxx/bin as anadi by "install.sh", of there Is a problem on the copy we need to resolve It.

Hey @Cereal84, I have created a pull request correcting this issue.

The problem is the copy in install.sh,.we don't need an alias


djxl PNG Conversion Acting Up

Describe the bug
When converting a particular JXL image to PNG, the PNG has noticeable color issues with patches of discoloration.
To Reproduce
Download this
djxl theimage.jxl out.png
Compare the png to the JXL.
Expected behavior
The PNG would be visually identical to the JXL, or at least close enough where I wouldn't see obvious discoloration or where the PNG is earning horrible ssimu2 scores.
Screenshots
If applicable, add screenshots or example input/output images to help explain your problem.
Environment

OS: Linux
Compiler version: gcc (GCC) 12.2.1 20230201
CPU type: x86_64
cjxl/djxl version string: djxl v0.9.0 13caf6f8 [AVX2,SSE4,SSSE3,SSE2]

Additional context
The problem persists with other versions of cjxl/djxl when using the source PNG (which is almost 100mb).

Notably, the JXL file has an attached ICC profile and is XYB encoded. djxl is outputting a PNG in Linear Light rather than in sRGB.

If you want the source PNG, let me know

It is the fact that djxl uses RGB_D65_SRG_Rel_Lin profile there.
If the JXL and decoded PNG look significantly visually different, that's a problem of non-implemented (or not working) color management support of the viewer application.
The functionality of djxl is not technically wrong.
Color profile used to decode can be changed:
djxl --color_space=RGB_D65_SRG_Rel_SRG imagetest15-Q70.jxl out2.png

When inputting the weird PNG into ssimulacra2, it doesn't understand it & gives it a terrible score

Did you try the "keep original" color space option when exporting from darktable? The JPEG XL file will be considerably larger, but it'll preserve the profile. Otherwise, it discards it when encoding and only decodes to linear RGB (unless you're doing lossless, i.e. quality 100 as well when you get out what you put in).

There are three things that would fix this, and I think we need to do all of them:

Make cjxl recognize Display P3 and use the Enum representation for it rather than a generic icc profile. This would help for compression, and it circumvents the djxl bug.
Make djxl default to writing a 16-bit png if the image is in xyb colorspace.
Make libjxl decode do full color management by default (make it a special build flag to build without dependency on external CMS).

There are three things that would fix this, and I think we need to do all of them:
2. Make djxl default to writing a 16-bit png if the image is in xyb colorspace.

I would disagree with always decoding XYB to 16-bit PNGs. I think it should only do this if there's an attached ICC profile and no enum values for it, or if the enum values suggest it should. If there's enum values tagged for an SDR gamut & transfer (e.g. sRGB) and the file is tagged as 8-bit, then I think djxl should output 8-bit PNGs.

If i have an 8-bit PNG as input which i encode with jxl , then decode again but then i don't get 8-bit again because ssimulacra2 generates minus values, then something else is not working well?

If writing to an integer format, we should also not use sRGB primaries as it could cause gamut clipping (or worse). Which primaries to use is not obvious but P3 and Rec. 2020 would probably both be safer choices. (Not perfect but we don’t need to have found “perfect” to implement an improvement.)
Today, I started writing some logic in that direction but haven’t gotten it to work yet. What I was going for was along the lines of:
If the color space is described by an ICC profile rather than enums, and no color space hint was provided on the command line, then request the output in a color space with:

white point: D65;
transfer function: linear if floating point output, otherwise sRGB;
primaries: sRGB (Rec. 709) if floating point output, otherwise P3 if 8-bit output or Rec. 2020 if 16-bit output;
rendering intent: relative.

Any thoughts on that?

Make cjxl recognize Display P3 and use the Enum representation for it rather than a generic icc profile. This would help for compression, and it circumvents the djxl bug.

Is that what the embedded profile is here? I’m surprised we don’t recognise it since it’s just RGB_D65_DCI_Rel_SRG.

It makes sense that we currently don’t recognize it as we make no attempt to recognize pure gamma curves.

Why not? It seems very doable if there's a curv tag rather than a gamma LUT.

It makes sense that we currently don’t recognize it as we make no attempt to recognize pure gamma curves.

Why not? It seems very doable if there's a curv tag rather than a gamma LUT. Adobe RGB can be represented with gamma TRC and custom primaries, so I feel like we should do that.

The best answer I can give to “why not” is pretty much “because we have not implemented it so far”, but I have just started giving this a try (#2341). I have it working with skcms, now I just need to implement the lcms2 version. (Or I suppose we could already merge the skcms part, but something makes me uneasy about not having feature parity between the two.)

#2341 has now been merged. It doesn’t solve the issue with this specific .jxl file, but at least, if the same source file is compressed to JPEG XL again, it should create a file without the issue.

I'm a beginner at this, sorry if this info isn't relevant.
One more image that decodes to something that does not look like the original, but a dark and dull looking PNG.
I used djxl v0.9.0 96d76a3 from: https://artifacts.lucaversari.it/libjxl/libjxl/2023-10-17T11%3A15%3A45Z_56949f8a9772c0139803c25e46bd8ccf8ef93f7e/
Sample image:

Found here: https://people.csail.mit.edu/ericchan/hdr/hdr-jxl.php
JXL: https://people.csail.mit.edu/ericchan/hdr/jxl_images/20140606_102418_IMGP0297.jxl
Reference JPEG image / how it should look, i think: https://people.csail.mit.edu/ericchan/hdr/jxl_images/20140606_102418_IMGP0297.jpg

Reference JPEG image:
Click to expand

First tried djxl in.jxl out.png --bits_per_sample=8 (with or without --bits_per_sample=8 made no visual difference), it created a dark and dull result.
Click to expand

Then opened original JXL in GIMP to look for metadata, it said Exif.Photo.ColorSpace: sRGB. Then tried djxl in.jxl out.png --color_space=RGB_D65_SRG_Per_SRG --bits_per_sample=8, it looked good compared to the reference JPG file, and how GIMP decodes the JXL.
Click to expand

I also tried jxlinfo in.jxl, it said nothing about sRGB:
JPEG XL file format container (ISO/IEC 18181-2)
JPEG XL image, 1638x2048, lossy, 16-bit RGB
Color space: RGB, D65, Rec.2100 primaries, PQ transfer function, rendering intent: Perceptual
Uncompressed Exif metadata: 818 bytes
Brotli-compressed XML  metadata: 5664 compressed bytes
unknown box: type: "hrgm" size: 147802
layer: full image size, name: "main"

Two images that v0.9.1 still have problems with.

Jungle HDR image

Found here: https://people.csail.mit.edu/ericchan/hdr/hdr-jxl.php
JXL file: https://people.csail.mit.edu/ericchan/hdr/jxl_images/20140606_102418_IMGP0297.jxl

Cat HDR image

Found here: https://github.com/d2phap/ImageGlass/issues/1677#issuecomment-1819045271
JXL file: https://github.com/gwy15/hdr/blob/main/IMG01623-HDR.jxl

Both djxl input.jxl output.png and djxl input.jxl output.png --bits_per_sample=8 results in an output with washed out colors.

Do note that this may be an error with the actual PNG viewer. djxl input.jxl output.png for the Jungle image results in a PNG file that has cICP tags setting the color space information. If your viewer doesn't cICP, then the image will look like this:

Likewise, the image on the right looks exactly like what you'd get if you interpret the BT2100/PQ png that was output as though it were sRGB.

Even then, we used to also generate a fallback ICC chunk. That we don’t anymore is a regression, apparently introduced by #2635. I’ll have a closer look next week.

PNG spec isn't clear what happens if you have both an sRGB chunk and an iCCP chunk. It recommends against it, but it doesn't forbid it

I think it does forbid it. But that doesn't mean it doesn't happen, or if various implementations deal with it consistently.

IMO fallback ICC profile is not needed in the sRGB case anyway.

Right, in the sRGB case, we didn’t, only in the cICP-but-not-sRGB case.

Do note that this may be an error with the actual PNG viewer. djxl input.jxl output.png for the Jungle image results in a PNG file that has cICP tags setting the color space information. If your viewer doesn't cICP, then the image will look like this:

Darktable is said to support cICP since 4.2.0: https://www.darktable.org/2022/12/darktable-4.2.0-released/
With Darktable v4.6.0, opening the PNG results in a very dark looking image:

I tried the latest versions of IrfanView, XnView MP, Windows Photos app, GIMP, Krita, ImageGlass, JPEGView. All view this image like the example you posted.
Do we have any example of a program that can properly view PNG with cICP?
It doesn't make sense to decode to some exotic output that no current image viewers and editors can view properly IMO.

With Darktable v4.6.0, opening the PNG results in a very dark looking image:

If this is a PQ or HLG transfer curve image, darktable does not do any tone mapping, and just pulls the image down so max stays at 1.0 (which makes an HDR image datk). Use the exposure module to push it back up.

Do we have any example of a program that can properly view PNG with cICP?

Chromium and FFmpeg both support cICP chunks.


Looking for additional maintainer(s)!

Hello all, we are searching for another maintainer or two for Pyzeebe! Please note our maintainer and reviewer expectations.
Please reply if you are interested :)

I've attempted to solve some issues but it seems no active maintainers are available and the original @JonatanMartens is revoked. May you suggest solution other then create another pyzeebe?

Hi @yuval9313. The only maintainer is @JonatanMartens (who still has Maintainer access, where are you seeing that it is revoked?)
I agree that I'd rather not fork pyzeebe, which is why we're looking for another Maintainer. Is that something you'd be able to take on?

Hi! I would like to be maintainer of pyzeebe. Problem is that my English is not very good, so I have some problems writing docs.

@dimastbk Hi Dmitriy! Glad to hear it, I'll give you Maintainer permissions now! 🚀
No worries about your English, we are a global community so we have many contributors where English isn't their first language. If you ever want a proofreader, feel free to tag me and I am happy to review! :)

@xomiamoore thanks!

@xomiamoore could you remove these actions from the branch ruleset?

unit-test (3.6)
unit-test (3.7)

Now supported python 3.8+

Hey @xomiamoore I could certainly try

@xomiamoore and could you see MR rules? Now review from @JonatanMartens is required (see #397).

@xomiamoore no, I can't merge #398

@xomiamoore Hi! Could you see https://github.com/camunda-community-hub/pyzeebe/pull/398#issuecomment-2113964308 ?

@dimastbk I saw you were able to merge it, did closing and reopening give you the right permissions?

@xomiamoore No, I made a hack: I added empty jobs for python3.6 and python3.7 to workflow, see https://github.com/camunda-community-hub/pyzeebe/pull/398/commits/e9bf785eeace61712b172ab78517bedcdad74a73. But we should remove this jobs from branch ruleset, because of EOL of these python versions were in 2021 and 2023.

@xomiamoore @JonatanMartens Hi! Can you add PYPI_TOKEN (https://github.com/camunda-community-hub/pyzeebe/blob/master/.github/workflows/publish.yml#L26) to environment variables? As I see on pypi, @JonatanMartens is owner of  https://pypi.org/project/pyzeebe/. I would like to create new prerelease https://github.com/camunda-community-hub/pyzeebe/releases

Hey @dimastbk @xomiamoore, I think Camunda should create a pypi organization. Let me know when it is set up and I will transfer pyzeebe to the organization.
The PYPI_TOKEN environment variable is a github secret, which I don't have access to change currently.

I would also like to add some maintainers to the read-the-docs. @xomiamoore let me know who I can add.

@JonatanMartens, I got this notice when I tried to sign up for a pipy org, so not sure how long it will take to get a Camunda organization. Until then, I can add you as an admin to the repo to add the token as a secret?

@dimastbk would you be interested in being added to the read-the-docs as a maintainer as well?

@xomiamoore yes, dima_st_bk

@xomiamoore feel free to add me as an admin, will add the token asap

@JonatanMartens done!

Added the token

@JonatanMartens Awesome, did you add @dimastbk to read-the-docs also?

@xomiamoore Yes

@JonatanMartens hi. Can you send invite again? I missed the link and it has expired.

Hello,
I am interessed, @xomiamoore could you link maintainer and reviewer expectations again the link is broken.

Hey @felicijus -- thanks for the heads up, it's here now: Maintainer and reviewer expectations
@dimastbk, @JonatanMartens, do you need another maintainer?

@xomiamoore Hi. Yes.

@JonatanMartens Hi. Can you send invite to RTD again? I missed the link and it has expired.


Picoclick C3 not recognized in Windows 11?

Do I need a driver for the picoclick to show up in PlatformIO win Windows11?
I have tried a variety of cables, the picoclick lights up but nothing shows up in platformio or in the device manager.

It's probably only the charge status LED which lights up. Do you have a suitable power supply connected to the battery port? A Lipo battery or something between 3.6V and 4.2V is perfect.
If you don't wanna use an external power supply, you have to short a soldering jumper on the device: https://makermoekoe.gitbook.io/picoclick-c3/hardware

Ah, sorry, I was not aware of this. Seems I made assumptions when I should have been rtfm. :)
I'll try again with a battery soldered to it. Thanks.


Moving libssh package from SPECS-EXTENDED to SPECS folder. Promoting …

…as dependency for package python-ssh-python.
Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/tools/cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[x] Ready to merge

Promoting libssh package to SPECS folder as dependency for python-ssh-python
Change Log

Moved package to SPECS folder.

Does this affect the toolchain?
NO
Associated issues

#xxxx

Links to CVEs

https://nvd.nist.gov/vuln/detail/CVE-YYYY-XXXX

Test Methodology

Local build

Understood. Changes done for promoting libssh to SPECS folder.
Build Dependency package PR's raised:
pam_wrapper:     https://github.com/microsoft/CBL-Mariner/pull/3429
socket_wrapper: https://github.com/microsoft/CBL-Mariner/pull/3428
uid_wrapper:      https://github.com/microsoft/CBL-Mariner/pull/3427
nss_wrapper:      https://github.com/microsoft/CBL-Mariner/pull/3430

Thank you for the update! I think we still need to lint the spec a bit more because I see that the Summary tag is not the first one anymore, which is standard after running the linter. I should have mentioned more details about linting the spec. Here's more details about how to configure the one we're using (just 3 short steps). That's also what the "Spec Linting" PR check is running. The linter might change a few things in the wrong way (that's why the PR check is not required btw.) but in general it's reliable and I'll help you out with anything that the linter might get wrong. We're still tweaking it a bit.

I have linted the specs following https://dev.azure.com/mariner-org/mariner/_wiki/wikis/mariner.wiki/125/Introduction-to-SPEC-Files?anchor=spec-linter
The changes have been verified via Buddy Build: https://dev.azure.com/mariner-org/mariner/_build/results?buildId=239719&view=results


Fix the link to the airbrake-js notifier

This fixes the link to the airbrake-js notifier and re-aligns the
paragraph.
PTAL @thompiler :)

Thanks @thompiler! Let's merge :D


[ISSUE #2868]Fix ORIGIN_MESSAGE_ID field not write into commitlog

Make sure set the target branch to develop
What is the purpose of the change
issue #2868
Brief changelog
refresh properties string  before write message into store.
Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Coverage decreased (-0.09%) to 52.323% when pulling 5095ba29ed47fe28f7c532819658587a140c8f06 on maixiaohai:fix_dlq_message_lack_field_ORIGIN_MESSAGE_ID into f2a5a747fbf248776340f4a99118d421de2a5310 on apache:develop.


Hyperlink updated

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

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

patterns-practices/guide/13-prism-library-5.0-for-wpf.md
:white_check_mark:Succeeded

patterns-practices/guide/7-composing-the-user-interface-using-the-prism-library-5.0-for-wpf.md
:white_check_mark:Succeeded

patterns-practices/guide/deploying-prism-in-silverlight-applications.md
:white_check_mark:Succeeded

patterns-practices/guide/download-and-setup-prism-library-5.0-for-wpf.md
:white_check_mark:Succeeded

patterns-practices/reference/bindablebase-onpropertychanged-method-mspp-mvvm.md
:white_check_mark:Succeeded

patterns-practices/reference/bindablebase-onpropertychanged-method-string-mspp-mvvm.md
:white_check_mark:Succeeded

patterns-practices/reference/clearchildviewsregionbehavior-getclearchildviews-method-mspp-regions-behaviors.md
:white_check_mark:Succeeded

patterns-practices/reference/clearchildviewsregionbehavior-onattach-method-mspp-regions-behaviors.md
:white_check_mark:Succeeded

patterns-practices/reference/defaultconfirmationwindow-class-mspp-interactivity-defaultpopupwindows.md
:white_check_mark:Succeeded

patterns-practices/reference/delegatecommand-t-fields-mspp-commands.md
:white_check_mark:Succeeded

patterns-practices/reference/eventaggregator-constructor-mspp-pubsubevents.md
:white_check_mark:Succeeded

patterns-practices/reference/eventaggregator-getevent-teventtype-method-mspp-pubsubevents.md
:white_check_mark:Succeeded

patterns-practices/reference/eventsubscription-tpayload-subscriptiontoken-property-mspp-pubsubevents.md
:white_check_mark:Succeeded

patterns-practices/reference/idelegatereference-properties-mspp-pubsubevents.md
:white_check_mark:Succeeded

patterns-practices/reference/ieventsubscription-getexecutionstrategy-method-mspp-pubsubevents.md
:white_check_mark:Succeeded

patterns-practices/reference/ieventsubscription-interface-mspp-pubsubevents.md
:white_check_mark:Succeeded

patterns-practices/reference/ieventsubscription-properties-mspp-pubsubevents.md
:white_check_mark:Succeeded

patterns-practices/reference/ieventsubscription-subscriptiontoken-property-mspp-pubsubevents.md
:white_check_mark:Succeeded

patterns-practices/reference/mefbootstrapper-methods-mspp-mefextensions.md
:white_check_mark:Succeeded

patterns-practices/reference/mefregionnavigationjournalentry-class-mspp-mefextensions-regions.md
:white_check_mark:Succeeded

patterns-practices/reference/modularityexception-class-mspp-modularity.md
:white_check_mark:Succeeded

patterns-practices/reference/modularityexception-constructor-string-mspp-modularity.md
:white_check_mark:Succeeded

patterns-practices/reference/modulecatalog-validatedependencies-method-mspp-modularity.md
:white_check_mark:Succeeded

patterns-practices/reference/modulenotfoundexception-events-mspp-modularity.md
:white_check_mark:Succeeded

patterns-practices/reference/navigationparameters-class-mspp-regions.md
:white_check_mark:Succeeded

patterns-practices/reference/popupwindowaction-getwindow-method-mspp-interactivity.md
:white_check_mark:Succeeded

patterns-practices/reference/popupwindowaction-preparecontentforwindow-method-mspp-interactivity.md
:white_check_mark:Succeeded

patterns-practices/reference/pubsubevent-tpayload-constructor-mspp-pubsubevents.md
:white_check_mark:Succeeded

patterns-practices/reference/subscriptiontoken-gethashcode-method-mspp-pubsubevents.md
:white_check_mark:Succeeded

patterns-practices/reference/unityregionnavigationcontentloader-class-mspp-unityextensions-regions.md
:white_check_mark:Succeeded

patterns-practices/reference/updateregionsexception-events-mspp-regions.md
:white_check_mark:Succeeded

patterns-practices/reference/weakeventhandlermanager-class-mspp-commands.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


npm pre-install script to check OS version

In the package.json, make it run a pre-install script that checks the OS version for a start. If darwin is not specified, do not run the build script.
For the future, we could do the other checks listed in CONTRIBUTING.md

This would be really, really nice. Right now I have a project where ios-sim is a dev-dependency, but developers on Linux can't even npm install the project now, because package.json's platform field is preventing NPM from considering it a successful installation. I think the timing of that decision is poor. Consider also that there may be people who want to install dependencies on Windows or Linux, and package the whole project, before using it on OSX.


Cluster Application Resource Mapping

This change adds an extension specification for a cluster-wide mapping of non-Podspec-able resource types acting as applications.

Wildcards for versions?

@arturdzm Can you please write up an example for RuntimeComponent?

@arthurdm Wildcard added and ready for review.

Example for RuntimeComponent
apiVersion: service.binding/v1alpha2
kind: ClusterApplicationResourceMapping
metadata:
 name:  app.stacks.runtimecomponent
spec:
  versions:
  - version: v1beta1
    env:
    - .spec.env
    - .spec.initContainers[*].env
    volumeMounts:
    - .spec.volumeMounts
    - .spec.initContainers[*].volumeMounts
    volumes: .spec.volumes

We do not have containers[] in the spec, but RuntimeComponent has spec.initContainers

@arturdzm should the sidecar containers be bindable as well? Something like:
  versions:
  - version: v1beta1
    env:
    - .spec.env
    - .spec.sidecarContainers[*].env
    - .spec.initContainers[*].env
    volumeMounts:
    - .spec.volumeMounts
    - .spec.sidecarContainers[*].volumeMounts
    - .spec.initContainers[*].volumeMounts
    volumes: .spec.volumes

@scothis Well, we no longer have any examples with a hard-coded version at all, nor do we have any that show the "fallback to wildcard" behavior where some versions can be specified but not all.  On the other hand, there are no in-the-wild examples of either of those, so trying to force them in seems like a mistake.


Greyhound stops responding

After upgrading Greyhound to be able to use the nativeBounds in queries we are now seeing issues where Greyhound will work for a period of time and then just stop responding.  The docker container is still there and running but Greyhound isn't doing anything.  Checking the logs of the container after it has been stopped and there is no error message.
If I kill the container and restart it, all is fine again for a period of time and then it stops.  This goes for PoTree as well as my own application.
To test for it being alive I have tried issuing an info command on a resource (I assume these are quite light weight? unless there is a server status type request I could make?) and the TCP-IP connection establishes but I get nothing back.
I don't have a timescale for this happening alas, it's quite intermittent that Greyhound is called on and so far we have not needed to monitor it for responsiveness.

I saw this a couple of times as well, and added some extra logging (as well as some unrelated enhancements) and haven't seen it since.  Can you try updating to the very latest Greyhound image which I've just pushed, and if you see this failure again, paste any error-like messages from the end of the server logs?

OK, have grabbed latest and restarted.  I doubt it will get much use over the weekend, but if I see any more lock ups etc I will paste errors etc here.  Thanks

Hi @connormanning Our Greyhound server stopped responding again after upgrading to the newer version.
I stopped the container with docker stop before starting up a fresh instance.  Checking output with docker logs shows no error messages, just the last few requests that it responded to.

I also just had the fresh restarted version die within 13 minutes of being started.. again, no error output just logs of last activity.

Sorry to keep bringing this up, have you made any progress with this yet? At the moment Greyhound is staying up for anything between 20 seconds and several hours, I have not yet seen any form of error message output.  Sometimes the problem occurs just after it has served data, some times it is when it is sweeping (from the output I can see).
Thanks

Have not seen this issue since your help, many thanks.


Nyc instrumenter considers " " a statement when found in a for loop

I've been moving my client side tests from istanbul to nyc and have noticed an issue in the way nyc classifies statements.  In the following statement for (var i = 0; i < env.count; i++) nyc considers the whitespace between = and 0 to also be a statement.
Link to bug demonstration repository
min reproduction
Run with npm test.
This will run nyc@latest and<EMAIL_ADDRESS>instrumentation on a test file and produce two files in the root directory, 'statementMap_nyc.txt' and 'statementMap_istanbul.txt'.  Each file will contain prettified statementMaps extracted from instrumented source files created under both nyc and istanbul.
There will be an entry in nyc's output that's not found in istanbuls, corresponding to some  whitespace in the for loop.
            2: {
                start: {
                    line: 11,
                    column: 17
                },
                end: {
                    line: 11,
                    column: 18
                }
            },

Expected Behavior
nyc considers for (var i = 0; i < env.count; i++) to be a statement, but not the whitespace between the = and the 0.
Observed Behavior
nyc considers the whitespace between the = and the 0 to be a statement.
Troubleshooting steps
None taken, I'd assume this should work out of the box.
Environment Information
  System:
    OS: macOS High Sierra 10.13.6
    CPU: (4) x64 Intel(R) Core(TM) i5-7600 CPU @ 3.50GHz
    Memory: 1.63 GB / 32.00 GB
  Binaries:
    Node: 8.15.0 - ~/.nvm/versions/node/v8.15.0/bin/node
    Yarn: 1.7.0 - /usr/local/bin/yarn
    npm: 6.9.0 - ~/.nvm/versions/node/v8.15.0/bin/npm
  npmPackages:
    istanbul: ^0.4.5 => 0.4.5
    nyc: ^14.1.1 => 14.1.1

istanbul-lib-instrument columns start from 0.  You can see this if you add a line-feed to your src/index.js:
'use strict';

(function(env) {
    // Nyc's instrumenter thinks that the space between '=' and '0' below is a statment
    for (var i =
0; i < env.count; i++)
    {
        console.log('Running ' + i + ' of ' + count + '.');
    }
})(this);

With this modified source you would see statement 2 start at column 0 and end at column 1.  This is reporting the assignment as a statement.  The actual bug I see this demo repo showing is that i < env.count is not seen as a branch and i++ is not seen as a statement.  Originally all statements inside the for were ignored, istanbuljs/istanbuljs#188 enabled instrumentation for the initialization of the loop.

Hi Corey, thanks for the background on this it makes a little more sense now.
I probably should have called this issue 'Instrumentation differences between nyc and istanbul, the old one'.  Anyway I think the crux of my problem now is that the var i = part of var i = 0 of an assignment expression is no longer included in the listing in the statement map.  From a multiple variable declaration point of view it kind of makes sense but I'm still not clear on why the statement part would be 0 and not i = 0.

What we're discussing is actually istanbul-lib-instrument.  I'm not sure if it can include the i =  part of a declaration.  This is not specific to for(...).  We currently have:

var i; - declaration is not considered a statement
var i = 0; - the assignment expression 0 is considered a statement, the declaration still is not
i = 1; - not a declaration so the entire thing is the statement.

This is partly the result of how babel works but I also think it's not necessarily wrong.  I'm not sure how coverage i = 0 of var i = 0 would be accomplished.

It sounds like this is a low priority heading towards won't fix, and I'm happy to live with this as it is.  I did have another question regarding differences in function mappings and how it affects reporting, but after doing some digging that all seems to be answered by istanbuljs/istanbuljs#285.
So to sum up, I suppose it's as simple as instrumentation in nyc is different to instrumentation in istanbul, and this will affect the results presented in any reports.