Mouse Hover / Click  from Iframe and list view throws exception

Steps to Reproduce
working on Web application:
I have an IFrame with html which contains video player inside and list view below it
when switching with the mouse  between the IFrame and the List I get this:
The following assertion was thrown while routing a pointer event:
Assertion failed: org-dartlang-app:///packages/flutter/src/gestures/mouse_tracking.dart:467:14
trackedAnnotations.contains(annotation)
is not true

When the exception was thrown, this was the stack:
package:dart-sdk/lib/internal/js_dev_runtime/private/ddc_runtime/errors.dart 196:49 throw
package:dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 26:3 assertFailed
package:flutter/src/gestures/mouse_tracking.dart 467:52 _dispatchDeviceCallbacks
package:flutter/src/gestures/mouse_tracking.dart 297:9
package:flutter/src/gestures/mouse_tracking.dart 416:26 [_updateDevices]
...
Event: PointerHoverEvent#f30ce(position: Offset(205.7, 453.1), delta: Offset(10.7, -3.0), timeStamp: 0:00:29.136330, pointer: 0, kind: mouse, device: -1, down: false, pressure: 0.0, pressureMin: 0.0)
position: Offset(205.7, 453.1)

DOCTOR:
[✓] Flutter (Channel dev, v1.13.6, on Mac OS X 10.14.5 18F203, locale en-IL)

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 11.2.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 3.5)
[✓] Connected device (2 available)

• No issues found!

Hi @giladna
To better address the issue, would be helpful
if you could post a minimal code sample to reproduce the problem
Thank you

@VladyslavBondarenko
how can I upload my project?

@giladna
Can you modify my code sample to reproduce the exception?

Code sample
import 'package:flutter/material.dart';
import 'package:webview_flutter/webview_flutter.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Welcome to Flutter',
      home: SafeArea(
        child: Column(
          children: <Widget>[
            Container(
              height: 200,
              child: WebView(
                initialUrl: Uri.dataFromString(
                        '',
                        mimeType: 'text/html')
                    .toString(),
                javascriptMode: JavascriptMode.unrestricted,
              ),
            ),
            Container(
              height: 200,
              child: ListView(
                padding: EdgeInsets.all(8),
                children: <Widget>[
                  Container(
                    height: 50,
                    color: Colors.amber[600],
                    child: Center(child: Text('Entry A')),
                  ),
                  Container(
                    height: 50,
                    color: Colors.amber[500],
                    child: Center(child: Text('Entry B')),
                  ),
                  Container(
                    height: 50,
                    color: Colors.amber[100],
                    child: Center(child: Text('Entry C')),
                  ),
                ],
              ),
            ),
          ],
        ),
      ),
    );
  }
}

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution


Support SPRAM Framebuffer

Add iCE40 SPRAM support for the new framebuffer design.
Current demos for iCEBreaker use BRAM, which restricts them to 160x90 in 4 colours. With SPRAM, iCEBreaker could support 320x180 in 16 colours as used on other boards.

had you some code to share?
I'm struggling with maskwren, examples in the wild are hard to find...
https://projectf.io/posts/spram-ice40-fpga/
makes a start, but....
tx


[Feature] forceRerender as an array

Right now we have only one property on the forceRerender prop, I had to add my createOrder function to it, which is an useCallback function, and it respects the array of properties of it to force the rerender.
I think we can make it more readable/reliable if we make the forceRerender be an array, so we can pass as many properties to it as we want, and it would be very easy to implement.

Hey @pedroapfilho, sure I'm open to adding this feature with turning the forceRerender prop into an array. Right now we expect this prop to be a primitive value so it would be a breaking change. Would you be up for sending a PR for adding this feature?

I would! This change is very simple! I'll do it today at night!


Support composer installer

Allow installing shopware as dependency and to overwrite the install path and name

1. Why is this change necessary?
Sometimes you need to install shopware as dependency and integrate it in an existing project
2. What does this change do, exactly?
Enables support for composer installers, so that you can change the install path/name
3. Describe each step to reproduce the issue or behaviour.
4. Please link to the relevant issues (if any).
5. Which documentation changes (if any) need to be made because of this PR?
6. Checklist

[x] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[x] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

Why do we need that?
Is https://github.com/shopware/composer-project not something you want?

Why do we need that?
Is https://github.com/shopware/composer-project not something you want?

No. The composer project forces a specific project structure. We want to be able to specify the structure by ourselves. For example:

app
bin
shopware
...

The existing composer project forces a specific application structure.

But the structure the project enforces is the structure Shopware needs to work properly. What is the benefit to specify another structure if Shopware won't work?

What would be the downside of being able to do that? The advantage would be that you CAN use it. No one MUST use it.

What would be the downside of being able to do that?

One more dependency to care about?

We want to be able to specify the structure by ourselves.

The composer-project ist boilerplate code, you can change everything to your needs :-)

The composer-project ist boilerplate code, you can change everything to your needs :-)
Again: it is about EXISTING projects. I know we could use the composer project, if we start a new one. But how does that help me to integrate shopware as a dependency in existing projects?

The downside I see is setting a wrong expectation. If I am able to just install Shopware using your change, but Shopware isn't able to function as expected, that might lead developers into wondering what they are doing wrong.
What I do not understand currently: What existing projects might need a copy of Shopware code that isn't able to work due to where it is installed?

I wonder why you'd think it wouldn't work. We have exactly such a setup and it runs perfectly. And basically it is nothing else than the composer project, only with the difference that this one can also be used for existing projects.

@mschakulat did you try to install plugins, themes etc?

Well, you pretty sure needed some changes to e.g. set the Version of Shopware. Are plugins just installed inside the of the shopware dependency? What about logs and caches? You might have to create some symlinks to make that work.
I'm not saying that it can't be fixed, just that it won't work as one might expect it to out of the box.

This PR was closed due to inactivity. If this change is still important to you, feel free to create a new pull request.
For more information about our contribution guidelines, see https://developers.shopware.com/contributing/contribution-guideline/.


Ecto interpolating select_merge keys into query

Environment

Elixir version (elixir -v): 1.10.2
Database and version (PostgreSQL 9.4, MongoDB 3.2, etc.):  PostgreSQL 12.2
Ecto version (mix deps):  3.3.4
Database adapter and version (mix deps): postgrex 0.15.3
Operating system: Ubuntu 20.04

Current behavior
The issue is outlined in this elixirforum post in a bit more detail, but the gist is that when I try to inject a dynamic key into a select_merge call for a subquery, the quoted expression is escaped incorrectly, and throws an error.
Example, when composing a subquery using a dynamic key for the select:
x = "play_id"
q = from p in Galaxy.Dimension.Play, select: %{}, select_merge: %{^x => p.id}, limit: 10
Galaxy.Repo.all(from x in subquery(q))

** (Ecto.SubQueryError) the following exception happened when compiling a subquery.

    ** (Ecto.QueryError) only atom keys are allowed when selecting a map in subquery, got: `%{^0 => &0.id()}` in query:

    from p0 in Galaxy.Dimension.Play,
      limit: 10,
      select: %{^"play_id" => p0.id}

The subquery originated from the following query:

from p0 in subquery(from p0 in Galaxy.Dimension.Play,
  limit: 10,
  select: %{^"play_id" => p0.id}),
  select: p0

    (ecto) lib/ecto/repo/queryable.ex:161: Ecto.Repo.Queryable.execute/4
    (ecto) lib/ecto/repo/queryable.ex:17: Ecto.Repo.Queryable.all/3

Expected behavior
Expected behavior is basically just that the key gets escaped correctly, and I can use variables to compose subquery select statements.  I managed to write workaround using Macro.prewalk where I just inject the atom directly into the quoted expression held at query.select.expr.  I have a basic understanding of what's going on here, but not enough to pinpoint exactly where a change would fix this in ecto.
key = "play_id"

expr =
  Macro.prewalk(query.select.expr, fn
    {{:^, [], [0]}, {{:., [], [table_ref, ^col]}, [], []}} ->
      {key, {{:., [], [table_ref, col]}, [], []}}
    expr -> expr
  end)

