build: Fix error linking to libcamera-base.so

It's a bit strange why this did not fail all the time.
I suspect the "wrong" variable may have been cached by cmake, so it kept working when it should not have been!

@davidplowman

I'm not really understanding this either. As far as I can see the values are:
LIBCAMERA_LIBRARIES: camera;camera-base
LIBCAMERA_LINK_LIBRARIES: /usr/local/lib/arm-linux-gnueabihf/libcamera.so;/usr/local/lib/arm-linux-gnueabihf/libcamera-base.so
so the difference is that the second explicitly gives the full name - but they're in the "standard" place and it seems they should be found anyway. Certainly if I delete my build directory and rebuild from scratch, everything seems to work as it stands...

@kbingham Wondering if you had any ideas here. One of our users has had the problem whereby our executables link, but when run it can't find libcamera-base.so and aborts (though it does find libcamera.so). But if we run sudo ldconfig the problems goes away. Any thoughts?

I've done another full-install-from-scratch and everything works fine. I wonder if there's some issue whereby a pre-libcamera-base version of libcamera doesn't quite upgrade the ld.so.cache appropriately when that extra library appears?

OK, so I've been through the whole process again starting with a clean image. This time I checked out libcamera and libcamera-apps from early June. Everything builds and runs. I notice that /etc/ld.so.cache contains only libcamera.so, as expected.
Now I update libcamera to top of tree, rebuild and re-install. libcamera-base.so has now appeared, but I note ld.so.cache still only refers to libcamera.so. Anyway, I now update and build libcamera-apps (no errors), and sure enough, libcamera-base.so is not found when I try to run the executable. Running sudo ldconfig makes libcamera-base.so appear in ld.so.cache, and all is now well.
So the workaround for now does indeed seem to be sudo ldconfig. I've filed a bug at https://bugs.libcamera.org/show_bug.cgi?id=68

After a bit of delving around it seems a bit unclear whose responsibility it is to update the ld.so.cache. Under the circumstances it's probably worthwhile making this change as it solves the problem for users without having to find the sudo ldconfig workaround. and would appear to have no bad side-effects.

@kbingham Wondering if you had any ideas here. One of our users has had the problem whereby our executables link, but when run it can't find libcamera-base.so and aborts (though it does find libcamera.so). But if we run sudo ldconfig the problems goes away. Any thoughts?

Hi David, sorry for the delayed reply - I was on holiday last week so I've seen this too late.
I'm not particularly proficient in cmake, so I'm not sure about what effect the specific change has - but if it works it sounds helpful ;-)
I see from other discussions it may also be due to ldconfig not running after package installations - so it does sound a bit more painful, and I wouldn't want users to manually run sudo ldconfig after installations. Perhaps that's handled by the distributions when they install a package, and not expected to be done at 'ninja install' time (especially as the ninja install might be installing to a temporary location) ...
Anyway, sounds like this solves your problems for now.


Skeleton project for Play2 Framework

