Traefik is not using consul tags properly.

Do you want to request a feature or report a bug?
Bug
What did you do?
I'm using docker container with Traefik:1.7.3-alpine in my stack with config:
defaultEntryPoints = ["https"]
[entryPoints]
    [entryPoints.https]
    address = ":443"
    [entryPoints.https.tls]
        ...
[consulCatalog]
    endpoint = "$NGINX_CONSUL"
    exposedByDefault = false
    watch=true
    [consulCatalog.tls]
        ...
        insecureSkipVerify = true
[api]
  entryPoint = "traefik"
  dashboard = true
  debug = true

And I've got some services registered to this consul.
So with these tags, the service is not showing in traefik:
dumbTag traefik.frontend.rule=Host: example.com.traefik traefik.protocol.https traefik.enable=true

When I move my dumbTag at the end, so it looks like here:
traefik.frontend.rule=Host: example.com.traefik traefik.protocol.https traefik.enable=true dumbTag

then it works fine
What did you expect to see?
Traefik should check all tags, despite their order.

Your tags have syntax errors (extra whitespace, missing =), try this:
dumbTag traefik.frontend.rule=Host:example.com.traefik traefik.protocol=https traefik.enable=true

Yup, my bad. Sry.
Anyway, strange that in one case (even with syntax errors) it was working...


Unable to recover from blankscreen/powersave on kirkstone-l4t-r32.7.x

Describe the bug
On the kirkstone-l4t-r32.7.x, after idle-time (default 300 sec) the system goes into power-saving mode, and we do not get the screen back by pressing the keyboard or by clicking or moving the mouse.
Kernel message:
[   21.260121] tegradc tegradc.0: blank - powerdown
[   21.325419] extcon-disp-state extcon:disp-state: cable 47 state 0 already set.
[   21.325421] Extcon AUX1(HDMI) disable
[   33.932101] vdd-fan: disabling
[   33.935566] vdd-usb-vbus: disabling
[   33.939260] vdd-usb-vbus2: disabling
[   33.942981] vddio-sdmmc3-ap: disabling
[   33.946928] avdd-io-edp-1v05: disabling
[   33.950864] vdd-usb-hub-en: disabling

For testing purposes, you can shorten the idle-time, by adding this parameter:
/etc/xdg/weston/weston.ini
[core]
idle-time=10

Under Dunfell, this problem does not exist, but there the system does not go into power-saving mode, only we have a blank screen.

On dunfell:
[ 1102.957007] tegradc tegradc.0: blank - normal

then it can wakeup:
[ 1606.315842] tegradc tegradc.0: unblank
[ 1606.349425] tegradc tegradc.0: sync windows ret = 242

This looks similar to something only I've been able to reproduce on Jetpack 5 so far in https://github.com/OE4T/meta-tegra/issues/1069

I tested it on tegra-demo-distro with the same result. I tried to run xset --display display:0 -q but the command was missing, then I added it, and told me no display was found.


Fetch fails when guest content set Host header.

When the guest content sets the Host header, it fails with the following error
 Error: Failed to clone headers

This is because' Host' is a forbidden header in the wasi-http spec. I believe that this was fixed a while back where the engine would remove the host header but it seems to have regressed now.

This may well have regressed in the recent headers work, but this should be a simple fix, I believe what is needed is to add a forbidden headers filter after obtaining the headers list here - https://github.com/bytecodealliance/StarlingMonkey/blob/main/builtins/web/fetch/headers.cpp#L451.
And it would also be good to add a test to avoid future regressions as well.

I am not entirely sure how the tests work in this repo but I think this is a test that already tracks it(?)
https://github.com/bytecodealliance/StarlingMonkey/blob/523d78deaac8a8106f641ca36cfd70cf85713fe7/tests/wpt-harness/expectations/fetch/api/basic/request-forbidden-headers.any.js.json#L35-L36

It may well do, although this has never passed for StarlingMonnkey so that doesn't line up the comment that this was a regression, but however we get coverage is of course fine.


subtract median phased light curve profile shape

This is a reminder to remove the median light curve profiles for the CQV sample, in order to analyze differential variability over the course of each TESS sector.
TIC224283342 S29 for instance stands out by this metric.

Addressed by aa96aff
Future added functionality should include:

smooth f(φ) model
PDM the residual
TLS the residual

For now, marking as resolved.


If job.tasks is empty, don't override command

 Issue by technosophos
2017-07-18 04:48:38

Right now, if Job.tasks is empty, this runs an empty shell script. Instead, it should not override the CMD in the Docker image.

Comment by technosophos
2017-08-18 23:53:21

This is fixed in the new acid-runner.


Modification of jetty annotation scanning

In the jetty-maven-plugin there is a property called webInfIncludeJarPattern that can be used to reduce the number of jars scanned for annotations on deployment.
The use case for this is a large farm with about 10 wars. The difference in startup time is around 45sec vs 5min.
I have started to do some digging into the source and from what I can tell the WebInfLibs are set in the JettyConfigurerImpl class, but I can't find a way to send parameters down there

Is this enough? I have created a trivial WAR containing a single elementary servlet and BouncyCastle 1.58, and then configured the Jetty Maven plugin like this:
<plugin>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-maven-plugin</artifactId>
    <version>${jetty.version}</version>
    <configuration>
        <war>${project.build.directory}/${project.build.finalName}</war>
        <systemProperties>
            <systemProperty>
                <name>org.eclipse.jetty.annotations.maxWait</name>
                <value>300</value>
            </systemProperty>
        </systemProperties>
        <webAppConfig>
            <contextPath>/</contextPath>
            <webInfIncludeJarPattern>^((?!bcp...-jdk15on).)*$</webInfIncludeJarPattern>
        </webAppConfig>
    </configuration>
</plugin>

This boots in milliseconds:
[INFO] jetty-9.4.7.v20170914
[INFO] Scanning elapsed time=57ms

However, the WAR takes over 2 minutes to boot when I use the exact same regexp with gretty:
gretty {
    httpPort = 8080
    contextPath = "/"
    servletContainer = 'jetty9.4'
    integrationTestTask = 'integrationTest'
    webInfIncludeJarPattern = '^((?!bcp...-jdk15on).)*$'
    jvmArgs = [
        "-Dorg.eclipse.jetty.annotations.maxWait=300"
    ]
}


[Feature] NetworkPolicy for Cluster and Pooler

It would be nice if there was a default NetworkPolicy for created clusters that only permitted inbound traffic on the expected ports maybe also restricting egress if there are rational limits.  https://cloudnative-pg.io/documentation/1.19/security/#exposed-ports
In theory it could have some "smart bits" that limit access to port 8000 to just and only the operator container(s) or a enable access to the metrics port if and only if the metrics service is started.
Ideally, I'd like to be able to instead provide my own NetworkPolicy if I want something more restrictive - such as "only this namespace can reach port 5432" or "only this container from this namespace can reach the metrics port".
Having the NetworkPolicy with the Cluster/Pooler definition feels like it helps centralize the operational knowledge of how the database(s) should be accessible.

hi @jcpunk
Creating a NetworkPolicy it's out of the scope of the operator, since every network can be managed differently and using a totally different policy or even custom policies, this must be managed and it's up to the Kubernetes cluster administrators, not CloudNativePG
Closing this since it's not in the operator scope.
Regards!

Is there a list of default port usage for help setting up the policy on the local end?

You can have a look here: https://cloudnative-pg.io/documentation/current/security/#network-policies.
Feel free to ping us if you need some clarification.


Changed navbar collapse size from lg to xl

Fixes #533
The logo doesn't shrink on bigger devices now.

Changed from "navbar-expand-lg" to "navbar-expand-xl" in nav class

Coverage remained the same at 82.582% when pulling 6cd8b18b49b2f85dd620595286871b6ff5a223d1 on lukyjuranek:nav-logo-fix into d5d514788ab8dd92b23ea5da0797b41e6d03d0d8 on CircuitVerse:master.

Can you add screenshot for before and after the change ?

It just makes the navbar collapse earlier
After:

Before:

Navigation menu need to collapsed on smaller screen, not on wider screen

It collapses on smaller devices now so the logo can fit next to the navbar.

We switched to new ui


Bad Grammar Cat Photo App 8

Describe the Issue
The last sentence here is bad grammar. Also. The period after the code block can look awkward on mobile.

HTML attributes are special words used inside the opening tag of an element to control the element's behavior. The src attribute in an img element specifies the image's URL (where the image is located). An example of an img element using an src attribute: .

Affected Page
https://www.freecodecamp.org/learn/2022/responsive-web-design/learn-html-by-building-a-cat-photo-app/step-8
Your code
N/A
Expected behavior
Rework sentence for better grammar and formatting.
Possible fix

HTML attributes are special words used inside the opening tag of an element to control the element's behavior. For example, the src attribute in an img element specifies the image's URL (where the image is located).

Screenshots
No response
System
All
Additional context
No response

Perhaps something like:
HTML attributes are special words used inside the opening tag of an element to control the element's behavior. The `src` attribute in an `img` element specifies the image's URL (where the image is located).

Here is an example of an `img` element with a `src` attribute pointing to the freeCodeCamp logo:

```html
<img src="https://cdn.freecodecamp.org/platform/universal/fcc_secondary.svg">
```