select =
  query.select
  |> Map.put(:expr, expr)
  |> Map.put(:params, Keyword.drop(query.select.params, [key]))

Map.put(query, :select, select)

Appreciate all the work you all put into this project!  Ecto has enabled us to do some pretty incredible things wrt composing queries dynamically.

This is intentional. :) We need to know the names of fields in subqueries so we can select and perform type checking in the parent. An interpolated name does not allow us to do so. I recommend for you to return a map such as %{field: ^x, value: p.id}. I do not recommend mangling the query by hand, it is private API and you can even expose yourself to issues such as SQL injection. In any case, thanks for the report!

Thanks for the response!  For my own understanding, can you expand a bit on the type checking portion?  In the live use case the interpolated key is an existing atom, and as part of mangling the query we're removing it from the params keyword list.  How does the type checking piece fit in there?  It might add some clarity to this if I provide the live code we're using to dynamically allow group-bys for our system.  column in this case is a compile-time generated module/struct that references a single field in a schema to construct a dynamic query off of.  So model_key in this case is a reference to the atom used for the named join on the query.  Hopefully this makes sense:
defimpl Ultimate.Domain.Groupable, for: Any do
  import Ecto.Query

  def group(nil, key, _query) do
    raise "Groupable not available for: #{key}"
  end

  def group(column, key, query) do
    %{model_key: model_key} = column # get the name for the column's join
    join = Ultimate.Domain.Joinable.join(column, key, true, query)  # joins in the schema needed
    col = Ultimate.Domain.Column.field(column) # get the specific field on the referenced schema

    from(join)
    |> group_by([{^model_key, x}], field(x, ^col))
    |> select_merge([{^model_key, x}], %{^key => field(x, ^col)})
    |> inject_key(key, col)
  end

  def group_context(nil, key, _query) do
    raise "Groupable not available for: #{key}"
  end

  def group_context(_column, key, query) do
    query
    |> from()
    |> select_merge([totals], %{^key => field(totals, ^key)})
    |> inject_key(key, key)
  end

  defp inject_key(qry, key, col) do
    expr =
      Macro.prewalk(qry.select.expr, fn
        {{:^, [], [0]}, {{:., [], [table_ref, ^col]}, [], []}} ->
          {key, {{:., [], [table_ref, col]}, [], []}}
        expr -> expr
      end)

    select =
      qry.select
      |> Map.put(:expr, expr)
      |> Map.put(:params, Keyword.drop(qry.select.params, [key]))

    Map.put(qry, :select, select)
  end
end

I understand that this is a little risky with respect to it being a private API and would be at risk for sql injection if this ended up as a user input.  I'm just curious where the type checking portion comes into place such that an (existing) atom held in a variable could not be a valid key for the select_merge.  Thanks again for taking the time to look at this :)

You can do things like this:
from s in subquery(query), where: s.field == ^param

And we need to know the field information to check/cast the param. This requires knowing the fields names, which is hard with the interpolation.


Add/clarify OAI-PMH documentation

Purpose / why
Reading the OAI-PMH documentation page yesterday did not answer a couple of questions I had. I asked those questions in Slack. After seeing the answers in Slack, I realized part of the answers were implicit in the existing documentation page, but not really clear if you are coming to this fresh.
What changes were made?

Adds two new sections to the OAI-PMH doc page: OAI-DC Metadata Format/Metadata Mappings and Creating additional metadata formats
Reorganizes some of the existing documentation content into these two sections, and adds some additional information to them
Clarifies that the "OAI Dublin Core (RDF Mapping)" you see in the OAI config is not a separate RDF mapping
Adds link to example metadata format plugin