Hello guys,
Currently I am trying to use play2 framework (http://playframework.com) and aurelia together. Just wondering if you would keen to have skeleton project for Scala/Play2? If so, I will submit pull request for it once I setup the project.
Emily

@suchcto This sounds very intriguing. We are working on a CLI for creating new Aurelia projects. Perhaps that's a good candidate for where to put this. Can you share a bit what would be involved with the skeleton and what might make it different? We would certainly like to explore options.

I think we have this tracked on the CLI so closing here.


What does status proposed mean?

Before opening the issue, have you...?

[X] Searched for existing issues
[X] Looked through common issues
[X] Updated plugin to the latest version (if applicable)

Describe Your Problem
Hi, I´m using you plugin but I dont see the controlls in my Home app on my phone, I just see the volume, but I can see the device at Homebridge devices.
Logs
[smartthings-tv] [[TV] Samsung Q60 Series (55)] Capability Media Input Source might not work as expected because it's status is: proposed
If applicable, add screenshots to help explain your problem.
No response
Environment Information
- Plugin Version: v2.3.1
- Homebridge Version: latest
- Node.js version: latest
- NPM version: latest
- Operating System: Docker

Please have a look at #371 and #404. You should find solutions/answers to your problems.


Add possibility to disable event dispatcher

:+1:

Ok on the principle, but out of curiosity, what's the use case that requires this feature?

\M6Web\Bundle\AmqpBundle\Amqp\AbstractAmqp::setEventDispatcher
this function takes around 2 ms and dispatching event on each rabbitmq publishing takes a little less than 1 ms, but I have not use this events at all in my system and saving this time make sense for me

:+1:

Thank you for your explanation, it's obviously a valid workaround


Please consider fixing issues detected by repository checker

Notification from ioBroker Check and Service Bot
Dear adapter developer,
I'm the ioBroker Check and Service Bot. I'm an automated tool processing routine tasks for the ioBroker infrastructure. I have recently checked the repository for your adapter volvo for common errors and appropiate suggestions to keep this adapter up to date.
Please see the result of the check below.
ioBroker.volvo
   -

ERRORS:

[ ] :heavy_exclamation_mark: [E026] "{'engines': {'node'>='16'}}" is required at package.json, "{'engines':{'node'>='18'}}" is recommened
[ ] :heavy_exclamation_mark: [E162] js-controller 1.4.2 listed as dependency but 4.0.24 is required as minimum, 5.0.19 is recommended. Please update dependency at io-package.json.

WARNINGS:

[ ] :eyes: [E145] Missing mandatory translation into de of some "common.news" in io-package.json.
[ ] :eyes: [W034] @iobroker/adapter-core 3.1.4 specified. 3.1.6 is recommended. Please consider updating dependencies at package.json
[ ] :eyes: [W040] "keywords" within package.json should contain "ioBroker"
[ ] :eyes: [W105] Missing suggested translation into uk of "common.titleLang" in io-package.json.
[ ] :eyes: [W109] Missing suggested translation into uk of "common.desc" in io-package.json.
[ ] :eyes: [W115] "common.tier" is required in io-package.json. Please check https://github.com/ioBroker/ioBroker.docs/blob/master/docs/en/dev/objectsschema.md#adapter.
[ ] :eyes: [W145] Missing suggested translation into ru,pt,nl,fr,it,es,pl,uk,zh-cn of some "common.news" in io-package.json.
[ ] :eyes: [W173] Potential sensitive data "password" not listed at "protectedNative" in io-package.json
[ ] :eyes: [W174] Potential sensitive data "password" not listed at "encryptedNative" in io-package.json
[ ] :eyes: [W181] "common.license" in io-package.json is deprecated. Please define object "common.licenseInformation"
[ ] :eyes: [W184] "common.main" is deprecated and ignored. Please remove from io-package.json. Use "main" at package.json instead.
[ ] :eyes: [W184] "common.materialize" is deprecated for admin >= 5 at io-package.json. Please use property "adminUI".
[ ] :eyes: [W184] "common.title" is deprecated and replaced by "common.titleLang". Please remove from io-package.json.
[ ] :eyes: [W522] Please consider migrating to admin 5 UI (jsonConfig).
[ ] :eyes: [W853] .npmignore found - consider using package.json object "files" instead.

Please review issues reported and consider fixing them as soon as appropiate.
Errors reported by repository checker should be fixed as soon as possible. Some of them require a new release to be considered as fixed. Please note that errors reported by checker might be considered as blocking point for future updates at stable repository.
Warnings reported by repository checker should be reviewed. While some warnings can be considered as a suggestion and be ignored due to good reasons or a dedicated decision of the developer, most warnings should be fixed as soon as appropiate.
Feel free to contact me (@iobroker-bot) if you have any questions or feel that an issue is incorrectly flagged.
And THANKS A LOT for maintaining this adapter from me and all users.
Let's work together for the best user experience.
your
ioBroker Check and Service Bot
@mcm1957 for evidence

This issue has been replaced by new isse #33
This issue can be closed.
your
ioBroker Check and Service Bot


⚠ Mobitopup has degraded performance

In d9f104e, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 3686 ms

Resolved: Mobitopup performance has improved in 4e3513a.


Fix flexbox containers in panel

See #78 for more info. This cleans up some layout bugs inside the panel.
(Closes #78)

@arunoda Do you know why the CI tests might be failing, doesn't seem like it has anything to do with my changes in this PR?

@bluetidepro I have some design change requests. Could you apply them?
Color Knob
See following image:

Now we click on the color knob, it shows the color popup at the end of the screen. Earlier it was not like that. Could you check on that and do something about it.
Color and Date knob sizes
As we resize above both knobs, their size won't change. See:

Can we do something about it?

@arunoda Good find, sorry, I did not see that before! I can take a look and fix those really easily.
I'm also actually currently not able to build the project because it fails on npm install just like the CI errors on this PR (and past recent PR's), so I didn't catch those errors.
Do you know why that may be failing? It seems like it has to do with "typescript-definition-tester": "frederickfogerty/typescript-definition-tester#528375132cfbfd58affd401f66c02ef54813f3ce" in package.json?

@bluetidepro I don't find such errors.
If that's still causing issues, move that package to this: https://www.npmjs.com/package/typescript-definition-tester
I hope then it'll work.
/cc @frederickfogerty, do you have any input here?

The main repo now supports typescript 2.0, so the reference to my fork can be removed.

@bluetidepro I opened a PR on your repo https://github.com/bluetidepro/storybook-addon-knobs/pull/1

@arunoda @frederickfogerty Okay, I fixed the bugs, and squashed the commits. I made the color picker appear in the same spot the date picker did. I made all the fields go 100% to be aligned correctly. All the fields look good, now:

Yep. This is great.

Released with v1.7.1

Thanks @arunoda


Service is_enabled KO

Hi
I'm testing a salt formula via kitchen, installing and enabling caddy service. As you can see, the service is enabled
kitchen@74cb1d70442b:~$ sudo su
root@74cb1d70442b:/home/kitchen# systemctl status caddy
● caddy.service - Caddy HTTP/2 web server
   Loaded: loaded (/lib/systemd/system/caddy.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-03-19 10:45:59 UTC; 32min ago
     Docs: https://caddyserver.com/docs
 Main PID: 3042 (caddy)
    Tasks: 10 (limit: 4915)
   CGroup: /docker/74cb1d70442be3231e88e77c241e11f01e3af60b87eeb25c89df9140535eaa55/system.slice/caddy.service
           └─3042 /usr/bin/caddy -log stdout -agree=true -email<EMAIL_ADDRESS>-conf=/etc/caddy/Caddyfile -root=/var/tmp

But testinfra thinks otherwise
============================= test session starts ==============================
platform linux2 -- Python 2.7.13, pytest-4.3.0, py-1.8.0, pluggy-0.9.0
rootdir: /var/lib/jenkins/workspace/salt-formula-caddy/test, inifile: pytest.ini
plugins: testinfra-1.19.0, metadata-1.8.0, html-1.20.0
collected 6 items

test/integration/test_caddy.py ....FF                                    [100%]

=================================== FAILURES ===================================
_ test_service[docker://74cb1d70442be3231e88e77c241e11f01e3af60b87eeb25c89df9140535eaa55] _

host = <testinfra.host.Host object at 0x7ffb77697710>

    def test_service(host):
        s = host.service("caddy")
        assert s.is_running
>       assert s.is_enabled
E       assert False
E        +  where False = <service caddy>.is_enabled

Here's the kitchen verifier command if that might help
verifier:
  name: shell
  remote_exec: false
  command: pytest --junitxml=test/${KITCHEN_INSTANCE}_test_report.xml --html=test/${KITCHEN_INSTANCE}_test_report.html --self-contained-html --color=yes --host="docker://root@${KITCHEN_CONTAINER_ID}" "test/integration/"

Hi,
You can run py.test with -vvs flags to enable debug output and see what command is actually run by testinfra.
In this case I think testinfra run systemctl is-enabled caddy what is the output of this command ?

Ok, I found why.
https://github.com/philpep/testinfra/blob/master/testinfra/modules/service.py#L54
We are running tests in a docker container and systemd is lauched by docker, so there is no  /sbin/init link and testinfra fallback to SysVinit which can't work.
I got around by adding the missing link in our containers.

Maybe we should look for /proc/1/exe instead of /sbin/init
That being said, IIRC, some commands work with systemd not being pid 1 (like systemctl is-enabled).

That's also an issue I get with a container based on Archlinux.
The link /sbin/init doesn't exist and Testinfra falls back to SysVinit.
cating /proc/1/comm seems to give good results (here are some tests I did on vagrant boxes):

Gentoo : init (+ rc-service exists) ;
Ubuntu 14.04 : init (+ initctl exists) ;
Ubuntu 19.04 : systemd ;
Debian Stretch : systemd ;
Archlinux : systemd.

Also, wouldn't it be a better idea to fall back to SystemdService ?
I'm volunteering to write a PR if the above sounds OK to you :-)

Ok, I found why.
https://github.com/philpep/testinfra/blob/master/testinfra/modules/service.py#L54
We are running tests in a docker container and systemd is lauched by docker, so there is no /sbin/init link and testinfra fallback to SysVinit which can't work.
I got around by adding the missing link in our containers.

I have this exact same problem when running tests using a systemd-enabled Debian 9 image.

Ok, I found why.
https://github.com/philpep/testinfra/blob/master/testinfra/modules/service.py#L54
We are running tests in a docker container and systemd is lauched by docker, so there is no /sbin/init link and testinfra fallback to SysVinit which can't work.
I got around by adding the missing link in our containers.

I have this exact same problem when running tests using a systemd-enabled Debian 9 image. In my case, though, I'm running systemd inside of a Docker container, and so my systemd process is not PID 1.

In case anyone else encounters this issue when exercising testinfra via molecule, I was able to get around it by creating molecule/default/prepare.yml with the following content:
- name: Group hosts by OS distribution
  hosts: all
  tasks:
    - name: Group hosts by OS distribution
      group_by:
        key: os_{{ ansible_facts['distribution'] }}
- name: Install init (Debian)
  hosts: os_Debian
  tasks:
    - name: Install init (Debian)
      package:
        name:
          - init

Hi, it seems that adding the systemd-sysv package to docker resolves the problem.
See: https://github.com/geerlingguy/docker-debian10-ansible/pull/4

So I can confirm that testinfra(3.4.0) test now passes with those services:
assert host.service("postfix").is_enabled
assert host.service("mariadb").is_enabled
assert host.service("nftables").is_enabled
assert host.service("ntp").is_enabled
assert host.service("rsync").is_enabled
assert host.service("ssh").is_enabled
assert host.service("zabbix-agent").is_enabled


🚧 Added interfaces for IGpioController and IGpioPin

Description

Added interfaces for IGpioController and IGpioPin to support better community supplied controllers.  --  Also fixed the files names for GpioController and GpioPin because they had control characters in them.

These are the same interfaces that the UWP platform has but are marked internal.
Motivation and Context

UWP provides a Provider model for the GpioController so new controllers can be added. This would be a lot of work and overhead for the nanoFramework, so the simpler (and easier to understand) interface model was used.
Addresses nanoFramework/Home#411.

Types of changes

[X] Improvement (non-breaking change that improves a feature, code or algorithm)
[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[X] My code follows the code style of this project.
[X] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[X] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Signed-off-by: roySalisbury<EMAIL_ADDRESS>

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Yes, I originally missed the ctor for the GpioPinValueChangedEventArgs.  It would need to be changed from internal to public.  I did not go back and add that to my initial submission since I had already submitted both PR's and did not want to confuse things by submitting an update.

Care to do that and submit another PR to the interpreter repo with the events change?
(if we release that on the same merge it will save time with the subsequent updated on the managed classes 😉  )

Care to do that and submit another commit to the open PR (interpreter repo) with the events change?
(if we release that on the same merge it will save time with the subsequent updated on the managed classes 😉 )

Does not look like the nf-interpreter files needed changed.  The stubs or checksum do not appear to have been changed with just changing the access modifier.


Explicitly synchronize with main container during shutdown

(This is used to request new product features, please visit https://discuss.istio.io for questions on using Istio)
Describe the feature request
It is well known that because Kubernetes doesn't recognize sidecars or container dependencies as a first-class concept, it is difficult for istio-proxy to know in general when it can shut down. Until now, Istio has tried adding various waits and delays to the shutdown process, but these do not really solve the problem in all cases. I propose adding a more explicit mechanism, until container dependencies are reified.

The mutating webhook will modify the pod spec to add an emptyDir volume mount. This will be mounted in both the main container as well as istio-proxy. The webhook will also add two environment variables to both containers: ISTIO_PROXY_UDS and ISTIO_PROXY_PRESTOP_DIR. (These names are not finalized.) The first will refer to the path of a Unix domain socket and the second will refer to the path of a folder.
At startup, istio-proxy will create a Unix domain socket at the path dictated by ISTIO_PROXY_UDS, and a directory at the path dictated by ISTIO_PROXY_PRESTOP_DIR.
At startup, first-party containers can dial ISTIO_PROXY_UDS. No traffic will be sent over this connection, but it will be kept alive until the container exits. To avoid a race where the socket doesn't exist yet, the application should retry in a loop. (As a side effect, this also obviates the need for holdApplicationUntilProxyStarts, since the success of that connection means the sidecar has started.) To avoid a hard dependency on Istio, if this environment variable is not set, this logic should be skipped entirely.
Third-party containers that have a shell can be configured with a pre-stop hook that creates a file in ISTIO_PROXY_PRESTOP_DIR, performs the shutdown, and then deletes the file. Again, to avoid a hard dependency on Istio, if this environment variable is not set, the file logic should be skipped entirely.
Third-party containers that do not have a shell will have to continue to rely on the existing guesswork.
When istio-proxy receives SIGTERM, it will first sleep for some configurable duration. Then it will close the UDS and wait for all its connections to be closed. Then it will poll the ISTIO_PROXY_PRESTOP_DIR until it is empty. Finally, it will drain envoy and sleep for another configurable duration, before finally exiting. During this final sleep, it can be configured to periodically check if there are no active connections and terminate preemptively, as is done today. Note that Envoy is not drained until the very last step.

Describe alternatives you've considered
The existing mechanisms provided to work around this issue do not meet our needs. They shut down Envoy prematurely, causing in-flight requests to fail. And they try to guess when the main application container is done, which won't work in general.
Affected product area (please put an X in all that apply)
[ ] Docs
[ ] Installation
[x] Networking
[x] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Additional context

I am not against this, but wanted to list some alternative ideas I have thought of:

Fix https://github.com/kubernetes/kubernetes/issues/106896, then trigger exit when the other containers shut down
During injection copy a small binary, say istio-wait, into a shared volume. Replace their pod spec args with istioctl-wait <original args> which executes their actual app once ready and triggers istio-agent to shutdown once their app exists. This might break some apps that are very particular around how they run but should be transparent in most cases.

Your idea about istio-wait sounds intriguing. Behind the scenes it could probably just leverage the UDS I proposed. I guess istio-init can copy the executable to the shared volume so it is there before pod startup.

@howardjohn I was thinking about this more, and had an idea. Rather than having istio-wait fork and exec the main application, what if it just execs? It would work like this:

First istio-wait dials the aforementioned Unix domain socket.
Then it execs the main application on top of itself, without closing the UDS connection. In Go this is accomplished with exec.Cmd.ExtraFiles.
When the main application exits, the kernel will automatically close all of its fds, including the UDS connection.

This I think resolves a few issues nicely. You don't need to deal with forwarding signals in istio-wait. There isn't an extra process running that does nothing 99% of the time. The main application remains pid 1.

Nice! One concern we should be aware of when doing this is that app container may exit + restart. Ideally proxy is around the whole time.
We could have two modes:

If container will restart: agent catches SIGTERM. Exit only when we get SIGTERM and UDS closes
If container will not restart: exit when UDS closes

Main concern is that restart policy can be OnFailure. In that case we don't know which one to do probably?

Isn't (2) also applicable to job pods? I'm not sure how restart policy works there.

Main concern is that restart policy can be OnFailure. In that case we don't know which one to do probably?

If the restart policy is "OnFailure", and the main container exits with failure, and then the sidecar exits with success, it seems like it would cause a problem when the main container is then restarted. But if the sidecar exits with failure, it will get into an infinite loop.
Do you know if the bug you filed (https://github.com/kubernetes/kubernetes/issues/106896) also applies when the containers exit outside pod termination? If not, then maybe something like this will work.

If the restart policy is "Always", then there is nothing special to do at runtime.
If the restart policy is "Never", then whenever the last UDS connection closes, istio-proxy should check the pod status, and automatically exit if all relevant containers have exited.
If the restart policy is "OnFailure", then whenever the last UDS connection closes, istio-proxy should check the pod status, and automatically exit if all relevant containers have terminated successfully.

This is orthogonal to the SIGTERM logic. I'm not sure if the pod status API suffers from eventual consistency. If it does then you would need to periodically poll it in (2) and (3) while there are no UDS connections.

Do you know if the bug you filed (kubernetes/kubernetes#106896) also applies when the containers exit outside pod termination?

It does update if the pod is not terminating. One note is istio-agent cannot read pod status. We would have to have Istiod push this info over XDS. Its not that hard but more complex than it would be otherwise. I have a POC branch that sends a signal to kill itself when the containers exit per pod spec but because of that issue it doesn't work for shutdown -- only for containers exiting outside of pod termination.
So maybe we just do the pod status for container shut down, and UDS for pod termination. I think that should cover all edge cases...

 This should be reliable, pod status shows all the info we need.
If proxy gets SIGTERM, pod must be terminating. Wait until UDS closes then exit.

The only case I can think of where it would fail is if something manually sends SIGTERM to proxy, but that is really an edge case.... they should be able to SIGKILL to force it?
WDYT? Its pretty complex TBH but could be reliable.
One note on the istio-wait injection. K8s allows settings just plain args without command (with command in the docker image metadata). if a user does this, we cannot recreate the command with istio-wait injected (unless we parse the image manifest, which is incredibly complex). So its not the most robust solution, but users can easily tweak their apps to allow it to work?

So maybe we just do the pod status for container shut down, and UDS for pod termination.

Seems reasonable. Since these are somewhat orthogonal concerns they can be implemented separately too.

The only case I can think of where it would fail is if something manually sends SIGTERM to proxy, but that is really an edge case.... they should be able to SIGKILL to force it?

I think you could encounter a similar situation today anyway if someone configures "exit on zero active connections", and then only sends SIGTERM to the proxy. And I'm not really sure why someone would do that.

K8s allows settings just plain args without command (with command in the docker image metadata). if a user does this, we cannot recreate the command with istio-wait injected (unless we parse the image manifest, which is incredibly complex).

Hmm, that is unfortunate, especially because the entrypoint for a container may be non-obvious. For example, the entrypoint for ingress-nginx is apparently dumb-init. In fact in that case istio-wait could have been prepended to the list of args in the pod spec and it would have worked fine. The same is probably true for any containers that are using some init system. Unfortunately, the mutating webhook would have no way to know this from the pod spec. Maybe we can add some pod annotation to control this behavior?

If no annotation and no command, then istio-wait is not injected.
If no annotation, but there is a command, then istio-wait is prepended to command.
If annotation, but no args, then webhook should reject. (?)
If annotation and args, then istio-wait is prepended to args.

Another issue to consider is what happens if istio-proxy itself restarts, due to a bug, or running out of memory, or any such thing. If that happens all the UDS connections will be lost, which implies we would need the wrapper process to be long-lived so it can re-dial.
For me that isn't so bad, because I can just integrate the dial loop into my Go applications instead, as long as the socket path is an injected env var. For other applications such as ingress-nginx, I can opt into the istio-wait wrapper, or even write my own. This just leaves applications that are sensitive to exactly how they are run, as you mentioned. Do you have examples of this, and why specifically they would have issues? Maybe for now that could use the exec-only version of istio-wait, and accept the gap in robustness, potentially falling back to the sleep-based guesswork.

cc @costinm This idea is a total redesign, there are serveral reaons i think i am against it.

first why do we need such a tricky way to handle maybe <1% rare case, is it worthwhile?
A new optional binary, say istio-wait, it is able to recv any signals and pass them to app process,  I guess not possible.
As a user, why do I accept changing the command I am running. I would rather explicitly send a signal (maybe api call) to sidecar.

So the best solution is k8s provide a way to sync between all the containers, in short term it looks not realistic. Then what we can do it comply pod terminationGraceSeconds.

first why do we need such a tricky way to handle maybe <1% rare case, is it worthwhile?

This is not a < 1% rare case. Every single time our pods get cycled (e.g., during deployment rollout), we get some failed requests specifically because of Istio shutting down incorrectly.

A new optional binary, say istio-wait, it is able to recv any signals and pass them to app process, I guess not possible.

I don't understand you are proposing here.

As a user, why do I accept changing the command I am running. I would rather explicitly send a signal (maybe api call) to sidecar.

My assumption is most users really want Istio injection to be fully transparent, meaning they do not want to modify their applications or pods to make it work.
A signal would not work across containers, unless you mandate shareProcessNamespace. And even then, you would have to know what pid to signal.
Neither of these approaches is reliable, since it is possible for the main application to crash/exit without ever calling it.
The UDS that I have been mentioning basically already serves this purpose.

Then what we can do it comply pod terminationGraceSeconds.

The pod termination grace period is intended to be the worst case termination time. I assume most users (myself included) would find it unacceptable if Istio caused pod shutdown to always take this long.
This is why I think the best course of action is for the mutating webhook to inject the UDS path as an env var into the main container. Then users have three options:

Users that can accept adding Istio-aware logic directly in their application can just do the UDS logic there.
Users that would prefer it be handled transparently can opt into the istio-wait wrapper injection, which in turn will handle the UDS logic for them.
Users that want the istio-wait wrapper but are concerned about runtime injection can obtain istio-wait out of band, add it to their image, and configure their entrypoint and/or cmd appropriately.
Users that find none of these acceptable can continue to leverage the sleep-based guesswork.

Changing the injection logic or app listening to UDS etc(app being Istio aware) seems little complicated to me.
Let us step back and see why ExitOnActiveConnections does not solve the general case (regular pods) and improve it? I can think of only case is long running Http Streaming connections - I guess if there is a long running streaming connection that means the pod is processing streams so it is OK to terminate on longer terminateDrainDuration.
ExitOnActiveConnections does not work for Jobs. But for jobs we can force kill proxy using /quit/quit/quit
are there any other use cases that ExitOnActiveConnections does not solve in the short term?

@ramaraochavali ExitOnZeroActiveConnections makes the fallacious assumption that the main container will neither receive any more inbound connections nor create any more outbound connections between receiving SIGTERM and exiting. This flaw exists for any solution that involves istio-proxy guessing about when the main container is done, and it always leads to request failures during pod shutdown, which is not acceptable.

Changing the injection logic or app listening to UDS etc(app being Istio aware) seems little complicated to me.

Changing the app to dial a socket in a loop is pretty trivial. I agree that the automatic injection logic could get hairy in certain situations, but from my perspective it would be fine if you did not do this yet and instead users just got istio-wait out-of-band and manually set up their containers to use it. And again, if someone does not want to make their app Istio-aware, they still have the option of relying on the sidecar guessing when they are done, and accepting the resulting downtime.

@ramaraochavali Also, one thing I am unclear on is why ExitOnZeroActiveConnections starts draining Envoy at all. Why not just wait the MINIMUM_DRAIN_DURATION, then poll Envoy until there are no active inbound/outbound connections without draining, and then exit? This would resolve most (but not all) of our issues, because there will at least be the inbound connection the request was received through until we are done.

ExitOnZeroActiveConnections makes the fallacious assumption that the main container will neither receive any more inbound connections nor create any more outbound connections between receiving SIGTERM and exiting. This flaw exists for any solution that involves istio-proxy guessing about when the main container is done, and it always leads to request failures during pod shutdown, which is not acceptable.

this is not true. We do graceful drain. Refer to https://www.envoyproxy.io/docs/envoy/v1.20.1/operations/admin#post--drain_listeners?graceful and the draining period is configurable by https://github.com/istio/api/blob/master/mesh/v1alpha1/proxy.proto#L345

Changing the app to dial a socket in a loop is pretty trivial.

It breaks the fundamental assumption the sidecar is a drop-in thing and app need not be aware of its presense/absence.

out-of-band and manually set up their containers to use it. And again, if someone does not want to make their app Istio-aware, they still have the option of relying on the sidecar guessing when they are done, and accepting the resulting downtime.

Again I think users having to do some manual/additional steps is not a good user experience IMO

Also, one thing I am unclear on is why ExitOnZeroActiveConnections starts draining Envoy at all. (Really I don't see why istio-proxy ever drains it.) Why not just wait the MINIMUM_DRAIN_DURATION, then poll Envoy until there are no active inbound/outbound connections without draining, and then exit?

Without draining even if you wait for MINIMUM_DRAIN_DURATION - active inbound/outbound connections will never become zero. IMO there wont be any significant traffic loss and mostly client side retries would account for them (it is definitely better than pod crashing). Refer to https://www.envoyproxy.io/docs/envoy/v1.20.1/intro/arch_overview/operations/draining.html?highlight=draining

@ramaraochavali The Envoy docs don't make any sense, and also do not align with our observations during pod shutdown. For example, they mention that "Envoy will discourage requests for some period of time", but what exactly does it mean to "discourage" requests? We are seeing failures for inbound and outbound connections/requests even during the supposed grace period.
To that end, I see that you are using --drain-strategy=immediate.
https://github.com/istio/istio/blob/17ac63d9f8e12f05e3a03e0593d88f2b858128f1/pkg/envoy/proxy.go#L124
While the Envoy docs are currently broken and won't show me what the CLI options mean, the source code implies that it means the connections can be closed as soon as draining begins.
https://github.com/envoyproxy/envoy/blob/c75c1410c8682cb44c9136ce4ad01e6a58e16e8e/envoy/server/options.h#L58-L61

active inbound/outbound connections will never become zero

Why not? Once the main container exits, all of its inbound and outbound connections should be automatically closed by the kernel, so what would remain at that point?

mostly client side retries would account for them

You are making assumptions about what our clients choose to do.

The Envoy docs don't make any sense, and also do not align with our observations during pod shutdown.

Can you please elaborate on what your observations are during pod shutdown?

Why not? Once the main container exits, all of its inbound and outbound connections should be automatically closed by the kernel, so what would remain at that point?

The case I am talking about is when main container enters in to graceful shutdown mode (i..e stop accepting inbound connections and processes inflight transactions) - if proxy also does not do the same that means does not enter in to graceful drain mode, there will be still  incoming connections to proxy till it shuts down.

You are making assumptions about what our clients choose to do.

I agree. But the point I am making is this can happen when pod crashes also - then what do you do?

Can you please elaborate on what your observations are during pod shutdown?

What we observe most often is ingress-nginx starts sending back sporadic 502 (or similar) status codes when the upstream pods are terminating. Exactly why is unclear. It could be because istio-proxy is exiting too quickly at shutdown, although 5 seconds is pretty long. Or it could be because Envoy stops accepting inbound connections during graceful shutdown - the Envoy docs and Istio docs disagree on what the behavior here is.

if proxy also does not do the same that means does not enter in to graceful drain mode, there will be still incoming connections to proxy till it shuts down.

When the pod starts terminating it is removed from the Service, meaning that there really shouldn't be new connections coming in after a few seconds.  From what I gather the only real benefit to doing anything special is so Envoy starts sending back the Connection: close header.

this can happen when pod crashes also - then what do you do?

If the pod crashes by definition this is an abnormal situation - a bug in my code that needs to be fixed. Pod termination is not a bug, it is part of the normal lifecycle of a Kubernetes application.

Or it could be because Envoy stops accepting inbound connections during graceful shutdown - the Envoy docs and Istio docs disagree on what the behavior here is.

With graceful behaviour Envoy will continue to accept new connections till drain period while closing the existing connections after request completion.

From what I gather the only real benefit to doing anything special is so Envoy starts sending back the Connection: close header.

Yes. See above

The current workarounds that I have seen using existing istio releases suggest tweaking the envoy settings and these suggestions don't quite get us to a transparent solution because there are scenarios in which envoy cannot simply deduce what the primary container is up to based on connections that the pod may have open at the time that SIGTERM is received from kubernetes.
For example, we have pods wrapped into the service mesh so they can auth/talk to other services but it's possible they do not have open connections at the time of SIGTERM/graceful shutdown. We want them to be able to set terminationGracePeriodSeconds, stay open until then if they wish, open/close connections in that time, and when the process finally decides to exit then istio-proxy will be shutdown as well.
I don't see how to do this without something like istio-wait being injected - it seems like a great idea. At least until kubernetes stabilizes some sidecar apis, but since the main KEP was closed it'd be so useful if istio could come up with an interim solution.

We already have an istio-launcher.py that we run to try to handle this but it cannot coordinate with envoy exactly how we would like because it'd require us configuring envoy to ignore SIGTERM entirely and let the wrapper tell envoy when to quit.
This workaround does not work with arbitrary workloads that we want to run in the mesh - we have to build our own images with support for the wrapper script builtin - istio should handle this for us to make it more transparent.

Finally, does anyone have a stop-gap recipe on how to configure a pod to work right now with something like istio-wait? With my limited envoy knowledge I haven't been able to figure out all the tweaks to envoy that are required to let the other container control it properly and not do it solely based on open connections or a minimum duration.

As a followup to my previous comment just above - here [1] is the solution I'm currently using to implement something similar to an istio-wait that allows the main container to open/close connections during shutdown, keeping the proxy alive until the main container exits. You can see how it's implementing both quitquitquit and a listener blocking prestop to handle both one-off job scenarios as well as graceful shutdown. Both of these scenarios boil down to same logic: sidecar should block inbound connections and then wait until the main container exits.
I hope it helps someone, and that istio itself grows something like this because it requires modifying each app container right now.
I'd love to see istio rewriting the entrypoint to run an injected binary that bundles tini + istio-wait as pid 1.
[1] https://gist.github.com/mmerickel/a2159c51d7a2486b9ac7057fa6b69139

@howardjohn This is not stale.

Please reopen

Please reopen

There does not seem likely to be a path towards an Istio native fix for this beyond https://istio.io/latest/blog/2023/native-sidecars/ which solves this problem entirely.


Update API docs with {set,get}Config

Including:

Marking deprecated methods
Change to Prebid Server config

@mjacobsonny and @matthewlane, would appreciate your review on this one.
Lane, I liberally plagiarized your excellent work documenting the PR FYI.  Let me know if you want me to amend the commit message or something, I feel a little weird about it.
Please let me know if either of you see any technical errors or if there is missing info, or if something is just unnecessarily confusing.
Also, is there any additional info we can add to the docs about how to tell if your config JSON object is incorrect/malformed?
Plus anything else you can think of in general.  Thanks!

@mjacobsonny gonna merge this one in order to move on to other tasks - if you see any additional work needed here or have an opinion about something, let me know!


Add ability to specify URL as one parameter

URL can be a local path, so LDAPI becomes possible
solves: https://github.com/ergochat/ergo-ldap/issues/2

Tested connecting via ldap, ldaps, ldapi, haven't tested with StartTLS (don't have setup for it ready)
Additionally, this change would make config options "host", "port", "use-tls" redundant (existing setups should not be effected). Maybe it is worth to consider removing these options in the future.


Ask for permission of reuse your figure

@vdumoulin Thanks for your great job.Could I use a figure of deconvolution in your guide directly in my paper with a citation?

@kangmiao15 The license file grants you permission, as long as you follow the terms of that agreement https://github.com/vdumoulin/conv_arithmetic/blob/master/LICENSE

Thank you so much!


qemu_nios2 crash when enabled icount

seems when qemu runes instruction WRCTL of nios2 arch with icount enabled, there will be crash.

diff --git a/home/wentongw/tmp/qemu-4.2.0/hw/nios2/cpu_pic.c b/./hw/nios2/cpu_pic.c
index 1c1989d..ada8d5b 100644
--- a/home/wentongw/tmp/qemu-4.2.0/hw/nios2/cpu_pic.c
+++ b/./hw/nios2/cpu_pic.c
@@ -21,6 +21,7 @@
 #include "qemu/osdep.h"
 #include "cpu.h"
 #include "hw/irq.h"
+#include "sysemu/cpus.h"

 #include "qemu/config-file.h"

@@ -54,9 +55,11 @@ static void nios2_pic_cpu_handler(void *opaque, int irq, int level)

 void nios2_check_interrupts(CPUNios2State *env)
 {
-    if (env->irq_pending) {
-        env->irq_pending = 0;
-        cpu_interrupt(env_cpu(env), CPU_INTERRUPT_HARD);
+    if (!use_icount) {
+        if (env->irq_pending) {
+            env->irq_pending = 0;
+            cpu_interrupt(env_cpu(env), CPU_INTERRUPT_HARD);
+        }
     }
 }

experimental patch deferring interrupt handle to cpu_exec seems work, need more debug.
int cpu_exec(CPUState *cpu)
{
    CPUClass *cc = CPU_GET_CLASS(cpu);
    int ret;
    SyncClocks sc = { 0 };

    /* replay_interrupt may need current_cpu */
    current_cpu = cpu;

    if (cpu_handle_halt(cpu)) {
        return EXCP_HALTED;
    }

    rcu_read_lock();

    cc->cpu_exec_enter(cpu);

    /* Calculate difference between guest clock and host clock.
     * This delay includes the delay of the last cycle, so
     * what we have to do is sleep until it is 0. As for the
     * advance/delay we gain here, we try to fix it next time.
     */
    init_delay_params(&sc, cpu);

    /* prepare setjmp context for exception handling */
    if (sigsetjmp(cpu->jmp_env, 0) != 0) {
#if defined(__clang__) || !QEMU_GNUC_PREREQ(4, 6)
        /* Some compilers wrongly smash all local variables after
         * siglongjmp. There were bug reports for gcc 4.5.0 and clang.
         * Reload essential local variables here for those compilers.
         * Newer versions of gcc would complain about this code (-Wclobbered). */
        cpu = current_cpu;
        cc = CPU_GET_CLASS(cpu);
#else /* buggy compiler */
        /* Assert that the compiler does not smash local variables. */
        g_assert(cpu == current_cpu);
        g_assert(cc == CPU_GET_CLASS(cpu));
#endif /* buggy compiler */
#ifndef CONFIG_SOFTMMU
        tcg_debug_assert(!have_mmap_lock());
#endif
        if (qemu_mutex_iothread_locked()) {
            qemu_mutex_unlock_iothread();
        }
        qemu_plugin_disable_mem_helpers(cpu);

        assert_no_pages_locked();
    }

    /* if an exception is pending, we execute it here */
    while (!cpu_handle_exception(cpu, &ret)) {
        TranslationBlock *last_tb = NULL;
        int tb_exit = 0;

        while (!cpu_handle_interrupt(cpu, &last_tb)) {
            uint32_t cflags = cpu->cflags_next_tb;
            TranslationBlock *tb;

@andrewboie

(gdb) info breakpoints
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x00426408 in z_set_timeout_expiry at /home/wentongw/zephyr/zephyrproject/zephyr/include/arch/nios2/arch.h:52
	breakpoint already hit 2 times
2       breakpoint     keep y   0x00426408 in z_set_timeout_expiry at /home/wentongw/zephyr/zephyrproject/zephyr/include/arch/nios2/arch.h:52
	breakpoint already hit 1 time
(gdb) si
0x0042640c	52		__asm__ volatile (
(gdb) si
0x00426410	52		__asm__ volatile (
(gdb)
0x00426414	52		__asm__ volatile (
(gdb)
0x00426418	52		__asm__ volatile (
(gdb)
0x0042641c	52		__asm__ volatile (
(gdb)
0x00426420	52		__asm__ volatile (
(gdb)
0x00426424 in arch_irq_lock () at /home/wentongw/zephyr/zephyrproject/zephyr/include/arch/nios2/arch.h:52
52		__asm__ volatile (
(gdb)
0x00426428	52		__asm__ volatile (
(gdb)
0x0042642c	52		__asm__ volatile (
(gdb)
0x00426430	52		__asm__ volatile (
(gdb)
Remote connection closed

@andrewboie @andyross @nashif after wrctl instruction qemu(icount enabled) will abort itself, but first I wonder if there is other way to lock irq on nios2 arch? Thanks
void z_set_timeout_expiry(s32_t ticks, bool idle)
{
  426408:       defffc04        addi    sp,sp,-16
  42640c:       dc400115        stw     r17,4(sp)
  426410:       dc000015        stw     r16,0(sp)
  426414:       dfc00315        stw     ra,12(sp)
  426418:       dc800215        stw     r18,8(sp)
  42641c:       2021883a        mov     r16,r4
  426420:       2823883a        mov     r17,r5
        __asm__ volatile (
  426424:       0025303a        rdctl   r18,status
  426428:       00bfff84        movi    r2,-2
  42642c:       9084703a        and     r2,r18,r2
  426430:       1001703a        wrctl   status,r2
        __ASSERT(z_spin_lock_valid(l), "Recursive spinlock %p", l);
  426434:       d1201504        addi    r4,gp,-32684

*** Booting Zephyr OS build zephyr-v2.1.0-5757-g394ff7a28b6b  ***
Running test suite test_fifo_timeout
===================================================================
starting test - test_timeout_empty_fifo
qemu: fatal: Raised interrupt while not in I/O function
IN: PC=426430 z_set_timeout_expiry
     zero=00000000        at=00000000        r2=00000000        r3=00400b6c
       r4=00000002        r5=00000001        r6=00000000        r7=00000000
       r8=00000000        r9=00000000       r10=00400c94       r11=00400c00
      r12=00000000       r13=00000000       r14=00000000       r15=00000000
      r16=00000002       r17=00000001       r18=00000000       r19=00000000
      r20=00000000       r21=00000000       r22=00000000       r23=00000000
       et=00000000        bt=00000000        gp=004083d0        sp=004035a8
       fp=00000000        ea=00000000        ba=00000000        ra=00426958
   status=00000000   estatus=00000000   bstatus=00000000   ienable=00000004
 ipending=00000004     cpuid=00000000 reserved0=00000000 exception=00000000
  pteaddr=00000000    tlbacc=00000000   tlbmisc=00000000 reserved1=00000000
  badaddr=00000000    config=00000000   mpubase=00000000    mpuacc=00000000
reserved2=00000000 reserved3=00000000 reserved4=00000000 reserved5=00000000
reserved6=00000000 reserved7=00000000 reserved8=00000000 reserved9=00000000
reserved10=00000000 reserved11=00000000 reserved12=00000000 reserved13=00000000
reserved14=00000000 reserved15=00000000 reserved16=00000000 reserved17=00000000
      rpc=00426430  mmu write: VPN=00000 PID 00 TLBACC 00000000

Aborted (core dumped)

checked nios2 arch doc, the behavior locking irq is correct in zephyr code.

will communicate below patch with qemu community
diff --git a/hw/nios2/cpu_pic.c b/hw/nios2/cpu_pic.c
index 1c1989d5..b04db4d7 100644
--- a/hw/nios2/cpu_pic.clog_core/src/log_core_test.c" 544L, 13181C                                                                                247,8-15      44%
+++ b/hw/nios2/cpu_pic.c
@@ -42,7 +42,9 @@ static void nios2_pic_cpu_handler(void *opaque, int irq, int level)
         } else if (!level) {
             env->irq_pending = 0;
             cpu_reset_interrupt(cs, type);
-        }
+        } else {
+            cs->interrupt_request |= type;
+       }
     } else {
         if (level) {
             cpu_interrupt(cs, type);

patch has been merged to qemu master, 5.1 version of which will include them.

@galak any plan to upgrade zephyr sdk qemu based on qemu 5.1? Thanks

@galak any plan to upgrade zephyr sdk qemu based on qemu 5.1? Thanks

@wentongwu QEMU 5.1 will (probably) be released on 18 Aug (see https://wiki.qemu.org/Planning/5.1).

@stephanosio thanks, not sure Zephyr's release plan, but if next Zephyr SDK release(probably 0.11.5) doesn't follow QEMU 5.1, I think we need cherry-pick above patches...

@galak just see Zephyr SDK has already upgraded QEMU to 5.1 version, but is there any plan to do a new release for Zephyr SDK recently? Thanks a lot！

@galak ping.

@galak @nashif @andrewboie ping


Not possible to have different readmodels

The current implementation does not allow to have different readmodel in one EventSourced root. The reason is that currently the readmodels are expected to be given as a list. Each readmodel holds its own state which is by nature completely different from other readmodels. Therefore 'State is not the same in each readmodel which gives me the expected error:
All elements of a list constructor expression must have the same type. This expression was expected to have type 'Conference.ConferenceReadModel', but here has type 'Conferences.ConferencesReadModel'.

closed by https://github.com/rommsen/ConfPlanner/pull/29


TypeError when defining MACD parameters

Hi, I am getting this error when using the parameter names 'window_slow', 'window_fast', and 'window_sign'. It works ok if I stop after the "close" parameter, but then I can't play with the window sizes. Is it something I've done wrong?
--> 730             ind_MACD = ta.trend.MACD(close=df["close"], window_slow=26, window_fast=12, window_sign=9)
TypeError: __init__() got an unexpected keyword argument 'window_slow'

I'm also hitting this kind of error with SMAIndicator

init() got an unexpected keyword argument 'n'

I'm also hitting this kind of error with SMAIndicator

init() got an unexpected keyword argument 'n'

Hi all,
The last release of the library update (standardize) the name of some input argument for the indicators. It looks like you are using an old version code and the current version of the documentation. So, please, update the version of the ta library:
pip install -U ta

The last version number is v0.7.0. Let me know if it is solving your issues.
Best,
Dario

Hi all,
The last release of the library update (standardize) the name of some input argument for the indicators. It looks like you are using an old version code and the current version of the documentation. So, please, update the version of the ta library:
pip install -U ta

The last version number is v0.7.0. Let me know if it is solving your issues.
Best,
Dario

Thanks Dario,
upgraded to 0.7.0
then I changed the arguments from n=int(num to window=int(num)
it worked for me

Thanks Dario,
upgraded to 0.7.0
then I changed the arguments from n=int(num to window=int(num)
it worked for me

I have the same problem with macd
indicator_macd = ta.trend.MACD(data['Close'], window_slow = 26, window_fast = 12, window_sign = 9)
TypeError: init() got an unexpected keyword argument 'window_slow'

Same problem with adx
indicator_adx_neg = ta.trend.adx_neg(data.High, data.Low, data.Close, window=14)
adx_neg() got an unexpected keyword argument 'window'

Hi @emiliano890,
What version of the library which are you using? You can check the versions of your packages using the command:
pip freeze

Try to use the last one (0.8.0):
pip install ta==0.8.0

Please, take a look at an example of how to call the MACD and ADX
Let me know if you continue getting problems.

Hello Dario,
I have ta==0.8.0
ta.trend.adx_pos(high, low, close, window=14, fillna=False)
only work without window.
The same with MACD only work without the parameters (windows_slow/fast/sign)

Hi @emiliano890
I will take a look ASAP.
Thanks!

Hi all,
I am running every example that you expose on this topic:

I have used the last version of ta (0.9.0), and I can run with python3.6 and python3.8.
The data used are from a publicly available financial dataset: https://www.kaggle.com/c/g-research-crypto-forecasting/data
I close the issue, but please feel free to re-open it.
Thanks.


How to feed frames from live video to a trained ONNX model

using System.Drawing classes I am able to read a .MP4 file and receive frames from it and store them as Bitmap,
this process is happening on a separate thread, simultaneously on another thread I want to feed this Bitmap data to my loaded pretrained .onnx model.
I am not able to find any documentation or support on how to achieve this.
Any suggestions will be helpful, thanks in advance

Hi @asheesh1996
You can take a look at this sample which uses a YOLO ONNX model for object detection inside a UWP app to analyze live video. Note that this sample is in the process of being upgraded to the latest version of ML.NET, but the logic to process videos should not change.
https://github.com/dotnet/machinelearning-samples/blob/master/samples/csharp/end-to-end-apps/ObjectDetection-Onnx/OnnxObjectDetectionApp/MainWindow.xaml.cs

Closing this issue for now since there are no docs related issues. @asheesh1996 I hope that the sample below was able to point you in the right direction. Please feel free to submit another issue if you find any docs related issues.

Closing this issue for now since there are no docs related issues. @asheesh1996 I hope that the sample below was able to point you in the right direction. Please feel free to submit another issue if you find any docs related issues.

Thanks, this was helpful, i have an idea how to proceed now :)


BIOS UUID troubleshooting not showing in document

I receveid problems in discover for physical servers, the BIOS UUID not showing in the appliance discover.
The error page shows this document and guide to execute some commands, but for Windows this commands not exists in document.
I received this via Support Engineer, the Microsoft can add this commands bellow for search BIOS UUID in this document:
[CmdletBinding()]
Param(
[Parameter(Mandatory=$True,Position=1)]
[string]$Hostname
)
$HostNS = "root\cimv2"
$error.Clear()
$Cred = Get-Credential
$Session = New-CimSession -Credential $Cred -ComputerName $Hostname
if ($Session -eq $null -or $Session.TestConnection() -eq $false)
{
Write-Host "Connection failed with $Hostname due to $error"
exit -1
}
Write-Host "Connection established with $Hostname"
#Get-WmiObject -Query "select uuid from Win32_ComputerSystemProduct"
$HostIntance = $Session.QueryInstances($HostNS, "WQL", "Select UUID from Win32_ComputerSystemProduct")
$HostIntance | fl *

@LeoMarks7 - Thank you for your question.
Can you please share with us the URL of the document that you are having issues with?
Please note that we scope issues on this repo to feedback related to the docs. If you have a product question, please post it on Microsoft QnA or Stack Overflow. Thank you for your understanding.

Hi,
Below is URL of the document:
https://docs.microsoft.com/en-us/azure/migrate/migrate-support-matrix-physical#physical-server-requirements
Regards,
Leonardo Marques
Obter o Outlook para iOShttps://aka.ms/o0ukef

De: MonikaReddy-MSFT @.>
Enviado: Thursday, July 22, 2021 12:03:34 AM
Para: MicrosoftDocs/azure-docs @.>
Cc: Leonardo Marques @.>; Mention @.>
Assunto: Re: [MicrosoftDocs/azure-docs] BIOS UUID troubleshooting not showing in document (#78664)
@LeoMarks7https://github.com/LeoMarks7 - Thank you for your question.
Can you please share with us the URL of the document that you are having issues with?
Please note that we scope issues on this repo to feedback related to the docs. If you have a product question, please post it on Microsoft QnA or Stack Overflow. Thank you for your understanding.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/78664#issuecomment-884625570, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AU5VZP5HPPQBGZ32GPDOKLLTY6DANANCNFSM5AYMRSIQ.

@LeoMarks7 the commands have been documented here: https://docs.microsoft.com/en-us/azure/migrate/troubleshoot-appliance#failed-to-fetch-bios-guid-for-server-during-validation

I realize that the redirect link in the section: https://docs.microsoft.com/en-us/azure/migrate/migrate-support-matrix-physical#physical-server-requirements is not redirecting to the right section. I will get it corrected.

@Vikram1988  - Thank you for providing your insights.
@LeoMarks7  - I hope @Vikram1988 has answered your question.
At this moment, Since there is no doc update required, We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Vickel: Watch ebrownargenta(?:@gmail.com)?

Vickel requests the watch of the watch_keyword ebrownargenta(?:@gmail\.com)?. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

ebrownargenta(?:@gmail\.com)? has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


0.9.2: documentation build fails

+ /usr/bin/sphinx-build -n -T -b man doc build/sphinx/man
Running Sphinx v7.0.1
WARNING: Invalid configuration value found: 'language = None'. Update your configuration to a valid language code. Falling back to 'en' (English).
making output directory... done
[autosummary] generating autosummary for: code_links.rst, devel/design.rst, devel/improving_markdown.rst, devel/make_release.rst, devel/sphinx_example_project.rst, index.rst, introduction.rst, markdown_base.rst, mpl_interactive.rst, nbplots.rst, scripts.rst, worked_example.rst
building [mo]: targets for 0 po files that are out of date
writing output...
building [man]: all manpages
updating environment: [new config] 12 added, 0 changed, 0 removed
reading sources... [  8%] code_links
reading sources... [ 16%] devel/design
reading sources... [ 25%] devel/improving_markdown
reading sources... [ 33%] devel/make_release
reading sources... [ 41%] devel/sphinx_example_project
reading sources... [ 50%] index
reading sources... [ 58%] introduction
reading sources... [ 66%] markdown_base
reading sources... [ 75%] mpl_interactive
reading sources... [ 83%] nbplots
reading sources... [ 91%] scripts
reading sources... [100%] worked_example

/home/tkloczko/rpmbuild/BUILD/nb2plots-0.6.1/doc/index.rst:37: WARNING: toctree contains reference to nonexisting document 'converted_example'
/home/tkloczko/rpmbuild/BUILD/nb2plots-0.6.1/doc/index.rst:37: WARNING: toctree contains reference to nonexisting document 'converted_plus_notebooks'
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
writing... python-nb2plots.3 { introduction worked_example scripts nbplots mpl_interactive code_links markdown_base devel/improving_markdown devel/sphinx_example_project devel/make_release devel/design } /home/tkloczko/rpmbuild/BUILD/nb2plots-0.6.1/doc/worked_example.rst:15: WARNING: unknown document: 'converted_example'
/home/tkloczko/rpmbuild/BUILD/nb2plots-0.6.1/doc/worked_example.rst:53: WARNING: unknown document: 'converted_plus_notebooks'
/home/tkloczko/rpmbuild/BUILD/nb2plots-0.6.1/nb2plots/nbplots.py:docstring of nb2plots.nbplots:84: WARNING: py:class reference target not found: NBPlotFlags
done

Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/sphinx/events.py", line 96, in emit
    results.append(listener.handler(self.app, *args))
  File "/home/tkloczko/rpmbuild/BUILD/nb2plots-0.6.1/nb2plots/runroles.py", line 309, in write_runfiles
    NAME2ROLE[code_type].write_queue(queue, app)
  File "/home/tkloczko/rpmbuild/BUILD/nb2plots-0.6.1/nb2plots/runroles.py", line 104, in write_queue
    self.write(node, app)
  File "/home/tkloczko/rpmbuild/BUILD/nb2plots-0.6.1/nb2plots/runroles.py", line 118, in write
    built = self.get_built(node, app)
  File "/home/tkloczko/rpmbuild/BUILD/nb2plots-0.6.1/nb2plots/runroles.py", line 142, in get_built
    own_params[code_type] = self._build(node, app)
  File "/home/tkloczko/rpmbuild/BUILD/nb2plots-0.6.1/nb2plots/runroles.py", line 148, in _build
    builder = self.builder_class(app)
  File "/home/tkloczko/rpmbuild/BUILD/nb2plots-0.6.1/nb2plots/sphinx2foos.py", line 18, in __init__
    super(MarkdownBuilder, self).__init__(app)
TypeError: __init__() missing 1 required positional argument: 'env'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/sphinx/cmd/build.py", line 285, in build_main
    app.build(args.force_all, args.filenames)
  File "/usr/lib/python3.8/site-packages/sphinx/application.py", line 353, in build
    self.events.emit('build-finished', None)
  File "/usr/lib/python3.8/site-packages/sphinx/events.py", line 107, in emit
    raise ExtensionError(__("Handler %r for event %r threw an exception") %
sphinx.errors.ExtensionError: Handler <function write_runfiles at 0x7f9566d78a60> for event 'build-finished' threw an exception (exception: __init__() missing 1 required positional argument: 'env')

Extension error (nb2plots.runroles):
Handler <function write_runfiles at 0x7f9566d78a60> for event 'build-finished' threw an exception (exception: __init__() missing 1 required positional argument: 'env')

Sorry mistake.
I've alredy reported that.


Retrieve registration information and display on risk form

An FYI, a migration as part of this PR will drop two columns on the Risk table "Mappa Level" and "Mappa Category". These are replaced with "RegistrationDetailsJson". This information will be updated via the overnight service.


Make topology zoomable

When a multinode topology is used often only part of it is displayed in the interface. Both in the network tab and in the edit --> topology.
It would be nice if the interface was zoomable.

Notifying @AlexanderWirtz

Alternatively, we could provide a button that opens the topology view in a separate tab, so that the whole screen can be used to view a topology. This screen is available when you open a topology in the top-level menu item Topologies.
We could also make the field of view size customizable so that the user decides how much space to dedicate to viewing the topology.


SoapySDRUtil probe freeze RSP1

Running probe multiple times will eventually block the my RSP1. Environment
is Raspberry PI3.
The only chance is to reboot the Raspberry.
Library mir:
root@xxxxx~ # ls -l /usr/local/lib/libmirsdrapi-rsp.so.2.13
-rw-r--r-- 1 root staff 183188 Mar 15 11:00 /usr/local/lib/libmirsdrapi-rsp.so.2.13
root@xxxxx:~ # SoapySDRUtil --probe="driver=sdrplay"
######################################################
Soapy SDR -- the SDR abstraction library
######################################################
Probe device driver=sdrplay

-- Device identification
driver=SDRplay
hardware=18070ED596
mir_sdr_api_version=2.130000
mir_sdr_hw_version=255

-- Peripheral summary
Channels: 1 Rx, 0 Tx
Timestamps: NO
Other Settings:
* RF Gain Select - RF Gain Select
[key=rfgain_sel, default=4, type=string, options=(0, 1, 2, 3, 4, 5, 6, 7, 8, 9)]
* IF Mode - IF frequency in kHz
[key=if_mode, default=Zero-IF, type=string, options=(Zero-IF, 450kHz, 1620kHz, 2048kHz)]
* IQ Correction - IQ Correction Control
[key=iqcorr_ctrl, default=true, type=bool]
* AGC Setpoint - AGC Setpoint (dBfs)
[key=agc_setpoint, default=-30, type=int, range=[-60, 0]]
* BiasT Enable - BiasT Control
[key=biasT_ctrl, default=true, type=bool]
* RfNotch Enable - RF Notch Filter Control
[key=rfnotch_ctrl, default=true, type=bool]
* DabNotch Enable - DAB Notch Filter Control
[key=dabnotch_ctrl, default=true, type=bool]

-- RX Channel 0
Full-duplex: YES
Supports AGC: YES
Stream formats: CS16, CF32
Native format: CS16 [full-scale=32767]
Antennas: RX
Corrections: DC removal
Full gain range: [0, 48] dB
IFGR gain range: [20, 59] dB
RFGR gain range: [0, 9] dB
Full freq range: [0.01, 2000] MHz
RF freq range: [0.01, 2000] MHz
CORR freq range:  MHz
Sample rates: 0.25, 0.5, 1, 2, 2.048, 6, 7, 8, 9, 10 MSps
Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz
root@xxxxx~ #
root@xxxxxx:~ # SoapySDRUtil --probe="driver=sdrplay"
######################################################
Soapy SDR -- the SDR abstraction library
######################################################
Probe device driver=sdrplay
Error probing device: map::at
root@xxxxx:~ # SoapySDRUtil --probe="driver=sdrplay"
######################################################
Soapy SDR -- the SDR abstraction library
######################################################
Probe device driver=sdrplay
^C
root@xxxx:~ #

Looks like one of those runs actually caused a crash before it got into this lock up state. FWIW, I didnt see this on my PC, so it might be something related to the driver on ARM specifically.
I know this is terribly annoying, but can you comment out the exception handling here: https://github.com/pothosware/SoapySDR/blob/master/apps/SoapySDRUtil.cpp#L192 and get a traceback from when it throws the first Error probing device: map::at?
Alternatively for the freeze up, throw in a tone of prints into SoapySDRPlay: https://github.com/pothosware/SoapySDRPlay/blob/master/Settings.cpp and lets find out what mirics API call is locked up, that should help @SDRplay look at the problem closer.

I've open a support case to SDRPlay website. Changing Raspberry was a good option. From RPI3 to my old RPI2. Anyway the rtl_airband is still stopping after few minutes.
Which is not happpening with my 8 euro junk RTL-SDR. I'll do experiments and keep
you informed. Indeed incredible anoying.
SoapySDR: device 'driver=sdrplay': using native sample format 'CS16' (fullScale=32767.0)
RTLSDR-Airband version v3.0.1 starting
SoapySDR: device 'driver=sdrplay': sample rate set to 3000000 sps
SoapySDR: device 'driver=sdrplay': gain set to 25.0 dB
SoapySDR: device 'driver=sdrplay' initialized
[INFO] Using format CS16.
SoapySDR: device 'driver=sdrplay' started
Writing to /root/audio/fm146.2125_20190318_08.mp3
Writing to /root/audio/fm146.2250_20190318_08.mp3
Writing to /root/audio/fm146.2375_20190318_08.mp3
Writing to /root/audio/fm146.2000_20190318_08.mp3
Writing to /root/audio/fm146.1875_20190318_08.mp3
Writing to /root/audio/fm146.0250_20190318_08.mp3
Writing to /root/audio/fm146.0375_20190318_08.mp3
Writing to /root/audio/fm146.0500_20190318_08.mp3
Writing to /root/audio/fm146.0625_20190318_08.mp3
Writing to /root/audio/fm146.0750_20190318_08.mp3
Writing to /root/audio/fm146.0875_20190318_08.mp3
Writing to /root/audio/fm146.1000_20190318_08.mp3
Writing to /root/audio/fm146.1125_20190318_08.mp3
Writing to /root/audio/fm146.1250_20190318_08.mp3
Writing to /root/audio/fm146.2750_20190318_08.mp3
Writing to /root/audio/fm146.2875_20190318_08.mp3
Writing to /root/audio/fm146.1375_20190318_08.mp3
Writing to /root/audio/fm146.1750_20190318_08.mp3
Writing to /root/audio/fm146.2500_20190318_08.mp3
Writing to /root/audio/fm146.2625_20190318_08.mp3
Writing to /root/audio/fm146.0000_20190318_08.mp3
Writing to /root/audio/fm146.0125_20190318_08.mp3
Writing to /root/audio/fm146.1500_20190318_08.mp3
Writing to /root/audio/fm146.1625_20190318_08.mp3
OSoapySDR device 'driver=sdrplay': readStream failed: OVERFLOW, disabling
All receivers failed, exiting
Freeing GPU memory
Cleaning up
Input threads closed

I know this is terribly annoying, but can you comment out the exception handling here: https://github.com/pothosware/SoapySDR/blob/master/apps/SoapySDRUtil.cpp#L192 and get a traceback from when it throws the first Error probing device: map::at?

Hi,
I don't have the freezes, and I am on x86-64 (ubuntu 14.04lts), but I also get "Error probing device: map::at". I always get this, not just ocassionally. I can't use SoapySDR due to this.
Here is output with the try and whole catch block uncommented:
Probe device
terminate called after throwing an instance of 'std::out_of_range'
what():  map::at
Aborted (core dumped)
despite what it says about a core dump, I do not have a core dump file because ubuntu. I will post it if I find it or succeed in producing it. How could I get a proper exception with stack traces and stuff?

(gdb) run --probe
Starting program: /usr/local/bin/SoapySDRUtil --probe
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device
[New Thread 0x7ffff3e03700 (LWP 25327)]
[New Thread 0x7ffff3602700 (LWP 25328)]
[Thread 0x7ffff3e03700 (LWP 25327) exited]
[New Thread 0x7ffff3e03700 (LWP 25329)]
[Thread 0x7ffff3e03700 (LWP 25329) exited]
[Thread 0x7ffff3602700 (LWP 25328) exited]
terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at

Program received signal SIGABRT, Aborted.
0x00007ffff6fbdc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff6fbdc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6fc1028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff77e4535 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff77e26d6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff77e2703 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff77e26c7 in std::rethrow_exception(std::__exception_ptr::exception_ptr) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff7b6ba97 in std::__basic_future<SoapySDR::Device*>::_M_get_result (this=0x7fffffffd6b0) at /usr/include/c++/4.8/future:598
#7  0x00007ffff7b683cc in std::shared_future<SoapySDR::Device*>::get (this=0x7fffffffd6b0) at /usr/include/c++/4.8/future:804
#8  0x00007ffff7b5d90f in SoapySDR::Device::make (inputArgs=...) at /home/vrm/sw/src/SoapySDR-soapy-sdr-0.7.1/lib/Factory.cpp:192
#9  0x00007ffff7b5db56 in SoapySDR::Device::make (args=...) at /home/vrm/sw/src/SoapySDR-soapy-sdr-0.7.1/lib/Factory.cpp:201
#10 0x0000000000413571 in probeDevice (argStr=...) at /home/vrm/sw/src/SoapySDR-soapy-sdr-0.7.1/apps/SoapySDRUtil.cpp:200
#11 0x0000000000413a1c in main (argc=2, argv=0x7fffffffda08) at /home/vrm/sw/src/SoapySDR-soapy-sdr-0.7.1/apps/SoapySDRUtil.cpp:320
(gdb)

"Error probing device: map::at" happens when findSDRPlay() does not find any available devices, so this is probably just the side effect of the root problem. The freezing is probably also a side effect as it happens after the device is stuck in an unavailable state.

Looks like we resolved the map at issue, it was no devices found, its reported better now. I guess any lock up has to be taken up with SDRPlay drivers. Thanks! Reopen if something comes up


go: 1.10 -> 1.10.1

https://github.com/golang/go/issues/24563

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Success on x86_64-linux (full log)
Attempted: go
Partial log (click to expand)
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
/nix/store/cyyx6wc23xmbbrsf4rlw5hv62nx152xr-go-1.10.1

Success on x86_64-darwin (full log)
Attempted: go
Partial log (click to expand)

ALL TESTS PASSED
---
Installed Go for darwin/amd64 in /nix/store/n7zg8az2mjgbj4r2ckxfz6xbsldap825-go-1.10.1/share/go
Installed commands in /nix/store/n7zg8az2mjgbj4r2ckxfz6xbsldap825-go-1.10.1/share/go/bin
post-installation fixup
strip is /nix/store/0fzpxnsanc02i4jsb1yhchjp4p62b2n3-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/n7zg8az2mjgbj4r2ckxfz6xbsldap825-go-1.10.1/bin
patching script interpreter paths in /nix/store/n7zg8az2mjgbj4r2ckxfz6xbsldap825-go-1.10.1
/nix/store/n7zg8az2mjgbj4r2ckxfz6xbsldap825-go-1.10.1

Success on aarch64-linux (full log)
Attempted: go
Partial log (click to expand)
cannot find section .dynamic
cannot find section .dynamic
wrong ELF type
wrong ELF type
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
/nix/store/g5d1grprb2476ji4mbhb4jkpb24l7gzl-go-1.10.1

Success on x86_64-linux (full log)
Attempted: go
Partial log (click to expand)
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
/nix/store/q2lvnkj8rrgmvffypxlhm50wfj9nakyc-go-1.10.1

Success on aarch64-linux (full log)
Attempted: go
Partial log (click to expand)
cannot find section .dynamic
cannot find section .dynamic
wrong ELF type
wrong ELF type
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
cannot find section .dynamic
/nix/store/nzbbn6ga5pyw91iryxicczxmxsfzhf7b-go-1.10.1

Failure on x86_64-darwin (full log)
Attempted: go
Partial log (click to expand)
cannot build derivation '/nix/store/5swa2hflqr22z12gdy03zw6h29k4mixv-python2.7-execnet-1.4.1.drv': 10 dependencies couldn't be built
cannot build derivation '/nix/store/nj1vahkyyhn8mh630ghmmk3gy0cblki9-python2.7-hg-git-0.8.11.drv': 8 dependencies couldn't be built
cannot build derivation '/nix/store/xmvmyjqp5hp81pn245cqdwcdy5wi174n-python2.7-pytest-xdist-1.22.2.drv': 11 dependencies couldn't be built
cannot build derivation '/nix/store/98vmxd6l7qrhl6h1ddxdldsnxb4lkjlj-mercurial-4.5.drv': 12 dependencies couldn't be built
cannot build derivation '/nix/store/palfzq4m2cy74lwcznd3viddbrkybw75-python2.7-hypothesis-3.45.2.drv': 14 dependencies couldn't be built
cannot build derivation '/nix/store/mcn096qg4j0kjjhcs2ch8r2cjix81a6w-python2.7-cryptography-2.1.4.drv': 22 dependencies couldn't be built
cannot build derivation '/nix/store/d2dahz1hi2jlin2cir6cnplifpn4r1sc-python2.7-paramiko-2.1.1.drv': 9 dependencies couldn't be built
cannot build derivation '/nix/store/pwlkmlcixk4fzjljq36whs9jc1wkpghk-bazaar-2.7.0.drv': 8 dependencies couldn't be built
cannot build derivation '/nix/store/2wvzsmphb2baxhzhmspll9w2ywgkh21p-go-1.10.1.drv': 21 dependencies couldn't be built
error: build of '/nix/store/2wvzsmphb2baxhzhmspll9w2ywgkh21p-go-1.10.1.drv' failed


Add explanation

This part of the text wasn't very clear imo, I just made it a bit easier to understand.
Also added a missing dot

Good catch!


Feature Request: Enable multi-line logging

Is your feature request related to a problem? Please describe.
When multiple lines of output are generated (for example, a stack trace when an error occurs), they all end up as single records in the ContainerAppConsoleLogs_CL Log Analytics table, with the same timestamp. Sorting these lines is impossible.
Describe the solution you'd like.
Implement the multi-line logging feature, that was introduced on AKS last year, see: https://techcommunity.microsoft.com/t5/azure-observability-blog/announcing-ga-multi-line-logging-in-azure-monitor-container/ba-p/3984289
Describe alternatives you've considered.
Adding an extra column to the ContainerAppConsoleLogs_CL with the line number, would also help when sorting, but the multi-line logging feature is more clear in keeping atomic log records together.
Additional context.
Announcing GA: Multi-Line Logging in Azure Monitor - Container Insights

Absence of this functionality is blocking us going into production with Container Apps, as it's near-impossible to get usable .NET stack traces from the logs with them split across multiple unsortable lines, so I hope this AKS feature can be implemented in ACA soon.


dbs as query param

The dbs query param should be permissive. It must not be possible to provide a dbs query param for a template with an explicit dbs property.

#1564 removes the dbs query param being sent from mapp requests. The dbs connection is either explicit for a query template or derived from layer < locale < workspace


Add another way to enable the dev login

When deploying on Netlify, the NODE_ENV is no longer set to "development"
but I still want to be able to use the dev login.
Part of #23.

This mostly works now, you can click the "Details" link from the netlify/tupu-app/deploy-preview check and login with out test user. I'd say we merge it, because then we can have a "staging" environment that we can check online after merging.
However, I didn't manage yet to get NEXTAUTH_URL to be set dynamically in next.config.js, not sure why. According to https://github.com/nextauthjs/next-auth/discussions/3176 it should have worked. In practice this means that we cannot use the PR previews, which is a bummer. I'll try later, or perhaps we need to switch to another alternative.

it's a good step ^^ then let's merge this, and leave open the NEXTAUTH_URL problem in the #23


Improve experience of adding Resources through bottom dock

Here are some features that could improve the bottom dock for Resource arrays:

add resource right as it is inserted into the picker. This helps add resources without an extra button click, hopefully not interfering with creation of new, local resources.
allow dragging multiple resources into the dock.
save recently added resources, like the other array docks do.

Dragging multiple resources into place (such as if the cell represents an array) would be huge for me also. In the broader sense this is something inexplicably missing from Godot at large, but regardless of that having the option to do that for arrays would be far better than what exists here.

I only just now figured out the functionality of the central panel is, and I'm still not sure what the left and right panels do at all.

Yeah, the left and right panels don't do much here. But they do work for arrays of strings. I will work on this, seeing it's needed.

inexplicably missing from Godot at large

Wait, I thought they brought this back? I guess it's still stuck back in the Godot 3.x inspector.

This feature has been implemented. For bugs, please open a new issue!


#17 issue, I can't move on to the next challenge.

Challenge Size your Images has an issue.
User Agent is: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.

Closing as not an issue with the site. Please use the Help chat room for getting challenge related help. Happy Coding!


working bc wallet credential offer test and agent abstraction layer

Signed-off-by: Sheldon Regular<EMAIL_ADDRESS>This PR contains a working Credential Offer test scenario using AATH based issuer. It also contains the implementation of on approach who's goal is to provide a layer of abstraction from the tests and the issuer and verifier agents to make common tests work with different issuers and verifiers. Looking mainly for review of this factory pattern approach.
This PR will remain in draft until I can run it with the lattes BC wallet, but thought I'd get this PR started to get review on the Agent Abstraction Layer.

This will also remain in draft until we update the GHA in the BC wallet repo to utilize AATH agents.

PR https://github.com/bcgov/bc-wallet-mobile/pull/235 has dependancy on this PR being merged.

Merging this. If feedback requires changes, they will be in future PRs.


Custom Compiled libvips For HEIC

Following the prior HEIF/HEIC issue https://github.com/lovell/sharp/issues/1105 regarding the need for a custom compiled libvips package I did so.
I've used this docker file https://github.com/jcupitt/docker-builds/blob/master/libvips-amazonlinux2/Dockerfile except I'm using lambci/lambda:build-nodejs10.x as a base to have nodejs support.
Installation of libvips goes well and is successful. It finds libheif and references it in the supported formats during install.
Where I'm running into an issue is that when I install sharp I'm missing reference to the libvip lib files.

Following this comment about adding a reference to ldconf  https://github.com/lovell/sharp/issues/327#issuecomment-167094002 I'm able to now see all the references to the libraries I'm supported in the custom libvip build.

But following the install I no longer have a vendors directory in the sharp directory of node_modules. My understanding is that the vendor folder contains the binaries of the libraries for sharp to use.

The sharp/vendor folder is for prebuilt binaries, which won't be created/present when a globally-installed libvips is detected, as is the case here.

@lovell Oh. I was expecting to get the output into sharp/vendor and be able to copy that over for usage into a Lambda Layer.
So, in the case of that not happening, I'm needing to move all of the required binaries (w/ mappings) to be used on the Lambda?

https://github.com/lovell/sharp/blob/master/binding.gyp#L160 ensures the compiled build/Release/sharp.node file always contains the vendor/lib location in its rpath so it might "just work" if you put other shared libraries in the same directory.
Another option might be setting LD_LIBRARY_PATH - good luck!

@smcguinness Were you able to make any progress with this?

@lovell I wasn't able to make it work by reference to that directory. It certainly may have been an issue with the binaries, or something else, but the process was long as it required deployments to test. I ultimately went down the path of a custom lambda layer to allow the references to exist on the server environment instead of within the vendor/lib directory.
Having the ability to do that would be definitely ideal because we ultimately moved away from doing Lamda@Edge because of the need for the layer. If we could have placed the compiled libraries with the run of a docker (extending the AWS release steps), I think it would be a great win for be able to add additional formats as needed (including the possibility of selectively compiling).
I've been hoping to put it together in a repo as I had to piece together repos, issues, and comments on my way through it to get work (first time using layers).

@smcguinness I'm trying to do something similar with self compiled binary of libvips for heif support. I also was unable to make it work by reference to binaries in the sharp directory. Do you have any suggested online resources for building a layer with the binaries?

For anyone coming here looking for a lambda layer: I've created one that includes sharp with HEIC/HEIF support: https://github.com/zoellner/sharp-heic-lambda-layer
It can be added to any lambda function. See repo for details.

For anyone coming here looking for a lambda layer: I've created one that includes sharp with HEIC/HEIF support: https://github.com/zoellner/sharp-heic-lambda-layer
It can be added to any lambda function. See repo for details.


About fp16 training

When the model is put in fp16 mode, does that mean all operations are in fp16? Also, is it possible to switch to a different optimization tool, say apex?

FP16 uses torch mixed precision. Under this scheme, a select subset of operations (e.g. softmax) are run in full precision, while other operations (e.g. matmul) are automatically cast to half precision. For more information, see https://pytorch.org/docs/stable/amp.html. If you're using DeepSpeed, which uses its own AMP implementation, you have the option to specify apex-like "levels" of mixed precision in the DeepSpeed config. See https://www.deepspeed.ai/features/#mixed-precision-training.

BTW: I just learned that Pytorch-Lightning has an --amp_backend flag that lets you switch to apex if you want even without DeepSpeed.


feat(inscriptions): add content moderator service

What would you like to be added:
Add a content moderation service that can be provided with an inscriptionId to moderate and mark nsfw if it contains questionable content.
Why is this needed:
To ensure that our services are compliant with potential regulations where nsfw may not be appropriate we want to ensure to give pre-moderation of said material and mark them accordingly.
Considerations:
We may want to add this as part of the worker scope built in a way so that it can run on a independent server depending on the amount of resources this process needs. It needs to be able to process a anything from 1,000 - 10,000 inscriptions per block with an interval of 3 - 60 minutes.
We only need to run moderation over media content so it won't be every inscription in a block, and most inscriptions are text based so we shouldn't be seeing an unreasonable amount of media to cover per block.

To be solved by third party vendors.


fuzzer: Increase coverage of encode and encode_decode

Increase the value ranges for fields of DecodeTestParameters. Ensure the still_picture limit is respected.
Use a single thread for encode_decode - This helps to avoid over-allocating threads when running with many cores.

Coverage increased (+0.02%) to 80.3% when pulling 7b93b3525d848a1b38091f0347c5766e5fbf5a8d on barrbrain:fuzzer into f55d508d55f5d81441a06db0bf51b5caeb754962 on xiph:master.

The following fields are not yet fuzzed:
pub struct EncoderConfig {
  ...
  pub sample_aspect_ratio: Rational,
  pub color_description: Option<ColorDescription>,
  pub mastering_display: Option<MasteringDisplay>,
  pub content_light: Option<ContentLight>,
  pub switch_frame_interval: u64,
  pub enable_timing_info: bool,
}

When sample_aspect_ratio is sufficiently large it can cause the calculated render_width to be out of range.
e.g. width: 7680, sample_aspect_ratio: Rational::new(9, 1), implies render_width = 69120 which exceeds the 16-bit range.
Also, enable_timing_info is mutually exclusive with still_picture.


Display list for dynamically generating scenes

This patch puts a rendering pipeline into place, with a solid architecture though currently somewhat limited functionality. There are a number of parts to it.
The display list is split into two parts. The renderlist part renders content into a reduced bit depth buffer. The scanlist part takes those reduced bit depth buffers and encodes into TMDS. Both renderers are implemented as direct threaded virtual machines, with the individual operations written in assembly for performance.
The scanlist rendering happens on the video interrupt and is intended to run in less than one scanline time. The renderlist rendering is striped across both cores, preferentially running in core1 main, but if that is busy, it runs in an interrupt in core0.
The application rendering happens in core0 main. It acquires display list builders (which in general means waiting for vsync), builds the display list, then sends them to the system, which swaps them each frame if available. If main takes longer than a single frame time, then the previous frame is repeated.
Text is rendered to a 1bpp buffer, using a fixed palette.
There are some rough edges. Naming and organization could be improved. There is a cavalier approach to safety. Obviously more functionality in the renderers can be built. But this commit represents a significant advance.

There's a lot here. I could split it into smaller pieces, but I'm not sure that would help much; the various parts of the design interlock, and I'm not sure you want to see my internal commits.
I'm open to criticism and can revise this PR. I also think it's a fairly solid base on which to build.

This is some impressive work. I can see your idea coming together. This runs perfectly on my pico (even in debug mode). This is a lot to review, but I do not want to slow down any progress by holding this up from merging. I am having some trouble wrapping my head around the many different components that are now working together to get the display working.
It seems like you are able to get code out at a much faster rate than I am, Do you have recommendations on what I can focus on so that we don't end up with overlapping work?

Playing around on this branch, already I've been able to do some cool stuff. Setting up the rp2040's RTC and adding a rudimentary fps counter we can get a pretty cool demo with a clock:
https://github.com/DusterTheFirst/pico-dvi-rs/assets/14093962/773ba49d-3ed7-4df5-92d8-05b0fff2ef02
Adding a loop of a bunch of nops into the core0 main to slow down the frame generation, the video is stil great due to the architecture you set up not requiring the frame generation to beam race.
https://github.com/DusterTheFirst/pico-dvi-rs/assets/14093962/b7edc543-d0bc-494e-95b1-5482aa203a21
I have ran into problems trying to get multiple lines of text on the screen, which I am still looking into. But I was able to move the text before the SMPTE color bar pattern, but not able to get one both before and after it.

Ok, I believe I've addressed the actionable comments. There are a number of items remaining for discussion and future development.
One is what to do next, and how to split that up. I think a reasonable strategy is to pick some classic demos to do. One set is m4vga. In particular, I think the conway demo could be ported over without too much trouble. The existing pipeline is not really designed around framebuffers; the easiest thing to do would be for renderlist to memcpy a scanline, but the code could also be be tweaked so that the scanlist reads directly from the framebuffer. Note that 640x480x1 bit is 38400 bytes,  and you need two (800x600 is 60000, also doable).
The tunnel demo (pixel doubled) would also be fun, but the pixel doubled asm scanout routines are not yet written.
I'll probably do a version of the PicoDVI tiles demo, with 16x16 4bpp palette tiles. I have the render and scan asm prototyped for that, but not yet wired up in the Rust codebase. There's also the question of coming up with a visually pleasing tileset :)
I'd personally like a way to select pinout using a cargo feature, as it's annoying cherry-picking my pinout commit.
Maybe it would be good to chat again? I'm happy to discuss.

I'd personally like a way to select pinout using a cargo feature, as it's annoying cherry-picking my pinout commit.

How would you suggest this be setup? Just one feature for my pinout, another for the adafruit's pinout?
I think these demos are a great direction and we have a lot of the tools already to get these demos working.
I'll merge these changes so we can start building off of them, and I'll shoot you an email about chatting again. I think with the amount of progress you've made its worth a chat.