Problem with GFX fonts

I have read and tried suggestions from #134 but nothing changed
Issue persists in 3 different esp32 boards
Drawing pixels and geometry is wroking fine
Tried to use other fonts from gfx library but all of them having same issue

Same here. Fonts doesn't seem to work properly.
1/8 scan rate 64x32 panel here.
All fonts give a result of blank pixels or mislocated pixels.

@zznty could you solve the issue?
Can you otherwise post an example code so that we can try to replicate it?

nope.
Havent tried new updates, last attempts was in march.
the main problem if im using the gfx api such as print or println, the font getting damaged
but it's fine with displaying gifs, plasma and other shapes


A little doubt

I don't quite understand the functionality of your project, I run test, and then the computer and IOS device in a local area network. Is it my iOS phone to search to this server?

As the readme says, this is a "low level AirPlay server", that you can use to "use to easily implement your own AirPlay functionality". You can implement an AirPlay server that receives an audio (video as well?) stream and can pipe it into something (e.g. speakers or a file).

Once you implemented your (custom) AirPlay server and ran it, you can send audio from your iPhone to it.

For ready-to-go AirPlay servers, check shairplay or nodetunes.


remove the webpack-target-electron-renderer

We're using this dependency: https://github.com/chentsulin/webpack-target-electron-renderer
It's an older project, and during some initial tests when I removed it, it didn't seem to impact anything in the Electron build
Cannot upgrade to Webpack 5.x until the target issue is solved

https://github.com/slashman/jsrl/pull/15


[Bug]: Adapt Get-WingetOutdatedApps to more scenarios

The problem
When $upgradeResult = & $Winget upgrade --source winget | Out-String is run and the array is built, some scenarios aren't taken care of (with winget v1.4.10173):
PS C:\Windows\system32> Winget upgrade --source winget
Name                      Id                          Version      Available
-------------------------------------------------------------------------------
Adobe Acrobat DC (64-bit) Adobe.Acrobat.Reader.64-bit 22.001.20142 22.003.20310
2 upgrades available.

The following packages have an upgrade available, but require explicit targeting for upgrade:
Name                         Id              Version    Available
------------------------------------------------------------------
Teams Machine-Wide Installer Microsoft.Teams <IP_ADDRESS>70 <IP_ADDRESS>6
1 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.

What version of WAU has the issue?
1.16.1
What version of Windows are you using (ex. Windows 11 22H2)?
Win 10 21H2
What version of winget are you using?
v1.4.10173
Log information
No response
Additional information
https://github.com/Romanitho/Winget-AutoUpdate/issues/276#issuecomment-1422305433

https://www.neowin.net/news/winget-14-launches-with-zip-extraction-support-and-more/
Install / Upgrade Flow Enhancements
Some packages require an explicit argument to be passed in order to perform an upgrade. This was causing winget to fail if a user ran winget install and the package was already installed on the machine. We made some additional enhancements to detect that the package was already installed and switch to the upgrade flow. If you don’t want the upgrade, you can pass --no-upgrade. This is most commonly encountered in scritped scenarios. We’ve also noticed several packages can upgrade themselves, so our default behavior is to allow them to do so. If you run winget upgrade --all and one or more of these packages are encountered, they will be skipped. If you want to include them, just add --include-explicit.


shotwell: 0.25.2 -> 0.25.5

Motivation for this change
Update shotwell to the last version
Things done

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

[X] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

Per https://git.gnome.org/browse/shotwell/tree/NEWS this contains quite few bug fixes, perhaps consider also picking this to stable.


Compile and export tailwind style file in portal.js components

Bug: styling is missing on example sites e.g. https://catalog-portal-js-datopian1.vercel.app/
The tailwind styles applied in portal.js components are not applied when an app using Nextjs is built for production.
This could be caused by the fact that tailwind classes in portal.js components are not imported when components are reused.
This means we have to write and export a tailwind style file, and this can be imported into a nextjs app before build.
Acceptance
~* [ ] Extract all tailwind component class in portal.js into a single style file~
~* [ ] Import and use exported styles in examples~
~* [ ] Test and ensure styles are correctly applied when using portal.js in a  nextjs app~

@rufuspollock After fixing the build error and using portal.js in the examples, I noticed that the component styles coming from portal.js are not applied. You can confirm this via these builds here or here.

@risenW what do you mean by:

external styling cannot be used in Nextjs builds

I'd like to understand a bit more what the issue is. Do you mean that styles that come from components don't work or the overall style in a give app does not work in a production build? The latter seems a bit surprising ... how does everyone else do their nextjs builds?

I mean, importing a component with a style class won't work.
We have to extract all styles into a css file and the import that file in the Nextjs _app.js. This makes it globally available to all pages.

@risenW i assume that is because when tailwind does the purge it is not aware of the styles from the external components ... and hence does not include the styling. So that makes sense. (And is my understanding correct?)

I saw the styling on https://docs-portaljs.vercel.app/ is broken and I just found this issue.

I could however not replicate the issue. I forked this repo and deployed it to vercel and the styling works fine, the tailwind css classes are present.
You can check my deployment here: https://docs-portaljs-flax.vercel.app/
I also couldn't replicate it locally, npm build and then npm start also worked fine.
I don't know if this is helpful at all, was trying to understand the problem. My main taught now was to check your vercel deployment set-up (double-check if correct branch is selected etc.)

I saw the styling on https://docs-portaljs.vercel.app/ is broken and I just found this issue.

I could however not replicate the issue. I forked this repo and deployed it to vercel and the styling works fine, the tailwind css classes are present.
You can check my deployment here: https://docs-portaljs-flax.vercel.app/
I also couldn't replicate it locally, npm run build and then npm start also worked fine.
I don't know if this is helpful at all, was trying to understand the problem. My main taught now was to check your vercel deployment set-up (double-check if correct branch is selected etc.)

Thanks for the comment @glgoose This styling issue has to do portal.js examples projects and not docs. However, we also notice a breaking style issue in the docs as you have noted here. This has been fixed here: https://github.com/datopian/portal.js/pull/570

I'm not sure this can (just) be issue with the third party components as e.g. the navbar styling is messed up yet that component is a local component that is part of the example.

OUTDATED: This has already been fixed. See https://catalog-portal-js-datopian1.vercel.app/


transparent_background and other options for catppuccin/nvim

There's a slew of options for catppuccin/nvim that might be worth being able to set.
On the other hand, the other apps catppuccin configures don't seem to have so many options made available, so I'm not sure if we want to expose all of them through catpppuccin/nix. (Cava does have a transparency option.)
I did make a fork with the transparent_background option, but I don't want to make a PR just yet, because this is my first time writing options for any nix packages, and I'm not confident regarding style and conventions etc. (e.g. do we keep the snake case?)
Any guidance would be appreciated!

a freeform module would probably be ideal here as we wouldn't need to constantly update our options to reflect the upstream port
PRs are welcome here


Button adjustments

Adjust these button changes according to design:
(https://projects.invisionapp.com/d/main?origin=v7#/console/22098616/468807390/preview)

Adjust button/text alignment
Adjust button radius
Change fueltype selection buttons to be radio buttons

Will be added here: https://github.com/pace/connectedfueling-app-android/tree/Change-add-icons

Done


Fix 'state'less addresses weridness

Fixes #25
Before

After

YAY! Thank you @muan :sparkling_heart:


Docker engine swarm api service discovery

In docker 1.12, the docker engine will ship with swarm mode built in. This means that it is now possible to stand up a swarm cluster using a bunch of nodes with just docker installed. In addition, swarm mode will come with dns and health checks built-in, negating the need to run consul or some other service discovery mechanism. More info here: https://docs.docker.com/engine/swarm/
It would be nice if prometheus can directly use the new services API to discover services running in a swarm cluster: https://docs.docker.com/engine/reference/api/docker_remote_api_v1.24/#3-8-services
Perhaps the config option could be called docker_swarm_sd.

In addition, swarm mode will come with dns and health checks built-in,

This will need to be bypassed for Prometheus service discovery.
We may want to wait for a release or two for this to stabilise before adding it, and ensuring there's sufficient interest to justify the maintenance effort of another SD.

This feature would be amazing. It would allow us to simplify some dependencies now we need to manage to maintain a dynamic Prometheus environment

You could use dns_sd_configs.
Im running a global cadvisor service and a global prometheus/node-exporter service and can scrape all nodes with following config, using the
tasks.<servicename> feature of swarm mode discovery.
  - job_name: 'cadvisor'
    dns_sd_configs:
    - names:
      - 'tasks.cadvisor'
      type: 'A'
      port: 8080

  - job_name: 'node-exporter'
    dns_sd_configs:
    - names:
      - 'tasks.node-exporter'
      type: 'A'
      port: 9100

Its a workaround but functional.

Any progress on this? I'm really looking forward to use this feature.
Thanks very much!

@michaelharrer Unfortunately, there is no way to determine the node_exporter is running on which node. Only node_exporter itself knows it, but there's no option to provide it into its metrics (https://github.com/prometheus/node_exporter/issues/319)

I just hacked in a proof-of-concept that syncs tasks from Swarm manager to Prometheus: https://github.com/function61/prometheus-docker-swarm
Current limitation is that Prometheus has to be running on a Swarm manager node.

@genki, @joonas-fi: I've updated the description of the image I created for getting the metrics: https://github.com/bvis/docker-prometheus-swarm. It's not perfect but it is very useful and the best I've seen until now.
@joonas-fi I'll try your solution when I get some time, probably it's a better alternative. And you don't need to have it running in a swarm manager node if you expose the metrics to the cluster thanks a a proxy. A similar approach to:
docker \
  service create \
  --mode global \
  --name docker-exporter \
  --network monitoring \
  --publish 4999 \
  basi/socat:v0.1.0

Or:
docker \
    service create --name docker-proxy \
    --network my-network\
    --mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock,readonly \
    --constraint 'node.role==manager' \
    rancher/socat-docker

That gets the docker swarm events and expose them in the docker-proxy:2375 endpoint in the network.

@bvis Thank you for great work, I have tested your work in advance ;)
I have sent a PR #2312, this could solve this issue as long as the services are not in global mode but replication mode.