Verification??
These edits are based on responses from @seth-shaw-unlv and @jordandukart in Slack (here and here(thread)
They may wish to verify I have not misrepresented their responses in working them into the documentation page.
Interested Parties
@Islandora/documentation
Checklist

Pull-request reviewer should ensure the following

[ ] Does this PR link to related issues?
[ ] Does the proposed documentation align with the Islandora Documentation Style Guide?
[ ] Are the changes accurate, useful, free of typos, etc?

Person merging should ensure the following

[ ] Does mkdocs still build successfully? (This is indicated by TravisCI passing. To test locally, and see warnings, see How To Build Documentation.)
[ ] If pages are renamed or removed, have all internal links to those pages been fixed?
[ ] If pages are added, have they been linked to or placed in the menu?
[ ] Did the PR receive at least one approval from a committer, and all issues raised have been addressed?

The note about creating a profile via the twig templating system predates the metadata map plugins; I would scratch that. I would also move the note about the metatag plugin into the "OAI-DC Metadata Format/Metadata Mappings" section as the RDF and Metatag plugins are both ways of getting defining OAI-DC.

Feedback incorporated.

@kspurgin, speaking on behalf of DIG, are you planning on making changes do this PR, are you waiting for someone to review, or do you need any help from DIG to get this merged into the documentation? Just trying to help. Thanks in advance.

Thanks for checking in, @ysuarez.
I don't plan on making any more changes unless further changes are requested. I believe I incorporated all existing feedback from @seth-shaw-unlv and @jordandukart


Prometheus generates "could not convert" error messages for heaters

Home Assistant release with the issue:
0.102.1
Last working Home Assistant release (if known):
none
Operating environment (Hass.io/Docker/Windows/etc.):
docker
Integration:
homematic / prometheus
Description of problem:
The prometheus export should just ignore this sensor or value. It could also just store the temperature instead of the mode of operation...
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

prometheus:
  namespace: hass
homematic:
  interfaces:
    wireless:
      host: <IP_ADDRESS>

Logs (if applicable):
2019-11-24 15:24:27 WARNING (SyncWorker_2) [homeassistant.components.prometheus] Could not convert <state climate.neq1413228=heat; hvac_modes=['auto', 'heat', 'off'], current_temperature=22.4, min_temp=4.5, max_temp=30.5, target_temp_step=0.5, temperature=20.0, preset_mode=None, preset_modes=['boost', 'comfort', 'eco'], battery=2.8, rssi_peer=-69, valve=0, mode=Manual, id=NEQ1413228, interface=wireless, friendly_name=Thermostat Arbeitszimmer, supported_features=17 @ 2019-11-24T15:23:19.162086+01:00> to float

Additional information:

I get similar errors with components.eq3btsmart.climate:
2019-11-27 19:32:56 WARNING (SyncWorker_14) [homeassistant.components.prometheus] Could not convert <state climate.bawialnia=auto; hvac_modes=['heat', 'off', 'auto'], current_temperature=23.0, min_temp=5.0, max_temp=29.5, temperature=23.0, preset_mode=None, preset_modes=['boost', 'away'], away_end=None, is_locked=True, low_battery=True, valve=69, window_open=False, friendly_name=bawialnia, supported_features=17 @ 2019-11-26T22:09:58.730866+01:00> to float

Climate entities should be ignored.


Fixes

For the HttpStatus class there is a much simpler and better way to bridge it; because it's an abstract class that can't be instantiated you can actually just do registry.addSource() with the original code of the class, like we do in flutter_eval Colors.

For the HttpStatus class there is a much simpler and better way to bridge it; because it's an abstract class that can't be instantiated and just has statics you can actually just do registry.addSource() with the original code of the class in a string, like we do in flutter_eval Colors.

That's auto generated tho should I remove it?

Oh, nice. I'm assuming you still had to write the __static getter functions and registerBridgeFunc() stuff yourself though no?
Either way I would say it should be replaced, yeah. It's a lot more efficient to code it as a string if possible since the compiler can tree-shake unused values, plus in this case doing so is super easy. I should add a feature to detect this in the auto generator though.

Oh, nice. I'm assuming you still had to write the __static getter functions and registerBridgeFunc() stuff yourself though no?
Either way I would say it should be replaced, yeah. It's a lot more efficient to code it as a string if possible since the compiler can tree-shake unused values, plus in this case doing so is super easy. I should add a feature to detect this in the auto generator though.

No, I wrote a handy eval generator to help me bridge packages I needed for my project so, I used it here too.

No, I wrote a handy eval generator to help me bridge packages I needed for my project so, I used it here too.

That's really cool. If you're open to sharing the source I'd love to try to integrate that into dart_eval.

Sorry for the delay on this. Please revert this commit as it is no longer necessary due to the changes I made in v0.7.6. Otherwise everything looks great now!

done


Detect the PeerPodService is installed and running

I don't have peerpod-ctrl installed on my cluster, and I get a message saying the PeerPodService is initialized (which seems ok so far):
$ kubectl logs -l app=cloud-api-adaptor -n confidential-containers-system --tail=100
+ exec cloud-api-adaptor libvirt -uri 'qemu+ssh://runner@<IP_ADDRESS>/system?no_verify=1' -data-dir /opt/data-dir -pods-dir /run/peerpod/pods -network-name default -pool-name default -socket /run/peerpod/hypervisor.sock
cloud-api-adaptor version v0.7.0-dev
  commit: ffef318cecb7028fb186ba525d9f70ca7376c86f-dirty
  go: go1.20.7
cloud-api-adaptor: starting Cloud API Adaptor daemon for "libvirt"
2023/08/17 17:19:24 [adaptor/cloud/libvirt] libvirt config: &libvirt.Config{URI:"qemu+ssh://runner@<IP_ADDRESS>/system?no_verify=1", PoolName:"default", NetworkName:"default", DataDir:"/opt/data-dir", VolName:"podvm-base.qcow2"}
2023/08/17 17:19:25 [adaptor/cloud/libvirt] Created libvirt connection
2023/08/17 17:19:25 [adaptor] server config: &adaptor.ServerConfig{TLSConfig:(*tlsutil.TLSConfig)(0xc0003b2280), SocketPath:"/run/peerpod/hypervisor.sock", CriSocketPath:"", PauseImage:"", PodsDir:"/run/peerpod/pods", ForwarderPort:"15150", ProxyTimeout:300000000000}
2023/08/17 17:19:25 [util/k8sops] initialized PeerPodService

^^^

But then it start saying peerPod could not be created which is misleading:
...
2023/08/17 17:21:03 [adaptor/cloud/libvirt] Creating VM 'podvm-http-server-a42a995d'
2023/08/17 17:21:03 [adaptor/cloud/libvirt] Starting VM 'podvm-http-server-a42a995d'
2023/08/17 17:21:05 [adaptor/cloud/libvirt] VM id 653
2023/08/17 17:21:41 [adaptor/cloud/libvirt] Instance created successfully
2023/08/17 17:21:41 [adaptor/cloud/libvirt] created an instance podvm-http-server-a42a995d for sandbox a42a995dc0882927c0bfbcdfeb68b410e3a6c4337098ff0a2f1b5134a2d2c8b5
2023/08/17 17:21:41 [adaptor/cloud] failed to create PeerPod: the server could not find the requested resource (post peerPods.confidentialcontainers.org)

^^^

2023/08/17 17:21:41 [adaptor/cloud] created an instance podvm-http-server-a42a995d for sandbox a42a995dc0882927c0bfbcdfeb68b410e3a6c4337098ff0a2f1b5134a2d2c8b5
...

The problem seems to be that it relies on s.ppService != nil test to determine the PeerPodService is installed, but this will always return true because the service is always initialized.
Example in https://github.com/confidential-containers/cloud-api-adaptor/blob/main/pkg/adaptor/cloud/cloud.go#L293:
if s.ppService != nil {
		if err := s.ppService.OwnPeerPod(sandbox.podName, sandbox.podNamespace, instance.ID); err != nil {
			logger.Printf("failed to create PeerPod: %s", err.Error())
		}
}

It should instead check somehow that the peerpod-ctrl is installed and running. On possible solution could be checking that the REST API endpoint exists. On the example above:
if s.ppService.isActive() {
		if err := s.ppService.OwnPeerPod(sandbox.podName, sandbox.podNamespace, instance.ID); err != nil {
			logger.Printf("failed to create PeerPod: %s", err.Error())
		}
}

Cc @snir911 @bpradipt

Nice catch!
Would be enough to check the endpoint? or we have to validate the controller is running, is there a common practice for such check?
For now, one simple solution would be to improve the error msg, something like 'failed to create the PeerPod resources monitoring object" WDYT?

Would checking the presence of the CRD peerpods... suffice?

It will for the current use case, however, i'm not sure about the case where this controller is embedded in another operator

Nice catch! Would be enough to check the endpoint? or we have to validate the controller is running, is there a common practice for such check? For now, one simple solution would be to improve the error msg, something like 'failed to create the PeerPod resources monitoring object" WDYT?

I don't know if there is a common practice TBH. But I think if the controller had an endpoint like /version to return information, it would be used as a checking endpoint.
Improving the error msg on short term if things get too complicated is okay for me.


'TransitionProps' of ExpansionPanel not recognized by react

[ ] The issue is present in the latest release.
[ ] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

Expected Behavior 🤔

Steps to Reproduce 🕹

Steps:

Context 🔦

Your Environment 🌎

Tech
Version

Material-UI
v4.?.?

React

Browser

TypeScript

etc.

Your issue has been closed because it does not conform to our issue requirements.
Please fill out the issue template and provide a minimal reproducible example.


(BKR-472) (BKR-475) Fix solaris for install_pe_on with 2015.2

When trying to install puppet-agent collection packages through
install_pe_on, eventually install_puppet_agent_pe_promoted_repo_on
gets called but has no entry for where the solaris packages are kept.
This commit adds the ability for solaris to install PC puppet-agent
packages.

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1841/
Test FAILed.

retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1867/
Test PASSed.


Better Feedback on Query Status

This PR does two things:

Trigger invalidate on the data object for each page whenever queries have changed, and update their contents client side
Report on the status of the queries with "toasts" in the bottom right 2.

See below -- no hard refresh on SQL edits:

Still to do:

[x] Some of our built-in components are not reactive to client side updates to the data object
[ ] The set context operation in preprocess is also not reactive

Cool - big improvement on the current "have to go back to my console to see if it's ready" experience.
Could you make it more obvious the that query is "running" when it's grey?
I'm imagining that if I had a query that was taking a longer time to run eg Snowflake seems to take a while, then it might not be super obvious what all the grey boxes mean?
For example you could make the text say:

working_query running
and then
working_query complete / failed

Or you could animate the toast with a ... or a spinner or something?

Just had another thought while I was working in stackblitz. The server crashed and the only feedback was on the console.
The final part of the "feedback experience" that hasn't made it into the UI yet, is whether the server is running (or has crashed).
It might be out of scope for this, but a little card popping up saying "Server crashed" would address this.
(Obviously it would be best if the server never crashed silently - ie with no visual feedback, but it still does in some edge cases)

@eleweek
Picking up the conversation here. Three items outstanding to get this into main:

[ ] preprocess creates local variables for each query {query_name}  in a way that is not reactive
[ ] tests aren't passing on this PR, in part because of this
[ ] merge conflict in __layout

@archiewood @ud3sh @hughess -- this is ready for review.
Would be helpful to get some additional tire kicking on this before we merge.
Thanks,


Cannot boot a new kernel

Hi,
I am working on compiling a kernel with BPF modules included for tc and the p4c-ebpf. I am stuck at booting a new kernel.
I was following the p4pi kernel compilation guide at https://github.com/p4lang/p4pi/tree/master/p4pi-kernel/README.md  with the current raspberrypi-linux version (5.10.60) taken from https://github.com/raspberrypi/linux.
I have the deb packages compiled:
-rw-r--r--  1 pi pi  7562092 Aug 24 09:06 p4pi-linux-headers-5.10.60-v8+_5.10.60-v8+-1_arm64.deb
-rw-r--r--  1 pi pi 22517552 Aug 24 09:07 p4pi-linux-image-5.10.60-v8+_5.10.60-v8+-1_arm64.deb
-rw-r--r--  1 pi pi  1118852 Aug 24 09:06 p4pi-linux-libc-dev_5.10.60-v8+-1_arm64.deb

However, after installing the image and header packages, the system still boots the old kernel:
pi@p4pi:~$ uname -a
Linux p4pi 5.10.52-v8+ #1 SMP PREEMPT Sat Aug 7 03:52:12 UTC 2021 aarch64 GNU/Linux

Do you have any ideas which step is missing?
Thanks,
Tamas

@levaitamas By default, the deb packages install the kernel in /boot/vmlinuz-5.10.60-v8+, however, Raspberry Pi 4
is using thekernel8.img filename on the boot partition when loading the kernel. Thus, you can replace the existing kernel with:
sudo mv /boot/vmlinuz-5.10.60-v8+ /boot/kernel8.img
sudo reboot

Thank you, @rst0git! It works.


Fix print preview on mobile

Fix print preview on mobile

We need to replace preview button with download button as react-pdf PDFViewer doesn't support mobile.
Ticket created #196


[Feature Request] Open Recipe Tree keybind

I'd like a keybind to open the Recipe Tree from in-world, instead of needing to hit E and then clicking on the Recipe Tree button with my mouse.

There is already a way, search "View tree" in the emi config. It will only open the tree when your inventory is open.

Works for me. I missed the keybind in the EMI config!


script: Print the realm's log in uart1

This PR modifies launch-realm.sh script so that it can print Realm's log messages in UART1 with islet while being compatible with the existing TF-RMM. For the default option, which one would be better: tf-rmm or islet?
Usage: ./launch-realm.sh <RMM>
  ex) ./launch-realm.sh tf-rmm     // Launch Realm with TF-RMM configuration
                                    (UART0:Host & Realm, UART3:RMM)
  ex) ./launch-realm.sh islet      // Launch Realm with ISLET configuration
                                    (UART0:Host, UART1:Realm, UART3:RMM)
  ex) ./launch-realm.sh            // The default option with no argument currently assumes TF-RMM