(unrelated but I strongly dislike the fact that github doesn't wrap codeblocks lol)

I like that fix better

Thanks for opening this issue.
This looks like something that can be fixed by "first-time" code contributors to this repository. Here are the files that you should be looking at to work on a fix:
List of files:

Cat Photo App - Step 8

Please make sure you read our guidelines for contributing, we prioritize contributors following the instructions in our guides. Join us in our chat room or our forum if you need help contributing; our moderators will guide you through this.
Sometimes we may get more than one pull request. We typically accept the most quality contribution followed by the one that is made first.
Happy contributing.

May I start working on this issue? This will be my first open source contribution, and it seems like I can fix it.

Heya @KunalSalunkhe12,
We typically do not assign issues. Instead, we accept the first pull request that comprehensively solves the issue.
Issues labelled with help wanted or first timers only are open for contributions.
Please make sure you read our guidelines for contributing. We prioritize contributors following the instructions in our guide. Join us in our chat room or the forum if you need help contributing - our community will be happy to assist you.

@naomi-lgbt
Thank you for the information. I have made sure to review the guidelines for contributing before submitting my pull request.


using batchmode and adding updated flag for Maven builds

I tried building locally and I did not get the compile problems you see on travis. So at least theoretically this should work
-B removes the log lines for KB download stuff
-U forces to check in upstream repo for artifacts
hth

sweet! much appreciated

When I look at the Travis log it's full of errors, but they're just ignored because of -fn
Or am I missing something?

Which log are you looking at specifically? And yes -fn ignores errors.

Also... you have to merge and try and see if it works.

Haha .. I just noticed you have branch build with travis and this branch passed.. and I did take out the repeated maven invocations. Let me check more in the log.

Looking at the travis log I still see compile problems. I do NOT get them locally.

You should see if you can manually run the SDK deployer locally and then an osmdroid build. That works for me.

I've been trying it a few times, and it seems to sometimes work and sometimes not.  I'm not sure what's different between the times it works and the times it doesn't.
But surely I shouldn't need to clean maven-android-sdk-deployer every time?
And shouldn't osmdroid work without -fn -B -U? Or at least without -fn?

Well.. thats what I am saying. It works without -fn for me just fine. Reproducibly..

the current travis file, clones the maven-sdk-deployer, then install -fn. Then builds osmdroid.
On my box, if i wipe out the .m2 repo, the problem is reproduced. Travis builds are essentially new VMs with every build and thus an empty local .m2 repo.

Let me try with a clean setup ..

Thank you for helping Manfred, I very much appreciate it :)
Please could you explain your thinking behind these changes that you made to .travis.yml:
For maven-android-sdk-deployer:
Why clean?  On the Travis server it's already a new box, and locally it takes forever.
Why -U?
For osmdroid:
Why -fn?  We want it to just pass without errors.
Why -U?  This causes it to get other osmdroid dependencies from Maven Central, whereas we should be building against our local version.
Sorry if I'm just not understanding Maven properly ;)

When I said "other osmdroid dependencies", I mean, for example, this:

[INFO] Downloading: https://oss.sonatype.org/content/repositories/snapshots/org/osmdroid/osmdroid-android/5.1-SNAPSHOT/osmdroid-android-5.1-20160117.193112-7.aar

clean is probably not necessary
-fn not either - it just causes it to keep running even if it fails
download from snapshots.. that looks like a bug in your project setup.

yup still an issue.
https://travis-ci.org/osmdroid/osmdroid/builds/103978076 this is without -fn

Hx'm x
On Jan 22, 2016 2:15 AM, "spyhunter99"<EMAIL_ADDRESS>wrote:

yup still an issue.
https://travis-ci.org/osmdroid/osmdroid/builds/103978076 this is without
-fn
—
Reply to this email directly or view it on GitHub
https://github.com/osmdroid/osmdroid/pull/247#issuecomment-173768598.


Remove work-around for setuptools 'attr:'.

The setuptools 'attr' can now load attributes defined at the
module top-level without loading the module itself (since 46.4).
As such, we no longer need the separate '_version.py' file, and
instead require an up-to-date setuptools.

Codecov Report

Merging #93 into dev will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              dev      #93      +/-   ##
==========================================
- Coverage   99.05%   99.05%   -0.01%
==========================================
  Files          11       10       -1
  Lines        1063     1061       -2
==========================================
- Hits         1053     1051       -2
  Misses         10       10

Impacted Files
Coverage Δ

tbmodels/__init__.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Fix schema.fieldsMatch

fixes #965
bootstraps new version releasing approach

Hi @peterdesmet, can you please take a look?

Thanks! I agree @peterdesmet
BTW @sapetti9 can you please ask OKFN to give me (gmail email) access to the datapackage pages project on Cloudflare so I can update the deployment approach (currently, we can only release from main).


fix: absolute __file paths leaking into production bundle

Description
vite recently changed the signature for resolveConfig() to take a 4th argument defaultNodeEnv, which by default is set to development.
Since this argument is not added when resolveConfig is called in vite-ssg, it causes NODE_ENV to get set to development.
n turn, this triggers vite-plugin-vue to consider this a development build, inserting absolute file paths into the bundle.
This PR adds the correct defaultNodeEnv so NODE_ENV is correctly set to production during a production build.
(Note: vite does the exact same when calling vite build)
Linked Issues
#354 #349

@antfu thank you for all the work you do for the Vue community!


Sloth Merchant URL is wrong

https://sloth.ucdavis.edu/harvest/Transactions/Details/674e1c1b-4587-4173-86b6-57dbc6d6b9e5

Just a config setting


fixed sorting userlist in admin window #909

Improved filter implementation

There seems to be some problem in the tests, I'm currently working on it.


Set security context to v2v

The v2v container needs security context in order to run in restricted namespaces.
Fixes #173

You are not setting SeccompProfile (can be set in Pod.SecurityContext) and you should also define the context for the init container with VDDK.

Please refer to https://github.com/kubev2v/forklift/pull/211

You are not setting SeccompProfile (can be set in Pod.SecurityContext) and you should also define the context for the init container with VDDK.

Please refer to #211 for the SeccompProfile.

I wonder why I didn't have this issue.

are you sure it's needed for the init container? it does pass the vsphere ci on restricted namespace.

Yes. If you look at the error provided in #173 it mentions both containers: pod or containers "vddk-side-car", "virt-v2v" must set...


spike: OCA

Reference:

https://oca.colossi.network/
https://hackmd.io/YKAPlPxxQ1S5gzV9YrSVsA?view

We are going with OCA, we will plan its implementation as needed to satisfy user stories


work on grid for samplePoints with explicit coordinate arrays

eg:
sample=grid.samplePoint(x=5, y=3)

adds get_index, get_axes_names and possibility of specifying sample points with explicit coordinate vectors, also adds column-stack on quantities.

I changed the default method for the samplePoints, since interpolation only works for 3D atm, and nearest is probably fastest


feat: convert themes to flavors

Resolves https://github.com/catppuccin/yazi/issues/1 - sorry, didn't wait for responses, @uncenter said I could create a draft PR for this first.

This PR converts the previous Yazi theme to the Yazi flavor format - a feature introduced in Yazi v0.2.4, it's designed to replace the existing themes, making them easier to update and with the same directory structure as Yazi's plugins.
This also solves the issue of users wanting to install multiple color schemes.
Flavor documentation: https://yazi-rs.github.io/docs/flavors/overview
TODO

[ ] Fix justfile & yazi.hbs

If this is acceptable, I will complete the remaining fixes. Let me know your thoughts, @sgoudham
By the way, if possible, please let me become a maintainer of this repository. I am willing to take on these additional works and collaborate with @uncenter to maintain them.

Thanks for moving this PR over here. I just thought we should try to avoid having multiple discussions/issues/PRs across different repos, and simply have everything in one place. Having this PR here does not mean that we are intending to move forward with this plan though, FYI.

Hmm I'm not sure this is the ideal format for flavors - mandating that flavors have to have preview images, READMEs, very specific file names, etc (https://yazi-rs.github.io/docs/flavors/overview/). This PR means this repository would have eight license files and five READMEs. This also doesn't solve the issue of duplicate tmtheme files, and the preview images should be in WebP instead of PNG.