@bvis Thank you for great work, I have tested your work in advance ;)
I have sent a PR #2312, this could solve this issue as long as the services are not in global mode but replication mode.

@bvis I have implemented your second suggestion https://github.com/genki/prometheus/commit/afde884ddcb6374869046d744b4bac4685157a59
This inject meta labels "__domain", "__service", "__task" and "__host" after the query execution time using docker API.

@genki Do you have a prometheus image ready for use? I've built your image but I think I still need to do more steps to include it in the project provided by @joonas-fi, or am I wrong?

@bvis Thank you for reporting :)
The injection is only taken place at querying on time series, so you couldn't see it on console, but I thought it is sufficiant.
I think this implementation is too optimized for docker users.
It is nice if there is more generalized and sophisticated way to pass meta data about sample source.

@bvis: oh man, thanks for tip regarding creating a service that exposes the manager Docker socket (via constraint) over TCP, I didn't think of that as a way to loosen the requirement of running it on a Swarm node. :)
I will make the Docker URL given to Docker client configurable, as you pointed out!
I'm not sure what you mean by "as it tries to obtain the data from the ingress network". To my understanding the ingress network is only for published ports and the routing mesh? So if you publish the socat port, it will be public and therefore will be visible both from the ingress network AND the container's IP itself. Publishing seems unnecessary as the port shouldn't be public anyway (security issue) and you can reach the socat service just by its name without the port being public (provided that socat service and monitoring are on the same network), if I understand correctly. :)
I haven't given much thought/researched into services running on different networks (business services and monitoring on different networks). Currently my assumption is that everything's running on the same network. I'll document that caveat. It might be easy to implement, I just don't know it yet.
Just to be super clear to everyone, mine and @bvis 's projects achieve different things:

Mine provides autodiscovery of your services running on Swarm that have metrics that Prom should scrape, but not container or node metrics
@bvis 's solution provides container ("Docker container metadata") and node metrics, but not metrics from the actual services if you have services that expose Prom metrics

@genki The problem I see with your solution is that it does not allow to filter any query based on these values, then I cannot use it in my dashboard to get values from one or some hosts.
@joonas-fi You are right when you say that it's unnecessary to publish the ports of the exporters in the routing mesh, I have used it just for debugging purposes. At the moment I removed the "--publish" option in cadvisor and node-exporter your system started to scrape the values correctly. But for use it under different environments and conditions I suggest to you to implement the networking selection feature.
Another suggestion is that it would be better to split your "docker-prometheus-bridge" binary in another image to allow process isolation, with both services running in the same container some problems could come. Or try to add it in the prometheus itself.
On other hand my dashboard shows the container metrics cadvisor provides. And it's easy to extend it. It would be good to allow me to create issues in your project to do a better follow-up.
And a 3rd option: create a prometheus fork adding your both features: @joonas-fi and @genki. It could be very useful until the Prometheus project adds support to Docker swarm service discovery, or maybe they could accept your changes, it's one of the best things of the open source model. ;)

@bvis Injected labels are only be usable for such as legend labels because it is not real labels in the scope of query.
Prometheus is using the labels as identifier of targets, so if inject something in it causes duplication of targets.
My motivation was just using injected labels for legend label in Grafana such like "{{__host}}".

Based on the Swarm discovery from @ContainerSolutions, I've coded that PoC that is working ok in our stagging env:
https://github.com/jmendiara/prometheus-swarm-discovery
Takes some of the great ideas from the original solution, but tries to fit best in a deployment where prometheus is executed in a swarm worker (dedicated) without mounting shared volumes between workers/masters (that is fairly complex in some cloud providers) and provides more swarm metadata
The original motivation was using the hostname from the worker as the instance label instead of the task endpoint that is get with @michaelharrer DNS solution
(see https://github.com/jmendiara/prometheus-swarm-discovery/blob/master/prometheus-configs/prometheus.yaml#L8-L9)
That client/server duality needed could be simplified if prometheus implements a generic <remote_sd_config> very similar to  <file_sd_config>, but gets the static_config array from a configured endpoint
Please, let me know what do you think about this approach

https://github.com/vegasbrianc/prometheus/issues/91

I'm closing the issue as unfortunately, we are currently not accepting new integrations.  ContainerSolutions/prometheus-swarm-discovery is listed in the Prometheus documentation to integrate Docker Swarm with the file service discovery.
We can only provide the stability and performance we want to provide if we can properly maintain the codebase. This includes, amongst others, test integrations in an automated and scalable fashion. For this reason, we are suggesting people integrate with the help of our generic interfaces. We have an integrations page on which integrations using our generic interfaces are listed.
Even if existing integrations can not be tested in an automated fashion, we will not remove them for reasons of compatibility. This also means that any additions we take on, or any changes to existing integrations we make or accept, will mean maintaining and testing these until at least the next major version, realistically even beyond that.
Feel free to question this answer on our developer mailing list, but be aware it's unlikely that you will get a different answer.

Be aware that ContainerSolutions/prometheus-swarm-discovery is not yet ready for production usage https://github.com/ContainerSolutions/prometheus-swarm-discovery/issues/9 due to file descriptors leaks.

I updated my old proof of concept to use a better strategy: https://github.com/function61/promswarmconnect
Previously it used the file service discovery type to dynamically write the file to disk based on the info in Swarm. Its drawback was that we had to make changes to the Prometheus container, overriding the entrypoint and launching the file synchronizer binary AND Prometheus. This is not robust, because we would have had to logic to deal with either of the binaries crashing.
My new approach emulates the API of the existing Triton service discovery, so we can run the released Prometheus container from Docker Hub 100 % unchanged. All you have to do is write configuration for the Triton SD in the Prometheus config file.

nice :) I've not been doing much on swarm lately but after having used k8s I might start doing so again. K8s is reallllllly heavy. I like how light swarm is.

I'm curious to hear about your experiences, since I'm interested about
learning about k8s! In what regard do you consider it "heavy" - is it
mentally hard to understand, or is it heavy on the server resources like
RAM and CPU? Both?
I'm currently running a super small startup, so having the ability to use
cheaper VMs with low overhead of the infrastructure layer is important to
me.
On Thu, Dec 20, 2018, 13:34 Donal Byrne<EMAIL_ADDRESS>wrote:

nice :) I've not been doing much on swarm lately but after having used k8s
I might start doing so again. K8s is reallllllly heavy. I like how light
swarm is.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prometheus/prometheus/issues/1766#issuecomment-448966078,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAmdh6iMJGZkJ6iyV36xnzUfD6S5JW6eks5u63WvgaJpZM4I-gA4
.

Docker Swarm Mode is popular enough that we can make an exception to the SD moratorium. We also previously discussed adding support for it according to @brian-brazil.

I see no reason to make any exceptions, we continue to have issues maintaining what we already have. We also previously decided not to support it, and it sounds like what exists now is not what existed then.

Why continue supporting other SDs then?
Maybe it would be possible to have some kind of plugin system for that? Generating configuration files is not that comfortable. I do understand, that maintenance of all different kinds of SDs is not your focus, but maybe it would make sense to deprecate all custom SDs, and have some kind of entry point for pluggable integration. Something like Apache Kafka has for pluggable Serializers?
@brian-brazil , can you close this issue, if your team is not considering accepting implementation for it? I'm going with your suggested file-based configuration for now :)

I highly disagree with this all or nothing approach and the indefinite moratorium on features/improvements to one of our core features.
I think we should accept an implementation of swarm SD as long as it's reasonably well done.