For the default option, which one would be better: tf-rmm or islet?

I think it's better to have two scripts (launch-realm-tf-rmm.sh launch-realm-islet.sh).
And copy it to launch-realm.sh on fvp-cca script according to rmm's type, which mean launching fvp time.
Then we don't need to consider it.

For the default option, which one would be better: tf-rmm or islet?

I think it's better to have two scripts (launch-realm-tf-rmm.sh launch-realm-islet.sh). And copy it to launch-realm.sh on fvp-cca script according to rmm's type, which mean launching fvp time. Then we don't need to consider it.

Thank you for the good suggestion. I wanted to remove the duplicate portion with the one file, yet the suggestion seems better in terms of usability. I will reflect it!


Correct effective context translation for NS_OPTIONS anon C++ enums attempt 2

Second attempt at: 62058

@swift-ci please smoke test

@swift-ci please smoke test

Please run the full test suite instead of just smoke test .

Please run the full test suite instead of just smoke test .

Yes I will, I'm just trying to run the macOs smoke tests repeatedly since I'm unable to reproduce the failure that caused the revert locally, and it seems to have passed in many many CI runs prior to the revert. https://ci.swift.org/job/swift-PR-macos-smoke-test/4317/.
Did this break PR break something a full run of smoke test would've caught?

First smoke test:

@swift-ci please test

@swift-ci please test

@swift-ci please test source compatibility


stop manager before protocols

What does this PR do?
Stops the USM ebpf-manager before the individual protocols.
Motivation
This is to prevent a send on a closed channel in the event consumers. If the manager is not stopped, it will continue to consume from the ebpf perf/ring buffers and call callbacks. Those callbacks will try to send on a closed channel due to a race on the closed flag.
Additional Notes
Technically this is a data race on the closed flag, but there isn't a good way to prevent it without having some performance impact.
Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Since the issue happens only during termination of system-probe, can't we use recover to handle the panic?

Are you certain this won't have the opposite effect, where the protocol depends on the manager being active, leading to a race condition if we close the manager while the protocol is still running?

where the protocol depends on the manager being active, leading to a race condition if we close the manager while the protocol is still running?

Great question. I don't know how you have architected the protocols, so I don't know what assumptions they are making. How might we answer that question?

Since the issue happens only during termination of system-probe, can't we use recover to handle the panic?

I don't believe so, because the place that it happens would not be able to distinguish between normal operation and shutdown. Beyond that, I wouldn't ever recommend solving a known panic with recover.

Did you run your branch in staging?

The proposed change is problematic - if you run system-probe locally and terminates it generates bunch of errors logs are the protocols' termination fails

2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__BIO_new_socket/sYdtr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__BIO_new_socket/sYdtr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_do_handshake/p8EIr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_do_handshake/p8EIr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_connect/p8EIr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_connect/p8EIr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_set_bio/p8EIr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_set_fd/p8EIr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_read/p8EIr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_read/p8EIr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_write/p8EIr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_write/p8EIr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_shutdown/p8EIr : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__BIO_new_socket/FwT2x : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__BIO_new_socket/FwT2x : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_read_ex/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_read_ex/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_write_ex/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_write_ex/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_do_handshake/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_do_handshake/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_connect/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_connect/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_set_bio/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_set_fd/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_read/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_read/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_write/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_write/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_shutdown/MCwQ6 : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_read_ex/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_read_ex/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_write_ex/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_write_ex/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_do_handshake/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_do_handshake/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_connect/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_connect/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_set_bio/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_set_fd/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_read/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_read/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_write/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_write/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_shutdown/mXZtH : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__BIO_new_socket/9GgjU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__BIO_new_socket/9GgjU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_handshake/TFRmg : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__gnutls_handshake/TFRmg : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_transport_set_int2/TFRmg : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_transport_set_ptr/TFRmg : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_transport_set_ptr2/TFRmg : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_record_recv/TFRmg : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__gnutls_record_recv/TFRmg : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_record_send/TFRmg : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__gnutls_record_send/TFRmg : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_bye/TFRmg : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_deinit/TFRmg : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_handshake/gCDNU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__gnutls_handshake/gCDNU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_transport_set_int2/gCDNU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_transport_set_ptr/gCDNU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_transport_set_ptr2/gCDNU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_record_recv/gCDNU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__gnutls_record_recv/gCDNU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_record_send/gCDNU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__gnutls_record_send/gCDNU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_bye/gCDNU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_deinit/gCDNU : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_read_ex/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_read_ex/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_write_ex/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_write_ex/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_do_handshake/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_do_handshake/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_connect/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_connect/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_set_bio/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_set_fd/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_read/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_read/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_write/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__SSL_write/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__SSL_shutdown/LZftb : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__BIO_new_socket/cDOlJ : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__BIO_new_socket/cDOlJ : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_handshake/CDPAh : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__gnutls_handshake/CDPAh : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_transport_set_int2/CDPAh : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_transport_set_ptr/CDPAh : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_transport_set_ptr2/CDPAh : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_record_recv/CDPAh : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__gnutls_record_recv/CDPAh : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_record_send/CDPAh : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uretprobe__gnutls_record_send/CDPAh : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_bye/CDPAh : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_ssl.go:733 in func1) | detach hook uprobe__gnutls_deinit/CDPAh : the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | INFO | (pkg/process/monitor/process_monitor.go:459 in Stop) | process monitor stopping due to a refcount of 0
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 11 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 0 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 5 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 7 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 2 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 13 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 6 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 9 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 1 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 4 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 12 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 8 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 14 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 3 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 15 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/process/monitor/process_monitor.go:252 in func1) | callback runner 10 has completed its execution
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:423 in removeInspectionResultFromMap) | could not remove inspection result from map for ino {64516 131487}: delete: bad file descriptor
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_0: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_1: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_2: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_3: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_4: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_5: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_6: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_0: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_1: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_2: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_3: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_4: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_5: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_6: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo_7: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook MIByo: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_gotls.go:490 in func2) | detached hooks on ino {64516 131487}
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:423 in removeInspectionResultFromMap) | could not remove inspection result from map for ino {64516 132577}: delete: bad file descriptor
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_0: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_1: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_2: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_3: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_4: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_5: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_6: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_0: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_1: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_2: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_3: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_4: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_5: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_6: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi_7: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook BBlpi: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_gotls.go:490 in func2) | detached hooks on ino {64516 132577}
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:423 in removeInspectionResultFromMap) | could not remove inspection result from map for ino {64516 131553}: delete: bad file descriptor
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_0: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_1: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_2: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_3: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_4: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_5: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_6: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_0: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_1: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_2: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_3: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_4: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_5: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_6: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@_7: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | ERROR | (pkg/network/usm/ebpf_gotls.go:487 in func2) | failed detaching hook 5ayI@: the manager must be initialized first
2024-08-29 08:47:43 IDT | SYS-PROBE | DEBUG | (pkg/network/usm/ebpf_gotls.go:490 in func2) | detached hooks on ino {64516 131553}
2024-08-29 08:47:43 IDT | SYS-PROBE | INFO | (comp/core/tagger/taggerimpl/remote/tagger.go:181 in Stop) | remote tagger stopped successfully