mandating that flavors have to have preview images, READMEs, very specific file names, etc (https://yazi-rs.github.io/docs/flavors/overview/).

Each flavor is designed as a package that can be used and updated independently. It's necessary to provide separate READMEs and screenshots for them. I'm not sure where these files should be stored if not like this PR's structure:
~/.config/yazi/flavors/
├── catppuccin-frappe.yazi/
│   ├── flavor.toml
│   ├── tmtheme.xml
│   ├── README.md
│   ├── screenshot.png
│   ├── LICENSE
│   └── LICENSE-tmtheme
├── catppuccin-mocha.yazi/
│   ├── flavor.toml
│   ├── tmtheme.xml
│   ├── README.md
│   ├── screenshot.png
│   ├── LICENSE
│   └── LICENSE-tmtheme

This PR means this repository would have eight license files and five READMEs.

If we want to avoid duplicating README and LICENSE files, the only solution I can think of is to move them out of the flavor packages to the parent directory, resulting in the following structure:
~/.config/yazi/flavors/
├── catppuccin-frappe.yazi/
│   ├── flavor.toml
│   ├── tmtheme.xml
│   └── screenshot.png
├── catppuccin-mocha.yazi/
│   ├── flavor.toml
│   ├── tmtheme.xml
│   └── screenshot.png
├── README.md
├── LICENSE
└── LICENSE-tmtheme

The README and LICENSE for catppuccin appear in the ~/.config/yazi/flavors/ directory, which is strange as this directory should not contain anything that is not a flavor.
Also if a user only installs catppuccin-frappe.yazi without copying all those files, they won't have the README and LICENSE files, which means they'll lose the introduction and licensing information. And README, especially LICENSE, should not change so frequently, I don't see any harm in simply repeating them.

This also doesn't solve the issue of duplicate tmtheme files

About the duplicate tmtheme files, I understand that this will add more work, the solution is for me to maintain and take on this extra work myself - I have stated in this PR that I am willing to become the maintainer of this repo and maintain it.

and the preview images should be in WebP instead of PNG.

As for using PNG instead of WebP, this is also for the convenience of flavor users/creators. All the screenshot software I have installed (CleanShot X/Shottr) does not support outputting in WebP format. When someone wants to create a flavor for Yazi, they would have to figure out a way (perhaps through online tools or specialized software to convert image formats), this is an additional step.
AFAIK, some desktop environments/file managers also do not support WebP. For example, Thunar cannot preview it, but it does support PNG (I know there are definitely ways to support it by installing software, but this is just inconvenient IMO):

And even GitHub does not support it (I know you can write a user script to replace it with an img tag, also inconvenient):

PNG is a very old and mature format, and I haven't heard of any desktop environments that don't support it. I don't want to waste time chasing after new formats like AVIF and JPEG XL, which offer better compression ratios than WebP.

mandating that flavors have to have preview images, READMEs, very specific file names, etc (yazi-rs.github.io/docs/flavors/overview).

Each flavor is designed as a package that can be used and updated independently. It's necessary to provide separate READMEs and screenshots for them. I'm not sure where these files should be stored if not like this PR's structure:
~/.config/yazi/flavors/
├── catppuccin-frappe.yazi/
│   ├── flavor.toml
│   ├── tmtheme.xml
│   ├── README.md
│   ├── screenshot.png
│   ├── LICENSE
│   └── LICENSE-tmtheme
├── catppuccin-mocha.yazi/
│   ├── flavor.toml
│   ├── tmtheme.xml
│   ├── README.md
│   ├── screenshot.png
│   ├── LICENSE
│   └── LICENSE-tmtheme

This PR means this repository would have eight license files and five READMEs.

If we want to avoid duplicating README and LICENSE files, the only solution I can think of is to move them out of the flavor packages to the parent directory, resulting in the following structure:
~/.config/yazi/flavors/
├── catppuccin-frappe.yazi/
│   ├── flavor.toml
│   ├── tmtheme.xml
│   └── screenshot.png
├── catppuccin-mocha.yazi/
│   ├── flavor.toml
│   ├── tmtheme.xml
│   └── screenshot.png
├── README.md
├── LICENSE
└── LICENSE-tmtheme

The README and LICENSE for catppuccin appear in the ~/.config/yazi/flavors/ directory, which is strange as this directory should not contain anything that is not a flavor.
Also if a user only installs catppuccin-frappe.yazi without copying all those files, they won't have the README and LICENSE files, which means they'll lose the introduction and licensing information. And README, especially LICENSE, should not change so frequently, I don't see any harm in simply repeating them.

A lot of this boils down to: I don't understand why your flavor specification mandates the locations, filenames, and general existence of files unrelated to the core operation as they relate to Yazi. Why does Yazi care as a program where a license or a README file is located? That shouldn't be in the specification in my opinion, its totally opinionated.

This also doesn't solve the issue of duplicate tmtheme files

About the duplicate tmtheme files, I understand that this will add more work, the solution is for me to maintain and take on this extra work myself - I have stated in this PR that I am willing to become the maintainer of this repo and maintain it.

It isn't about the amount of "work". It has been previously stated before that the tmtheme files aren't often updated over at catppuccin/bat anyways, but it is more about the principle of duplication and disorganization that we are trying to not break. Having users go download a separate file is not unheard of and isn't really much of a hassle.

and the preview images should be in WebP instead of PNG.

As for using PNG instead of WebP, this is also for the convenience of flavor users/creators. All the screenshot software I have installed (CleanShot X/Shottr) does not support outputting in WebP format. When someone wants to create a flavor for Yazi, they would have to figure out a way (perhaps through online tools or specialized software to convert image formats), this is an additional step.

Again, this boils down to: why is the flavor spec mandating this? It is literally nothing to do with Yazi lol. Catppuccin prefers to use WebP and I'm not sure why we can't. The only time a user will ever look at a preview image is in the README, before deciding if they want to use it.

AFAIK, some desktop environments/file managers also do not support WebP. For example, Thunar cannot preview it, but it does support PNG (I know there are definitely ways to support it by installing software, but this is just inconvenient IMO):

I'm not sure in what scenario a user would need to or want to have the preview images on their machines?

And even GitHub does not support it (I know you can write a user script to replace it with an img tag, also inconvenient):

GitHub displays WebP just fine in READMEs, which is the only place they are actually needed/used.

PNG is a very old and mature format, and I haven't heard of any desktop environments that don't support it. I don't want to waste time chasing after new formats like AVIF and JPEG XL, which offer better compression ratios than WebP.

Exactly. It isn't your job to police what image formats or file names people use for flavors ahah.

A lot of this boils down to: I don't understand why your flavor specification mandates the locations, filenames, and general existence of files unrelated to the core operation as they relate to Yazi. Why does Yazi care as a program where a license or a README file is located? That shouldn't be in the specification in my opinion, its totally opinionated.
Again, this boils down to: why is the flavor spec mandating this? It is literally nothing to do with Yazi lol. Catppuccin prefers to use WebP and I'm not sure why we can't. The only time a user will ever look at a preview image is in the README, before deciding if they want to use it.

I think the reason is simple, because it is what users need, and Yazi has always prioritized user experience as its primary goal.
As I mentioned above, each flavor is a separate package, so it needs its own README.md, screenshot.png, LICENSE, and LICENSE-tmtheme files:

README.md: I'm not sure how users would know how to install and use it without a README, and it is also a best practice.
screenshot.png: Users want to know what the flavor looks like, so it is necessary to provide a screenshot. If you don't, users will request you to add it, see https://github.com/yazi-rs/flavors/issues/2 and https://github.com/yazi-rs/flavors/issues/4.
LICENSE, LICENSE-tmtheme: Yazi values copyright, because flavors contain the necessary tmtheme.xml files, so adding the corresponding original author's LICENSE-tmtheme is a basic respect for their minimum labor achievements; similarly, if someone creates a flavor, including the author's LICENSE, it is also the most basic respect. If these files are missing in the flavor, such as moving these files to the parent directory to avoid duplication, it is a bug in the entire flavor specification that we need to try our best to avoid.

They need to be added eventually, so why not specify them in a unified and standardized way? This kind of determinism, such as the description file being called README.md, not README.txt, readme.md, ReadMe, etc., not only benefits users but also benefits Yazi maintainers (me). Such as the Yazi theme manager planned in the future, by using deterministic README.md, its content can be directly displayed without relying on constantly guessing different names, which is something I have been continuously advocating for to make future automation possible.
This is still the issue of convenience and automation that I keep mentioning. If catppuccin can't accept files containing tmtheme, I will close this PR because it no longer makes sense.

I'm not sure in what scenario a user would need to or want to have the preview images on their machines?
GitHub displays WebP just fine in READMEs, which is the only place they are actually needed/used.
Exactly. It isn't your job to police what image formats or file names people use for flavors ahah.

When users download and install multiple flavors and want to switch between them, what should they do? Is it to require them to constantly modify Yazi's configuration and then restart Yazi to see the effect?
Yazi's goal is to provide a consistent user experience for all users, and PNG is the way to achieve it - it seems that there are no devices that do not support PNG but support webp.

As a user of yazi

Yazi values copyright, because flavors contain the necessary tmtheme.xml files, so adding the corresponding original author's LICENSE-tmtheme is a basic respect for their minimum labor achievements

Imagine any standard user of yazi who doesn't care much about Licensing, they want it to be as easy as possible: If there isn't an up to date port, but they still find the yazi theme toml file and a tmTheme, then they have to make blank or copy-pasted placeholder files for the other required files -- again making the user jump through hoops for a theme. @sxyazi I understand your principals on respecting copyright, and I appreciate the sentiment, but I can't see it being enforced in any meaningful way here.
Really it's the job of lawyers, and the due diligence of theme maintainers, to make sure copyright isn't infringed, it shouldn't be yazi's responsibility if the themes are not developed by yazi. Having the flavor system be very opinionated on this, causes more friction for all maintainers of themes and all users of yazi, even in the event that all maintainers and users are already respecting copyright and licensing.
I partially understand your other points for why you want a theme to contain the files you outlined, but I must agree with @uncenter on:

why is the flavor spec mandating this? It is literally nothing to do with Yazi

It is up to the creators and maintainers of a theme to market and present their theme so that users want to use it, if they provide no screenshots or description then that's on them.

The only case in which I see this new flavor feature being useful, is if you are legitimately planning to implement a dashboard on yazi's website that users can search through with previews and details of themes (even in this scenario it isn't yazi's responsibility to enforce the flavor's license requirements, Microsoft's VS Code doesn't even require this).
But other than that I don't see a reason why yazi should require anything more than a toml with an optional tmTheme, especially since anyone can just circumvent the other required files by making garbage or empty files. Even if you were going to make a dashboard, you can opt to exclude any repo that doesn't have a screenshot, readme or license -- outright requiring these files to exist for a theme to even work on my own machine is still overreaching and too opinionated I think.

Reply to the part about Yazi

