Annotation context doesn't correctly project when projecting 3d keypoints into 2d image

Describe the bug

https://github.com/rerun-io/rerun/assets/25287427/02c51a77-7bba-4120-9468-a9c3d6e604f6
Currently when projecting a 3d entity into 2d, the annotation context doesn't currently get shown (as in the video above) in 0.6.0
To Reproduce
Steps to reproduce the behavior:

Log an annotation context for a 3d keypoint entity (such as a set of hand or body landmarks)
log said 3d key points in the world space and cameras via pinhole/rigid3d
Go to corresponding image and add entity to view
2d keypoints are projected fine (in this case they look wrong only because this is being projected as a pinhole camera with fisheye distortion parameters). But annotation context (in this case the links between the keypoints) does not correctly project

Expected behavior

The links between the keypoints should also correctly show in the 2d image (as they do in 3d)
Desktop (please complete the following information):

OS: Ventura 13.2.1

Rerun version

rerun_py 0.6.0 [rustc 1.69.0 (84c898d65 2023-04-16), LLVM 15.0.7] aarch64-apple-darwin release-0.6 643dea9, built 2023-05-25T20:38:09Z

Fairly sure this is fixed by #2407, but someone would need to confirm :)

Fairly sure this is fixed by #2407, but someone would need to confirm :)

Looks like this was fixed when I upgraded to latest prerelease, but something unrelated popped up when I log Monochrome images. They are much much dimmer now
https://github.com/rerun-io/rerun/assets/25287427/7b55fb8d-c524-436b-bc26-b37ac79d50f8

Both of these are fixed for me on 0.7.0! Nice job ya'll


Handle qpy serialization across versions and delete vendored fork