@guyarb implemented your suggestion

@brycekahle did you run the version in staging?


Connection Issue

Issue Type: Bug
At some point there was like a slight disconnection and the file I was seeing was different from that of my buddy's, and now we can't reconnect to each other properly.
Extension version: 1.0.1123
VS Code version: Code 1.40.0 (86405ea23e3937316009fc27c9361deee66ffbf5, 2019-11-06T17:09:34.601Z)
OS version: Darwin x64 18.6.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz (4 x 1800)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_offsurface_control: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
4, 4, 3

Memory (System)
8.00GB (0.97GB free)

Process Argv
-psn_0_1376592

Screen Reader
no

VM
0%

Hey @JasonK97  can you please share your logs? This seems like you had a de-sync issue. Was there perhaps a renaming/creation/deletion of the file that occurred before you saw this issue?
You can access them via the Live Share: Export Logs command from the command palette (ctrl + shift + p) and attach them to this issue.

Thank you, we ended up reconnecting and everything seemed to work fine
after that!
On Thu, Nov 14, 2019, 1:31 PM Filisha Shah<EMAIL_ADDRESS>wrote:

Hey @JasonK97 https://github.com/JasonK97 can you please share your
logs? This seems like you had a de-sync issue. Was there perhaps a
renaming/creation/deletion of the file that occurred before you saw this
issue?
You can access them via the Live Share: Export Logs command from the
command palette (ctrl + shift + p) and attach them to this issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/live-share/issues/2985?email_source=notifications&email_token=ALCPLYE2VNMMYRSQYHBQDZ3QTWYSBA5CNFSM4JNFVSQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEDGD5I#issuecomment-554066421,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALCPLYCXOVZF5WVOHEWHO53QTWYSBANCNFSM4JNFVSQQ
.

Great! Thanks for confirming you were unblocked!


<EMAIL_ADDRESS>hash check failed

Installing 'furmark' (<IP_ADDRESS>) [64bit] from extras bucket
Downloading https://geeks3d.com/dl/get/720#/FurMark_<IP_ADDRESS>_Setup.exe (-1 B)...
Checking hash of FurMark_<IP_ADDRESS>_Setup.exe ... ERROR Hash check failed!
App:         extras/furmark
URL:         https://geeks3d.com/dl/get/720#/FurMark_<IP_ADDRESS>_Setup.exe
First bytes: 3C 21 64 6F 63 74 79 70
Expected:    956925c17c7a5cbea2bdf96690f5cc38
Actual:      ac89a8a93750e812f5c23dd0a39e9e73

Please try again or create a new issue by using the following link and paste your console output:
https://github.com/ScoopInstaller/Extras/issues/new?title=furmark%4<IP_ADDRESS>%3a+hash+check+failed

https://github.com/ScoopInstaller/Extras/issues/11506


Eslint

It appears that eslint wants to slap a "const" on anything which is assigned once and never modified. However, many of these things aren't actually constants (their values are not known before the code runs). For example, in javascripts/common.js, we have:
const pathSplit = window.location.pathname.split('/').filter(function (str) { return str; });
Not only is pathSplit not known until the code runs, but the const keyword does not really guarantee immutability for arrays and hashes. You can do this and it works:
pathSplit.push('some new string');
Can we refine/limit what eslint wants to constantize?

@EvanGranthamBrown The var keyword is going out the door more and more. The new es6 javascript standard defines let as variables that are mutable and const as immutable. There are instances where the var keyword can jump scope and has some additional quirks.
Here's a blog post about it .  He describes const not as a CONSTANT but as one time assignment. Attempts to reassign pathSplit results in VM282:1 Uncaught TypeError: Assignment to constant variable.
This is the style that airbnb suggests. Personally, I like it. It makes comprehension faster knowing which variables are changing and which are not. If we don't like it, we can turn off that lint