Imagine any standard user of yazi who doesn't care much about Licensing, they want it to be as easy as possible: If there isn't an up to date port, but they still find the yazi theme toml file and a tmTheme, then they have to make blank or copy-pasted placeholder files for the other required files

Are you referring to the old theme.toml? If so, theme.toml and flavor.toml are not designed to be simply swapped out.
The license is provided by the flavor author; it's their work. The design of flavors aims to prevent users from modifying them (which would cause update conflicts), so users shouldn't manually add a license.
If the flavor author uses the official flavor template (which is what we encourage), it already includes a blank license file and instructs in the README to replace it with their own. The situation you mentioned would only occur if the flavor author manually deletes it or doesn't use the official template.

Really it's the job of lawyers, and the due diligence of theme maintainers, to make sure copyright isn't infringed, if the themes are not developed by yazi then it shouldn't be yazi's responsibility. Having the flavor system be very opinionated on this, causes more friction for all maintainers of themes and all users of yazi, even in the event that all maintainers and users are already respecting copyright and licensing.

I've never thought that being opinionated is a bad thing. In fact, Yazi is full of opinions. It was originally developed to meet my personal needs and designed around my workflow (I was looking for an alternative to ranger/joshuto at the time), and I'm glad to see that many people also like it.
The debate about copyrights has never stopped, I'm not a lawyer, but this is my choice and stance because I truly haven't seen the harm and trouble adding a license would bring. It only brings benefits and makes the flavor a more robust project, which benefits the flavor author as well. They don't have to worry about whether they should/can include a license, what filename to use, etc. All of this is based on convention and best practices from experience.

It is up to the creators and maintainers of a theme to market and present their theme so that users want to use it, if they provide no screenshots or description then that's on them.

The reality is, it's difficult for flavor authors to promote their flavors, especially for niche software like Yazi, which has a limited audience. As a maintainer, I try my best to help promote them, including creating a separate resource page and a flavors repository, linking them in GitHub issues/discussions, and posting them in Yazi's Discord group.

The only case in which I see this new flavor feature being useful, is if you are legitimately planning to implement a dashboard on yazi's website that users can search through with previews and details of themes (even in this scenario it isn't yazi's responsibility to enforce the flavor's license requirements, Microsoft's VS Code doesn't even require this).

This seems to be what's currently being done at https://github.com/yazi-rs/flavors, flavor authors can create a PR to add their flavors to this repository, and I'll also add them when I discover new flavors, and it includes links and screenshots for each flavor, I can't imagine what it would be like without images; as I mentioned earlier, users will request you to add images.
I don't think comparing Yazi to VS Code is reasonable. The user base and plugins/flavors for Yazi are different, which limits the number of plugins/flavors. This allows me to directly submit a PR when I discover errors or areas for improvement - I've already contributed to many of them. My point is, we will ultimately lean towards being a small, exquisite, and close-knit community rather than a large, comprehensive one. Therefore, I don't think adding images is a big issue. If the flavor author forgets to add it, I or someone can even submit a PR for it directly. Of course, all of this is done with the author's approval; they have 100% right to reject the PR because it's their own repository.

But other than that I don't see a reason why yazi should require anything more than a toml with an optional tmTheme, especially since anyone can just circumvent the other required files by making garbage or empty files. Even if you were going to make a dashboard, you can opt to exclude any repo that doesn't have a screenshot, readme or license -- outright requiring these files to exist for a theme to even work on my own machine is still overreaching and too opinionated I think.

If you are using the new flavor, tmTheme is required, for reasons at https://github.com/catppuccin/catppuccin/issues/2278#issuecomment-1959010956 and https://github.com/catppuccin/catppuccin/issues/2278#issuecomment-1959916406.

The license is provided by the flavor author; it's their work. The design of flavors aims to prevent users from modifying them (which would cause update conflicts), so users shouldn't manually add a license.

The design is a good design I believe, but if someone wants to make their own theme without ever publishing it, then I can't imagine them creating any meaningful readme, license or screenshot -- it's trivial to do, but it's pointless clutter for them. The same might happen for when their favourite theme doesn't haven't a port on yazi, they want to port it, but for their own personal reasons don't want to publish the yazi port.

The debate about copyrights has never stopped, I'm not a lawyer, but this is my choice and stance because I truly haven't seen the harm and trouble adding a license would bring. It only brings benefits and makes the flavor a more robust project, which benefits the flavor author as well. They don't have to worry about whether they should/can include a license, what filename to use, etc. All of this is based on convention and best practices from experience.

This is a good argument for how the flavor spec is beneficial, especially for people making a theme from scratch on yazi. My point of view is coming more from the perspective of well established themes, take https://github.com/EdenEast/nightfox.nvim for example: They currently have 7 palettes and their workflow for making ports revolves around having a single template file (list of their templates here) that generates the theme for each port and all palettes. I'm sure they're not the only theme maintainers with a workflow like this.
For creating a theme from scratch, the flavor template is very good, for established themes like nightfox it now requires a complete refactor on how they generate ports if they want to officially support a yazi theme based on your flavor spec.
So my main concern is that enforcing this flavor spec may result in less ports being published for yazi, but it seems yazi still work with a flavor that only has a flavor.toml and tmTheme.xml file in its directory, if it remains that way I don't see any problem. And I want to clarify that I like yazi having a flavor template with established file names and best practices, you have made a good design for this. I just wouldn't like for 'best practices' to become 'required practices', because it may be the best for some people but a burden for others (especially for a theme like nightfox).

but if someone wants to make their own theme without ever publishing it, then I can't imagine them creating any meaningful readme, license or screenshot

If a user wants to create a theme for their own use, they should use theme.toml instead of flavor.toml, as described in the flavor specification:

The "flavor" is a pre-made Yazi theme, while what we typically refer to as a "theme" is the user's own theme, i.e. ~/.config/yazi/theme.toml file.

The purpose of flavor is to provide convenience for others to use. I'm not sure why one would use the flavor format if they just want to use it for themselves.

They currently have 7 palettes and their workflow for making ports revolves around having a single template file (list of their templates here) that generates the theme for each port and all palettes

I think Yazi relies on both flavor.toml and tmtheme.xml already breaking this, which means it can't be provided as a single file but must be a directory (package). I haven't used nightfox, but if nightfox accepts adding additional tmtheme.xml files, I don't think adding a license would be a problem either.
If nightfox considers this a burden, they can refuse to provide a flavor for Yazi and allow for some community integration, as long as their color scheme is public. There are already some examples of this in https://github.com/yazi-rs/flavors, such as onedark and tokyo-night maintained by community users. We could even maintain it as an official flavor if there is a demand for nightfox but no one is making it.
The same applies to Catppuccin, if Catppuccin cannot accept additional tmtheme and license files and sees this as a burden, I can completely understand. I just hope to see Yazi's flavor come in Catppuccin, as this would be beneficial for both Catppuccin and Yazi users.

If a user wants to create a theme for their own use, they should use theme.toml instead of flavor.toml, as described in the flavor specification

The purpose of flavor is to provide convenience for others to use. I'm not sure why one would use the flavor format if they just want to use it for themselves.

Oh! I keep forgetting that theme.toml isn't deprecated, so since that is staying as a feature for yazi then most of my concerns are resolved.

I think Yazi relies on both flavor.toml and tmtheme.xml already breaking this, which means it can't be provided as a single file but must be a directory (package). I haven't used nightfox, but if nightfox accepts adding additional tmtheme.xml files, I don't think adding a license would be a problem either.

That's true. So I'm not suggesting a change to the flavor spec, I think the new flavor approach is better and more convenient for users given that flavor.toml and tmTheme.xml must be provided, it reduces the need for users to hunt for both files individually, makes sense that the files are together for a yazi theme.

While the flavor spec is opinionated, there is still the free choice to support the original theme.toml implementation, so I don't think there is any problem here.
What I am imagining in the future is a community maintained dashboard such as https://vimcolorschemes.com/, which is how I discovered catppuccin and nightfox originally. There may be many users in the future that get introduced to various themes by exploring themes for yazi, and the new flavor spec enables a consistent and predictable way for themes to be presented through dashboards, centralised repos, or in chat rooms like discord. So users can browse and preview themes quickly, and theme maintainers are given a platform to present their theme, seems like a win-win.
Because of these reasons I think catppuccin accepting this PR would be a good idea.

OK, I'll finish up the remaining work on this PR in the next few days, then see if @sgoudham is interested in merging it, or just closing it, either is fine to me

Looks like the discussion may have stalled since the last post was 3 weeks ago. I spent an hour reading through this discussion, trying to identify what the pain points are. Here are the things that I gathered, and my suggestions for solutions:
Problem 1: no agreement on the format of preview images (webp vs. png)
I don't have a stance on which is better, but here is how this could be resolved:

store the previews as one format in this repository, and convert to the other format in a build step. I think something like convert image.webp image.png (imagemagick) might suffice. This can be done in this repository, or in the future yazi theme site that @sxyazi mentioned there are plans for.
or, have continuous integration do the conversion

Problem 2: many copies of license and readme files
I cloned this PR and it looks like the license and readme files are almost exact copies with minor changes. It seems that this can easily be solved by automation:

copy the licenses over when building
create the flavor readme files from a template
the future yazi theme site could also do this
or, just make the theme site reject any invalid flavors and some improvements can be made at that point when things are clearer
or, the theme site can simply fall back to a top level readme as per some specification
or, store the license files as symlinks in the repository