Summary
For the next qiskit-ibm-runtime release it is desired to have it support both Qiskit 0.45.x/0.46.x and Qiskit 1.0.0. To do this with QPY it means we need to emit a fixed qpy version of 10 as that's currently the maximum version the server side can parse. The easiest way to manage this across versions is actually to rely on Qiskit's qpy module again. Starting in Qiskit 1.0.0 the qiskit.qpy.dump() function a new kwarg, version exists to specify the version of qpy emitted. We can use this to control the rollout of QPY format versions as the server side is updated. For right now this is fixed to version 10 which is the same as the QPY format version emitted by 0.45.x and 0.46.0. Because the versions are the same we can just use qiskit's qpy module moving forward as either we're on qiskit 0.45.x/0.46.x and will emit version 10 (as there is no option) or we're on >=1.0.0 and we explicitly set the qpy version to one that's compatible with the server side.
The qpy internals usage to serialize parameters and parameter expressions are left in place (although expanded on to include #1355 for parameter expressions) as an alternative needs to be considered for this. It is not a good idea to rely on qpy internals and explicitly private functions to do partial serialization.
This commit also deletes the vendored fork as it's never been included in a released version of qiskit-ibm-runtime and nothing is using it anymore.
Details and comments
Related to: #1375

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

-4 of 8 (50.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+9.8%) to 79.067%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit_ibm_runtime/utils/json.py
4
8
50.0%

Totals

Change from base Build<PHONE_NUMBER>:
9.8%

Covered Lines:
4850

Relevant Lines:
6134

💛  - Coveralls


ReferenceError: TypeInference is not defined.

It's in the title, help please? This looks really cool, and I really want to try it!

Universal-transpiler is compatible with SWI-Prolog. Which Prolog interpreter are you using?

Oh, I was using the javascript version, I'll try the Prolog version now though. :|

The latest version works correctly on Windows and Ubuntu. Which operating system are you using?

I am using Windows 10 currently.

I am using it on Windows 10 and it runs correctly. Is input.txt saved in the same folder as universal-transpiler.pl on your machine?

Yes it is saved in the same directory... Maybe it's because I am on the Fast ring of the Insider Program???

You might be using an outdated version of universal-transpiler. Does it prompt you to Edit the source code in input.txt, type the name of the the input language, and press Enter:?

That's exactly what it says, and I just downloaded the day I submitted this issue... :\

I made another update to the system now. Try running the latest version; it now detects the input language automatically and prints the output in each language.

I just redownloaded it, and now it's back to the initialization goal failed error.

universal-transpiler.pl works on my PC, though. I'm not sure what the problem is. Did you open another file by mistake?

Yes, it's extracted. I think my computer is just really crappy or something... :\


Dashed Line Error

Using a dashed line as an annotation causes data points and marker lines to also become dashed when the graph updates (when a data point is hovered over or a data set is hidden).

Before graph update

After graph update
I don't know much about js canvas, but it seems that the drawing mode is set to dashed before the annotation is drawn. But the problem occurs because the drawing mode isn't set back to solid before the graph is updated and redrawn.

@NZguy your hunch is correct. https://github.com/chartjs/Chart.Annotation.js/blob/master/src/line.js#L8 needs an update to save and restore the canvas context. I will get on that ASAP


add options to TextBreakLines

fixes #78

I assume, text_glyph_positions should call text_prepare as well.

I did a few updates, I wonder why it still fails. cargo test works well.

@KevinKelley will you merge this and publish it on crates.io?
If you don't want to, you might want to give me the rights to do so myself.

I got covid-stranded for a couple months here...sorry.  I've just finally got access back.  I'll look at it tomorrow or so.  I'm absolutely in favor of having this fixed.

@KevinKelley will you merge this and publish it on crates.io?
If you don't want to, you might want to give me the rights to do so


Bug 2055386: When services share IP, modifying any service should fail instead of allocating newIP

Users prefer seeing errors when modify services that are sharing the sameIP
using "allow-shared-ip" annotation than getting newly allocated serviceIP
Signed-off-by: Mohamed Mahmoud<EMAIL_ADDRESS>

/assign @fedepaol

/bugzilla refresh

/lgtm

/test metallb-e2e-metal-ipi-ovn


MVP for soft release

Trying to describe MVP for soft release.
MVP: scatter plots w/ USGS style

USGS theme not tied to session (preloads half-built gsplot object)
user config

New features:

[ ] config file method works (#402)
[ ] themes (#385)
[ ] all gsplot-only features captured in README
[ ] some functions need to be aware of axes extents (#338)
[ ] give mtext an identity (#359)
[ ] gsplot object metadata (#304)
[ ] SPN date handling in config (#134)
[ ] ggplot2-like df handling (#195)
[ ] temporarily change pars (#254)
[ ] global non-pars treated appropriately (#366)
[ ] strip arguments function (#303)
[ ] scientific=FALSE as argument to axis for labeling??
[ ] append axis (#408)

Bugs:

[ ] data.frames can be passed in (#322)
[ ] formulas can be used (#314)
[ ] dates work (#272, #285)
[ ] index for pts/lines (#245, #224)
[ ] keep defaults of bypassed functions (#236)

scientific=FALSE as argument to axis for labeling??


feat: migration to updownio API

This is a migration proposal from Uptime Robot to Updown.io
The good :

free (shared account for beta/dinum)
simple
we can use tchap webhooks and even telegram for "astreinte"

The bad :

shared account so we cannot manage it and so far the process to add modify a monitor is quite complicated
require an API call per monitoring and we still dont have as much data as uptime robot (we miss the creation date, that would require an aditional call)
not sure we can organise monitoring page the way we want (see https://updown.io/p/3sg8p)

closes #773

@BenoitSerrano could not find the API Bilans Financiers in the list of monitors.
I strongly believe I need an access to updown io or this migration will become a nightmare

@johangirod I took all of your comments into account. Thanks for the explanation about the for loop vs Promise.all. Makes much more sesn this way. I am ready to deploy.


Greater Middle Eastern ancestry category is not imported into curation app from submission template

Greater Middle Eastern ancestry category is not imported into curation app from submission template, but it should be added to list of ancestry categories upon import.

Lizzy tested thids, there was a problem in sandbox, @ala-ebi  is looking at it

Release held up pending Yomi changes - @ala-ebi  to create custom branch to release

Release held up pending Yomi changes - @ala-ebi  to create custom branch to release

release done


Allow for dynamic gradients

Gradients need to be created on the fly. Allow for this.

This is huge. 🍰!


Gtk3 integration using CDT s

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

@conda-forge-admin please rerender

Needs: https://github.com/conda-forge/cdt-builds/pull/63

Note to self, i think i need to add:
export PKG_CONFIG_PATH="$PKG_CONFIG_PATH;${CONDA_BUILD_SYSROOT}/usr/lib64/pkgconfig;/usr/lib64/pkgconfig/"

and add a few more CDTs.
The command
pkg-config --exists gtk+-3.0

can help while editing the files  surrounding
_build_env/x86_64-conda-linux-gnu/sysroot/usr/lib64/pkgconfig/gtk+-3.0.pc

@ccordoba12 do you know how to specify the GTK3 path?

Sorry, I don't.

This is ready for review and feedback.
Listing out which libraries are linked to the system libraries in the gtk3 plugin:
~/mambaforge/envs/dev/plugins/platformthemes $ ldd libqgtk3.so  | grep " /lib"
	libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007fa4b9989000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa4b9982000)
	libgtk-3.so.0 => /lib/x86_64-linux-gnu/libgtk-3.so.0 (0x00007fa4b9159000)
	libgdk-3.so.0 => /lib/x86_64-linux-gnu/libgdk-3.so.0 (0x00007fa4b9052000)
	libatk-1.0.so.0 => /lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007fa4b8fae000)
	libgdk_pixbuf-2.0.so.0 => /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007fa4b8e63000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa4b86fc000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa4b84b9000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa4b61be000)
	libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007fa4b603c000)
	libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007fa4b6008000)
	libatk-bridge-2.0.so.0 => /lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0 (0x00007fa4b5fab000)
	libepoxy.so.0 => /lib/x86_64-linux-gnu/libepoxy.so.0 (0x00007fa4b5e76000)
	libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007fa4b5de9000)
	libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007fa4b5ddc000)
	libXcursor.so.1 => /lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007fa4b5dd0000)
	libXcomposite.so.1 => /lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007fa4b5dcb000)
	libXdamage.so.1 => /lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007fa4b5dc6000)
	libwayland-cursor.so.0 => /lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007fa4b5d77000)
	libwayland-egl.so.1 => /lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007fa4b5d72000)
	libwayland-client.so.0 => /lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007fa4b5d61000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa4b5b98000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fa4b5ad6000)
	libatspi.so.0 => /lib/x86_64-linux-gnu/libatspi.so.0 (0x00007fa4b58dc000)

If we want to move forward with this strategy, we will need the CDTs to be merged from conda-forge
https://github.com/conda-forge/cdt-builds/pull/63

Looking through the logs, it seems that cairo is still being pulled from conda, and not the CDT. I'm going to see what i can do on this front.

I don't think there is much for me to do here.
The rest might just be "executive decisions" you can all make regarding comments, or the aggressive approach to linking to CDT cairo

Can you please catch me up with some of the motivation for this change? Since we've gone to the trouble of packaging gtk3, why switch to CDTs for it?

To summarize:

Qt is already a pretty heavy dependency. The goal here is not to integrate Qt with the rest of the GTK ecosystem in conda-forge. but with system GTK so that things are themed well.
I don't really want to to pull in all the GTK dependencies for something that I find only affects users of GTK
I've found inconsistencies when trying to use gtk command line utilities.  For example I cannot seem to run gio set from conda-forge with Ubuntu.

Thanks, that's helpful. I see now that the recipe already depends on a gtk2 CDT, and doesn't actively link with conda-forge's gtk3.
I don't love this situation, since it means that our Linux binaries will depend on this large stack of system libraries that might not be available everywhere. If we use conda-forge dependencies, our packages are more portable, although they also pull in more dependencies.
But given the current situation, it doesn't seem to me that what you're proposing makes that any more of an issue than it already was, and indeed it probably makes our compatibility better as people move away from gtk2. So it seems like a good change to me.

Linux binaries will depend on this large stack of system libraries

I'm hoping that in this case, since it is a plugin, Qt will "gracefully fail". Maybe I can install an Kubuntu VM and test this out....

So here is a Virtual Machine, running kubuntu, with gtk-3.0 uninstalled (I probably broke parts of Kubuntu doing this tbh).
However, it is still able to run spyder from within my environment.

Hopefully this should alleviate any concerns about extra system dependencies due to this addition.

Interesting! Thanks for gathering the evidence here — good that it seems to be able to fall back gracefully.
(If/when this PR moves ahead, it might be nice to have some comments in the meta.yaml explaining this general situation for posterity.)

Interesting! Thanks for gathering the evidence here — good that it seems to be able to fall back gracefully.
(If/when this PR moves ahead, it might be nice to have some comments in the meta.yaml explaining this general situation for posterity.)

How does the current explanation look

How does the current explanation look

Looks good to me.

I think we should avoid CDTs as much as possible. Is it too hard to package the older versions as conda packages?

Is what you are proposing, using old versions in conda forge (which we would rebuild), and ignoring their run exports?

Yes, but only if it's not too much trouble.

Yes, but only if it's not too much trouble.

The system integration testing what I'm most worried about.  I've already put in about 1 month of time testing this on live computers with various hardware configurations on Ubuntu 22.04. I'm worried that an other change in the approach would complicate things.
Given my responsibilities in the coming month, I do think it would be best if one either this PR, or https://github.com/conda-forge/qt-main-feedstock/pull/98 were to get pushed forward.
I do not want to dismiss your thoughts, i could write them up in an issue here, but I won't personally have time to investigate which "old versions we should build for" nor the system compatibility with Qt 5.15 at the moment.

I think we should avoid CDTs as much as possible. Is it too hard to package the older versions as conda packages?

I'm on @hmaarrfk side about this one (as I already stated before). There's no need to rely on conda-packages for this feature (as @hmaarrfk eloquently described in the comment he added on his last commit), Qt won't break if it can't find the required system libraries and this will maintain its package size manageable (instead of pulling the whole Gtk stack just to be able to use the Gtk open file dialog).
So, the pros outweigh the cons (I don't know what are the cons, really), so I'd say we should move with this approach, which is almost ready.

Qt won't break if it can't find the required system libraries and this will maintain its dependencies size as they are now (instead of pulling the whole Gtk stack just to be able to use the Gtk open file dialog).

I think you are misunderstanding what I mean. Using conda packages with ignore_run_exports will not increase the package size.

but I won't personally have time to investigate which "old versions we should build for" nor the system compatibility with Qt 5.15 at the moment.

The ones used by the CDTs are a good start. The CDT versions are an arbitrary lower bound and we are free to choose that or some other version.

Ok. I'm going to say: "Moving away from CDTs is too much work".
I think that:

Moving away from CDTs would put unnecessary burden on maintainers given we would be seeking to recreate the functionality of CDTs by adding the "run_export".
Moving away from CDTs would make me invested in maintaining an "old version" of a package, something that COS7 does for me today.

I think that the CDTs pointing to GTK2 were to maintain similar functionality in the past. For example, Ubuntu 16.04 references libqt5libgtk2
https://launchpad.net/ubuntu/xenial/amd64/libqt5libqgtk2/5.5.1+dfsg-16ubuntu7
And this may point to why, over the years, we've lost this feature in qt packaged conda-forge.
Unless there is a strong objection I'm going to proceed by asking for a review of the new CDTs I've asked to be included at conda-forge so we can move this forward.

I think we should discuss at a core meeting. I forgot that we need to add new CDTs for GTK3 and that they are not used anywhere else yet. I'm 100% against adding new CDTs. (I think we should reduce the existing CDTs, but that is a separate discussion)

i mean if your objection is that strong, then  this can wait until somebody decides to rebuild the requirements with older versions.
Perhaps what might help me formulate my question at a core meeting is if you could write up a few sentences about what packages would be considered for new CDTs in:
https://github.com/conda-forge/cdt-builds
I feel that the usage of CDTs proposed here is in spirit with "Linking against libGL" mentioned in the docs:
https://conda-forge.org/docs/maintainer/knowledge_base.html#core-dependency-tree-packages-cdts

I think that the CDTs pointing to GTK2 were to maintain similar functionality in the past.

Yep, that's correct. @mingwandroid did that while we were working at Anaconda.

Summarizing a conversation I had with Isuru, it seem that his thoughts are that we should strive to demonstrate that the functionality that we are trying to achieve here cannot be replicated on the target systems with conda packages.
This is the case with discoverability of OpenGL features, but it is still unclear that this is is the case for particular use case.
I somewhat agree that "a quick desire" for myself shouldn't superceed doing due diligence, and so I'm going to have to do more exploration.
i'll try to evaluate:

The size of the additional GTK dependency
The compatibility of using conda-forge GTK, with "older" versions of system GTK.

Given the feedback, I think that the best thing to start with is moving toward:
https://github.com/conda-forge/staged-recipes/pull/22086


[v1.2] User Guide Update

Updated Intro for User Guide
1.1 Welcome
1.2 Authors
1.3 Bluebird Help System
1.4 Features and Capabilities

Updated Command Summary for User Guide

added Hide
added Multi Delete
added Alias (unfilled, left for Deep4k to fill)

Coverage remained the same at 92.162% when pulling 0733a0b063d557d055eadf0e8209138dcafbdcfe on wynkheng:UG_Intro_FirstDraft into 97588e124db8a6047f51a9919b4bda59c923d966 on CS2103AUG2017-T15-B4:master.

Coverage remained the same at 89.9% when pulling 05bd54968f6524d468720a14843f42cbdd3621c7 on wynkheng:UG_Intro_FirstDraft into 98e6b5f78d82824eaabff325247f6f87ca4d2eab on CS2103AUG2017-T15-B4:master.


Declare return types in waterfallDialog.ts

See files for small fixes

Pull Request Test Coverage Report for Build 99962

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

Totals

Change from base Build 99861:
0.0%

Covered Lines:
8430

Relevant Lines:
9665

💛  - Coveralls


GetToken does not support query parameters

Query GetToken function does not expose query params to the caller.
https://github.com/binance-chain/go-sdk/blob/98a01c4963488fb43ade98680ff8158c41e12030/client/query/get_tokens.go#L10-L12
In the API reference, Get tokens list allows limit and offset so the client can optionally manipulate these values.
When the number of issued tokens is more than the default limit (which is 500), they got cut off. Thus, GetToken does not return the correct list of all tokens.

thks for your report. The issue is going to fixed in  https://github.com/binance-chain/go-sdk/pull/58


gun init descriptor or xpub. Versioned config and secret_protocol_randomness. Save PSBTs to psbt-output-dir and wait for signing

Fix anyhow related compilation errors, print values
InitOpts for Seed and Descriptor subcommands
Versioned config, init xpub, secret protocol randomness
Add psbt-output-dir init option, and wait for signing

New init subcommands
gun init seed
gun init descriptor
gun init xpub
descriptor and xpub have an --psbt-output-dir that defaults to $GUNDIR/psbts/
config.json layout is not identical to https://github.com/LLFourn/gun/issues/62
Looks like
  "wallet-key": {
    "descriptor": {
      "external": "wpkh([81148886/84'/0'/0'].../0/*)",
      "internal": "wpkh([81148886/84'/0'/0'].../1/*)"
    }

Seed phrase no longer printed after gun init seed.
Since PSBT betting is not yet supported, gun bet gives Error: Betting is not yet supported for descriptor based wallets. when using a descriptor wallet.
Currently WalletKey::SeedWordsFile still gets secret randomness from the seed phrase, whereas WalletKey::Descriptor uses the secret_protocol_randomness for the keychain. Would also using secret_protocol_randomness for seed wallets break any ongoing bets?

Is it easily possible to create a general/global structopt option that is shared across each enum variant?
E.g. network is an option on every init subcommand.
/// The network name (bitcoin|regtest|testnet)
#[structopt(long, default_value = "bitcoin", name = "bitcoin|regtest|testnet")]
network: Network,

Is it easily possible to create a general/global structopt option that is shared across each enum variant? E.g. network is an option on every init subcommand.
/// The network name (bitcoin|regtest|testnet)
#[structopt(long, default_value = "bitcoin", name = "bitcoin|regtest|testnet")]
network: Network,

yeah I think I do that with the --fee argument take a look at what I did there. Something to do with "flattening".


fix(Notification): materialize output will now match Rx4

changed notification's exception property to by named error

BREAKING CHANGE: Notification.prototype.exception is now Notification.prototype.error to match Rx4 semantics
fixes #2105

LGTM

Coverage remained the same at 97.593% when pulling 4983289b197c213a83846f8659bae585e76989cd on blesh:notification-fix into 39214f22b4b470e708e8c05f62b2243536e9f238 on ReactiveX:master.

LGTM


[FEAT] Add subtype survey times option to subtypes file

Requested Feature/Enhancement
Add the functionality for users to provide method surveys types on a per subtype basis in the subtype file.
Need for feature/Enhancement
Users can already provide subtype times on a per facility basis. This allows for user convenience when setting site behavior on a per subtype basis.
Problem to solve
Allows for expanded subtype file functionality to make setting inputs more intuitive.
Implementation Ideas
No response
Additional context
No response

V4 addressed this enhancement.


Change meritocracy distribution

I think this will be a bit better, as IMO contributing is more important than voting

I think we should keep the total at 20 (because in reality it would be more like 10-12 after the duplicates). 12 and 8 would probably be good, or 14 and 6.

@andrewda Overlaps reduce that though - I'll calculate what change this'll have.

This would reduce the size of the current meritocracy, but only from 15 to 14.

Ok that works for me. But I think that mentioning the members of the meritocracy when entering the extended voting period is a must, especially because his will change the meritocrats.

@andrewda I'd prefer to do that after the DB PR gets merged. It'll be a lot more stable then.

Yep works for me (as long as it's done pretty soon 👍 )

Merge conflicts fixed. I'll start working on the meritocracy mentions now.

I think the meritocracy balance might need to be tweaked. I'm not sure the top 5 voters is useful, since pretty much all of them are already in the meritocracy

@rudehn Pretty much all, but not all. That could also change. IMHO top voters isn't useful, but I added it due to popular approval.

I'd say voters should be in there somehow, maybe even number of comments on issues/PRs? That way we 'reward' contributions from the community who doesn't actually write code.

That's a good point @hongaar - something like the judicial branch of the Chaosbot democracy

@hongaar I'd support that, but the implementation might be complicated.

@PlasmaPower it would be much easier when database stuff gets up and running

One vote needed.

Or maybe 2, there's a decimal behind the .5.

@anythingbot well it's a good think I don't care :)

@anythingbot that'd be a republic, not a meritocracy. I've also considered it, but I think the current solution works fine.


Render the validator name that commits to the aggregated authority signature

        validatorSignatureData = {
            title: 'Aggregated Validator Signature',
            content: [
                {
                    label: `Signature`,
                    value: txdata.authSignInfo.signature,
                    monotypeClass: true,
                },
            ],
        };

currently explorer only shows the BLS aggregated signature, we also want to show what validator signed for the transaction with link to validator page by their pubkey.

add index to CommitteeInfo response https://github.com/MystenLabs/sui/pull/5337
when rendering the signature page for a tx, use txdata.authSignInfo.epochId to call endpoint: https://docs.sui.io/sui-jsonrpc#sui_getCommitteeInfo
match txdata.authSignInfo.signers_map to corresponding validator pubkey

tracked as frontend jira task. marks backend as done


Add illwoo changes

This should be closed, list of changes to be backported are documented in https://github.com/NIRALUser/GROUPS/issues/10#issuecomment-441761206


Update Azure table offerings for application Architecture

Summary

Update recommendations
Convert it to markdown for accessibility

@nishanil please check the by-default recommendations.

The images are slightly different in size.

The images are slightly different in size.

Yes, I wanted to make them highlight that way, besides the color, that they're the recommended option.
Did you like the white outline to improve the contrast in dark mode?
Just experimenting 😊

@mvelosop Can you make the images smaller.. And, update ms.date.


Easier python.pythonPath setup

When creating a virtualenv that is not in one of the directories monitored by VSCode, you have to add it manually to the python.path settings.
I teach Python regularly, and this is more difficult than it should be for most beginners. They need to:

learn the command palette
learn the existence of settings
learn the difference between user settings and workspace settings
learn that the settings is named python.path (and that it is not related to the PYTHONPATH)
look for it in the settings
understand that they need to copy paste the entire absolute path to python.exe (not a relative path, not the name of the virtualenv, not the path to the virtualen dir...)
find a way to copy it (few know about shift + click)
then paste

Requested feature:
I think it would improve things to have 2 new entries in the menu you get from clicking the bottom left button that let your select a virtualenv:

one entry to add a virtualenv to the list
one entry to add a directory to be monitored for new virtualenv by vscode

They would open a UI file selector, not ask for a string to be copy/pasted. The selector for the venv would accept the path to the exe or the path to venv or venv/bin folder and normalize it.
Even better would be an entry "manage virtualenvs" opening a dedicated UI that let you do all those things, and create or remove env as well. But that would be much more work. The first solution is simpler and would help greatly already.
I made a separate but related issue about the renaming the python.path setting: https://github.com/microsoft/vscode-python/issues/8646

Thank you for the suggestion! We have marked this issue as "needs decision" to make sure we have a conversation about your idea. We plan to leave this feature request open for at least a month to see how many 👍 votes the opening comment gets to help us make our decision.

Ok, thanks for having take the time to read it.

Hi @ksamuel, once again thank you for your feedback!
One part of your request is going to be covered when we address https://github.com/microsoft/vscode-python/issues/2125. About being able to add a directory with virtual environments to be monitored, right now you're able to do it through the settings UI (File > Preferences > Settings and then look for "venv folders"). I don't think a lot of people would use it so often to justify this option being displayed every time they select an interpreter, so we'd rather leave it on the settings for those who would want this additional configuration step.
TL;DR: closing in favour of https://github.com/microsoft/vscode-python/issues/2125.


lxd: Add clustering_fix_raft_address_zero patch to fix node with "0" as address

Signed-off-by: Free Ekanayaka<EMAIL_ADDRESS>

Testsuite passed


Release/2.7.1

@gulzar1996 @PratimMallick Can't merge these changes. Can you please resolve the conflict here?


On android when passed more than one type, it allows user to pick up every other type

Trying to filter images and pdf only, but videos, audio files also show up in the picker.
Is there a solution to fix this?

I am having the same issue

I also have the same issue


New package: OMcsv v0.10.6

Registering package: OMcsv
Repository: https://gitlab.com/christiankral/OMcsv.jl
Created by: https://gitlab.com/christiankral
Version: v0.10.6
Commit: bdb52dd0e61a4bfeeaa1df50a24e762a2829dc2e
Git reference: HEAD
Description: Perform OpenModelica simulations based on CSV parameter files
Release notes:

Fix some structural problems

I would recommend the name OpenModelicaCSV


feat: notify user about incompatible plugins in error popup

pretty simple change that adds incompatible plugin information to the error message
looks like this when both the DLL and scripts fail to load

looks like this when just scripts fail to load

we don't show the popup when there are no validation errors, because incompatible plugins on their own aren't necessarily a problem

Thanks again!


HDDS-8025. ReplicationManager: Count a container once for missing, under, mis or over replicated

What changes were proposed in this pull request?
If a container is missing, then the new Replication Manager currently counts 1 in the report for under replicated and 1 for missing, meaning the container is double counted.
It makes more sense if we only count under-replicated OR missing. Technically a missing container is also under-replicated, but it makes the report confusing when the container is in two states.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-8025
How was this patch tested?
Modified some existing tests.

@sodonnel some test failure in re-run looks related:
TestReplicationManager.testUnderReplicatedAndUnrecoverable:433 expected:<1> but was:<0>
TestReplicationManager.testUnrecoverableClosedContainerWithUnhealthyReplicas:495 expected:<1> but was:<0>

https://github.com/apache/ozone/actions/runs/4262416097/jobs/7419698367#step:6:1474

@sodonnel some test failure in re-run looks related:
TestReplicationManager.testUnderReplicatedAndUnrecoverable:433 expected:<1> but was:<0>
TestReplicationManager.testUnrecoverableClosedContainerWithUnhealthyReplicas:495 expected:<1> but was:<0>

https://github.com/apache/ozone/actions/runs/4262416097/jobs/7419698367#step:6:1474

Yea I missed those ones. Easy to fix so I have pushed a new commit now.


SYNTAX ERROR: WOQL.decimal is not a function

After toogle mode to JSON and back to WOQL and again to JSON (two times) with example query from docs i recive error: WOQL.decimal is not a function
Doc page:
https://terminusdb.com/docs/maths-based-queries-in-woql/
How to reproduce:

Paste example in WOQL-mode and run:
SERVER ERROR: Not well formed WOQL JSON-LD

let v = Vars("result");
evaluate(times(2,3), v.result)

Convert to JSON:

{
  "@type": "Eval",
  "expression": {
    "@type": "Times",
    "left": {
      "@type": "ArithmeticValue",
      "data": {
        "@type": "xsd:decimal",
        "@value": 2
      }
    },
    "right": {
      "@type": "ArithmeticValue",
      "data": {
        "@type": "xsd:decimal",
        "@value": 3
      }
    }
  },
  "result": {
    "@type": "ArithmeticValue",
    "variable": "result"
  }
}

Convert to WOQL:

WOQL.eval(WOQL.times({"@type":"xsd:decimal","@value":2}, {"@type":"xsd:decimal","@value":3}), "v:result")

Convert to JSON:

{
  "@type": "Eval",
  "expression": {
    "@type": "Times",
    "left": {
      "@type": "xsd:decimal",
      "@value": 2
    },
    "right": {
      "@type": "xsd:decimal",
      "@value": 3
    }
  },
  "result": {
    "@type": "ArithmeticValue",
    "variable": "result"
  }
}

Convert to WOQL:

WOQL.eval(WOQL.times(WOQL.decimal(2), WOQL.decimal(3)), "v:result")

Convert to JSON:
:x: SYNTAX ERROR: WOQL.decimal is not a function

From Discord:

LaurentS:
We tried replacing xsd:decimal with its equivalent (according to the docs) xsd:double but it didn't help.

Examples from the documentation still don't work a month later:
https://terminusdb.com/docs/maths-based-queries-in-woql/
The error changed from SERVER ERROR: Not well formed WOQL JSON-LD to:
SERVER ERROR: The query you have sent has no viable mode. Some variables can not be bound under any reordering.
let v = Vars("result");
evaluate(times(2,3), v.result)

or this:
evaluate(times(2,3), "v:result")

@GavinMendelGleason Give me a hint where to look at the code that is responsible for this? I'll try to find a bug or missing method

Related issue about unable to using math methods: https://github.com/terminusdb/terminusdb/issues/2076


Import from Share ID

New functionality that pushes the text from an existing brew's ShareID into a New brew page.
It is expected that this will be useful for:

assisting users with issues without interfering with their work, as they often accidentally share their edit links
creating documentation demonstrating specific CSS/Markdown techniques
other stuff that I haven't thought of yet

As always, please cast your eyes over this and let me know if/how/where the code can be improved.
Regards
-G

I appreciate the idea here. However, I am not really a fan of making this into an entire separate page that is essentially a duplicate of the new page, which is itself a duplicate of edit, as is the homepage. I've been running into lots of small bugs with the v3 update because I make a change on one but forget to update all 3. In fact, unifying all of the "edit-type" pages into one has been rolling around as a needed maintenance step for a while now.
Given that, do you think you could modify this to instead send the imported text to the "new" page? You can have the /import path in the server.js generate the brew text, but then reroute to a new page after that point rather than a nearly-identical /import page.

I've commented out the existing /new and changed the new /import to be /new instead. Initial testing shows this is working exactly as per the previous (/new results in a blank new, /new/{shareID} results in a new page loaded with the source from the brew with that shareID.

In fact, unifying all of the "edit-type" pages into one has been rolling around in my head as a needed maintenance step for a while now.

This has been percolating in the background of my mind for a while, ever since I realized just how similar big chunks of the pages are. However thus far I haven't committed to actually re-writing the page functions.

I've commented out the existing /new and changed the new /import to be /new instead. Initial testing shows this is working exactly as per the previous (/new results in a blank new, /new/{shareID} results in a new page loaded with the source from the brew with that shareID.

Alright, this is a good start. Now, ideally, I would like get rid of importpage.jsx and importpage.less so all of this logic is contained within newpage.jsx (if there is a brew imported from the share id, pass it in to the page to be displayed, but if not, pass in nothing so we get the same "empty" new page). Do you think you could make that work?

I've commented out the existing /new and changed the new /import to be /new instead. Initial testing shows this is working exactly as per the previous (/new results in a blank new, /new/{shareID} results in a new page loaded with the source from the brew with that shareID.

Alright, this is a good start. Now, ideally, I would like get rid of importpage.jsx and importpage.less altogether so all of this logic is contained within newpage.jsx (if there is a brew imported from the share id, pass it in to the page to be displayed, but if not, pass in nothing so we get the same "empty" new page). Do you think you could make that work?

Actually, that's exactly how this branch is currently working; under the current iteration of the change, newpage.jsx and newpage.less never get called - everything runs through the importpage code.
I've got a bit going on right now but I should be able to push a change to this branch in the next 48 hours where the entire importpage directory has been removed and all of the code references pushed back to newpage.

how this branch is currently working

Or rather, how I think it SHOULD be working. I'm not one to ignore the possibility that I've made a grievous error somewhere, or completely misunderstood how the code actually works.

Good, good. Sorry for my confusion. Yeah, if you can make that change then I'll go ahead and merge it.

Well, it WAS working fine... Something has gone awry after the conflict resolution with master. Chasing it down now...

Got it; it's working now - /new/{shareID} loads the brew source into the text, but /new still gives a blank page as per the current functionality.


Omnibear errors when auth error happens

When trying to sign in with commentpara.de, an error happens - but Omnibear does not say which, because it fails when displaying the error.
On Chromium 72, the error is:

TypeError: Cannot set property 'textContent' of null

at this code:
                case "fetch-token-error":
                    !function(e) {
                        if (t) {
                            var r = document.getElementById("status-heading")
                              , i = document.getElementById("status-paragraph");
                            r.textContent = "Error fetching token from token endpoint",
                            i.textContent = e.message

On Firefox 64 I get this error:

Unchecked lastError value: Error: paragraph is null (authentication.js:25:8)

but without any source locations.
So it seems that the "status-paragraph" is not there anymore on https://omnibear.com/auth/success/ ,  while status-heading still exists.

Omnibear itself removes it in page.js:

// hide paragraph used by old versions of Omnibear

(The underlying error from micropub-helper is "The me values did not match").

Still happens with Chromium 77 and Omnibear 1.2.0


Let plugins add information to the Readme.md

What problem does this feature solve?
Plugins and presets often need to add long-lasting generic information into a project, for example, a preset would add in deployment or configuration details to be done by developers outside of the Vue CLI.
What does the proposed API look like?
api.extendReadme(MarkDownFormattedString)
The readme would then generate a section based on the plugin/preset that inserted the string so that it can be included in the generated readme.md

Running hook after the README.md is generated would give developers more control over the changes. It would be possible to change the file using something like readFileSync.

Any update on this? I wrote a carefully crafted README in my template months ago and only today discovered that it is completely ignored! Or at least overwritten later.
I tried manually writing to it using fs in onCreateComplete() but it didn't take effect like other files that I'm modifying in that hook. I see that it prints out "Generating README.md..." - is there a hook for after that runs?
I have a super hacky workaround but I don't like it:
setTimeout(() => {
  // Update README.md.
}, 10000);

So the current situation is this:
There is a utility function for generating the readme file. It requires the final version of the package.json data in order to inspect what kind of npm scripts there are. Then it looks up the script names in a dictionary of script descriptions to add that information to the readme.
In order for it to pickup on all the scripts defined by the official plugins (e.g. eslint, jest, etc) it is only called after all the generators have been called.
To make the readme editable by other plugins, the creation process would have to be split.

Create a most basic readme file.
Call the generators
Add the script descriptions for official plugins by modifiying the readme.

As a further improvement, the script descriptions should be added directly by the generators of the official plugins. This way any preset and other plugins can override all of the readme content.

Now I'm using this method to solve it.
Writing the following code at API api.onCreateComplete
api.onCreateComplete(() => {
  process.env.VUE_CLI_SKIP_WRITE = true
})

Because the function writeFileTree of generating README.md use VUE_CLI_SKIP_WRITE to judge whether there is a need to do it.


No undo changes after file changes

VSCode Version: 1.38.1
提交: b37e54c98e1a74ba89e03073e5a3761284e3ffb0
date: 2019-09-11T13:35:15.005Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18362
Steps to Reproduce:
1.Change one when no file changes file
2.The file does not undo the change when it appears in change

This is version 1.32 which is fine.
Reinstallation does not take effect.

Does this issue occur when all extensions are disabled?: Yes

Same as #79239


Remove the auto translation disclaimer

Update the docfx.json metadata to remove the auto translation disclaimer.

Docs Build status updates of commit 5365d24:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

DocsLegal/docfx.json
:white_check_mark:Succeeded

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


Frame possible initialization issue

Hello @Paul-Riviere
I've just finalized one of my documentation project (now online at https://llaville.github.io/box-manifest/4.x/), and found a possible frame initialization issue with version 0.10.1
With a fresh web browser cache (without documentation contents), here is what I got when I visit the play terminal sessions part on main page.

To have ability to play movies, I need to click on F5 to refresh page and see the correct frame

I've the same issue : online on GH-Pages and with my local virtual host, and also with mkdocs serve command.
NB: when I test it locally with mkdocs serve -f mkdocks.local.yml, the config file is same as this one (https://github.com/llaville/box-manifest/blob/4.x/mkdocs.yml#L3 except I removed site_url setting).
FYI : all documentation including movies are available on branch 4.x into docs folder of my repo https://github.com/llaville/box-manifest/tree/4.x

https://github.com/llaville/box-manifest/blob/4.x/docs/README.md
https://github.com/llaville/box-manifest/tree/4.x/docs/assets/asciinema

Tested on Firefox version 129

Oh, and I've also noticed that I can't play movie online on GH-Pages, while it's ok locally with mkdocs serve command.

Tested right now with Microsoft Edge (version 127.0.2651.105) and got same behaviour issue

Hello @llaville , first of all thanks for this issue.
I've looked at your repo, and noticed that on the gh-pages your cast files'l links seem to be broken : "assets/asciinema/installation.cast" instead of "4.x/assets/asciinema/installation.cast" on your README.md.
Even if the links are broken, I don't have the same behavior as you have, on Chrome (Version 127.0.6533.120).
On Microsoft Edge (Version 127.0.2651.105) I can't reproduce what you have.
Do you have any errors in the console when you have the issue ? We had surch behavior when the generated documentation didn't load properly Asciinema's js script.
NB: I only tested with the gh-pages and didn't clone your repo for now, please let me know if the probleme persists even if you change the cast link.

Hello @llaville , first of all thanks for this issue.

Hello, and thanks for your reply

I've looked at your repo, and noticed that on the gh-pages your cast files'l links seem to be broken : "assets/asciinema/installation.cast" instead of "4.x/assets/asciinema/installation.cast" on your README.md.

It's not an error.
I want to have a portable documentation, that may be serve by any web host. That's means, it should be displayed (correctly) on GH-Pages but also with mkdocs serve command or any Virtual Host.

Do you have any errors in the console when you have the issue ? We had surch behavior when the generated documentation didn't load properly Asciinema's js script.

After many (commit) tries :

https://github.com/llaville/box-manifest/commit/d5cdca58f5fdb3eb6673c9ff2d1544ab2583d2f4
https://github.com/llaville/box-manifest/commit/1650749c23d6d7489561f4e167b1417d2d4f2575 (the worst approach IMO)

I've applied this one :

https://github.com/llaville/box-manifest/commit/27e414f97ea31ad1f58082501167917cc31075af

It works as expected on all situations : GH-Pages, locally with mkdocs serve and also on my vhost.
Even, if there is an initialization wasm error (see screenshot)

FYI:

When I've tried with commit d5cdca58f5fdb3eb6673c9ff2d1544ab2583d2f4, I've inspected the DOM and get

    window.addEventListener("load", function(event) {
        AsciinemaPlayer.create("/./assets/asciinema/installation.cast", document.getElementById("asciinema-player-0"), {

For me, it should be served as given, that means AsciinemaPlayer.create("./assets/asciinema/installation.cast" (without leading slash)

When I've tried with commit 1650749c23d6d7489561f4e167b1417d2d4f2575, I've inspected the DOM and get

window.addEventListener("load", function(event) {
        AsciinemaPlayer.create("/box-manifest/./assets/asciinema/installation.cast", document.getElementById("asciinema-player-0"), {

Finally, removing site_url mkdocs setting fixe issue.

Works with MS Edge and Firefox !

IMO, we should have the same principle as image serving :
For example:
Portable documentation, is as image serve, with always the same site_url, i.e : https://github.com/llaville/sarif-php-sdk/blob/1.0/mkdocs.yml#L3
The Graph Composer serve at https://llaville.github.io/sarif-php-sdk/1.0/getting-started/, did not require to specify subfolder 1.0
(see https://github.com/llaville/sarif-php-sdk/blob/1.0/docs/getting-started.md?plain=1#L10, and is a relative path to host server)
Same, for a new folder 2.0 https://llaville.github.io/sarif-php-sdk/2.0/
We still keep the same mkdocs setting (site_url) : https://github.com/llaville/sarif-php-sdk/blob/2.0/mkdocs.yml#L3
And with relative path https://github.com/llaville/sarif-php-sdk/blob/2.0/docs/README.md?plain=1#L9
It's serve as expected : https://llaville.github.io/sarif-php-sdk/2.0/

Hello @llaville , I figured out what seems to break your cast files's links.
When you deploy you gh-pages on the gh-pages branch, if you navigate through it on the repo directly, you have a "4.x" folder, and not the code directly. I'm pretty sure that's intended, but this is the code creating this foler : https://github.com/llaville/box-manifest/blob/4.x/.github/workflows/gh-pages.yml#L17C13-L17C33
As your gh-pages branch doesn,t have an index at the root folder, I think that the links generated by mkdocs starts where the index is (when the site_url is defined) so when you define the site_url without the "4.x" this generates links without it, but as you have a "4.x" folder, all links are broken.
What I suggest is :

If you don't need the "4.x" in the url you should remove this folder from the gh-pages workflows and put the files directly on the branch root (see https://github.com/pa-decarvalho/mkdocs-asciinema-player/tree/gh-pages for example)
If you really need the "4.x" in the url :

I think putting this at the end of your site_url isn't that bad, as this variable isn't only a domain, but a full URL. I saw you have a branch per major version, so you could imagine upgrading the URL when changing major version.
The best practice to me, is to put inside your docs folder, folders with version (1.x, 2.x, etc) so you'll have them inside the URL.

Also, if you put the 4.x in your URL the way you're doing it with this subfolder, when you upgrade to the 5.x for example, the links you gave to people, or anywhere, will be broken. If you manage versions directly inside your docs folder, you can easily manage versions, and keep served the documentation of older major releases you have, so that users can access old documentation.
I assume these aren't perfect solutions, but personally I would create a subfolder inside the docs folder, because as you said, removing the site_url is only a workaround that needs to be fixed.
Hope you'll find out how to manage it correctly, let's keep the issue open, in case we have something to do on the plugin repo 🙂

Hello @Paul-Riviere
First, I would like to thanks you to take time to give me a such so long answer. I appreciated a lot, even if I'm not agree with you.
As Mkdocs documentation mentioned it : https://mkdocs.readthedocs.io/en/859/user-guide/configuration/#site_url

This setting is only for canonical URL, used by web crawlers like Google, in SEO context, but IMO it should not break render of a page !
Currently, if I define the site_url in my mkdocs.yml config file like that :
site_url: https://llaville.github.io/box-manifest/4.x

Pages built included, as expected in <head> the :
<link rel="canonical" href="https://llaville.github.io/box-manifest/4.x/">

And on the index.html page generated, we can find such following contents :
<script>
    window.addEventListener("load", function(event) {
        AsciinemaPlayer.create("/box-manifest/4.x/./assets/asciinema/installation.cast", document.getElementById("asciinema-player-0"), {
            cols: 80,
            rows: 24,
            autoPlay: false,
            preload: false,
            loop: false,
            startAt: "0:00",
            speed: 1.0,
            theme: "asciinema",
            fit: "width",
            controls: "auto",
            pauseOnMarkers: false,
            terminalFontSize: "small",
            terminalFontFamily: "",
            terminalLineHeight: 1.33333333,
        });
    });
</script>

But it will probably works only online in GH-Pages context, and not when you test it locally with :  mkdocs serve  or on a virtual host (mine serve pages at my_project dvl to. See following screenshot (error on console)

I suggest to modify your code (https://github.com/pa-decarvalho/mkdocs-asciinema-player/blob/0.10.1/src/mkdocs_asciinema_player/plugin.py#L147) by this line
parsed_json["file_path"] = parsed_json["file"]

Or just used it into your template https://github.com/pa-decarvalho/mkdocs-asciinema-player/blob/0.10.1/src/mkdocs_asciinema_player/templates/asciinema-player.html#L8
If I simulate the FIX, and edit the contents of my index.html and replaces
        AsciinemaPlayer.create("/box-manifest/4.x/./assets/asciinema/installation.cast", document.getElementById("asciinema-player-0"), {

by
        AsciinemaPlayer.create("./assets/asciinema/installation.cast", document.getElementById("asciinema-player-0"), {

My Vhost is able to play the cast file, and the canonical link is present.

To finish, removing site_url is a workaround for me to be able to play cast file in all contexts (without to remember, if I should remove or keep the setting).
Hope you understand my point of view !

FYI, I've just published final version 4.0 of my documentation online on GH-Pages (with site_url defined), and of course in this context, and only this one, it works as expected with your plugin v0.10.1

Hello @llaville,
I wanted to change the functionality of the file variable to allow for a URL.
Example:
{
    "file": "https://raw.githubusercontent.com/pa-decarvalho/mkdocs-asciinema-player/main/docs/assets/asciinema/asciinema_example.cast"
}

Here are the changes made to test it:
plugin.py:
- parsed_json["file_path"] = self.site_url + parsed_json["file"]

asciinema-player.html:
- AsciinemaPlayer.create("{{ file_path }}", document.getElementById("{{ 'asciinema-player-' ~ match_id }}"), {
+ AsciinemaPlayer.create("{{ file }}", document.getElementById("{{ 'asciinema-player-' ~ match_id }}"), {

This works well whether the site_url variable is defined or not. However, the paths no longer work as I wanted. Using site_url allowed me to have a consistent path to the assets that didn't change regardless of the page on the site (which was equivalent to having "site_url" + "file").
So, with this change, on the home page (index.md), this does not cause any issues, but on another page, the path needs to be adjusted.
index.md page:
{
    "file": "assets/asciinema/asciinema_example.cast"
}

themes.md page:
{
    "file": "../assets/asciinema/asciinema_example.cast"
}

For themes.md, ../ is necessary because the URL becomes "https://base_url/themes/".
This remains open for discussion as to whether this behavior is desired or not.
So, I have two suggestions:

Directly insert the file variable into the asciinema-player.html file (which I like less).
Create two variables. Keep the file_path variable as it currently works, and add another variable, perhaps free_path, which would not include the site_url and would also allow for setting a URL.

For the second suggestion, we could ensure that if file_path is defined, then free_path is ignored:
Example of file_path:
{
    "file_path": "assets/asciinema/asciinema_example.cast"
}

Example of free_path:
{
    "free_path": "box-manifest/4.x/assets/asciinema/installation.cast"
}

or
{
    "free_path": "https://raw.githubusercontent.com/pa-decarvalho/mkdocs-asciinema-player/main/docs/assets/asciinema/asciinema_example.cast"
}

I don't like idea to introduce the free_path that won't work as file_path.
Ideally I want to write a Mkdocs Documentation site that may be served in all conditions (on all servers) without to change the contents of *.md pages.
Actually with the mkdocs.yml config file and site_url set to value https://llaville.github.io/box-manifest/4.0
=> See : https://github.com/llaville/box-manifest/blob/4.x/mkdocs.yml#L3
I am able to read asciinema movies :

on  GH Pages : https://llaville.github.io/box-manifest/4.0/
with following command on local

mkdocs serve

INFO    -  Building documentation...
INFO    -  Cleaning site directory
INFO    -  Documentation built in 0.55 seconds
INFO    -  [16:06:23] Watching paths for changes: 'docs', 'mkdocs.yml'
INFO    -  [16:06:23] Serving on http://<IP_ADDRESS>:8000/box-manifest/4.0/

BUT NOT on my local virtual host  http://my_project.dvl.to/ that serve contents built (site/ folder) with command mkdocs build

After all it's not a such IMPORTANT issue, as I am able to see movies on mkdocs serve URL : http://<IP_ADDRESS>:8000/box-manifest/4.0/
I'll stay like this because, as I said, the most important IMO is to have a portable documentation without need to apply some changes.
I'll always have the same canonical URL whatever the host is used : (it's theorical wrong, but I don't have any web crawler that will index my localhost ;-) so it's just a warning !

Hi @llaville ,
Since the current setup works for you and no further changes are necessary, we can proceed to close this issue.
If you ever encounter any issues or need to revisit this topic, feel free to reopen the issue at any time.
Thanks again for your collaboration!


Update match-sql-graph.md

Match is supported in Azure SQL

@grprakash : Thanks for your contribution! The author, @shkale-msft, has been notified to review your proposed change.

Approved. MATCH is supported in Azure SQL Database. Thanks for catching and fixing this!


NameError: name 'TerminalGRU' is not defined

Hi. I am trying to implement your model using the code line as follows:
vae = VAEUtils(directory='C:\Users\Autoencoder\chemical_vae-master\models\zinc_properties')
but however it results in the error:
~\Autoencoder\chemical_vae-master\chemvae\vae_utils.py in init(self, exp_file, encoder_file, decoder_file, directory)
55         # encoder, decoder
56         self.enc = load_encoder(self.params)
---> 57         self.dec = load_decoder(self.params)
58         self.encode, self.decode = self.enc_dec_functions()
59         self.data = None
~\Autoencoder\chemical_vae-master\chemvae\vae_utils.py in load_decoder(params)
21 def load_decoder(params):
22     if params['do_tgru']:
---> 23         return load_model(params['decoder_weights_file'], custom_objects={'TerminalGRU': TerminalGRU})
24     else:
25         return load_model(params['decoder_weights_file'])
NameError: name 'TerminalGRU' is not defined
Could you tell me, what should I do to make it work?

Did you install it via setup.py?
tgru_k2_gpu.py is the file where the TerminalGRU Layer is defined for the decoder model. Check whether vae_utils.py has from tgru_k2_gpu import TerminalGRU in it.

Thank You, it worked when I installed it using setup.py.


Support for rails 7.1

The current gemspec specifies 'rails', '>= 6.0', '< 7.1'.
Rails 7.1 is out as of October 2023; Temporal tables would block users from updating to Rails 7.1.
https://rubyonrails.org/2023/10/11/Rails-7-1-1-has-been-released

@bewatts This is implemented in v3.0.0


JSONObject should support narrowing to [key: number]:JSONValue

Use case
Behind the scenes, javascript converts numeric keys to strings. The pattern object[1234] is valid. However, JSONObject is defined as [key: string]: JSONValue and the result of getMultiple (dynamodb provider) cannot be cast into a type like [key: number] : JSONValue since string cannot be narrowed to number.
The type being used expects it to be a number, because that is how the parameter is accessed.
You can do object[1234] today without this change because TypeScript knows about the behavior of numbers being converted to strings. This is simply about narrowing the type to only allow numbers.
Solution/User Experience
Update JSONObject to the following type: type JSONObject = { [key: string | number]: JSONValue; }
This way a type can narrow JSONObject to [key: number]:JSONValue.
Alternative solutions
No response
Acknowledgment

[X] This feature request meets Powertools for AWS Lambda (TypeScript) Tenets
[ ] Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers
Please react with 👍 and your use case to help us understand customer demand.

I haven't actually had an issue using the Parameters utility, from a functionality standpoint, its working fantastic.
This is entirely a types issue.
The JSONObject is as follows:
type JSONObject = {    [key: string]: JSONValue; } today.
my parameters though are type MyParameters = { [key: number] : ParameterValue; }
When I do a getMultiple for the parameter, the object returned is of type JSONObject. I need to cast this into the type MyParameters. Since my type uses [key: number] (as my keys are always numbers) this causes a typescript error:
Conversion of type 'string | number | boolean | JSONObject | JSONArray' to type 'MyParameters' may be a mistake because neither type sufficiently overlaps with the other.
As soon as I change MyParameters to [key: string] this stops. Basically, my need is that I should be able to narrow the key of the parameter to a number (which JS converts to a string behind the scenes of course). This way type checking will help catch if I were to instead of a number try to get a parameter with a string like stringParameterId.
I'm not a typescript guru though so my supposition on how to correct it may be wrong. I am working around this by casting to unknown first, then MyParameters. But my instincts tell me that some improvements to the JSONObject type could eliminate this need.
This is mostly just a suggestion to investigate an improvement to the typing.

Hey @codyfrisch ,
I have double checked the option to use number as key, and you are correct. We could extend the key with number, so you can catch it for your return value. I have tested this options in multiple e2e tests and it works.

Hi @am29d!
I just stumbled upon this and didn't see anyone assigned so went ahead and made the required update.
Please review/approve and do the needful to merge the following PR into master.
https://github.com/aws-powertools/powertools-lambda-typescript/pull/1715

Hey @codyfrisch ,
I have double checked the option to use number as key, and you are correct. We could extend the key with number, so you can catch it for your return value. I have tested this options in multiple e2e tests and it works.
Also feel free to submit a PR, if you'd like.

Hi @KhurramJalil, thanks for the interest in contributing to the project!
I'll assign the issue to you and change its state to reflect that it's in progress.
This is a relatively small change so there's no issue, however for future reference, in the case of more significant contributions please review the contributing guidelines and make sure the change is discussed before submitting a PR, we would hate it for you to dedicate a lot of time and effort on something, only to be stopped in the review step.
Let's continue the discussion on the PR.


Add broadcast function

Added a Kotlin wrapper for the function to broadcast read-only variables to the cluster. It works just as easily as JavaSparkContext.broadcast()
Created because of issue: https://github.com/JetBrains/kotlin-spark-api/issues/69

Sorry for not looking into this for a long time. Could you please add relevant test? Thank you!


node hangs (FCOS) during cluster deployment and later node reboots

Describe the bug
Today I installed the first OKD 4.7 cluster. I had installed many 4.5 and 4.6 cluster before and also several OCP clusters.
I needed two attempts for the installation and even in the second attempt succeeded only after manual intervention.
My first attempt timed out in the bootstrap process and looking for the reason I found that one of the master nodes somehow hung. It was reachable via IP but I could not ssh into it nor log in via VM console, any login was refused because of "nologin" state. I reset the VM and after booting up, I could ssh into it. However, at this time the cluster bootstrap had already time out.
For the second attempt I started over from scratch (well, initial VM snapshots) and monitored the progess closely. After the FCOS rebase and reboot, once again one of the master nodes (this time a different one) was stuck in "nologin" state and did not progress. So I again reset the VM and after it came up again it was no longer locked and also progressed so the cluster bootstrap finally succeeded.
After the cluster installation was complete (3 workers), I always have a defined automated customization process that includes various items like replacing API and app ingress certificates, configuring LDAP authentication and so on. Some of the steps (like the certificate replacement) cause the machine config operator to update and then reboot all nodes. During such a process, one worker node also hung after rebooting in "nologin" state. It became accessible and progressed only after I again reset this VM.
So I assume, such "nologin" hangs/lockouts of nodes could happen anytime later whenever node reboots are performed.
Of course, I cannot predictably reproduce the problem, given this experience... but the problem appeared way too often.
What log files do you need? Will a must-gather help for this at all?
Version
4.7.0-0.okd-2021-02-25
vSphere UPI
How reproducible
Not explicitly reproducible, but often. See above.
Log bundle
Please advise if this would be helpful.

also several OCP clusters

Is it the same error in OCP?

No. I had done an OCP 4.7 installation a couple of days ago and it went flawlessly.

Please attach log bundle

(I have to find some spare time first ...)

I am having issues with 4.6 and 4.7 the installation just wont finish
If i use 4.5 install completed flawlessly every time

I was able to finally install OKD 4.7 yesterday, and I am wondering if the fedora repos are having some kind of limits on downloading, what I did is a wait 24 hours after my last install and doing that I was able to successfully install 4.7 without intervention

I did another deployment today ... and could not reproduce the problem.
Either I was just lucky or when I installed on Tuesday there was some outage in the quay.io repository services so the deployment hung because of that?
I can do another test tomorrow.

I did yet another deployment today and now have the problem again.
I'll attempt to get the logs now ...
But: I fear we won't get the node log from the one that failed because it does not allow any ssh access which I assume is also needed to gather logs:
"System is booting up. Unprivileged users are not permitted to log in yet. Please come back later. For technical details, see pam_nologin(8)."
Connection closed by <IP_ADDRESS> port 22
Any suggestion what I should do to get more log data?

Unfortunately - no go. The "gather bootstrap" simply hangs and does nothing.
[root@nfs install]# openshift-install gather bootstrap --dir=/opt/install --bootstrap bootstrap.kur-test.ars.de --master master-01.kur-test.ars.de
INFO Pulling debug logs from the bootstrap machine

For over an hour now ... I can access the bootstrap node and two masters via SSH but the failed master would be the interesting one ... :-(

I have reset the hanging worker and got its previous (--boot=-1) journalctl.
It boils down to millions of such lines:
Mar 05 17:24:46 master-03.kur-test.ars.de hyperkube[1132]: E0305 17:24:46.477219    1132 pod_workers.go:191] Error syncing pod 05435c0e-1367-47b6-806b-94fbea96046a ("installer-2-master-03.kur-test.ars.de_openshift-kube-scheduler(05435c0e-1367-47b6-806b-94fbea96046a)"), skipping: network is not ready: runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: No CNI configuration file in /etc/kubernetes/cni/net.d/. Has your network provider started?
So something went wrong there.

journalctl-of-failed-master.zip

I then got the control plane up and running after resetting the master-03. Then got the workers configuring and again one of the three hung. I reset this as well and got it done. Afterwards, I also got the previous boot's journalctl log and found the same error messages in it like for the master above.

I did another deployment test today (with the 03-06 release). This time one master hung in a different way.
I was able to ssh into it but it did not progress. After logging in, I saw:
Last login: Sun Mar  7 07:12:37 2021 from <IP_ADDRESS>
[systemd]
Failed Units: 3
  etc-NetworkManager-system\x2dconnections\x2dmerged.mount
  console-login-helper-messages-gensnippet-os-release.service
  console-login-helper-messages-gensnippet-ssh-keys.service

I rebooted it then it came up without these errors and configured itself successfully.
I have a journalctl output log from the previous boot if you are interested.

On Version 4.7.0-0.okd-2021-02-25-144700 i just update my ntp servers all nodes get rebooted and master-1 is just stuck there with no ip, i have try 20 different things reset restart power off , snapshot, power off, nothing works and cluster is unusable because of this this dhcp thing is really bad

On Version 4.7.0-0.okd-2021-02-25-144700 i just update my ntp servers all nodes get rebooted and master-1 is just stuck there with no ip, i have try 20 different things reset restart power off , snapshot, power off, nothing works and cluster is unusable because of this this dhcp thing is really bad

@bobby0724 your issue sounds like something very different than what I reported here. I suggest you open a separate issue.

For over an hour now ... I can access the bootstrap node and two masters via SSH but the failed master would be the interesting one ... :-(

Does
--bootstrap <bootstrap_address> \
    --master <master_1_address> \

make any difference here?

But that's what I did? Pass it the address the of the bootstrap node and of one of the master nodes.

I can access the bootstrap node and two masters

Was it one of the masters you can reach via ssh? Also, make sure your install has 3 masters (it won't work with 2 masters)

Yes, the master I tried was one of the two working masters. I wanted to try this first as I suspect that the log gathering will not work to/from the hanging master anyway. Sure I have three masters.
Did you see my message from yesterday with the case where I was able to access the master but it was still stuck and had the three failed systemd units? I captured its journal log. It may give us a hint what's happening.
logs20210307.zip

it was still stuck and had the three failed systemd units?

This doesn't tell me anything without knowing general info

Ok, but what can we do? Any suggestion?
Then I can try another deployment and see what I can get.
But when "gather bootstrap" does not work generally, I see no other option?

https://docs.okd.io/latest/installing/installing-troubleshooting.html#installation-manually-gathering-logs-with-SSH_installing-troubleshooting

Yes, I know this page. While I can use this for getting the data from the bootstrap host and annother (accessible) master node I cannot do this directly on the hanging master host because I can not SSH into it. All I can do is reset that VM and when I am able to access it again, I can pick up the previous boot's journalctl log. Would that help?

Yes, I know this page.

Would you mind providing this information then?

I can not SSH into it.

MCS logs from bootstrap would tell us if it has requested an ignition or its just stuck there

I'll start a new deployment tonight or tomorrow and then try to get what is possible then.
The cluster I was referring in my previous messages from the weekend is already gone by now (24 hour limit).
When I encountered such a stuck master node, it was already beyond the ignition. The node did definitely boot and get the ignition. Then it was stuck after the reboot following the FCOS rebase (I mentioned this in my opening description).
Also, I had the same problem even much later with some arbitrary nodes (workers) after full and successful installation, on some subsequent reboot.

@kai-uwe-rommel:
I had huge problems on vSphere with promiscuous mode turned on with OVNKubernetes since OKD 4.6. The NetworkManager seems to be not happy with that.
Maybe it's simpler, if we try to look in your setup in a live debug session?
<EMAIL_ADDRESS>

Yes, we can do so! I have a test environment where I can quickly start deployment of a new cluster where we hopefully can see the problem at the first attempt.
I'll send you an e-mail message.

During a debug session I had with @jomeier yesterday, we've seen the problem twice.
Interestingly, once it was already before the actual OKD deployment (e.g. rpm-ostree rebase) of the node.
So it is probably a problem of th FCOS release.
But since it also happens after the OKD stream for FCOS is installed, it seems to be a more generic problem, not that of a single release.
Any idea how we could tackle this?
I'm attaching a journalctl of such a case. I can see in there that an SSH login for "core" is denied but not why ...
Also, lots of networking errors.
journalctl-no-login.txt.gz

This happens also on vSphere IPI, either during installation, or even after the cluster is deployed. If a node (e.g. master1, worker nodes too) is being rebooted, half of the time it will not manage to get an IP address from the DHCP server. tcpdump shows DHCP server process and reply to the discover request, and assigning IP.
My workaround is to simply "reset" or reboot the node until I can ping it. Then everything goes back to normal.

@lvlts, I don't think you see the problem that I described in this issue. In my case, the nodes are either getting DHCP leases perfectly or are even configured with static IP addresses.
The symptom of my issue is that the node is booting up, gets its correct IP address (either DHCP reservation or static configuration), is pingable and I can connect to it via SSH (e.g. sshd is running and answering) but I cannot log in but are greeted with this message:
"System is booting up. Unprivileged users are not permitted to log in yet. Please come back later. For technical details, see pam_nologin(8)."
and then my ssh session is dropped.
Also if the node is still in the deployment process, it will not progress. So more thing inside it don't work but I cannot check because I cannot ssh into it.

@kai-uwe-rommel  @lvlts
Could you try this:
In my setup this seems to solve the problem:
 # sudo vi /etc/systemd/network/98-ovs-mac.link
 [Match]
 Driver=openvswitch

 [Link]
 MACAddressPolicy=none

https://bugzilla.redhat.com/show_bug.cgi?id=1936961

@jomeier we should make sure we don't mix issues. I don't see any DHCP problems and have such "hanging nodes" even when statically configuring IP addresses. Whenever I see the problem, the nodes have perfect network connectivity. To me it looks like systemd does not progress starting up the system so it never reaches "multiuser" state. Unfortunately, since I can't get into such a system yet, I don't know where exactly it hangs. I can only reboot and then it usually works (I had only one case so far where I had this twice in a row).

I just tried and it is possible to set a root password in FCOS and log in with it on the console. I'll try to get a root password into my ignition setup so that I can try to debug when the problem happens the next time.

As discussed in slack, hopefully
https://origin-release.apps.ci.l2s4.p1.openshiftapps.com/releasestream/4.7.0-0.okd/release/4.7.0-0.okd-2021-03-22-172926
and later have the fix for this

I did an installation with this release yesterday and had no hangs.
Usually, I have at least one such hang during each cluster installation.
But occassionally I got through an installation also without one.
So it may bee too early to definitely declare this as solved but probability is quite high. :-)

I'd say this is solved.


Issue#336 - Remove deprecated AbstractKafkaAvroSerDeConfig usage

Removed AbstractKafkaAvroSerDeConfig usage
Removed unused imports.

Local tested with regular mvn lifecycle: compile and test
#336

It looks like @saurabh-slacklife hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement here.
Once you've signed reply with [clabot:check] to prove it.
Appreciation of efforts,
clabot

[clabot:check]

@confluentinc It looks like @saurabh-slacklife just signed our Contributor License Agreement. :+1:
Always at your service,
clabot

Thanks for the PR. I think we also need to update

GenericAvroScalaIntegrationTest.scala
SpecificAvroScalaIntegrationTest.scala

Thanks for the PR. I think we also need to update

GenericAvroScalaIntegrationTest.scala
SpecificAvroScalaIntegrationTest.scala

@mjsax It's updated with scala changes.


[QUESTION] Issue with cjs file

Question
How can we help you?
I am struggling with this error when trying to run the tests for my code using the library
/home/petter/Tendium/odin-platinum-auth/node_modules/aws-jwt-verify/dist/cjs/jwt-rsa.js:322
        return new this(verifyProperties, additionalProperties?.jwksCache);
                                                               ^

SyntaxError: Unexpected token '.'

Library usage:

let cognitoJwtVerifier: CognitoJwtVerifierSingleUserPool<{
  clientId: string;
  tokenUse: "id" | "access" | null;
  userPoolId: string;
}>;
// Verifier that expects valid access tokens:
cognitoJwtVerifier = CognitoJwtVerifier.create({
  userPoolId: process.env.USER_POOL_ID,
  tokenUse: "access",
  clientId: process.env.CLIENT_ID,
});

{...}
decodedToken = await cognitoJwtVerifier.verify(activeToken);

Versions
Which version of aws-jwt-verify are you using? 3.4.0
Version: Node 16.17.0
npm: 8.15.0
"typescript": "^4.9.5"

That's optional chaining you seem to be stumbling over, which has been supported by NodeJS since v14. Are you sure you're running it in NodeJS 16 ...?
Your code looks good otherwise.

>> node --version
v16.17.0`
>> npm run test

><EMAIL_ADDRESS>test
> mocha -r ts-node/register tests/**/*.test.ts --exit

/home/petter/Tendium/odin-platinum-auth/node_modules/aws-jwt-verify/dist/cjs/jwt-rsa.js:322
        return new this(verifyProperties, additionalProperties?.jwksCache);
                                                               ^

SyntaxError: Unexpected token '.'
    at Object.compileFunction (vm.js:344:18)
    at wrapSafe (internal/modules/cjs/loader.js:1048:15)
    at Module._compile (internal/modules/cjs/loader.js:1082:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1138:10)
    at Module.load (internal/modules/cjs/loader.js:982:32)
    at Function.Module._load (internal/modules/cjs/loader.js:875:14)

I feel stupid but can't understand why it would have an issue with optional chaining :/ Used a lot in other parts of the code, so it's just when using the dist/cjs/ js file that causes issues

What ts-node version is that? And share your tsconfig.json?

{
  "compilerOptions": {
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "outDir": "dist",
    "noImplicitAny": true,
    "module": "commonjs",
    "target": "es2018",
    "declaration": true,
    "typeRoots": [
      "./node_modules/@types"
    ]
  },
  "include": [
    "./src/**/*"
  ]
 }

I tried `updating ts-node version now so tested it with 10.9.1 but still same issue :/
Dependencies and devdependencies:
"dependencies: {
   "aws-jwt-verify": "^3.4.0",
   "aws-sdk": "^2.804.0",
   "axios": "^0.19.2",
   "dotenv": "^8.2.0",
   "jsonwebtoken": "^8.5.1"
 },
 "devDependencies": {
   "@types/axios": "^0.14.0",
   "@types/chai": "^4.2.14",
   "@types/jsonwebtoken": "^9.0.1",
   "@types/mocha": "^5.2.7",
   "@types/npm": "^2.0.31",
   "@types/rewire": "^2.5.28",
   "@typescript-eslint/eslint-plugin": "^2.34.0",
   "@typescript-eslint/parser": "^2.34.0",
   "chai": "^4.2.0",
   "eslint": "^6.8.0",
   "mocha": "^10.2.0",
   "ncp": "^2.0.0",
   "node": "^13.14.0",
   "nyc": "^15.1.0",
   "rewire": "^4.0.1",
   "ts-node": "^10.9.1",
   "typescript": "^4.9.5"`

target es2018 might be it, try at least es2020

Tested with both es2020 and es2022, neither worked :/ Thanks for help but very confusing :(

Alas! Indeed very confusing.  Please create a reproducible  case for us. Ideally a GitHub repo with the minimum amount of code necessary to reproduce this.

Btw why also a dependency on jsonwebtoken? Because you're not getting aws-jwt-verify to work?

I will aim to to setup a reproducible state ASAP, but not fully able to prioritize it right now.
yes, dependency on jsonwebtoken is because I haven't been able to get it to work yet with the library.

Lol didn't know you could depend on node
Great it's solved now !


Add python package releases into CI

python -m build && python -m twine upload dist/*

More details?

We should add a stage into the CI flow to build and release the couchers python package into pypi.

Not needed anymore as we have the admin console


Add workflow to test Firedrake installation

Closes #75

This seems to work now. I temporarily made it follow the current state of #68 (has to be changed before the fix-mpi-install branch gets merged)
The CI on the second-to-last commit (https://github.com/mesh-adaptation/docs/actions/runs/12270023719/job/34234573494) installed Firedrake successfully and ran tests: Animate passed, Goalie hit the cache errors of https://github.com/mesh-adaptation/goalie/issues/252, and Movement tests were not run because the Goalie ones failed. So in the last commit I changed it so that tests are run even if previous ones fail (https://github.com/mesh-adaptation/docs/pull/77/commits/0aee9a155e0d0a2f42ac5cb0233e9bf152d1f884) but I cancelled the CI.

This seems to work now. I temporarily made it follow the current state of #68 (has to be changed before the fix-mpi-install branch gets merged)

Yeah, I'd like to merge main into #68 once this has been merged to actually test the changes.

The CI on the second-to-last commit (https://github.com/mesh-adaptation/docs/actions/runs/12270023719/job/34234573494) installed Firedrake successfully and ran tests: Animate passed, Goalie hit the cache errors of mesh-adaptation/goalie#252, and Movement tests were not run because the Goalie ones failed. So in the last commit I changed it so that tests are run even if previous ones fail (0aee9a1) but I cancelled the CI.

Okay cool.

This seems to work now. I temporarily made it follow the current state of #68 (has to be changed before the fix-mpi-install branch gets merged)

Yeah, I'd like to merge main into #68 once this has been merged to actually test the changes.

Not sure if you saw it, but I actually set the target branch of this PR to fix-mpi-install for this reason :)

I re-triggered the CI job that you cancelled so we can check the firedrake-install.log gets uploaded properly. But otherwise this is good to go, thanks!

It looks like the yes | was necessary! I'll let the CI complete now :)

Looks perfect so I'll merge


Add local launch scripts to deb

Make it easier to launch simulation processes by providing helper scripts that source the right environment and run the right commands, including:

launch_gazebo (source env and roslaunch)
launch_arbiter
launch_game_director

These exist now: gdi_env.sh fti_env.sh swarm_commander_env.sh  sasc_gazebo_env.sh
The only thing left is to update the documentation.


Performance enhancement: Update pipelineloop to use informer instead of lister for updating pipeline status.

Original issue: https://github.com/kubeflow/kfp-tekton/issues/1357
Note:
This is a reference issue for internal tracking purposes, please forward all discussion to the actual upstream issue.
When assigning this, please confirm this is already not in progress upstream.

Migrated to Jira: https://issues.redhat.com/browse/RHOAIENG-1617


More ways to answer calls in GTK+

This adds support for old versions of glib that don't have have GNotification (#65), by using libnotify as a fallback. However, libnotify notifications can't have buttons and so can't be used for accepting and rejecting incoming calls. So a new submenu is added here for each current incoming call, so that the user can accept or reject a call using the menu instead of by using the notification.

looks good!
tested on Debian 7.8 and Testing
                  libgtk2.0    libglib2.0     libnotify

Debian 5.0        2.12.12      2.16.6         0.4.4

Debian 7.8        2.24.10-2    2.33.12        0.7.5

Debian Testing    2.24.28      2.44.1         0.7.6-2


Is "docs.rs is managed by the members of the Core team" accurate?

In https://github.com/rust-lang/foundation.rust-lang.org/blob/c7ccdb7db0efc81c7706457400f56396dd3917a0/policies/privacy-policy.md#docsrs the website says

Docs.rs is managed by the members of the Core team and the Dev Tools docs.rs sub-team.

Is that accurate? I think some members of the infra team have access to the production server, but I don't think all of the core team does, and neither team is involved in day-to-day operations.

I discussed this in private with a member of the core team and I'm happy with their answer.


fix(colorhandle): updates animation

Description

Addresses CSS-559 and SWC issue 3443 which reported issues with the animation to the focused state for the ColorHandle.
Switching from tageting individual properties to all addressed fixed the animation issue
How and where has this been tested?
Please tag yourself on the tests you've marked complete to confirm the tests have been run by someone other than the author.

Regression testing
Validate:

A legacy documentation page (such as accordion), including:

[ ] The page renders correctly
[ ] The page is accessible
[ ] The page is responsive

A migrated documentation page (such as action group), including:

[ ] The page renders correctly
[ ] The page is accessible
[ ] The page is responsive

Screenshots

Chrome (114.0.5735.198)

Firefox(115.0.2)

Safari(16.5.2)

To-do list

[x] I have read the contribution guidelines.

[x] I have updated relevant storybook stories and templates.

[x] I have tested these changes in Windows High Contrast mode.

[x] If my change impacts other components, I have tested to make sure they don't break.

[x] If my change impacts documentation, I have updated the documentation accordingly.

[ ] ✨ This pull request is ready to merge. ✨

@jenndiaz Can you share more about the decision to replace the individual properties with all? How does this address the concern Westbrook raised about performance? Size & position transitions are high-cost as they cause repaint and I'm not sure how this might mitigate that. Could you do me 2 favors:

Would you please add an interaction test for this animation so we can prevent any possible regressions in this animation in future?
The interaction test above should automatically come with a profiling of the action. If that information is not there or not helpful, would you please leverage the profiling tools in WebKit to confirm the delta from the previous to this new method?

@jenndiaz Oh and just for reference, I was reading through this article to confirm my understanding - https://codeburst.io/low-performance-css-transitions-and-some-alternatives-f84ff35bf07 - we could try replacing this with a scale transform instead which could be a more performant option.

@jenndiaz Oh and just for reference, I was reading through this article to confirm my understanding - https://codeburst.io/low-performance-css-transitions-and-some-alternatives-f84ff35bf07 - we could try replacing this with a scale transform instead which could be a more performant option.

@castastrophe The designs for the focus state of the ColorHandle specify that the width and height increases but the border size(s) remaining the same. With the scale the border size increases. This was the main reason I did not go with scale.
Here is the good example from the article with a border added: https://codepen.io/jenndiaz/pen/abQRpQY This displays the border increase which would be a design change in this case.
transition: all 130ms ease-in-out addressed the safari issue. we could remove all since it is the default but I think it's helpful it is there in the case we change the styling of the ColorHandle in the future.
I also put together a code pen displaying the animation using scale, using scale and transition, and as it is now transition with the width and height. The version with out the transition is not quite as smooth as the one with.
https://codepen.io/jenndiaz/pen/QWJxZBj/3111a4c271dbaa21b585eebb016aa902?editors=1100
As for the storybook testing, I can look closer at this, I know Megan is already working on adding the integration testing with #1993.

@pfulton I would love to add a backlog story though to evaluate more performant ways to approach animations for CSS though in conjunction with designers.


Add experimental docs

This PR adds a docs directory and an experimental single page docs version of the k8s-master docs. This is mainly so I can proceed with developing the scripts to sync back and forth with discourse, and work out which bits will need to be rewritten.

@evilnick this looks good as a start. I'm a bit horrified by the mix of HTML in markdown but it's a start :)

The HTML is the only way, currently, we can make the tables work for the Config options. The templates there will need to be rewritten anyhow as the docs pages render in a different way from discourse, sadly. So, don't be too worried about the content anyhow.
Oh, and all the HTML is autogenerated by the scripts - no need for people to edit/write manually or even touch those sections ;)


migration of ingress do not work

Promising tool for migration did not work on my ingresses. So, there we have a k8s distribution, where the previously used traefik 1.7~ version should be migrated.
docker run --rm -v ${PWD}:/data containous/traefik-migration-tool ingress --input /data/in --output /data/out

Produces output, that is identically to input:
apiVersion: v1
items:
- apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    annotations:
      ingress.kubernetes.io/auth-secret: basic-auth-document-db
      ingress.kubernetes.io/auth-type: basic
      ingress.kubernetes.io/custom-request-headers: XYZ-My-Custom-Header:dev
      kubernetes.io/ingress.class: traefik
    creationTimestamp: "2018-02-27T10:03:59Z"
    generation: 9
    name: dev-protected
    namespace: dev
    resourceVersion: "277178439"
    selfLink: /apis/extensions/v1beta1/namespaces/dev/ingresses/dev-protected
    uid: 87d8d657-1ba5-11e8-a9cd-06fa2d724cac
  spec:
    rules:
    - host: svc.test.migrate.traefik.to.v2.com
      http:
        paths:
        - backend:
            serviceName: v2
            servicePort: 80

What could be the trick?

hello,
It's related to items, currently the migration tool don't support that.
If you extract you ingress into files with the following format, the migration will work.
apiVersion: extensions/v1beta1
kind: Ingress

#...

When I try to use your file, I have an error:
error while decoding YAML object. Err was: Object 'Kind' is missing in 'apiVersion: v1
...

Fixed by a41334769ee0776dcf90730e35071a20933ef146


Support multi instance

Checklist

[x] npm test passes
[x] tests and/or benchmarks are included
[ ] documentation is changed or added
[x] commit message follows commit guidelines

Affected core subsystem(s)

Description of change

@zcong1993 npm的owner也加我一下一下把，我的id: ngot 我来迁移到官方group维护起来

@ngot 加了


[Suggestion] to have a dedicated delay per channel

Laravel Version: 5.4.x
PHP Version: 7.1
Database Driver & Version: MySql

Description:
There is no way for us to make a delay for specific channel, Upon checking NotificationSender, based on my understanding, the loop call under L51 only uses the direct value of notification delay.
We have the sendNow() which only possible to inject channels in real time sending, however on send() we don't have the option to inject, so an option would probably help to, or check out my suggestion below.
Suggestion:
Allow the property $delay to be an array, if it's an array, we will map the channel based on value.
public $delay = [
    'push_notification' => Carbon...,
    'email' => Carbon...,
    'database' => Carbon...,
];

Since we can't inject carbon directly under the property, a dev can inject the call thru the constructor instead, which is a good work around.
On NotificationSender, the mapping will be based on the key channel, if the key doesn't exists, the default value will always be 0.
In reality, we want to limit sending of push notifications when it's evening.

Another option is to have a method call {$channel}Delay() if exists then we will use that, else we will use 0, so each notifications we can set the delay per channel too.

This is not a bug. You can open a proposal in the laravel/internals repo

Yeah you are correct @Dylan-DPC


Creating a new repo to automate E2E tests on live network

This task doesn't imply codebase changes but is about creating a new repo that could be utilized to automate E2E test on live network (Athens3, mainnet) using the zetae2e tooling. Name of the repo could be e2e-ops for example.
This repo would include actions that allows to run specific tests on a specific network.
Depends on:

https://github.com/zeta-chain/node/issues/1651
Have a Bitcoin node ready with a hot wallet
Adding better docs for zetae2e to describe how to run tests on a specific network

Tracked in DevOps project board


chore: zeebe-operator to 0.0.70

chore: Promote zeebe-operator to version 0.0.70

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


pythonPackages.anonip: init at 1.0.0

Motivation for this change
init at 1.0.0, fixes #64573.
Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

@GrahamcOfBorg build python3Packages.anonip

Can we maybe also run the unit tests https://github.com/DigitaleGesellschaft/Anonip/blob/master/tests.py ?

Can we maybe also run the unit tests https://github.com/DigitaleGesellschaft/Anonip/blob/master/tests.py ?

Done, I'm now building it from GitHub as the tests are not in pypi. Rebased.

Can we maybe also run the unit tests https://github.com/DigitaleGesellschaft/Anonip/blob/master/tests.py ?

Done, I'm now building it from GitHub as the tests are not in pypi. Rebased.

Lol, no tests in tarball and it's like one file. Looking now.