Okay, we can stick with airbnb's style; no need to turn off that lint. If that's how const is meant to be used in JS, then that's how we should use it.
(Adding "const != constant" to my list of gripes about Javascript. Now if you'll excuse me, I have to yell at some kids to get off my lawn.)

Are we ok with this pull request?


gamerule sendCommandFeedback

What is your Quests version / build number (do not say "latest")?
4.2.0
Describe the problem and how to replicate it.
When restarting the server with Quests plugin in, the gamerule sendCommandFeedback automatically gets set to false, whereas the default is true. This happens every time the server gets restarted, no matter how many other plugins are in. Issue stops when the plugin is removed. It does give a warning about custom objectives not being set, however the gamerule already got changed upon first adding the plugin (so before any quests were even created)
Any console errors to share?
No errors, just this:[Sun, 6. Feb 2022 13:06:28 UTC INFO] Gamerule sendCommandFeedback is now set to: false

If applicable, can you provide an example quest from quests.yml?
This is one of the quests we got a warning about, but again I don't think this is the reason
quests:
  custom1:
    name: Save Neighbelline
    ask-message: Challenge objectives!
    finish-message: Well done!
    stages:
      ordered:
        '1':
          use-block-names:
          - glass_pane
          use-block-amounts:
          - 1
          locations-to-reach:
          - world -7914945.0 62.0 7582079.0
          reach-location-radii:
          - 2
          reach-location-names:
          - Inspection-zone
          start-message: '"Hmm.. Looks like a fire broke out, lets inspect further"'
          complete-message: '"Cow-ard seems to be a bit hungry but overal he''s fine"'
        '2': {}

There is already a way to disable this; toggle disable-command-feedback in your config.yml file.


Client Credentials doc uses JWT that can't be validated without mentioning this fact

tl;dr a JWT is supposed to be signed by a private key on the identity server (azure ad) and then validated with a public key exposed at the /keys endpoint. However the specific example in the Azure docs was using some secret third key not mentioned anywhere, a private key, to sign the token.
Edit - After looking at some links I posted below, not sure if there's a third private key or just a nonce that requires special processing in the JWT. Regardless, there's no mention of these in the docs. I wrote the message below with the assumption that some third key is used which may be incorrect.
Overview
The JWT example provided in the docs acquires an access token with the Graph API as the scope. Apparently when this is done, some private key specific to the Graph API is used and there is no mention of this on the docs. The JWT itself is generated but the public key it references is not the corresponding key to the "special" private key the Graph API uses.
Technically I don't think the example is wrong but this is a vital piece of information left out as many developers will copy and paste examples from the docs and expect "normal" JWT behavior i.e. the public key in the JWT can be used to validate it but in this case, the public key referenced in the JWT cannot be used to validate it.
Problem
Looking at the example here, it makes a post to the Azure AD token endpoint to get an access token. This example has the scope of scope=https%3A%2F%2Fgraph.microsoft.com%2F.default.
# Replace {tenant} with your tenant!
curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d 'client_id=535fb089-9ff3-47b6-9bfb-4f1264799865&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=qWgdYAmab0YSkuL1qKv5bPX&grant_type=client_credentials' 'https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token'

I get back some access token in the form of
{"token_type":"Bearer","expires_in":3599,"ext_expires_in":3599,"access_token":"eyJ0eXAi... "}

The access_token field above is the JWT which gets passed to other API calls to authenticate you. I didn't paste the whole thing for security reasons. When I paste this at jwt.ms, I get the following decoded details:
{
  "typ": "JWT",
  "nonce": "<removed for security reasons>",
  "alg": "RS256",
  "x5t": "nOo3ZDrODXEK1jKWhXslHR_KXEg",
  "kid": "nOo3ZDrODXEK1jKWhXslHR_KXEg" << this is the key id for the public key that can be used to decrypt (validate) token
}.{
  "aud": "https://graph.microsoft.com",
  "iss": "https://sts.windows.net/<removed>/",
   ...
}.[Signature]

Note that the audience is https://graph.microsoft.com.
Now this JWT above implies that it was signed with a private key on Azure AD with the corresponding public key that has an key id of nOo3ZDrODXEK1jKWhXslHR_KXEg. This public key is available at https://login.microsoftonline.com/common/discovery/v2.0/keys. I pasted the corresponding public key below. Note that these keys get rotated so this specific example may no longer be available.
{"keys":[{"kty":"RSA","use":"sig","kid":"nOo3ZDrODXEK1jKWhXslHR_KXEg","x5t":"nOo3ZDrODXEK1jKWhXslHR_KXEg","n":"oaLLT9hkcSj2tGfZsjbu7Xz1Krs0qEicXPmEsJKOBQHauZ_kRM1HdEkgOJbUznUspE6xOuOSXjlzErqBxXAu4SCvcvVOCYG2v9G3-uIrLF5dstD0sYHBo1VomtKxzF90Vslrkn6rNQgUGIWgvuQTxm1uRklYFPEcTIRw0LnYknzJ06GC9ljKR617wABVrZNkBuDgQKj37qcyxoaxIGdxEcmVFZXJyrxDgdXh9owRmZn6LIJlGjZ9m59emfuwnBnsIQG7DirJwe9SXrLXnexRQWqyzCdkYaOqkpKrsjuxUj2-MHX31FqsdpJJsOAvYXGOYBKJRjhGrGdONVrZdUdTBQ","e":"AQAB","x5c":["MIIDBTCCAe2gAwIBAgIQN33ROaIJ6bJBWDCxtmJEbjANBgkqhkiG9w0BAQsFADAtMSswKQYDVQQDEyJhY2NvdW50cy5hY2Nlc3Njb250cm9sLndpbmRvd3MubmV0MB4XDTIwMTIyMTIwNTAxN1oXDTI1MTIyMDIwNTAxN1owLTErMCkGA1UEAxMiYWNjb3VudHMuYWNjZXNzY29udHJvbC53aW5kb3dzLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKGiy0/YZHEo9rRn2bI27u189Sq7NKhInFz5hLCSjgUB2rmf5ETNR3RJIDiW1M51LKROsTrjkl45cxK6gcVwLuEgr3L1TgmBtr/Rt/riKyxeXbLQ9LGBwaNVaJrSscxfdFbJa5J+qzUIFBiFoL7kE8ZtbkZJWBTxHEyEcNC52JJ8ydOhgvZYykete8AAVa2TZAbg4ECo9+6nMsaGsSBncRHJlRWVycq8Q4HV4faMEZmZ+iyCZRo2fZufXpn7sJwZ7CEBuw4qycHvUl6y153sUUFqsswnZGGjqpKSq7I7sVI9vjB199RarHaSSbDgL2FxjmASiUY4RqxnTjVa2XVHUwUCAwEAAaMhMB8wHQYDVR0OBBYEFI5mN5ftHloEDVNoIa8sQs7kJAeTMA0GCSqGSIb3DQEBCwUAA4IBAQBnaGnojxNgnV4+TCPZ9br4ox1nRn9tzY8b5pwKTW2McJTe0yEvrHyaItK8KbmeKJOBvASf+QwHkp+F2BAXzRiTl4Z+gNFQULPzsQWpmKlz6fIWhc7ksgpTkMK6AaTbwWYTfmpKnQw/KJm/6rboLDWYyKFpQcStu67RZ+aRvQz68Ev2ga5JsXlcOJ3gP/lE5WC1S0rjfabzdMOGP8qZQhXk4wBOgtFBaisDnbjV5pcIrjRPlhoCxvKgC/290nZ9/DLBH3TbHk8xwHXeBAnAjyAqOZij92uksAv7ZLq4MODcnQshVINXwsYshG1pQqOLwMertNaY5WtrubMRku44Dw7R"],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"}

Now I tried to take this public key and actually validate the JWT above but I found out this JWT example in the azure docs I referenced above uses a completely different private key even though the actual JWT itself implies otherwise. I wasted a bit of time trying to figure this out but I found out that when you have scope=https%3A%2F%2Fgraph.microsoft.com%2F.default in the initial request to get the access token at 'https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token', it will use some private key that doesn't have a corresponding public key exposed at the https://login.microsoftonline.com/common/discovery/v2.0/keys endpoint even though the JWT implies otherwise. If I specify any other scope like scope=<my_app_client_id>.default, then I can use the public key linked above to validate my JWT successfully.
Fix
Now I don't think the doc is technically wrong because you are not suppose to be validating a token that is meant for your API but if the Azure docs are going to use an example for tokens where the actual public key referenced in the JWT itself is not the true key that can be used to validate the token, they should be very obvious about it. They currently are not very obvious about it.
Example from the docs repeated from above:
# Replace {tenant} with your tenant!
curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d 'client_id=535fb089-9ff3-47b6-9bfb-4f1264799865&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=qWgdYAmab0YSkuL1qKv5bPX&grant_type=client_credentials' 'https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token'

I only found out about this after searching on stackoverflow and seeing this post "Microsoft Graph API access tokens are signed differently from other access tokens from what I can see. You do not need to validate tokens that are meant for another API, it is their job.". Again, that last sentence is correct but if the Azure docs are going to provide a JWT example that uses a totally different public key than the JWT itself implies, they should be very obvious about it and they're not. The Oauth flow has... a lot of content to it so debugging this and narrowing down the problem to this was tough and unexpected. I assumed that Azure AD always returned a "valid" access token but this was not the case for the specific example when scope=https%3A%2F%2Fgraph.microsoft.com%2F.default.
A simple sentence in the Azure docs right below the example above could have saved a lot of time. The docs make no mention of the (special) signing key used in the examples provided.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d32f55ac-acbc-292b-d1b7-ffdd257b11e1
Version Independent ID: ae2a266c-051b-7307-93fd-74bc521c93bf
Content: OAuth 2.0 client credentials flow on the Microsoft identity platform
Content Source: articles/active-directory/develop/v2-oauth2-client-creds-grant-flow.md
Service: active-directory
Sub-service: develop
GitHub Login: @hpsin
Microsoft Alias: hirsin

@mmankos-microsoft Thanks for the feedback! We are currently investigating and will update you shortly.

Thanks Bryan - FYI there are a few different threads on this

https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/521#issuecomment-577400515
https://stackoverflow.com/questions/49933215/how-to-validate-microsoft-graph-api-jwt-access-token-and-secure-your-api
https://stackoverflow.com/questions/45317152/invalid-signature-while-validating-azure-ad-access-token-but-id-token-works/67001816#67001816

I think its worth putting this explicitly in the docs so others don't get confused.

Graph tokens are a special, non-standard JWT format that you can't validate, that is correct, as they use some special logic that's internal to MSFT (remember, there is no access token format specified in OAuth2).  Please always test using your own APIs - someday Graph tokens will be encrypted, and then you certainly won't be able to validate them.  I'll look at updating this to warn the developer.

#please-close , we've added some fixes that will be live tomorrow.


Public API

We want to design public API so Sudachi would be usable like the following.
Syntax can be a bit invalid and all names are open for discussion.
let model = SudachiModel::from_cfg_file("...")?;
let mut analyzer = model.new_analyzer();

for line in data {
  for sentence in analyzer.analyze(sentence)? {
    for token in sentence {
      println!(token.surface);
    }
  }
}

Key points of API

Model should be immutable and safe to share between threads
It contains dictionary, connection, needed const data for preprocessing
Analyzer contains mutable data for analysis, e.g. lattice and tries to reuse allocations as much as possible.
In the long time, analyzer should have O(1) allocations

Because of Python API and lifetime considerations, Model should be a thin wrapper on Arc<RealModel> or something like that.

Names and semantics should be close to Java version as possible.
(comment from Takaoka-san)

TL:DR
Nice API with multiple sentences is currently blocked in stable Rust by in-progress GATs feature, also see http://lukaskalbertodt.github.io/2018/08/03/solving-the-generalized-streaming-iterator-problem-without-gats.html.
Want to have:

Analyzer having internal mutable state for storing one sentence (and not more) because of performance reasons
Iterator over analyzed sentences needs to borrow analyzer mutably to enforce that it is impossible to access the next sentence before consuming the current one

Problems:

Current Rust iterators can't borrow from &self without GATs which would probably introduce new-ish Iterator API as well

What to do

Provide non-allocating API for

Sentence splitting, returning Iterator of &str
Provide sentence-based analysis API

Optionally provide allocating combined API, which copies needed information (mostly POS) from analyzer

Splitting API into sentence splitter / analysis
for sentence in analyzer.split_sentences(line)? {
 let result = analyzer.analyzer_sentence(sentence)?
 for token in result.tokens() {
   // process token
 }
}

Morpheme's part_of_speech should not return option of POS array, it should panic instead.


Make it impossible to bypass Custom Registration questions

The registration questions' data is very important for the countries hosting IOGT. The questions are essentially part of the registration process and no user should be able to register to the platform without completing the questionnaire.
The custom questions need to be customisable by the editors and show up right after setting up the username password. If the user exits the website at this point, they should be 'locked out' of IoGT until they fill the survey form. They shouldn't even be able to access the public content that i accessible otherwise.
cc: @dannyparsons

I'm picking this ticket

@ehmadzubair Thank you for the quick work on this. Not sure how exactly this was implemented in the pull request but just to clarify - this should be a feature that an admin can enable or disable for their deployment, so that we can accommodate a broad set of use cases.

@cbunicef Yes the additional questions will be fully customisable by the CMS editors, including having no questions if desired. And of course the site is still accessible without login as normal.


[Site] Nighthawk description sections

Current State of the GetNighthawk.dev site
Currently, there is no proper section for a complete nighthawk description
Desired State of the GetNighthawk.dev site
screenshot from figma for this section:

Contributor Resources

See the Contributing to Meshery.io Website section of the readme.md.
See the Project Site section of GetNighthawk project doc

Can I try this? @vinayaksh42

Can I try this? @vinayaksh42

sure go ahead


Doc: Update production-users.md

Update the Backups policy

@xiang90 sorry, missed out on the backup policy

No problem. Thanks for update.


Absolute Import not work when create new file

Hi, I got this problem in VS code, only within this project.
When I created a new file, I can't use Absolute Import Path, I have to restart the VS Code or re-run npm start
This is the new file

And here, same file but after restart VS Code

It is time-consuming when I have to re-run the project or restart VS code every time when I create a new file.
Please help me out
Here is my tsconfig.json

don't you have any issues with the older files? I have the same issue with all files.


Provide DevOps best practices for secrets management

Since we are introducing a new place/way to store secrets in v4 we should, as part of deployment documentation, address typical DevOps flows for managing the secrets now present in the .bot file (and therefore the source code of a bot). What is the best practice for managing these secrets? How/when/by whom should they be encrypted? Can they be? How would different deployment environments be managed?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 41386916-1ae4-1a69-855a-c48f3804e673
Version Independent ID: 180ca783-20c2-672c-303c-69cc8b42e71b
Content: Configure continuous deployment for Bot Service - Bot Service
Content Source: articles/bot-service-build-continuous-deployment.md
Service: bot-service
Product: bot-framework
GitHub Login: @ivorb
Microsoft Alias: v-ivorb

Agreed. That is the plan once we land the changes in the CLI tools.


Teamu 1239 shared UI component library

Adds composite storybook and separate storybooks for older UIs to EOP

this is commiting a large number of files (300+) including some obfuscated javascript here - [packages/RainfallViewer/storybook-static/assets/index-DrFu-skq.js]. how trustworthy is it, and does it all need to be committed?

Yeah, I was going to use those builds in Github if poss. but need to investigate further, so they can go.


test: behaviors-message_on_lock_failure (2024-02-08 02:44:41.683925+00:00)

automatic test cleanup


New chat participant update is not correctly parsed

I found a bug to report
Please use the following template to ensure maintainers can reproduce the bug and solve it quickly.

Bug reports that do not follow this template will be kept closed because not-reproducible until the creator edits the post properly.

Steps to reproduce

In a conversation, add a user (or bot)
Telegram will send a request like that:
{   "update_id": xxxxxxx,   "message": {       "message_id": 6448,       "from": {           "id":<PHONE_NUMBER>,           "is_bot": false,           "first_name": "nimbus"       },       "chat": {           "id": -999999999999,           "title": "test reaction",           "type": "group",           "all_members_are_administrators": true       },       "date":<PHONE_NUMBER>,       "new_chat_participant": {           "id":<PHONE_NUMBER>,           "is_bot": false,           "first_name": "nimbus"       },       "new_chat_member": {           "id":<PHONE_NUMBER>,           "is_bot": false,           "first_name": "nimbus"       },       "new_chat_members": [           {               "id":<PHONE_NUMBER>,               "is_bot": false,               "first_name": "nimbus"           }       ]   } }
Break in Post method of the Webhook
The update is parsed as Message but the field Update.Message.NewChatMembers is null and Update.Message.Type is Unknown.

Expected  behavior
Update.Message.NewChatMembers is filled with data from the Telegram request
Actual behavior
Update.Message.NewChatMembers is null
Screenshots

Environment data
NuGet Package Version: 21.9.0
.NET Version: 8.0.7
IDE: VS2022
App: ASP.NET WebAPI

Ok, my bad if work well, but on the migration page https://telegrambots.github.io/book/migrate/Version-21.x.html, the link for webhook migration is broken
https://telegrambots.github.io/book/migrate/3/updates/webhook.html instead of https://telegrambots.github.io/book/3/updates/webhook.html
Please fix

oh, thanks !

fixed


Upgrade to flutter_map v7

Do you have any plans to support v7

Yes, just not in a rush atm as I think v7 needs to settle first. However, if anyone has a compelling reason, I'll try and make it happen sooner.

@ibrierley It seems that v7 does not have a major breaking change. Personally I hope to see the upgrade happen on this library sooner :)

Heya, no there's not a breaking change, but I think there is an issue on latest release so I wouldn't recommend updating yet, this issue highlights the problem with polygons vanishing.. https://github.com/fleaflet/flutter_map/issues/1921 but if anyone needs a v7 version, I'll do an update.

It seems that the issue mentioned is solved in flutter_map 7.0.2. I would really appreciate an updat of this package...

Ok, weird, I think something has gone astray with some flutter_map change (maybe), I can't get the polygon example to fill the poly. I can see there has been a change to isFilled, but I don't think that's related, as it doesn't draw borders if I include those in the poly params.

I think the problem is that in flutter_maps polygon.dart is has this line...
LatLngBounds get boundingBox =>
_boundingBox ??= LatLngBounds.fromPoints(points);
so it's caching the bounding box now. As the poly from an editor starts with nothing, I don't think that will get updated, so I'm assuming it just gets culled for optimisation every time...
I think it can be worked around by creating a new Poly every time, so it's never cached...so the code would look something like the following code. I'm not sure if I like this or not, as on the one hand, it cuts out the normal flutter flow (I'm a bit out of touch), on the other, it's an editor so performance not such an issue here, and also maybe it's more correct...not quite sure.
Any thoughts, let me know.
final polyPoints = <LatLng>[];

  @override
  void initState() {
    super.initState();

    polyEditor = PolyEditor(
      addClosePathMarker: true,
      points: polyPoints,
      pointIcon: const Icon(Icons.crop_square, size: 23),
      intermediateIcon: const Icon(Icons.lens, size: 15, color: Colors.grey),
      callbackRefresh: (LatLng? _) => {setState(() {})},
    );
  }

  @override
  Widget build(BuildContext context) {

    final polygons = <Polygon>[];
    final testPolygon = Polygon(
      label: 'Label!',
      color: Colors.deepOrange,
      borderColor: Colors.red,
      borderStrokeWidth: 4,
      points: polyPoints,
    );
    polygons.add(testPolygon);

    return Scaffold(

I have raised an issue at https://github.com/fleaflet/flutter_map/issues/1932 just to get some thoughts

Adding my interest to v7 support... I'm eager for v7.

I also would love to see a v7.  :-)

@ibrierley , how did you even get to that part? I am trying to give it a look but it fails before, when trying to create an initial LatLngBounds with no points, which is not accepted:
  factory LatLngBounds.fromPoints(List<LatLng> points) {
    assert(
      points.isNotEmpty,
      'LatLngBounds cannot be created with an empty List of LatLng',
    );

Is there something I am missing?

@ibrierley , how did you even get to that part? I am trying to give it a look but it fails before, when trying to create an initial LatLngBounds with no points, which is not accepted:
  factory LatLngBounds.fromPoints(List<LatLng> points) {
    assert(
      points.isNotEmpty,
      'LatLngBounds cannot be created with an empty List of LatLng',
    );

Is there something I am missing?

sorry, completely missed this comment...I'm just retesting the update above after the discussion in FM, will probably use the workaround...

I did some tests and it looks like it is working without any issue. Thanks a lot @ibrierley

in v7 branch the flutter_map_dragmarker is constrained to v6 while the version that supports flutter_map 7 is v7

Can you clarify where you are seeing that, as I can't find v6 referenced in the pubspecs, but may have missed something.

@ibrierley Never mind, seems like a cached pub situation. pubspec.yaml looks ok. Thanks.

Ok Super.
Should be published on pub.dev now as well. Thanks for the help testing everyone.


connect to server over https

I try to run a genie-client on my raspberry pi zero w.
When i try to connect to a genie server on home assistant
(installed like this: https://wiki.genie.stanford.edu/getting-started/installation-guide/3rd-party-home-assistant-addon)
i get the following errors:
(genie-client:1382): genie::conversation::Client-WARNING **: 23:15:53.503: Failed to get access token from Home Assistant: (null) genie::conversation::Client-Message: 23:15:56.511: Requesting Home Assistant session token from http://<IP_ADDRESS>:443/api/hassio/ingress/session genie::conversation::Client-Message: 23:15:56.534: Sent access token request to Home Assistant, got HTTP 8
my config is as follows:
[general] url=https://<IP_ADDRESS>:443/api/hassio_ingress/IdKw5rkogeJyopPlD8cc4CDZaZoUmXuUY5apDSLNCqs/api/conversation auth_mode=home-assistant accessToken=*redacted* conversationId=genie-wz
i also added these lines, with no difference:
[system] ssl_strict=false ssl_ca_file=/home/pi/ca.gunsch.tirol.crt
is it supported to connect via https or am i doing it wrong?

The configuration looks correct, except https should be wss in the url
Do you have a good TLS certificate (issued by a CA like letsencrypt) or is it self signed? If self-signed, I'm not sure we currently support that. We might need to pass additional options to libsoup to handle a self-signed certificate.

Also, could you try setting ssl_strict=false without also setting ssl_ca_file ?

Thanks, had a similar issue and using wss:// solved it.
The home assistant add-on suggested to use http:// under the "External Clients" configuration section and I thought it was as simple as changing it to https://, not the case, hah!

Oh thanks for the report, I just fixed the configuration page, it should show ws now

Wow, you guys move fast.
setting the url to wss:// and setting ssl_strict=false fixed it for me too.
I was trying to get things working with ssl_strict=true and a ssl_ca_file, but i got some issues in my ssl load balancer,
so sadly i cannot comment to this at the moment.
But it works for testing now, so thanks a bunch!

Great to hear it works, closing!


add nonsudo travis

Modify the travis file to not use sudo.

Not sure why tests failed. These are the relevant tests.

Thanks to swapping to allclose, these are passing now.

Commented in the issue.  I am happy to merge this, assuming that we want to keep pegged to the ubuntu scipy.


Server returned 503 error.

I have just installed VSCode from your website but for some reason I am continually getting a "Server returned 503" error and I have no idea how to fix it. If I try to install support for JavaScript i get the error, if I go to the extensions tab it just shows a blank with no extensions listed, if I search for an extension such as Chrome it shows no extensions for Chrome.
As far as I know there is no proxy setup, unless my internet provider has set one up (we live in dubai).
I have installed it on my new Macbook Pro as well and it is having the exact same issue as my iMac. I have attached a few pictures.
I'm totally lost, any help would be appreciated. Chrome, Firefox, Safari all work perfectly.

@Javac7 - Guess this is why. I'm pretty exiced about Google already cached this issue 🗡 👍
We're working to restore all services as quickly as possible. Please check back soon.

Ref A: 1234C41DAAD5413CAFA66A746083CDE0 Ref B: AMS04EDGE0109 Ref C: 2018-09-04T13:55:23Z```

I thought is my network problem too, hah hah.🙃

exactly the same issue, wasted half hours to figure out if my proxy(live in China) failed me...

Facing same ! Any idea when it will up

Same issue, hoping it will be up again soon

OH MY! after 3 hours of changing network configurations I find this hahahahaha

was about to reinstall vs code .. glad .. saw this thread first ...
hope the server will get back online pretty soon..

praying for the coder god...

Ugh, just reinstalled then found this thread. At least I was planning on moving over to the user setup distribution anyway.

They must be running Windows Server.

opsss.. i also wonder why not able to search..

I've just setted up my fresh linux install and i was thinking that this error is my fault. But now I'am happy in my sadness...

I though that cause my network problem...

Duplicate of #57851

And there I was uninstalling and re-installing lol

Damn, I had to reinstall thrice, before getting here :) :)

For the heavens sake, I reinstalled VS twice.

Ха, Смешные ребята))) Переустанавливали несколько раз??? Зачем??


testing SMTP settings for a portal as administrator email popup message states it came FROM<EMAIL_ADDRESS>TO<EMAIL_ADDRESS>

Description
testing SMTP settings for a portal as administrator email popup message states it came FROM<EMAIL_ADDRESS>TO<EMAIL_ADDRESS>Steps to reproduce

create a dnn host website
set and test HOST SMTP SETTINGS
crreate a website for another administrator
set SMTP Server Mode: Portal (not global, basic smtp authentication with SSL enabled)
test SMTP settings

Current result
popup message states it came FROM<EMAIL_ADDRESS>TO<EMAIL_ADDRESS>Expected result
popup message stating a message FROM<EMAIL_ADDRESS>TO<EMAIL_ADDRESS>The test message is the message that should be for the portal settings not for host settings.  Host email settings should not be used in any messages when configuring PORTAL specific SMTP settings.
Affected version

[x] 9.2
[x] 9.1.1
[ ] 9.1
[ ] 9.0

Affected browser

[ ] Chrome
[ ] Firefox
[ ] Safari
[ ] Internet Explorer
[ ] Edge

I couldn't find any  place to update host settings then I executed following query in SQL:
update hostsettings set settingvalue =<EMAIL_ADDRESS>where settingvalue =<EMAIL_ADDRESS>

The option to change the host email has been added in https://github.com/dnnsoftware/Dnn.AdminExperience/pull/39 but i agree that when sending the test email from the admin settings (and not the host settings) the test email should come from the admin email because the admin smtp server may refuse sending that using the host email.

This was fixed in #3237 I believe so I will close.  Thank you.