Let me know if I have missed some issues. As a user of yazi, I'm looking for a way to have my yazi plugins and themes (want to eventually use flavors) be tracked via git and some plugin manager so that I can pull in new features and fixes for them.
I can also provide this as a PR to address today's problems, and then the design can be improved on in the future.

Looks like the discussion may have stalled since the last post was 3 weeks ago. I spent an hour reading through this discussion, trying to identify what the pain points are. Here are the things that I gathered, and my suggestions for solutions:
Problem 1: no agreement on the format of preview images (webp vs. png)
I don't have a stance on which is better, but here is how this could be resolved:

store the previews as one format in this repository, and convert to the other format in a build step. I think something like convert image.webp image.png (imagemagick) might suffice. This can be done in this repository, or in the future yazi theme site that @sxyazi mentioned there are plans for.
or, have continuous integration do the conversion

Problem 2: many copies of license and readme files
I cloned this PR and it looks like the license and readme files are almost exact copies with minor changes. It seems that this can easily be solved by automation:

copy the licenses over when building
create the flavor readme files from a template
the future yazi theme site could also do this
or, just make the theme site reject any invalid flavors and some improvements can be made at that point when things are clearer
or, the theme site can simply fall back to a top level readme as per some specification
or, store the license files as symlinks in the repository

Let me know if I have missed some issues. As a user of yazi, I'm looking for a way to have my yazi plugins and themes (want to eventually use flavors) be tracked via git and some plugin manager so that I can pull in new features and fixes for them.
I can also provide this as a PR to address today's problems, and then the design can be improved on in the future.

I guess if I had to summarize the discussion, it is less so about the implementation details here and feasibility of the changes and moreso about the implementation of Yazi's flavor spec itself. As someone who has worked with Yazi since October of last year, created the schema files for the configuration spec, contributed heavily to the documentation, etc. I have some major issues with the flavor spec as is. Notably, as I've already said, I don't see why Yazi needs to mandate the filenames and presence of files not directly related to Yazi. I understand if the spec requires the tmtheme and the theme.toml files with certain names, but the rest - no. I think the best course of action is for me to open an RFC issue on the Yazi repository to move further discussion over there.

Ah I completely forgot about this PR - I'll finish the rest of this PR now

As there are no plans to improve the flavor spec, I don't think proceeding with this makes sense.

@uncenter would you accept a PR for the "minimal" spec you proposed?
It would allow me to proceed with my own config changes, would break no existing functionality, and could be improved on later in case agreement on the flavor spec can be reached.

for the "minimal" spec you proposed?

Uhhh sure... not sure how that solves your issue though. It wouldn't be a valid "flavor" (-_-) and it wouldn't work as a theme file.

in case agreement on the flavor spec can be reached.

My issue was closed without the slightest indication of any possibility of the spec changing. No discussion even! Not looking too good on that front. All my suggestions have been repeatedly rejected - removing those requirements, allowing a configuration option for a path to a theme file (remote and local), etc.

My issue was closed without the slightest indication of any possibility of the spec changing. No discussion even!

This is because I don't see the point of that issue - everything described in that issue is a repetition of the comments on this PR, and I've already provided explanations for them (GitHub/Discord). I really don't want to spend time discussing them all over again.
Of course, if there's any new content that hasn't been discussed before, feel free to file a new issue!


Axis associated with Logarithmic scale not rendering ticks

Using PowScale in this chart works fine:
https://codesandbox.io/s/chart-parts-example-6-seicb
Here's the same chart with LogScale:
https://codesandbox.io/s/chart-parts-example-6-58pbc

It looks like this has to do with zero being an invalid domain value for Logarithmic charts
see (https://github.com/d3/d3-scale#log-scales)
When using a small value instead of zero:


How to duplicate a module's parameters similar to semantics of deepcopy a PyTorch module?

In reinforcement learning, target network is a common technique to assist off-policy value learning. In PyTorch-based implementations, target_q_network = deepcopy(q_network) could create a target network with initial parameter identical to the value network. But I found it not easy to achieve in haiku. This is different from ways in the parameter sharing document, as the parameters are separately updated after initialization. Several ways I could think of

Create two separate modules, then manually edit the parameter dict after init (seems not elegant and error-prone to me. I wish to achieve this inside the init transform)
deepcopy(q_network) leads to only one set of parameters (as expected in haiku)
Somehow use a custom parameter initializer or custom_creator? Not sure how to achieve this.

Hi @jjyyxx , in JAX all tensors (including parameters) are immutable. This means you don't need to deepcopy to clone their value, you can just make multiple references to them:
def q_network(..):
  # .. use some haiku modules ..

q_network = hk.transform(q_network)

# Create our initial model params.
params = q_network.init(rng, ..)

# Because tensors in JAX are are immutable, we don't need to make a copy
# of the model params for the target network, we can just reference the same
# tensors.
target_params = params

while training:
  # params will be a new set of parameters. This will not update `target_network`.
  params = train_step(params, ..)

  if update_target_params:
    # Again, because tensors are immutable we don't need to make a copy.
    target_params = params

Thanks for your clarification @tomhennigan
I understand the immutable nature of Jax tensors. But what I would like to achieve is "duplicate nested modules" for a parent module.
class A(hk.Module):
  def __init__():
    self.q = Q(name='q')
    self.target_q = ?  # Q(name='target_q')

My current way is to edit the param dict similar to your approach params['A/~/target_q'] = params['A/~/q'], but I found editing it outside the transform is error-prone. You are right that creating networks and transforming separately avoids such problems, but I wonder if there's any better solution for the usecase mentioned above?

Personally I would advise you to consider alternative approaches. I think doing this inside transform will overall be more error prone than doing it outside.
You might find this example of DQN useful from rlax (which uses Haiku), as you can see their approach is having a single network definition (self._network) and two copies of the parameters (online_params, target_params):
https://github.com/deepmind/rlax/blob/master/examples/simple_dqn.py
--
If you do decide that doing this inside transform is overall the right approach for you, then there are two things to be aware of:

Lazy creation - Unlike PyTorch, in Haiku it is typical to create parameters when a module is used rather than in __init__. As such you need to call the module you want to clone before you clone it.
Name based reuse - In Haiku parameter reuse is based on module naming. To achieve a "copy of the initial parameter values" between a pair of equivalent modules it is not sufficient to deepcopy it (since you would just deepcopy the module name). Instead you need to intercept Haiku's state management (e.g. get_parameter) and point it somewhere else. The utility for this (during init) is custom_creator.

I think this Colab shows how you might tie the initial value of two haiku modules together:
https://colab.research.google.com/gist/tomhennigan/b3b5a7fcde988e5a95015fe10cbf3a4d/example-of-tying-initial-parameter-values-between-modules.ipynb

Thanks for your detailed explanation and helpful suggestion!
I rethought the way to create and organize multiple networks and decided to transform them separately as you suggested before. This might need a bit more boilerplate but avoids further difficulties of calling different networks. I guess the current solution will work smoothly, at least before some form of parameter sharing is needed.
Nevertheless, thanks for your excellent answer gist. I was thinking of using custom_creator, but my lack of deep understanding of haiku prevents me from implementing it.


Implemented auto-layout when importing the PG. Will find an available…

… spot on a canvas which doesn't overlap with other components and is as close to the canvas center as possible.
Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[ ] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[ ] Has your PR been rebased against the latest commit within the target branch (typically master)?

[ ] Is your initial contribution a single, squashed commit?

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

Merged to my fork.


Seems to have problems with scoped packages

This currently crashes when dep tree includes scoped packages
Error: Cannot find module<EMAIL_ADDRESS>Require stack:
- /.../node_modules/license-checker-webpack-plugin/src/licenseUtils.js
- /.../node_modules/license-checker-webpack-plugin/src/index.js
- /.../engine-frontend/webpack.config.js

It's trying to find a package.json under the "Scope" part of scoped packages (which would never exist)

oh whoops nvm this seems to be a duplicate of https://github.com/microsoft/license-checker-webpack-plugin/pull/37/files

For a workaround see https://github.com/microsoft/license-checker-webpack-plugin/pull/37#issuecomment-1006780673.


Accuracy circle layer

https://github.com/mapbox/mapbox-gl-native/pull/9426 looks to add support for circle pitch alignment in runtime styling thus unlocking the ability to simplify the logic for the accuracy ring and animate it.
We are currently using a fill layer since it lays flat even when the maps tilted but with this property unlocked it should become a circle layer. Technically all the layer really could become a circle layer but for the customizability available as far as using drawable for the location icon, I'm thinking they should remain symbol layers.
cc: @tobrun @zugaldia

On second look, this doesn't seem to be in 5.1.2. Any chance we could pull in that PR into the 5.1 release branch so that we can use it here @tobrun?

circle pitch alignment should be available in a 5.2.0-SNAPSHOT, no plans of adding new features to patch releases.

User report on this in https://github.com/mapbox/mapbox-plugins-android/issues/85


update the linking style for Sophus package

"Legacy style CMake variables such as Sophus_INCLUDE_DIRS are not defined by the Sophus package config anymore, since Dec 13, 2017."
You need to link the target against the Sophus::Sophus.

感谢指出，已合入。


Export CMake config

When trying to use this library from another CMake project, I've noticed that this project does not export CMake config.
I know that this library is meant to be vendored/bundled with my project, but in my case, this is quite undesirable.
So I've created a patch to export the config here: https://github.com/aljazerzen/arrow-nanoarrow-nix/blob/main/0001-patch.patch
I'm relatively new to CMake, so this issue is mostly about "i this a good idea" and "why not?"

Yes, exporting a nanoarrowConfig.cmake is the 'modern CMake' way to make you lib usable by other projects. I can have a look at the patch/turn it into a pr (feel free to that as well @aljazerzen!) but I'll have to read up on the details a bit. As a victim of bad configs I want to make it right :D (e.g. always including targets is bad when using fetchContent because the targets then already exist and clash).

I can open the PR, I thought there was a reason this was not done in the first place.


is rechoir used anywhere?

https://github.com/shelljs/shelljs/blob/master/package.json#L54
Is the dependencies rechoir used somewhere?  A grep didn't find it in any code.
$ find . -name "*.j*" | xargs grep rechoir
./package.json:    "rechoir": "^0.6.2"

Hi @jchip, rechoir is used in bin/shjs.

yeah, just found it. :)  thanks.  would be nice if I could get the shelljs module w/o the command line program though.