It is not like "all or nothing", I see it more like responsibility split, you can keep existing integrations in default bundle of prometheus, but make it possible to add other integrations as plugins (Like I mentioned in kafka's case you just add your implementation to classpath and set config value-serializer: com.github.YourImplementation)

I think the file-based approach suffers from the fact that you need to have the SD agent write files in the same container as Prometheus is in. Problems:

You either have to build the custom SD on top of Prometheus' Docker image (which is what my first POC of promswarmconnect did), which forces the SD project to release their image for every Prometheus' release
Or you have to schedule the SD container on the same host as the Prometheus' container and have them share a filesystem (deep, unclean coupling, might not play well with high availability setups..)

A cleaner approach would be to make the file SD support also http URLs from which the discovery file is fetched. Whether this is a new SD plugin or a change to the file SD plugin is beside the point.. this remote file (maybe JSON) support would get us very far, so the actual SD implementation would be a separate app/container.

There was talk a while back about a "standard discovery API" within the CNCF. AFAIK this work is stalled.
Having file_sd_configs support URLs is something I've proposed several times.

It is not like "all or nothing", I see it more like responsibility split, you can keep existing integrations in default bundle of prometheus, but make it possible to add other integrations as plugins (Like I mentioned in kafka's case you just add your implementation to classpath and set config value-serializer: com.github.YourImplementation)

@pdambrauskas unfortunately there is no practical option in Go otherwise I guess that pluggable SD would have been done a long time ago...

Have you guys seen cuigh's post above? His implementation (https://github.com/cuigh/prometheus) is complete, fully integrated and confirmed working. Considering that he already did all the heavy lifting, why not simply integrate his implementation? By the looks of things he even seems more than happy to maintain it.. .

I think it would be great. @cuigh Would you be willing to open a PR to add it?

@SuperQ that was already rejected at #3687 😉

Hey, just test the @cuigh fork and it fill my needs, but i prefed to stay in the main prom repo
As i understand, the good solution is to create a new custom sd mechanism like the example in here : https://github.com/prometheus/prometheus/tree/master/documentation/examples/custom-sd
With the code of @cuigh fork in
Anybody have started working on this ?

I would propose re-submitting #3687 as a new PR. We can take an official vote on the Prometheus developers list to decide if it's good enough to merge, rather than having one person on prometheus-team object.

Hey, just test the @cuigh fork and it fill my needs, but i prefed to stay in the main prom repo
As i understand, the good solution is to create a new custom sd mechanism like the example in here : https://github.com/prometheus/prometheus/tree/master/documentation/examples/custom-sd
With the code of @cuigh fork in
Anybody have started working on this ?

I still don't think it's a good idea to implement swarm_sd based on file_sd, unless HTTP is supported in file_sd.

Yeah agree
But i think prometheus team implement this plugin mechanism to be a standard for all sd
As I understand, they want in the future move existing core sd out of prometheus binary too. So all sd will use the plugin mode

By co-locating Prometheus and our new executable we can configure Prometheus to read the file_sd-compatible output of our executable, and therefore scrape targets from that service discovery mechanism. In the future this will enable us to move SD integrations out of the main Prometheus binary, as well as to move stable SD integrations that make use of the adapter into the Prometheus discovery package

See https://prometheus.io/blog/2018/07/05/implementing-custom-sd/

No, we don't want to remove SD from the core. We do want to make it easier to add new methods outside the core.

OK
So who can resubmit PR for a vote ?
@cuigh I would like to improve a bit some code in your fork, can you enable issues on your fork so we can echange on that ?

We discussed this at our monthly meeting today, the moratorium remains. Currently we're awaiting integration testing for a good swathe of our existing SDs, which any new SD would be expected to follow in the steps of.

@brian-brazil could you then please add http support to the file SD (so the SD JSON can be fetched over HTTP), so we'd at least get a clean point of integration for adding SD agents running outside of Prometheus' container?
See use case of https://github.com/function61/promswarmconnect - this would be much cleaner if it could produce JSON compatible with the file SD agent!

We have a moratorium on new SDs, and we already have a clean generic interface for integrations.

We have a moratorium on new SDs, and we already have a clean generic interface for integrations.

That interface is just passing complexity management to the users. With that interface I need to have a the SD binary (let's say promswarmconnect) running either:

Inside the Prometheus' container. In this case the SD plugin project needs to release a new version each time Prometheus releases a new version (the SD plugin project overlays its binary inside Prometheus' Docker image). This also requires a process supervisor, because now we're having unrelated processes running inside a single Docker image. I tried that in my first proof-of-concept of promswarmconnect project. This approach is not robust and creates unnecessary burden for SD plugin developers

Another container running on the same host as Prometheus runs on, and they have to share a filesystem. This is also far from clean. This also requires support from your orchestration layer allowing you to specify ("this container should always run on the same host as Prometheus"), unless you just want to schedule it manually and therefore forget automatic rescheduling if a host goes down..

I ask again, is all this complexity justified just because you don't want to add remote JSON support to the file SD? I can totally understand not wanting to add 4 138 different SD plugins you have to maintain, for trendiest service platform of the week, but we're asking for an olive branch here because what you're suggesting is far from elegant and especially not of a microservice philosophy which Prometheus in other regards so elegantly fits in.
TL;DR: generic HTTP based SD integration is the only elegant way we'll be able to build SD integrations outside of Prometheus' tree.

This also requires support from your orchestration layer allowing you to specify ("this container should always run on the same host as Prometheus")

The sidecar model is pretty standard, and not something you can really avoid if you're using Prometheus. We assume a POSIX system, and that includes processes being able to share filesystems, send each other signals etc.

This approach is not robust and creates unnecessary burden for SD plugin developers

I've done it in the past, the bash scripting is a little finicky, but it's quite doable. Especially if you can use a non-ancient version of bash.

generic HTTP based SD integration is the only elegant way we'll be able to build SD integrations outside of Prometheus' tree.

I disagree here, and there's many out there that build fine on what we have. Writing code and deploying it are separate concerns, and I don't think we should be adding features just because one particular deployment system happens to lack a basic feature.

@cuigh I would like to improve a bit some code in your fork, can you enable issues on your fork so we can echange on that ?

Already merged, thanks.

Docker Swarm rocks :metal:

Looks like this issue has gone stale...I'm looking for mechanisms to implement metrics discovery for Swarm-hosted containers and came across this thread.  Any further progress/thoughts on whether this will be supported in the master branch?  Thanks.

@kz1000fan I think it's no way here
Give a try to the https://github.com/cuigh/prometheus fork

I am aware that there have been several discussions around this subject - has a decision since been made on whether to natively support swarm service discovery?

@darkl0rd Yes, we're willing to accept new discovery. The new rules are

Find a core maintainer to be a sponsor.
Write the code.

I'm happy to be the sponsor for the docker swarm discovery, but someone needs to write the code. :)

@SuperQ there is a complete, working fork / pull request in here from @cuigh.

There are several variants out there, however I've yet to see one which is of a standard where it could be inside Prometheus - for example no hardcoding of business logic.

I am working on this in #7420


Struct.fromJson is very slow on big payloads

Not sure this is the reason but seems redundant in any case - calling Struct.fromJson twice
UPD: this is the reason.

Just to illustrate the severity of the issue - the Struct.fromJson() execution on the following sample JSON data (with 50 levels of depth) runs (on the same machine):

with that line: 8395 ms  (the current version)
without that line: 1 ms

const sample: JsonValue = {"except":false,"were":"soap","fall":false,"father":832438330.2492619,"judge":{"bell":true,"forty":"lion","spell":false,"treated":"lead","powerful":[-1915382547.1272616,true,{"president":false,"drawn":"cow","there":false,"your":-131216582.6039195,"steam":143255540},"environment",["chosen","fruit","neighbor",-1214418426,[{"excited":"throughout","four":-46610307.352087975,"flat":"nails","planning":109343296.10292482,"early":362555568},["somebody",[{"six":{"belt":"reason","elephant":"flew","valley":true,"cent":[[false,{"grandfather":["grown",{"meant":{"sing":"afraid","monkey":"rest","center":[[{"basic":["rise",{"stick":1633501586.562191,"elephant":[true,false,true,false,["lips",false,false,{"indicate":-1642409024.5867453,"eaten":[{"pass":true,"provide":[-1058168439.2220569,[536736276.5472021,"trace",1158274419,{"expect":{"scene":{"hung":true,"nuts":true,"gasoline":{"someone":1565658968,"create":"folks","magnet":"square","mainly":[false,2003291389.6244845,false,[true,[{"occasionally":{"shelf":[[[["period",false,1422326620,[true,"replied","stronger",{"whom":[[[true,47711407,"slope",false,[true,false,false,["fair",[true,-1504694419,1632021133.595004,{"bend":{"valley":-1471244027,"bottle":-518866140.98673487,"shelter":"claws","meet":"promised","invented":-700995723.2329488},"dig":false,"ship":{"tip":-452764443,"canal":"lips","sink":-693283987.5097332,"having":true,"noun":"character"},"several":"story","mine":false},713120907],"clock","pay","whether"],1060804687.9293032]],true,true,"various",855940359.2635612],"sense",-1836095985,"root",false],"instance":"cow","consist":"find","upper":655025342,"putting":-143954973},true],true],1591051111,"shown",-1160075515,60184337.82134724],"position","factory","pilot","went"],true,"sweet",-1862688052.5706272,true],"mind":true,"kitchen":-44407961.5400815,"supper":true,"blew":1020863550.5061803},"roll":false,"angle":559911736.7126079,"too":true,"if":"tight"},"with",-1482035767.2366438,221553545,true],502030747,true,true],-31195225],"own":"needs"},"route":"numeral","within":false},"satellites":"wheel","member":false,"chemical":"wherever","eaten":-1916828045},"happen":false,"nearby":654420565.6144781,"proper":true,"yellow":"variety"},false],"goes",793680281,true],"oil":1442911062,"edge":-1027501111,"nodded":-1305299714.2021503},2024356005.9774342,"to","breeze",false],"herself":-514808092,"except":"future","sad":true},-1679478137.9356961]],"entire":false,"customs":false,"nearly":-841054557},true,true,670591782.6754055],"hungry":false,"pressure":false,"control":true,"shot":"stop"},true,false,-174469618.75811386,true],true,"onlinetools","film",662852906.7231336],"journey":"ordinary","love":"topic"},"sat":-1086615090.715889,"river":true,"wherever":"seems","speed":"current"},1086474724.2683077,"package",1853000028],"town":716345922.2678947,"where":"selection","bowl":true,"biggest":"first"},-2090384320,"symbol",true],"dry",-386553720,-1327828102,true],"pig":1001090992},"wrapped":"surface","break":"shirt","valley":1266508947.5033917,"hundred":"herd"},696669116,1697057798,-210203549.1382451,"won"],"ancient",true,-2015612880],-423849485,"vowel",false]]]}};

Struct.fromJson(sample);

@timostamm PR is pending, though failed for some unrelated reason.

@alexandervain, are you sure this takes 8 seconds?
Happy to take a PR removing the duplicate Struct.fromJson call!

That's what I measured on my machine.
(The PR is pending as @hugebdu pointed above)

Fix is released in v2.8.3.

Thanks a lot @timostamm

Looks like master build fails as well :(

Yes, with a silly error:

npm ERR! This is an error with npm itself.

This project needs to move away from lerna to npm workspaces. And from Circle CI to GH actions.
Help is welcome.


Fix: default serialization for FunctionAbiEntryType

When deserializing a "deprecated" Cairo contract class using the starknet-api and compiling with starknet-compile version 0.11, the deserializer expects the value of the "type" attribute of the ABI schema for functions to be "regular". However, the JSON output of the Cairo program compilation contains an ABI schema with the entry type being "function". This causes the deserialization to fail when trying to read a Cairo contract class.
This PR provides a fix to this issue by changing the default value expected in FunctionAbiEntryType to "function" instead of "regular".

This change is

src/deprecated_contract_class.rs line 59 at r1 (raw file):

    #[serde(rename = "function")]
    #[default]
    Regular,

Consider changing the variant name as well (although it is somewhat weird that a FunctionAbiEntryType will have a Function variant.
Code quote:
Regular


Make cli filtering more consistent

Currently few commands accept all 3 filters (--host, --path and --tag) and a lot of other commands accept just one or two. Can we try and make things more consistent? For a casual user consistency rules. They don't want to look at the help each time they need to run a command.
My first attempt at solving this. Not a PR yet (expecting loads of comments ^^ and will have merge conflicts with the 2 other PRs I have inflight):
https://github.com/middelink/restic/compare/master...middelink:widespread-tags

Good idea, consistency is important!

Will you add a PR for this so we can discuss the code?


Can we always assume UTF8?

Right now, ktfmt uses the default system charset to parse files. This has caused some headaches when users have unusual charsets as the default. Usually it ends up mangling non-ASCII characters.
Kotlin specifies that all source files must be in UTF8, so it's reasonable that ktfmt could make the same assumption. We could ignore the system default and always use UTF8.
The only caveat I can see with this change is that, ktfmt may crash when invoked on the command line with literal text, on a system using a different default encoding. This usecase seems pretty unlikely, so maybe not worth worrying about compared to the advantages. Also, in this situation, do we emit the formatted code using the system encoding?

Kotlin specifies that all source files must be in UTF8

I couldn't find a reference to this (outside of Google's style guide), but this sounds reasonable. Maybe worth running this by folks in the Kotlin slack.

Oh weird. I thought UTF8 was a language level thing, but maybe I mixed that up with https://developer.android.com/kotlin/style-guide


Add Font Awesome as Font Icon Library

https://docs.fontawesome.com/web/use-with/vue/

Great Idea!


MX error: host not found

hi mwader,
As you're probably aware, peertube uses/suggests your image for their mail/notification work
I'm trying to setup my own peertube instance, and have worked through every other issue, however a persistent email error eludes me..
the error is as follows:
<EMAIL_ADDRESS>relay=none, delay=0.11, delays=0.08/0.03/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=gmail.com type=MX: Host not found, try again
the email address is usable, accessed regularly (though redacted for this issue); I'm just curious, if there's fix for this.. if there's something I'm doing wrong.. any help is appreciated

Hi, that is strange. Can you docker exec into the container and use nslookup or host to see if you can lookup the MX record? might have to install bind9-host and  dnsutil packages and then do something like host -v -t mx gmail.com.

Hi, that is strange. Can you docker exec into the container and use nslookup or host to see if you can lookup the MX record? might have to install bind9-host and  dnsutil packages and then do something like host -v -t mx gmail.com.

I got command not found when trying nslookup and host..
and I got unable to locate package when trying to install bind9-host and dnsutil
This seems strange to me

I got command not found when trying nslookup and host..
and I got unable to locate package when trying to install bind9-host and dnsutil
This seems strange to me

Ah sorry you probably have to do apt-get update first, the package source files are removed in the Dockerfile.

Ah sorry you probably have to do apt-get update first, the package source files are removed in the Dockerfile.

nslookup:
root@704fad740233:/app# nslookup gmail.com
Server:         xxx.xxx.xxx.xxx
Address:        xxx.xxx.xxx.xxx#53
Non-authoritative answer:
Name:   gmail.com
Address: 216.xxx.xxx.101
Name:   gmail.com
Address: 2404:xxxx:xxxx:xxx::2005
host -v -t mx gmail.com:
Trying "gmail.com"
(some output, not sure if you wanted it)
Received 27 bytes from <IP_ADDRESS>#53 in 1 ms

nslookup:
root@704fad740233:/app# nslookup gmail.com
Server:         xxx.xxx.xxx.xxx
Address:        xxx.xxx.xxx.xxx#53
Non-authoritative answer:
Name:   gmail.com
Address: 216.xxx.xxx.101
Name:   gmail.com
Address: 2404:xxxx:xxxx:xxx::2005
host -v -t mx gmail.com:
Trying "gmail.com"
(some output, not sure if you wanted it)
Received 27 bytes from <IP_ADDRESS>#53 in 1 ms

hmm empty MX? i see this:
$ host -v -t mx gmail.com
Trying "gmail.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18309
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gmail.com.			IN	MX

;; ANSWER SECTION:
gmail.com.		1510	IN	MX	40 alt4.gmail-smtp-in.l.google.com.
gmail.com.		1510	IN	MX	5 gmail-smtp-in.l.google.com.
gmail.com.		1510	IN	MX	30 alt3.gmail-smtp-in.l.google.com.
gmail.com.		1510	IN	MX	20 alt2.gmail-smtp-in.l.google.com.
gmail.com.		1510	IN	MX	10 alt1.gmail-smtp-in.l.google.com.

Received 150 bytes from <IP_ADDRESS>#53 in 4 ms

hmm empty MX? i see this:
$ host -v -t mx gmail.com
Trying "gmail.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18309
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gmail.com.			IN	MX

;; ANSWER SECTION:
gmail.com.		1510	IN	MX	40 alt4.gmail-smtp-in.l.google.com.
gmail.com.		1510	IN	MX	5 gmail-smtp-in.l.google.com.
gmail.com.		1510	IN	MX	30 alt3.gmail-smtp-in.l.google.com.
gmail.com.		1510	IN	MX	20 alt2.gmail-smtp-in.l.google.com.
gmail.com.		1510	IN	MX	10 alt1.gmail-smtp-in.l.google.com.

Received 150 bytes from <IP_ADDRESS>#53 in 4 ms

Or no sorry, no answers at all

Or no sorry, no answers at all

Do you get MX records answers if you do host -v -t mx gmail.com <IP_ADDRESS>? you can also try asking your ISP:s DNS server etc, that answer comes from docker:s built in DNS relay

Do you get MX records answers if you do host -v -t mx gmail.com <IP_ADDRESS>? you can also try asking your ISP:s DNS server etc, that answer comes from docker:s built in DNS relay

Does it persist even after a docker daemon restart? does it start to work sometimes without doing anything?

Does it persist even after a docker daemon restart? does it start to work sometimes without doing anything?

Yes I do get answers when I do host -v -t mx gmail.com <IP_ADDRESS>
The error persists after docker restart.. and has never worked

Yes I do get answers when I do host -v -t mx gmail.com <IP_ADDRESS>
The error persists after docker restart.. and has never worked

<IP_ADDRESS> is the docker DNS, thats obviously where the issue is

<IP_ADDRESS> is the docker DNS, thats obviously where the issue is

Does it work to lookup MX on the host that runs docker?

Does it work to lookup MX on the host that runs docker?

nice work; it doesn't

nice work; it doesn't

Maybe a good test is to lookup MX for some other domains or is this only gmail?

Maybe a good test is to lookup MX for some other domains or is this only gmail?

I try a few domains everytime I try the commands, it never works

I try a few domains everytime I try the commands, it never works

obviously the issue is with my server setup; I feel like we can close this issue.
Thanks for all the diagnostic help; it's actually been a good learning experience

obviously the issue is with my server setup; I feel like we can close this issue.
Thanks for all the diagnostic help; it's actually been a good learning experience

Ok! no problem!

Ok! no problem!


checkver: automatically commit updated manifests with git

My workflow for updating personal manifests is simple:

run checkver -update * or checkver -update ${app}
run `git commit -m '${app}: update to ${version}'

It'd be kind of nice if checkver -update would automatically do that commit for each changed manifest.  Not a big thing, but it'd save a bit of manual work.

.\bin\auto-pr.ps1

Seems like your question was answered,


openrocket: init at 23.09

Description of changes
Closes https://github.com/NixOS/nixpkgs/issues/274805
This PR adds 1 package: openrocket
I won't worry about reproducibility until https://github.com/NixOS/nixpkgs/pull/278322 is merged. For now this is just for the package to exist.

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 283850 run on aarch64-linux 1

1 package built:

openrocket


ci  update ci config

Description
Update GitHub Actions:

build(deps): bump github/codeql-action from 3.26.0 to 3.26.1
ci: 🐝 update CI config
build(deps): bump github/codeql-action from 3.26.1 to 3.26.2
build(deps): bump github/codeql-action from 3.26.2 to 3.26.3
ci: 🐝 update dprint config

Type of change

[X] CI

Checklist:

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have made corresponding changes to the documentation
[X] My changes generate no new warnings
[X] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes
[X] Any dependent changes have been merged and published in downstream modules

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 52.32%. Comparing base (344b68b) to head (013c5d3).
Report is 12 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #50   +/-   ##
=======================================
  Coverage   52.32%   52.32%
=======================================
  Files           4        4
  Lines         946      946
=======================================
  Hits          495      495
  Misses        451      451

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Upgrading RHEL7.9 to RHEL 8.4 on SAP environments - IOError: [Errno 2] No such file or directory: u'/etc/leapp/repos.d/system_upgrade/common/files/rhui/azure/content.crt'

Actual behavior
During the Leapp upgrade to RHEL 8.4 in a environment running the latest version of RH7.9 on Azure PAYG without RHSM creates a error IOError: [Errno 2] No such file or directory: u'/etc/leapp/repos.d/system_upgrade/common/files/rhui/azure/content.crt'
After running the command leapp preupgrade --no-rhsm --channel e4s --enablerepo rhel-8-for-x86_64-appstream-e4s-rhui-rpms --enablerepo rhel-8-for-x86_64-baseos-e4s-rhui-rpms --enablerepo microsoft-azure-rhel8-sap-ha
==> Processing phase `TargetTransactionFactsCollection`
====> * target_userspace_creator
        Initializes a directory to be populated as a minimal environment to run binaries from the target system.
Process Process-448:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/lib64/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python2.7/site-packages/leapp/repository/actor_definition.py", line 72, in _do_run
    actor_instance.run(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/leapp/actors/__init__.py", line 290, in run
    self.process(*args)
  File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/actor.py", line 52, in process
    userspacegen.perform()
  File "/usr/lib/python2.7/site-packages/leapp/utils/deprecation.py", line 42, in process_wrapper
    return target_item(*args, **kwargs)
  File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/libraries/userspacegen.py", line 673, in perform
    target_repoids = _gather_target_repositories(context, indata, prod_cert_path)
  File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/libraries/userspacegen.py", line 616, in _gather_target_repositories
    rhui.copy_rhui_data(context, indata.rhui_info.provider)
  File "/usr/share/leapp-repository/repositories/system_upgrade/common/libraries/rhui.py", line 177, in copy_rhui_data
    context.copy_to(os.path.join(data_dir, path_[0]), path_[1])
  File "/usr/share/leapp-repository/repositories/system_upgrade/common/libraries/mounting.py", line 233, in copy_to
    shutil.copy2(src, self.full_path(dst))
  File "/usr/lib64/python2.7/shutil.py", line 130, in copy2
    copyfile(src, dst)
  File "/usr/lib64/python2.7/shutil.py", line 82, in copyfile
    with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: u'/etc/leapp/repos.d/system_upgrade/common/files/rhui/azure/content.crt'

To Reproduce
During the Leapp upgrade to RHEL 8.4 in a environment running the latest version of RH7.9 on Azure PAYG without RHSM.
leapp preupgrade --no-rhsm --channel e4s --enablerepo rhel-8-for-x86_64-appstream-e4s-rhui-rpms --enablerepo rhel-8-for-x86_64-baseos-e4s-rhui-rpms --enablerepo microsoft-azure-rhel8-sap-ha

install '...'
setup '....'
run '....'
(when run leapp, use always the --debug option to provide more data)
See error

Process Process-448:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/lib64/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python2.7/site-packages/leapp/repository/actor_definition.py", line 72, in _do_run
    actor_instance.run(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/leapp/actors/__init__.py", line 290, in run
    self.process(*args)
  File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/actor.py", line 52, in process
    userspacegen.perform()
  File "/usr/lib/python2.7/site-packages/leapp/utils/deprecation.py", line 42, in process_wrapper
    return target_item(*args, **kwargs)
  File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/libraries/userspacegen.py", line 673, in perform
    target_repoids = _gather_target_repositories(context, indata, prod_cert_path)
  File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/libraries/userspacegen.py", line 616, in _gather_target_repositories
    rhui.copy_rhui_data(context, indata.rhui_info.provider)
  File "/usr/share/leapp-repository/repositories/system_upgrade/common/libraries/rhui.py", line 177, in copy_rhui_data
    context.copy_to(os.path.join(data_dir, path_[0]), path_[1])
  File "/usr/share/leapp-repository/repositories/system_upgrade/common/libraries/mounting.py", line 233, in copy_to
    shutil.copy2(src, self.full_path(dst))
  File "/usr/lib64/python2.7/shutil.py", line 130, in copy2
    copyfile(src, dst)
  File "/usr/lib64/python2.7/shutil.py", line 82, in copyfile
    with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: u'/etc/leapp/repos.d/system_upgrade/common/files/rhui/azure/content.crt'

=========================================================================================================
Actor target_userspace_creator unexpectedly terminated with exit code: 1 - Please check the above details
=========================================================================================================
2022-07-22 17:33:47.870 INFO     PID: 10179 leapp: Answerfile will be created at /var/log/leapp/answerfile
2022-07-22 17:33:48.109 WARNING  PID: 10179 leapp.reporting: Stable Key report entry not provided, dynamically generating one - 29dc5fbec67feabdf323a3eed704a09b7cc38b7c
2022-07-22 17:33:48.314 WARNING  PID: 10179 leapp.reporting: Stable Key report entry not provided, dynamically generating one - 29dc5fbec67feabdf323a3eed704a09b7cc38b7

Expected behavior
A full upgrade from RHEL 7.9 to 8.4
System information (please complete the following information):

OS and version: (e.g. Fedora 29 or $ cat /etc/system-release)
# uname -a

linux 3.10.0-1160.71.1.el7.x86_64 #1 SMP Wed Jun 15 08:55:08 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

# rpm -qa "*leapp*" (or shorthashes of commits in case of manual installation):

leapp-upgrade-el7toel8-0.16.0-4.el7_9.noarch
leapp-rhui-azure-sap-1.0.0-1.el7.noarch
leapp-upgrade-el7toel8-deps-0.16.0-4.el7_9.noarch
leapp-deps-0.14.0-1.el7_9.noarch
python2-leapp-0.14.0-1.el7_9.noarch
leapp-0.14.0-1.el7_9.noarch
leapp-rhui-azure-1.0.0-2.el7.noarch

Hi @PRELVAS94, thank you for your detailed report and pointing out this issue.
I've checked the described behavior, and it is indeed a bug, due to an outdated leapp-rhui-azure package present in the RHUI repositories. This outdated leapp-rhui-azure does not yet reflect that since the the v0.16.0 release of leapp-repository, the files necessary when upgrading RHUI systems need to be present elsewhere - the packages places these files into /etc/leapp/repos.d/system_upgrade/el7toel8/files/rhui/, whereas they need to be in /etc/leapp/repos.d/system_upgrade/common/files/rhui. Therefore, the workaround is straightforward - manually copying the files into the correct folder.
We will work on updating our RHUI-specific packages for Azure, and any updates regarding this bug will be posted in this issue.

HI Team,
Thanks for sharing the feedback. I solved it by using other repos… Here’s a small workaround I did for it to work
Next step is to make sure we have the appropriate packages in the repolist. One thing to make sure is that we do not have this following repo:
rhui-microsoft-azure-rhel7-base-sap-apps                                      Microsoft Azure RPMs for Red Hat Enterprise Linux 7 (rhel7-base-sap-apps)
To get rid of it we will do the following :
Get inside /etc/yum.repos.d
And delete the following:
@.*** yum.repos.d]$ rm -rf  rh-cloud-base-sap-apps.repo
With the other repo deleted, we will need to configure this repo:
yum --config='https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel7-base-sap-ha.config' https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel7-base-sap-ha.config' install 'rhui-azure-rhel7-base-sap-ha’

On 2 Aug 2022, at 14:17, Michal Hečko @.***> wrote:
Hi @PRELVAS94 https://github.com/PRELVAS94, thank you for your detailed report and pointing out this issue.
I've checked the described behavior, and it is indeed a bug, due to an outdated leapp-rhui-azure package present in the RHUI repositories. This outdated leapp-rhui-azure does not yet reflect that since the the v0.16.0 release of leapp-repository, the files necessary when upgrading RHUI systems need to be present elsewhere - the packages places these files into /etc/leapp/repos.d/system_upgrade/el7toel8/files/rhui/, whereas they need to be in /etc/leapp/repos.d/system_upgrade/common/files/rhui. Therefore, the workaround is straightforward - manually copying the files into the correct folder.
We will work on updating our RHUI-specific packages for Azure, and any updates regarding this bug will be posted in this issue.
—
Reply to this email directly, view it on GitHub https://github.com/oamg/leapp/issues/786#issuecomment-1202536240, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUQIFEDT6FYKYXU7XNURESTVXENW3ANCNFSM54MIY5MQ.
You are receiving this because you were mentioned.

@PRELVAS94 Hi, I am sorry for the late response here. The issue around applications is fixed in the current upstream leapp-repository release (will be fixed officially during RHEL 8.8 GA date). switching to leapp-repository.


mobile/test: Fix SetEventTracker test flakes

The event tracker callback can get called multiple times at different junctures in the code, not just from the TestEventTracker filter. This PR ensures that we only fulfill the test expectation when the TestEventTracker filter's events appear in the callback.

/assign @fredyw


Jest Tests fail only when running on Tekton

I am using Tekton on Openshift.
We are trying to migrate from GitHub Actions to Tekton.
When we run our nodejs tests locally they run just fine, when we run it on GitHub Actions or just running the commands in a Dockerfile it works as expected but when running on Tekton with nodejs image or ubuntu or centos I get the same errors.
Anyone know what could be going wrong? Attached the log file.
yarn-install.log

From the log I can only really tell that there are syntax errors, which I'd usually attribute to configuration problems.  It's difficult to say how this could be Tekton related without seeing the Tekton resources.  Can you isolate this problem to a single minimal Task & TaskRun and then post those YAMLs?  Remember to remove any sensitive information before posting.

I'm pretty sure there are not syntax errors, I cannot give the source code to test but when I am running locally this commands it work:
yarn install
yarn bootstrap
yarn compile
yarn test:ci
Also I created this Dockerfile to test, it also does work all the test are finishing succesfully if I run it with docker podman or on openshift
FROM node:latest ENV GITHUB_TOKEN ***  ENV NPM_TOKEN *** RUN git clone<EMAIL_ADDRESS>WORKDIR zeus RUN yarn install RUN yarn bootstrap RUN yarn compile RUN yarn test:ci
However when running this task that ( from my understanding) does pretty much the same thing I get all this syntax errors and I am wondering what could the difference be. ( Now the task is using centos but I tried with node:latest and other images as well)
apiVersion: tekton.dev/v1beta1 kind: Task   name: yarn-install spec:   resources:     inputs:       - name: zeus-repo         type: git   steps:     - command:         - sh         - '-c'         - >-            cd /workspace/zeus-repo/ && ls -a && curl --silent --location           https://rpm.nodesource.com/setup_14.x | bash - && curl --silent           --location https://dl.yarnpkg.com/rpm/yarn.repo | tee           /etc/yum.repos.d/yarn.repo  && yum install yarn -y && yarn install &&           export PATH="$PATH:yarn global bin" && yarn bootstrap && yarn           compile && yarn test:ci       env:         - name: NPM_TOKEN           valueFrom:             secretKeyRef:               key: NPM_TOKEN               name: secure-properties         - name: GITHUB_TOKEN           valueFrom:             secretKeyRef:               key: GITHUB_TOKEN               name: secure-properties         - name: NODE_ENV           valueFrom:             secretKeyRef:               key: NODE_ENV               name: secure-properties       envFrom:         - secretRef:             name: secure-properties       image: 'centos:latest'       name: yarninstall       resources: {}       securityContext:         privileged: true         runAsUser: 0

Yeah, it's difficult to nail down what Tekton could be doing to mess things up here. I think we'd definitely need more info about what's different in the Tekton-run container vs the others.  Couple things I notice:

Mixing env and envFrom.  I think you only need 1 of those?
I think you can use the workingDir field in the Step to set the directory where you want the commands to run from, eliminating the cd
Instead of passing sh as the command you can use a script block:

script: |
  ls -a
  curl --silent --location https://rpm.nodesource.com/setup_14.x | bash -
  curl --silent --location https://dl.yarnpkg.com/rpm/yarn.repo | tee /etc/yum.repos.d/yarn.repo
  yum install yarn -y
  yarn install
  export PATH="$PATH:`yarn global bin`"
  yarn bootstrap
  yarn compile
  yarn test:ci

I would be surprised if any of these fix your problem though.  One thing you can try is to add a sleep into the script like this:
script: |
  ls -a
  curl --silent --location https://rpm.nodesource.com/setup_14.x | bash -
  curl --silent --location https://dl.yarnpkg.com/rpm/yarn.repo | tee /etc/yum.repos.d/yarn.repo
  yum install yarn -y
  export PATH="$PATH:`yarn global bin`"
  sleep 10000

Then use kubectl exec -it <name of pod> -c <name of Step container> -- /bin/sh to run a shell in the Step and start poking around trying to find out why things are not working.  e.g. checking env returns the values you expect, checking what happens when you run the yarn commands manually etc...
One final idea: Have you tried writing a plain Pod with a container that also runs these commands?  Something like this:
kind: Pod
apiVersion: v1
metadata:
  name: foo-pod
spec:
  containers:
    - command:
        - sh
        - '-c'
        - >-
           yum install -y git && mkdir /workspace && git clone <repo> /workspace/zeus-repo &&
          `cd` /workspace/zeus-repo/ && ls -a && curl --silent --location
          https://rpm.nodesource.com/setup_14.x | bash - && curl --silent
          --location https://dl.yarnpkg.com/rpm/yarn.repo | tee
          /etc/yum.repos.d/yarn.repo  && yum install yarn -y && yarn install &&
          export PATH="$PATH:`yarn global bin`" && yarn bootstrap && yarn
          compile && yarn test:ci
      env:
        - name: NPM_TOKEN
          valueFrom:
            secretKeyRef:
              key: NPM_TOKEN
              name: secure-properties
        - name: GITHUB_TOKEN
          valueFrom:
            secretKeyRef:
              key: GITHUB_TOKEN
              name: secure-properties
        - name: NODE_ENV
          valueFrom:
            secretKeyRef:
              key: NODE_ENV
              name: secure-properties
      envFrom:
        - secretRef:
            name: secure-properties
      image: 'centos:latest'
      name: yarninstall
      resources: {}
      securityContext:
        privileged: true
        runAsUser: 0

If this Pod also exhibits the same problem then there's something more general going on, otherwise it does look like Tekton is modifying something that's causing Jest to choke.  If this Pod works then you can compare the Pod that Tekton created for the TaskRun with the Pod you ran and see if there are any obvious differences that might explain the different jest behaviour.

The same happens with plain pod and with running the commands in the container so I guess this is unrelated with Tekton.

did you find a fix to run jest in containers? is this related to maxWorkers ?


Failed to connect to OTA provider Node (CON-565)

I am testing the matter OTA function, and the ESP Matter device has an error of "Failed to connect to OTA provider Node".
The OTA test log is as follows：
chip-tool-pair-requestor.log
ota_provider2.log
chip-tool-pair-provider.log
write_acl.log
start_ota.log

Could you please provide the device log so that we can know why the requestor cannot connect to the provider?

@wqx6
I removed the parameter "deviceType" of the write ACL command, and when the command is executed, it prompts that the "deviceType" parameter is required
ota_write_acl.log

@wqx6 The problem has been solved, it is the problem of the computer firewall.


Feature: optimise example video

Optimizing example - removed unneeded transformations and methods and further simplified code.
From testing on Pi 4 60FPS its usable with 40-65% cpu, before these changes CPU was 50-80%
@steelbrain @rhysmorgan134 curious if you have a similar experience on this branch?

I've done some testing
new changes

current master branch

jmuxer/electron

Not particuarly useful as it's obviously a 1min average, but test was to go to map, choose navigate to work, let maps zoom in, then manually zoom out 5 clicks, then cancel route.
Worth noting, I am unsure how jmuxer scored so high, jmuxer @ 1080 @ 60fps feels the worst in the case of useablility but got the lowest averages, I am guessing it is just dropping frames so technically lowering the load, but causing severe lag.
I would say the new changes feel better, but I still think 1080 @ 60fps on all implementations doesn't feel "smooth". This is all with gpu mem set to 256mb on a pi4 4gb

Added more renderers - particularly interested in WebGPU (supposed to be faster than WebGL), which we need Vulkan for - planning to try and enable Vulkan on the pi following - https://qengineering.eu/install-vulkan-on-raspberry-pi.html
You can also enable fps reporting to see console logs with FPS every 5 seconds

Added more renderers - particularly interested in WebGPU (supposed to be faster than WebGL), which we need Vulkan for - planning to try and enable Vulkan on the pi following - https://qengineering.eu/install-vulkan-on-raspberry-pi.html

The referenced blog post seems very heavy weight just to try Vulkan, here’s something from ChatGPT https://chat.openai.com/share/bbaefbb3-9115-41c1-9cf9-0d4f3086dc53
Looks like it’s bundled in raspi repositories now?

Looks good to me, will give the different renderers a try when I get a chance!

@gozmanyoni It was on macOS, I spent a few minutes on the pi and gave up after Chromium didnt enable webgpu even after vulkan drivers were installed.
I can try again on the weekend and document what works and what doesnt

@gozmanyoni @steelbrain silky smooth on a pi5 even at 1080@60fps!

@rhysmorgan134 nice! Do you have a demo video?
Also - does the pi5 play well with PiMOST? No stock of these in Australia yet :-(

@gozmanyoni no video yet, will grab one though.
Pi5 itself seems to be working well with it, however bookworm is having issues with i2s and the simple-audio-card overlay!


Add debugging information to determine if running in container

Something that might be useful for people using software containers, such as Docker / OCI or rkt, would be to include some debugging information to $PSVersionTable, to determine whether or not the PowerShell instance is running inside a software container. This may aid in debugging by providing additional, contextual information about the PowerShell process.
Cheers,
Trevor Sullivan
Docker Captain
Microsoft MVP: Cloud & Data Center Management
https://trevorsullivan.net
https://twitter.com/pcgeek86

Could also use an $env variable to give us something to work with, which is more of a Docker-y way of presenting that

@phwelo Possibly a PS variable, but $env variables are explicitly environment variables. Unless there's already an environment variable for knowing if you're in a container, I don't think that's applicable here.

My point was more that a container is describing the environment more than it is the Powershell thread. Overall it doesn't matter to me as long as I can differentiate though!

@phwelo oh, gotcha, that make sense.
I'm hoping that .NET Core 2.0 exposes something in System.Environment to help with this. But otherwise, it might be Docker's responsibility, as you say.

There is many ways to detect docker container
https://stackoverflow.com/questions/43002803/detect-if-process-executes-inside-a-windows-container
https://stackoverflow.com/questions/20010199/how-to-determine-if-a-process-runs-inside-lxc-docker
I close the issue until we decide to do the detection inside PowerShell Core.


Translate concepts/overview/working-with-objects/annotations in Korean

from #13647

/assign @seokho-son

/reopen


joint_velocity_violation

I need Franka to run at a relatively fast angular velocity, but I always get the error “joint_velocity_violation”.
I tried turning up the velocity in panda_arm.xacro, limit effort="12" lower="-2.8973" upper="2.8973" velocity="3.6100", but that didn’t work. I also changed kMaxJointVelocity and kMaxRotationalVelocity in rate_limiting.h to a larger size, but it didn’t work.
So how can I change it so that Franka can run faster?

joint_velocity_violation tells you already, that you are moving too fast. You can not move faster and expect that there will be no joint_velocity_violation anymore.


Cannot submit form when enter key down

vue-autosuggest version: 2.0.0
node version: 10.15.0
npm (or yarn) version: 6.9.0

Relevant code or config

What you did:
The form submit when [Enter] key down at input element on this component.
What happened:
Key down event inhibite at this component key down event handler.
Thus, the form submit was canceled.

Reproduction repository:

Problem description:
Suggested solution:
If not affected, evaluate isOpen property in keydown event handler when captured at keycode 13.

You have to submit the form yourself, and this can be done in a number of ways:
<form ref="theForm">
<vue-autosuggest @keyup.enter="$refs.theForm.submit()"

<form @submit.prevent="submitHandler">
<vue-autosuggest @keyup.enter="submitHandler"

But you probably want to also check to see if the user selected an item and not always submit the form.

Thank you for reply. This is my first post issue, I'm so fun !
And, I'm sorry for my poor english.
My wish, When suggest list is opened, enter is choise list item and the form never submit.
When suggest list is not opened, enter is submit the form.
Your prepared sample is always submit form when key enter.
I want to handle it as standard operation as possible (key enter make to submit form).
Please do the 'preventDefault' currently being executed in the key down event only when the list is open.
Usually I have to PR it myself, but I can not do it yet because I started github in a few days...

I see your problem now. You can do this: If a user hits enter @selected is emitted, and if no item is passed in, then you can submit the form. I updated the example:
https://codesandbox.io/s/httpsgithubcomdarrenjenningsvue-autosuggestissues125-sn74o
Let me know if that helps.

I could!
Thank you for your help and kindness sample code.
Please close this issue.

Hello,
What if you are using multiple sections? where @input="fetchResults" is not used but the onSelected on the sectionConfigs instead?
Thanks!

@daniel-farina do you have a codesandbox you could reproduce? I would assume you can use the same method inside onSelected in the section config, but maybe I misunderstand your point.


Add Coolify

Add icons for Coolify app (https://github.com/coollabsio/coolify).

Closing as duplicate of https://github.com/walkxcode/dashboard-icons/pull/684


fix(form): force calling clear at form creation/model change

Calling clear at form creation allow the field validation strategies to be in place. This does not seem to have any negative effect.
Fixes #2282.

Could we have a test here to prevent future regressions?

I added a simple test and verified that the test fails without the fix.


Plugin Checkbox. Whole_node option problem

With Whole_node option when clicking on a node resets all other checkboxes.
Like input type='radio' does.

You probably have misconfigured the plugins. Here is a simple demo: http://jsfiddle.net/DGAF4/866/
You can see checkbox and wholerow work nicely together.
Best regards,
Ivan

I meant the whole_node property of a checkbox plugin. http://jsfiddle.net/p7w3yn7a/
I wish it sets checkbox only when clicking on checkbox, not on the name of node. Instead of this it switch checkboxes in "radio" style when I click on the node name.

This is the purpose of the setting - from what I see it is working according to the docs. Maye you need the checkbox.tie_selection option set to false?

checkbox.tie_selection seems no effect in my case
By clicking on the text of the node I need not to affect the checkbox. I need it happens only when you press directly on the checkbox. Instead, it switches on the checkboxes every time I click on the text of the node. It doesn't toggle it, only switchs on. Maybe some misunderstanding. Sorry
For example, I need to open contextmenu on the node, but not to select checkbox. Now, when I press right button on the node, it switchs on checkbox, and my old selection modified. It is not convenient.
Unfortunately, http://jsfiddle.net/p7w3yn7a/2/ doesn't show contextmenu for me too.
I’m sorry to bother you

I don't know is it bug or not, but by trial-and-error testing I found  that it needs both options: checkbox.whole_node to false and checkbox.tie_selection to false to work properly.
http://jsfiddle.net/p7w3yn7a/4/


[UI] Hyperlink styling in notifications

Current Behavior
Ugliness and a regression of hyperlink styling, which is out of accordance with the Sistent design system:
Desired Behavior
Revert recent changes that impacted hyperlink styling inside of notifications.
Implementation
This might need to be driven through the Sistent design system.
Screenshots/Logs

Environment

Browser: Safari
Host OS: Mac
Meshery Server Version: stable-v0.7.122

Contributor Guides and Handbook

🎨 Wireframes and designs for Meshery UI in Figma (open invite)
🖥 Contributing to Meshery UI
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

@aabidsofi19 will you remark on the suggestion under "Implementation" in the description?

Hello @leecalcote can you clarify what kind of design there should be? Like we can create a text and then embed the hyperlink onto it.

@Pratik-050, a good place to review is that of the Sistent component for notifications, assuming that there is one. Use Sistent's theme. Revert the change previously made.
@sudhanshutech, there are still only three published components on this project site? What become of the promise made to see them all published? @nebula-aac, it's difficult to ask contributors to use Sistint components when they're not documented. From what I can see on the project site, there is no link to the GitHub repo. How are new contributors to find their way around? There is only an npm install command.
@Pratik-050 here is a link to Sistent design system repo - https://github.com/layer5io/sistent/

Apologies @leecalcote , there is a pr which are adding few more components but a little work required then it will be good to go and you will see other components. There is challenge to add a meaningful content because there is no mockups we have for them so i had to research for them.

Thanks @Pratik-050 for jumping in , there was small update required through sistent to support style in notifications which is not fixed and updated. I will try to add other components to layer5 soon.

Thanks @Pratik-050 for jumping in , there was small update required through sistent to support style in notifications which is not fixed and updated. I will try to add other components to layer5 soon.

Thanks @sudhanshutech for resolving the issue so fast.
If there's any UI issue I can help with let me know!


Performanc issue with big data (Webgl support?)

Performanc issue with big data, and only solution I guess is webgl support?
Any time soon?

please open a discussion in the relevant section.


WIP: Add value_counts() to DataFrame

abstract bin generation from cut to use elsewhere. Panel goes to ndarray on
apply so that's a future TODO.

I'm relatively certain that this works, but I don't have explicit tests
for it. I'm hoping others who are interested (cough cough @rockg) will
be willing to create some of them. Key to test are that binning,
normalization and sorting all work correctly.
Will close #5377 when completed.

closing as stale


fix language ids

Testing if #53 is fixed with a new PR
This PR uses the approved language IDs for the code blocks
https://docs.microsoft.com/en-us/contribute/code-in-docs#supported-languages

Docs Build status updates of commit 7b04317:
:warning: Validation status: warnings

File
Status
Preview URL
Details

globalization/locale/handling-calendars-in-dotnet-framework.md
:warning:Warning
View
Details

globalization/locale/time-formatting-and-time-zones-in-win32.md
:warning:Warning
View
Details

globalization/input/console-globalization.md
:white_check_mark:Succeeded
View

globalization/input/text-rendering.md
:white_check_mark:Succeeded
View

globalization/locale/currency-formatting-in-the-dotnet-framework.md
:white_check_mark:Succeeded
View

globalization/locale/currency-formatting-in-win32.md
:white_check_mark:Succeeded
View

globalization/locale/handling-calendars-in-win32.md
:white_check_mark:Succeeded
View

globalization/locale/number-formatting-in-dotnet-framework.md
:white_check_mark:Succeeded
View

globalization/locale/number-formatting-in-win32.md
:white_check_mark:Succeeded
View

globalization/locale/sorting-and-string-comparison.md
:white_check_mark:Succeeded
View

globalization/locale/time-formatting-and-time-zones-in-dotnet-framework.md
:white_check_mark:Succeeded
View

globalization/locale/units-of-measurement.md
:white_check_mark:Succeeded
View

globalization/localizability/avoid-run-time-composite-strings.md
:white_check_mark:Succeeded
View

globalization/localizability/do-not-compound-several-variables.md
:white_check_mark:Succeeded
View

globalization/localizability/dotnet-framework-string-format.md
:white_check_mark:Succeeded
View

globalization/localizability/element-resizing.md
:white_check_mark:Succeeded
View

globalization/localizability/isolate-localizable-resources.md
:white_check_mark:Succeeded
View

globalization/localizability/mirroring-in-dotnet-framework.md
:white_check_mark:Succeeded
View

globalization/localizability/mirroring-in-win32.md
:white_check_mark:Succeeded
View

globalization/localizability/win32-formatmessage.md
:white_check_mark:Succeeded
View

globalization/locale/handling-calendars-in-dotnet-framework.md

Line 11: [Warning] Link 'http://msdn2.microsoft.com/en-us/library/system.datetime.aspx' is insecure. Links to Microsoft sites must use 'https' instead of 'http'.
Line 11: [Warning] Link 'http://msdn2.microsoft.com/en-us/library/system.globalization.datetimeformatinfo.calendar.aspx' is insecure. Links to Microsoft sites must use 'https' instead of 'http'.
Line 11: [Warning] Link 'http://msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.calendar.aspx' is insecure. Links to Microsoft sites must use 'https' instead of 'http'.

globalization/locale/time-formatting-and-time-zones-in-win32.md

Line 114: [Warning] Link 'http://msdn2.microsoft.com/' is insecure. Links to Microsoft sites must use 'https' instead of 'http'.

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

Docs Build status updates of commit a5cccb2:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

globalization/input/console-globalization.md
:white_check_mark:Succeeded
View

globalization/input/text-rendering.md
:white_check_mark:Succeeded
View

globalization/locale/currency-formatting-in-the-dotnet-framework.md
:white_check_mark:Succeeded
View

globalization/locale/currency-formatting-in-win32.md
:white_check_mark:Succeeded
View

globalization/locale/handling-calendars-in-dotnet-framework.md
:white_check_mark:Succeeded
View

globalization/locale/handling-calendars-in-win32.md
:white_check_mark:Succeeded
View

globalization/locale/number-formatting-in-dotnet-framework.md
:white_check_mark:Succeeded
View

globalization/locale/number-formatting-in-win32.md
:white_check_mark:Succeeded
View

globalization/locale/sorting-and-string-comparison.md
:white_check_mark:Succeeded
View

globalization/locale/time-formatting-and-time-zones-in-dotnet-framework.md
:white_check_mark:Succeeded
View

globalization/locale/time-formatting-and-time-zones-in-win32.md
:white_check_mark:Succeeded
View

globalization/locale/units-of-measurement.md
:white_check_mark:Succeeded
View

globalization/localizability/avoid-run-time-composite-strings.md
:white_check_mark:Succeeded
View

globalization/localizability/do-not-compound-several-variables.md
:white_check_mark:Succeeded
View

globalization/localizability/dotnet-framework-string-format.md
:white_check_mark:Succeeded
View

globalization/localizability/element-resizing.md
:white_check_mark:Succeeded
View

globalization/localizability/isolate-localizable-resources.md
:white_check_mark:Succeeded
View

globalization/localizability/mirroring-in-dotnet-framework.md
:white_check_mark:Succeeded
View

globalization/localizability/mirroring-in-win32.md
:white_check_mark:Succeeded
View

globalization/localizability/win32-formatmessage.md
:white_check_mark:Succeeded
View

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

@v-kents do you know who owns this repo?

@mairaw I think the last time I asked around, it was Scott Li (CELA) (not sure if he's on Github, I'll email him separately).
However, I can merge this if you'd like. It all looks clean and more correct than before.

@v-kents this is a super straightforward PR so I think it should be ok to merge. But thanks for emailing the owner so they can start tracking PRs from time to time here. This doesn't seem like a busy repo.

@mairaw 'struth. Ownership has also bounced around a few times due to people leaving the company. Going out now, and thank you again.

@pallep - discussion about ownership of doc.microsoft.com/globalization, possibly of interest to you...


Long start time on bpf-next (6.4-rc3)

How to reproduce:
cd $GOPATH/src/github.com/cilium
git clone https://github.com/cilium/little-vm-helper
cd little-vm-helper && make && sudo make install && cd -
mkdir images/
IMAGE_DIR=./images ./little-vm-helper/scripts/pull_image.sh quay.io/lvh-images/kind:bpf-next-20230531.165437
lvh run --image ./images/kind_bpf-next.qcow2 --host-mount $GOPATH/src/github.com/cilium/ --daemonize -p 2222:22 --cpu=3 --mem=6G
ssh -p 2222 -o "StrictHostKeyChecking=no" root@localhost
cd /host/pwru
./pwru --filter-dst-ip=<IP_ADDRESS>
... takes ages until attach kprobes appear

strace.log

Ouch! :sweat_smile: Definitely a cilium/ebpf issue. Mind moving the issue?

I also confirm that github.com/cilium/ebpf/btf.Copy() consumes most of loading time.
It consumes 10m1.519248586s of 10m21.610184033s bpfSpec.LoadAndAssign() running time.
My running env is 6.2 kernel on Ubuntu 23.04 VM built from server ISO (#201 env info).
pwru.run.log

Whoa, nice finding!

Furthermore, I add a fmt log in github.com/cilium/ebpf/btf.Copy():
func Copy(typ Type, transform Transformer) Type {
	defer functrace.Trace()()
	fmt.Printf("Copy type: %s, %+v\n", typ.TypeName(), typ)
	copies := make(copier)
	copies.copy(&typ, transform)
	return typ
}

Here is the log file:  pwru.run.log.
Then, dump the copying structs info from vmlinux:  btf.vmlinux.structs.txt by bpftool btf dump file /sys/kernel/btf/vmlinux format raw | grep -E "'(iphdr|ipv6hdr|net|net_device|pt_regs|sk_buff|sock|tcphdr|udphdr)'" > btf.vmlinux.structs.txt.
Hopefully, it can help to solve this issue.

Fixed by #220.


serve: Decouple httprule handler from serve

Decouple httprule.Server from serve.Server to that alternate
implementations or just other `http.Handlers can be plugged into the
server.
This is done by simplifying the handling of unknown methods in the
server, using an unused parameter to the unknown handler to specify the
method name (making outside callers much simpler), exporting the
server's registry.Files field and abstracting the httprule.Server in
serve.Server as an http.Handler and making it pluggable.
This is a breaking change to outside users of the server, requiring them
to create the httprule server themselves and plug it in with:
s := serve.NewServer(...)
h := httprule.NewServer(s.Files, s.UnknownHandler)
s.SetHTTPHandler(h)

If the httprule server is not plugged in then the server will not serve
HTTP via the HttpRule annotations.

@juliaogris This is RFR please. It is most easily reviewed commit-by-commit rather than all at once.
@mightyguava RTYI

I should note that this change makes it possible to use serve.Server with cmux (https://github.com/soheilhy/cmux) if that's your thing - just don't set an http handler and pass the cmux sub-listener to serve.Server.Serve():
l, _ := net.Listen(tcp, listenAddr)
m := cmux.New(l)
s := serve.NewServer(...)
h := http.Server{Handler: httprule.NewServer(s.Files, s.UnknownHandler)}
grpcL := m.Match(cmux.HTTP2HeaderField("content-type", "application/grpc"))
httpL := m.Match(cmux.HTTP1Fast())
go s.Serve(grpcL)
go h.Serve(httpL)
m.Serve()


Bump pipeine-tools to v0.1.12

Related issue: https://github.com/rancher/rancher/issues/22057
Depend on https://github.com/rancher/pipeline-tools/pull/16 and the new pipeline-tools release.

LGTM