@jchip I agree (see #500). We should probably get on that before the v0.8 release so we can deprecate the binary within the main package.


cuda-binaries-native: update licence location and md5sum

Seems to only fail from a clean build, and is passed over when populated from sstate which makes it easy to miss.

actually, scratch this; it seems the license moves about or isn't available all the time. I'll keep investigating.

For reference.
10:23:47 NOTE: recipe cuda-binaries-native-8.0.34-1-r0: task do_populate_lic: Started
10:23:47 WARNING: cuda-binaries-native-8.0.34-1-r0 do_populate_lic: Could not copy license file /mnt/SSD1TBA/jenkins/workspace/oe-pimbox/openembedded/build/tmp-glibc/work-shared/cuda-binaries-native-8.0.34-1-r0/usr/share/doc/cuda-license-8-0/copyright to /mnt/SSD1TBA/jenkins/workspace/oe-pimbox/openembedded/build/tmp-glibc/work-shared/cuda-binaries-native-8.0.34-1-r0/license-destdir/cuda-binaries-native/copyright: [Errno 2] No such file or directory: '/mnt/SSD1TBA/jenkins/workspace/oe-pimbox/openembedded/build/tmp-glibc/work-shared/cuda-binaries-native-8.0.34-1-r0/usr/share/doc/cuda-license-8-0/copyright'
10:23:47 ERROR: cuda-binaries-native-8.0.34-1-r0 do_populate_lic: QA Issue: cuda-binaries-native: LIC_FILES_CHKSUM points to an invalid file: /mnt/SSD1TBA/jenkins/workspace/oe-pimbox/openembedded/build/tmp-glibc/work-shared/cuda-binaries-native-8.0.34-1-r0/usr/share/doc/cuda-license-8-0/copyright [license-checksum]
10:23:47 NOTE: recipe cuda-binaries-native-8.0.34-1-r0: task do_populate_lic: Succeeded

I think I know what the issue is here, and will put in a fix that adds a task dependency for do_populate_lic to eliminate the race condition.

I'm still seeing issues with this, we might need the commit above changing the file location also
WARNING: cuda-binaries-native-8.0.34-1-r0 do_populate_lic: Could not copy license file /mnt/SSD1TBA/jack/build/openembedded/build/tmp-glibc/work-shared/cuda-binaries-native-8.0.34-1-r0/usr/share/doc/cuda-repo-ubuntu1404-8-0-local/copyright to /mnt/SSD1TBA/jack/build/openembedded/build/tmp-glibc/work-shared/cuda-binaries-native-8.0.34-1-r0/license-destdir/cuda-binaries-native/copyright: [Errno 2] No such file or directory: '/mnt/SSD1TBA/jack/build/openembedded/build/tmp-glibc/work-shared/cuda-binaries-native-8.0.34-1-r0/usr/share/doc/cuda-repo-ubuntu1404-8-0-local/copyright'
ERROR: cuda-binaries-native-8.0.34-1-r0 do_populate_lic: QA Issue: cuda-binaries-native: LIC_FILES_CHKSUM points to an invalid file: /mnt/SSD1TBA/jack/build/openembedded/build/tmp-glibc/work-shared/cuda-binaries-native-8.0.34-1-r0/usr/share/doc/cuda-repo-ubuntu1404-8-0-local/copyright [license-checksum]

Keyboard Interrupt, closing down...

NOTE: Tasks Summary: Attempted 2798 tasks of which 2747 didn't need to be rerun and all succeeded.
ERROR: Command execution failed: Stopped build

Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
Execution was interrupted, returning a non-zero exit code.
[jack@tesla build]$ ls /mnt/SSD1TBA/jack/build/openembedded/build/tmp-glibc/work-shared/cuda-binaries-native-8.0.34-1-r0/usr/share/doc/cuda-repo-ubuntu1404-8-0-local/copyright
ls: cannot access '/mnt/SSD1TBA/jack/build/openembedded/build/tmp-glibc/work-shared/cuda-binaries-native-8.0.34-1-r0/usr/share/doc/cuda-repo-ubuntu1404-8-0-local/copyright': No such file or directory
[jack@tesla build]$ tree /mnt/SSD1TBA/jack/build/openembedded/build/tmp-glibc/work-shared/cuda-binaries-native-8.0.34-1-r0/usr/share/doc/
/mnt/SSD1TBA/jack/build/openembedded/build/tmp-glibc/work-shared/cuda-binaries-native-8.0.34-1-r0/usr/share/doc/
├── cuda-license-8-0
│   ├── changelog.Debian.gz
│   └── copyright
└── cuda-repo-ubuntu1404-8-0-local
    └── changelog.Debian.gz

2 directories, 3 files
[jack@tesla build]$

OK, checking on it.


a question

hi,
why is layoutNodeImpl(...) also implemented in the java library ?
as there is also the c++ implementation.

This is deprecated and we are slowly moving over to only using the C version via JNI. It will be removed soon.


Improve main menu navigation experience

When navigating the settings, the user has no feedback on if he/she is currently navigating the main menu or a sub menu except for the highlighting of elements in the submenu.
This PR changes the behavior of the navigation bar when entering and exiting a submenu element.
I.e. when navigating the main menu, no red arrow is shown. It only appears when entering a submenu. At this moment, the highlighting of the navigation bar changes, indicating a change in the level of navigation.
This feature is open to discussion, any opinion about it is highly appreciated! When accepted, it closes #363
Screenshots
Before

After

Would it be possible to modify the side menu selected entry to make it either bold or increase the font size slightly?

Would it be possible to modify the side menu selected entry to make it either bold or increase the font size slightly?

Yes and no.
Although I'd prefer making the selected tab bold, it is unfortunately impossible without declaring a completely new font bitmap. Slightly increasing the font size is possible, yet unfortunately looks really weird imho.

In the past I thought the red arrow was redundant. Now it seems to have value. It seems to mean "Look to the right (submenu)".

There are two ways to exit the secondary menu:

Press  < Back or up and left-click. After my test, there is no problem.
Enter video mode. For example, automatically enter a certain channel after scanning. Or enter av in through source. At this time, the navigation triangle is not hidden. Please resolve this issue.


Dijkstra's Algorithm- Python implementation

💥 Proposal
Task- Given a graph and a source vertex in the graph, find the shortest paths from source to all vertices in the given graph.
Dijkstra’s algorithm is very similar to Prim’s algorithm for minimum spanning tree. Like Prim’s MST, we generate an SPT (shortest path tree) with a given source as root. We maintain two sets, one set contains vertices included in the shortest-path tree, another set includes vertices not yet included in the shortest-path tree. At every step of the algorithm, we find a vertex that is in the other set (set of not yet included) and has a minimum distance from the source.
Have you read the Contributing Guidelines on Pull Requests?
Yes

Please assign me the task. I'm ready with the code.

I will take this issue.

@reachpranjal Do check the existing issues before opening a new one. This is a duplicate issue for #47 . Kindly comment there and wait for a project maintainer to assign you the issue in your preferred language.

@rutujak24 Please comment on #47 and do not pull a request before you are assigned the issue.


Move --database option to "aur" command

I have separated custom repos for AUR and my locally built dev pkgs.
Therefore I'm forced to specify --database option for almost all commands of aurutils.
At this point it becomes sane to move option itself to "aur" wrapper, as it was done in git with -C /path/to/repo option.
Afterwards it becomes possible to define alias aur='aur --database aur' and be happy.

alias aur=AUR_REPO=aur aur'

Thanks, it's rational variant -- but not immediately (intuitively) obvious -- which is first point.
And second point (in my opinion) is: moving options would allow ever-so-slightly decrease complexity of scripts by exporting everywhere-needed vars as AUR_REPO from single place only.
So suggested alias is nice but does not eliminate proposal altogether.
Or is there any strong contrarguments?

Adding options to aur(1) makes things harder on my end since you have to keep conflicts with existing aur-foo options in mind, besides adding potential ambiguities (compare aur --database build vs. aur build --database). As such I'd rather avoid it. Nothing prevents you from writing your own aur(1) script though - it's just placed in PATH and can be overwritten accordingly.

I don't see ambiguity 'cause we don't have multi-repo operations here, and single repo is chosen first.
So, command "aur" couples with concrete "repo" and then to this closure we apply chosen operations with their respective operational args.
Under such arrangement providing same option to most of the commands starts looking illogical.
And there are precendents such as "git" at least, however I met before a couple more.
Still, you provided alternative way to solve the problem and I will be content with it.

git also uses a highly complex mechanism to handle that: https://github.com/git/git/blob/master/git.c#L684
A few user tears are worth it when you can achieve the same thing with a simpler mechanism. :slightly_smiling_face:


Windows 7, really?

Sort of awkward that this high-security topic still allows for Windows 7.

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

ID: d0157378-8843-f6e1-3838-41a63450bc10
Version Independent ID: a4defdb9-9111-0c7e-f004-6dc5c130c682
Content: How to generate and transfer HSM-protected keys for Azure Key Vault - Azure Key Vault
Content Source: articles/key-vault/hsm-protected-keys-legacy.md
Service: key-vault
GitHub Login: @msmbaldwin
Microsoft Alias: mbaldwin

@Rvvhub Thanks for your feedback! We will investigate and update as appropriate.

@Rvvhub I suggest you to please post this as a feedback at UserVoice.  "This Product" button in at the bottom section of the document now to take you directly to the appropriate feedback page.

@Rvvhub We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


New version: OpenMedia.4KVideoDownloaderPlus version <IP_ADDRESS>8

Pull request has been created with komac v2.3.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run

https://github.com/microsoft/winget-pkgs/issues/152555

@wingetbot waivers Add Validation-Installation-Error


Add Ubuntu repo for GCC 7.3

Signed-off-by: Joe deKoning<EMAIL_ADDRESS>

I am unable to test against an Linux ARM distro, so I have purposely put this together to avoid installing on ARM.  If someone can verify that these packages are available for the ARM distro I can update.  Otherwise, this is the safe option.


Add new route in the code editor not reflected in the canvas after sync

Describe the Bug
When users add new route in the code editor, this new route is not displayed in the canvas after the code sync.
Steps to Reproduce the Bug or Issue

create seceral camel routes in the code editor (add [] on new line)
sync code changes
see no new routes were created

Screenshots or Videos

Platform

OS: [e.g. macOS, Windows, Linux]
Browser: [e.g. Chrome, Safari, Firefox]
Version: [latest]

It would be a same root cause with #2056
The backend doesn't recognize [] as a route and just return empty integration JSON with this YAML. We have to either

Make both backend and frontend recognize [] as an empty route
Make backend generates at least from and steps for the empty route

https://github.com/KaotoIO/kaoto-ui/assets/265462/ea67953a-3673-4baf-ad7c-802004519a81

@igarashitm I also think that (2) makes more sense :+1:


Version conflict with GitHub pages

Bundler could not find compatible versions for gem "jekyll":
  In Gemfile:
    github-pages (= 33) ruby depends on
      jekyll (= 2.4.0) ruby

    octopress-video-tag (>= 0) ruby depends on
      jekyll (~> 2.0) ruby

    octopress-video-tag (>= 0) ruby depends on
      jekyll (~> 2.0) ruby

    octopress-video-tag (>= 0) ruby depends on
      jekyll (~> 2.0) ruby

    octopress-image-tag (>= 0) ruby depends on
      jekyll (>= 0) ruby

    octopress-video-tag (>= 0) ruby depends on
      jekyll (~> 2.0) ruby

    octopress (>= 0) ruby depends on
      jekyll (~> 2.5) ruby

This is definitely a problem caused by the strictness of the GitHub pages gem. @parkr, What do you recommend here?

I'd probably do >= 2.0 wherever it's possible but you may not yet support 3.0 :(

@imathis, any chance to get this fixed soon?

Octopress relies on features from Jekyll 2.5, but I've found a way around that and been able get the Octopress CLI working with Jekyll 2.4. I can release a version that you can use, but Octopress Ink and other plugins rely on features from Jekyll 2.5, so depending on what you use, you may still have the conflict.
Also, when 3.0 is released, everything will begin to require 3.0. I hope that GitHub Pages will be able to move to 3.0 quickly, but it may be a little while before you can use the newer versions of things.

Thanks for the quick reply, very much appreciated!
I'm using these Octopress gems:
group :jekyll_plugins do
  gem 'octopress'
  gem 'octopress-genesis-theme'
  gem 'octopress-image-tag'
  gem 'octopress-video-tag'
  gem 'octopress-codefence'
end

Would the workaround work for these? If so, please let me know when/how to access the release.

I'm finishing it up right now. Octopress Ink (which the Genesis Theme relies on) will be the tricky part. I think I can get it to work though.

Sounds good ;-)

Yay @imathis!


[installation] csharpier is not found in NuGet feeds

I just wanted to install csharpier but I seem not to be able to install it
: $nu.os-info                                                                                1 06/13/2024 02:35:08 PM
╭────────────────┬─────────╮
│ name           │ windows │
│ arch           │ x86_64  │
│ family         │ windows │
│ kernel_version │ 22631   │
╰────────────────┴─────────╯
: dotnet new tool-manifest --force                                                                    06/13/2024 02:37:32 PM
The template "Dotnet local tool manifest file" was created successfully.

: dotnet tool install csharpier -g                                                                    06/13/2024 02:37:35 PM
csharpier is not found in NuGet feeds C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\".

Any hints what I might be missing?

It sounds like maybe your only source is C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
You can see all the sources with this - CSharpier is on nuget.org
PS C:\> dotnet nuget list source
Registered Sources:
  1.  nuget.org [Enabled]
      https://api.nuget.org/v3/index.json
  2.  Microsoft Visual Studio Offline Packages [Enabled]
      C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

Sometimes clearing the nuget cache can also help
dotnet nuget locals all --clear

nuget.org was missing, thanks!


Create depth anything demo

Online demo: https://huggingface.co/spaces/Xenova/depth-anything-web
Video:
https://github.com/xenova/transformers.js/assets/26504141/bbac3db6-8d8f-4386-a212-7e66ca616a0d

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


Awkward docstring genders the mascot

According to the "Getting started" guide:

We refer to Ferris with the pronouns “they,” “them,” etc., rather than with gendered pronouns.

https://www.rust-lang.org/learn/get-started#ferris

Ah yeah I thought this had been taken care of in an older commit but I guess not. Thanks!


Fix missing lines in long tag/values, with no "More" button

Description
The goal of this PR is to fix missing lines in long tag/values, with no "More" button
In some specific cases, if the value field is too long to fit in the max number of lines, but not tto long to fit in the max available height, the text will be presented in shortened version (with "..."), but without "More" button enabling to see full value in a modal screen.
Changes include

[*] Bugfix (non-breaking change that solves an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (change that is not backwards-compatible and/or changes current functionality)
[ ] Tests
[ ] Documentation
[ ] Other (for changes that might not fit in any category)

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 59.96%. Comparing base (74a8e35) to head (2486a54).

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #761   +/-   ##
=======================================
  Coverage   59.96%   59.96%
=======================================
  Files          12       12
  Lines        1721     1721
=======================================
  Hits         1032     1032
  Misses        689      689

Flag
Coverage Δ

unittests
59.96% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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


Recent topics does not update when single message in topic is deleted.

When a message is deleted, I expect it to be removed from the recent topics view of any other user who received the message.
But when there is only one message in a topic and it is deleted, the recent topics view is not automatically updated / re-rendered to remove that topic from the view when the delete message event is processed.

Steps to recreate in development environment (which is where I noted the issue):

Have two browsers logged in to different users. One with the user who will send the message and be in recent topics view (Cordelia). One with the user who will delete the message (Desdemona).
With Cordelia, send a new message to a topic with an old message from a few days ago (stream: test, topic: printer). Also, send a new message to a new topic in the test stream. Navigate to recent topics view.
Switch to Desdemona's browser window, but make sure you can still see Cordelia's browser window.
First, to see the expected behavior, open and delete Cordelia's message in the test stream with the printer topic. The message should move out of the recent topics view in Cordelia's browser.
Second, to see the bug, open and delete Cordelia's message in the test stream with a new topic. Nothing will happen in Cordelia's browser even though the event was received and processed.

I believe the issue is in recent_topics_ui.update_topics_of_deleted_message_ids.
If there is only one message in the topic, then message_util.get_messages_in_topic(stream_id, topic) will return an empty array, which means the subsequent call to process_messages(msgs) will not call complete_rerender(), which means the live update is not triggered.

Screencast of steps above
Screencast from 24-08-22 14:32:33.webm

@zulipbot add "area: recent topics"

@zulipbot add "area: recent-topics"

@alya @laurynmm are we planning to resolve this issue?
I would like to work upon this.
Thanks!

@aparna-bhatt - Yes, I'll add the "help wanted" label to the issue so that it can be claimed. I'll also note that if you have an idea of how to work on an issue that's not labeled as "help wanted" or "good first issue", you can always post a comment on the issue with your idea/plan for fixing it.
@zulipbot add "help wanted".

Thanks @laurynmm for the advice I will note it.

@laurynmm  one fix could be:
In the function process_messages we could call the function complete_rerender when the messages.length is zero as at that time we would want the topic to be removed from top of the recent conversations table.

@aparna-bhatt - recent_topics_ui.complete_rerender is generally something expensive to do, so I don't think we'd want to do that every time there were no messages to process. Especially since recent_topics_ui.process_messages is called in various places in the codebase besides when a message is deleted.
Instead, I'd think we would want to identify that the topic (as if it had been muted) should be removed from the recent conversations view. Maybe look at how recent_topics_ui.inplace_rerender works for muting topics and see if that could be used in this case?

@laurynmm I have created a PR please take a look.


Getting error message

To run lab 3 I'm getting a warning: Rtools is required to build R packages but is not currently installed. Please download and install (url to cran.rstudio). Does that sound right?

Never mind, just needed a restart!


Add Identity and Access Proxy interfaces

This PR adds schemas for interfaces making part of Identity and Access Proxy:

auth_proxy
forward_auth

See IAP interfaces design document for more context.

@simskij @PietroPasotti can you please review? I can't add reviewers on the PR.


Certificate

made a react app which contains the certificate generation code and integrated the original readme file with the default readme provided by create-react-app , the certificate generation app can help organisation to generate pdf;s of certificate easily by entering the organisation , candidate , course name in the form on the left

i am participating in hacktoberfest so if this pull request gets accepted could you please assign this pull request a hacktober tag


Update README to add introduciton and clean up typos

I added a paragraph of text giving a basic introduction to Benchpress describing what it is.

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

@nonhermitian just updated the text to reflect your above comment


chore: switch delivlib to use projen for publishing

Currently, delivlib publishes via a delivlib pipeline (so meta!). As part of
credential standardization, switching to a projen-based publishing model with
GitHub-managed secrets.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: GitHubPipelineAutoBuildProj-XK8ItpxnSow5
Commit ID: 599b382013c25bf7bce4d45e90a98c5dd702f1fe
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@njlynch I'm not opposed to tearing down the global delivlib instance - but what would be the story around testing delivlib now? I'd still like to preserve the ability to deploy a delivlib pipeline on my personal account and test it out - are we loosing this/making it much harder?

I'm not opposed to tearing down the global delivlib instance - but what would be the story around testing delivlib now? I'd still like to preserve the ability to deploy a delivlib pipeline on my personal account and test it out - are we loosing this/making it much harder?

The testing story is still the same, as documenting in the contributing guide: https://github.com/cdklabs/aws-delivlib/blob/8b6eac1947b73ca546810e8a66bb493be98f60bd/CONTRIBUTING.md#testing. The instructions are for deploying a delivlib pipeline specifically for test and verification.

AWS CodeBuild CI Report

CodeBuild project: GitHubPipelineAutoBuildProj-XK8ItpxnSow5
Commit ID: 65b163089186972177b89bc604305709e77af364
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


www/nginx: tls fingerprints rfc8701 compat.

Hi!
noticed when playing with https://github.com/opnsense/plugins/pull/3016
Request tls fingerprints never match with "trusted" user-agent fingerprint because of typo in setup.php.
in addition, since the creation of the script, rfc8701 (https://datatracker.ietf.org/doc/html/rfc8701) has appeared, which leads to an increase of the fingerprints count for one ua and a high probability of a false fingerprint mismatch.
pr fixes typo in setup.php and ignores rfc8701 "GREASE cipher suite values" on fingerprint compiling and comparing.
Thanks!

@fabianfrz thanks!
yes, I did not use the backend when debugging (I just added $tls_intercepted to the logging and checked the results of the comparison in the nginx logs), but it seemed to me that parentheses are a legal comment delimiter (https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.6), such as in the UA header.
Im also concerned about the possible breakage of existing configurations when changing header values (although adding a comment might make debugging easier). What's your opinion: -revert old values  -make syntax like: Intercepted (reason:excess suite or wrong order), bump version with explanations in changelog -make syntax like: "Intercepted; reason="excess suite or wrong order"`, bump version with explanations in changelog
Thanks

Hi @kulikov-a, the last one would be the one I would like most.

@fabianfrz Hi! added http_post/*.conf hook if you don't mind

looks good

Thanks!


Error installing mdpo

Hello @mondeja,
Thank you again for the support - I'm creating a separate issue about my installation issue, so the conversation in #169 remains clean for the AntennaPod maintainer when he has a look. I have installed Python 3 using the deadsnakes ppa, and now am on version 3.6.9.
Please see here the output of the installation process:
$ sudo -H python3 -m pip install mdpo
[sudo] wachtwoord voor glotzbach:
Sorry, probeer opnieuw
[sudo] wachtwoord voor glotzbach:
Collecting mdpo
  Downloading https://files.pythonhosted.org/packages/db/0d/386157adab66578ba6a2e5cccf87fce9ee45eef7aeb757069e4ea229aee2/mdpo-0.3.73-py3-none-any.whl (49kB)
    100% |████████████████████████████████| 51kB 1.4MB/s
Collecting polib>=1.1.0 (from mdpo)
  Downloading https://files.pythonhosted.org/packages/9e/ee/54d6c558d4319a26145658584acb373d50ba0968eb9c19fedfb42458314a/polib-1.1.1-py2.py3-none-any.whl
Collecting pymd4c==1.1.1 (from mdpo)
  Using cached https://files.pythonhosted.org/packages/ae/7c/154eea1a02c6340d14e919a3d803c9e268e3cc7d3a00821a362b071c9319/pymd4c-1.1.1.tar.gz
    Complete output from command python setup.py egg_info:
    running egg_info
    creating pip-egg-info/pymd4c.egg-info
    writing pip-egg-info/pymd4c.egg-info/PKG-INFO
    writing dependency_links to pip-egg-info/pymd4c.egg-info/dependency_links.txt
    writing requirements to pip-egg-info/pymd4c.egg-info/requires.txt
    /usr/lib/python3.6/distutils/dist.py:261: UserWarning: Unknown distribution option: 'long_description_content_type'
      warnings.warn(msg)
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-mc4m1t4t/pymd4c/setup.py", line 131, in <module>
        **about
      File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 129, in setup
        return distutils.core.setup(**attrs)
      File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
        dist.run_commands()
      File "/usr/lib/python3.6/distutils/dist.py", line 955, in run_commands
        self.run_command(cmd)
      File "/usr/lib/python3.6/distutils/dist.py", line 974, in run_command
        cmd_obj.run()
      File "/usr/lib/python3/dist-packages/setuptools/command/egg_info.py", line 271, in run
        writer(self, ep.name, os.path.join(self.egg_info, ep.name))
      File "/usr/lib/python3/dist-packages/setuptools/command/egg_info.py", line 649, in write_toplevel_names
        for k in cmd.distribution.iter_distribution_names()
      File "/usr/lib/python3/dist-packages/setuptools/command/egg_info.py", line 648, in <listcomp>
        k.split('.', 1)[0]
      File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 874, in iter_distribution_names
        for ext in self.ext_modules or ():
      File "/tmp/pip-build-mc4m1t4t/pymd4c/setup.py", line 61, in __iter__
        self._fetch_pkgconfig_all()
      File "/tmp/pip-build-mc4m1t4t/pymd4c/setup.py", line 55, in _fetch_pkgconfig_all
        super().append(self._fetch_pkgconfig(extension))
      File "/tmp/pip-build-mc4m1t4t/pymd4c/setup.py", line 38, in _fetch_pkgconfig
        for k, v in pkgconfig.parse(libs).items():
      File "/tmp/pip-build-mc4m1t4t/pymd4c/.eggs/pkgconfig-1.5.5-py3.6.egg/pkgconfig/pkgconfig.py", line 248, in parse
        _raise_if_not_exists(package)
      File "/tmp/pip-build-mc4m1t4t/pymd4c/.eggs/pkgconfig-1.5.5-py3.6.egg/pkgconfig/pkgconfig.py", line 103, in _raise_if_not_exists
        raise PackageNotFoundError(package)
    pkgconfig.pkgconfig.PackageNotFoundError: md4c not found

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-mc4m1t4t/pymd4c/

I'm on a (too) old Ubuntu version, so I wouldn't be surprised if this usage is not supported.

What exact version of Ubuntu are you using?

I'm on Ubuntu 18.04.6 LTS
I'm on a 64-bit system (hard & software)

It seems that your Ubuntu 18.04 build doesn't include wheel by default. Try with pip install wheel or sudo apt-get install -y python-wheel before install mdpo to satisfy a PEP 427 installation.

Thanks @mondeja for looking into this. It seems that, unfortunately, that wasn't the issue:
$ sudo -H python3 -m pip install wheel
[sudo] wachtwoord voor keunes:
Requirement already satisfied: wheel in /usr/lib/python3/dist-packages
$ sudo apt install python-wheel
Pakketlijsten worden ingelezen... Klaar
Boom van vereisten wordt opgebouwd
De statusinformatie wordt gelezen... Klaar
python-wheel is reeds de nieuwste versie (0.30.0-0.2).
python-wheel staat ingesteld op handmatig geïnstalleerd.
0 opgewaardeerd, 0 nieuw geïnstalleerd, 0 te verwijderen en 7 niet opgewaardeerd.

Could you try updating pip? sudo -H python3 -m pip install -U pip

Awesome, updating (wheel and) pip did the trick. Thanks! Now I can start experimenting with mdpo :D


Change Saml-Ping testAndEnable and login output

once the property name is changed as mentioned, it LGTM


Adopt new SDK (with Combine); Observe the User

Cannot be done until the new, Combine-enabled SDK is available
The User and App objects will be ObservableObjects so can observe the User state

Blocked until the new Realm SDK is available


Ellipse Parameter Syntax Error

Redundant Comma in Attribute Definition
There appears to be a syntax error in the SVG ellipse parameters. Specifically, a redundant comma is present in the attribute definition, leading to potential parsing issues or unexpected behavior. The issue occurs in the ellipse element's attribute string: <ellipse cx=\"\(x)\" cy=\"\(y)\" rx=\"\(rx)\", ry=\"\(ry)\". The comma between rx and ry attributes is not required and should be removed to adhere to proper SVG syntax.

Noticed this small bug while working on a project and it bugged me. Thought it'd be best to fix it right away.