Cobertura Support

The PublishTestResults task says it "supports popular coverage result formats such as Cobertura and JaCoCo" but these are not one of the allowed inputs for testResultsFormat

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

ID: ba91e46a-de53-c0c1-f7f7-c02e797d527c
Version Independent ID: 6f478148-461f-694a-ed82-deb4d731854e
Content: Publish Test Results task - Azure Pipelines
Content Source: docs/pipelines/tasks/test/publish-test-results.md
Product: devops
Technology: devops-cicd-tasks
GitHub Login: @PBoraMSFT
Microsoft Alias: pbora

@winstonhenke Thank you for the feedback.
The documentation has been updated and is now pending review.
For open tickets on adding this support, please see here and here to solicit feedback from the product team.
.


N17: openEtG

For #408 :+1:

^ @serprex fyi

^ @serprex fyi

Merged, thanks for the PR!

Merged, thanks for the PR!


Ability to start a new RUM session within a kiosk app

When developing kiosk apps, where a single device is used, often anonymously, by many people over time, it would be useful to be able to manually force the start of a new RUM session, even though the app itself is not restarting.

This is currently a limitation on the native side I believe, but potentially solvable soon with some native changes that are in the pipe.

This is now available in 1.4.0


Create Sonar code quality scans for release branches

When a release is shipped, a consuming organisation may wish to refer to the code quality metrics for that release.
Currently we execute our Sonar scans (which also incorporate pmd and findbugs/findsecbug reports) on master after every merge.
We can also ensure we scan branches, which would then allow an organisation to refer to the results for the specific release they are using easily.
Sonarcloud appears to keep reports for at least 6 months
An alternative would be to manually run and attach as a pdf to the release on GitHub, however

requires manual effort
error-prone

Therefore we should document in a simple clear readme in the source and/or linked within the release notes
cc: @cong78

I think this is unnecessary. We'll focus on keeping master clean. An org can setup sonarcloud to scan any code/release they wish. I don't think we have enough resources to be able to focus across all releases


resolve Rhea mapping for 'beta-ketoacyl-acyl-carrier-protein synthase II activity' GO:0033817

(9Z)-hexadecenoyl-[ACP] + H(+) + malonyl-[ACP] = 3-oxo-(11Z)-octadecenoyl-[ACP] + CO2 + holo-[ACP] EquivalentTo EC:<IP_ADDRESS>	(most probable)	0.75
(9Z)-hexadecenoyl-[ACP] + H(+) + malonyl-[ACP] => 3-oxo-(11Z)-octadecenoyl-[ACP] + CO2 + holo-[ACP] EquivalentTo METACYC:<IP_ADDRESS>-RXN	(most probable)	0.75
beta-ketoacyl-acyl-carrier-protein synthase II activity EquivalentTo EC:<IP_ADDRESS>	(most probable)	0.8
beta-ketoacyl-acyl-carrier-protein synthase II activity ProperSubClassOf (11Z)-hexadecenoyl-[ACP] + H(+) + malonyl-[ACP] = 3-oxo-(13Z)-octadecenoyl-[ACP] + CO2 + holo-[ACP]		0.15
beta-ketoacyl-acyl-carrier-protein synthase II activity EquivalentTo METACYC:<IP_ADDRESS>-RXN	(most probable)	0.8

Looks like the reaction represented by GO:0033817 is currently mapped RHEA:14565, mapped to 'GO:0033817 beta-ketoacyl-acyl-carrier-protein synthase II activity', is a specific form RHEA:22836 (a fatty acyl-[ACP] + H+ + malonyl-[ACP] = a 3-oxoacyl-[ACP] + CO2 + holo-[ACP])
which corresponds to

EC <IP_ADDRESS> 	Beta-ketoacyl-[acyl-carrier-protein] synthase I
GO:0004315  3-oxoacyl-[acyl-carrier-protein] synthase activity

Since there is a single gene annotated, UniProtKB:P0AAI5, which is also mapped to the parent RHEA, I will merge GO:0033817 into GO:0004315  3-oxoacyl-[acyl-carrier-protein] synthase activity.
Pascale

Actually- the mapping to EC:<IP_ADDRESS> to GO:0033817 was wrong; already mapped to GO:0008925. So I will remove all references to EC:<IP_ADDRESS> from GO:0033817.


eventstore: update to 21.10.5, refactor to use buildDotnetModule

Description of changes
Refactor to use buildDotnetModule, also try to remove usages of dotnet 5.
Helps fix #146257 and #173115

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

This is a WIP, I'm currently a bit stuck on the Grpc.Tools nuget, which tries to execute a native binary at build time.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/961


Fix Lua Minor Crash + Fix Errors Not Showing Up

same pr as this one but modified a lil bit
https://github.com/ShadowMario/FNF-PsychEngine/pull/10091
this pr fixes the crashes when it passes around 2-4 minutes hopefully
havent fully tested it, dont merge yet

This PR was a life saver, Byte Funkin' suffered major crashes at launch and it chalked up to this exact lua leak, meaning that lua mods are pretty much unviable without this PR or a bandaid frame cap script. Should be pulled ASAP.


Restructure Worker Pod secrets' volumes' names

Since the name of the volumes and volume mounts that are configured for service-account pull-secrets are constructed from "pull-secret" and the actual pull-secret name, then it can result in names being more then 63 chars which will cause an error. This comment move the volumes names to be "pull-secret-hash(pull-secret-name)"

/lgtm


Permanent custom cloud-config during install

Currently the installation process copies over the squashfs content, we should provide a way to persist also a custom cloud-config during install.

[x] Modify the installer to accept a custom cloud-config
[x] Copy the cloud-config over the persistent partition
[x] QA

Needs #5

The mechanism seems to work. There is another issue which is not related - seems bootup fails with multiple cloud-init files. Currently investigating

Additional yaml file which gets copied to /oem can be given with the --config flag to the installer


Exception raised importing from snorkel.parser

Hi,
I get the following exception when trying to import from snorkel.parser:

from snorkel.parser import *
Traceback (most recent call last):
File "", line 1, in
File "snorkel/parser/init.py", line 5, in
from .spacy_parser import *
File "snorkel/parser/spacy_parser.py", line 11, in
raise Exception("spaCy not installed. Use pip install spacy.")
Exception: spaCy not installed. Use pip install spacy.

I believe the exception is being raised because of line 9 in the spacy_parser.py module:
try:
6     import spacy
7     from spacy.cli import download
8     from spacy import util
9     from spacy.deprecated import resolve_model_name
10 except:
11     raise Exception("spaCy not installed. Use pip install spacy.")
I currently have spaCy 2.0.2 installed and it does not have the spacy.deprecated module. Does snorkel depend on an older version of spaCy? If so, what version?
Note I had to install spaCy via conda since the recommended pip install --requirement python-package-requirement.txt failed to install spaCy for me.
Thank you.

Downgrading to spacy==1.10.0 should resolve the errors. Spacyv2.0 seems to have some major differences that are breaking snorkel at time of this writing.

Should be fixed by downgrading spacy as @piordanov says, fixed in PR #834


VariantRDD doesn't save partition map

@devin-petersohn I noticed that VariantRDD doesn't call AvroGenomicRDD.savePartitionMap in saveMetadata.
https://github.com/bigdatagenomics/adam/blob/master/adam-core/src/main/scala/org/bdgenomics/adam/rdd/variant/VariantRDD.scala#L182
Was this omission intentional?

No this was not intended, but I believe @fnothaft has a better way to handle the optPartitionMap in #1590.


Continuous legend

For numeric variables with many categories.
See suggestions here: https://stackoverflow.com/questions/13355176/gradient-legend-in-base

I was playing around with some ideas over the weekend and I think it's possible to a hack this approach in way that (a) integrates with the existing plot2::draw_legend() logic and (b) looks pretty reasonable.
Proof of concept:
library(plot2)

# some "global" params and palette options for this MWE

ncolors = 101L
nlabs = 5L
collab = "Sepal.Length"

pal = hcl.colors(ncolors, "inferno")
palramp = colorRampPalette(pal)

colvar = iris[[collab]]

# colors for the actual plot points

cols = palramp(length(colvar))
## NB: we reorder now so we can assign colors as part of the points()
## call later on. (Saves having to split by a continuous variable.)
colord = findInterval(colvar, sort(colvar))
cols = cols[colord]

# legend color ramp

## subset to the pretty labels for the legend
pcolvar = sort(pretty(colvar, n = nlabs), decreasing = TRUE)
# pcolvar = pcolvar[pcolvar >= min(colvar) & pcolvar <= max(pcolvar)]
colvar2 = unique(c(colvar, pcolvar))
lcolord = findInterval(pcolvar, sort(colvar2))
cols2 = palramp(length(colvar2))
lcols = cols2[lcolord]
lcols_all = colorRampPalette(lcols)(ncolors)

# legend labels

lgd = rep(NA, times = ncolors)
## match the legend labels to their position in the colorbar
pidx = na.omit(match(lcols, lcols_all))
if (!is.null(attr(pidx, "na.action"))) {
    lgd[as.integer(pidx)] = pcolvar[-attr(pidx, "na.action")]
} else {
    lgd[pidx] = pcolvar
}
## Add "padding" on either side, otherwise the y.intersp adjustment
## (see below) will cause the labels to look funny
lgd = c(NA, lgd, NA)
lcols_all = c(NA, lcols_all, NA)

# draw the legend using our bespoke colour ramp and labels

## first adjust vertical legend spacing (to compress as if there were only 'nlabs'
## discrete colour boxes to draw)
intersp_adj = rep(1/ncolors*length(pcolvar), times = ncolors)
intersp_adj[1] = 1

## now draw the legend
draw_legend(
    legend = "right!",
    lgnd_labs = lgd,
    legend.args = list(
        title = collab,
        bty = "o",
        y.intersp = intersp_adj,
        pt.cex = 3.5
    ),
    type = "p",
    pch = 22,
    col = NA,
    bg = lcols_all
)

# Manually add the points and other plot region elements
# (mostly to give an idea of what the end plot will look like)

plot.window(xlim = range(iris$Petal.Length), ylim = range(iris$Sepal.Length))
axis(1); axis(2); grid()
title(xlab = "Petal.Length", ylab = "Sepal.Length", main = "Continuous legend")
points(
    x = iris$Petal.Length, y = iris$Sepal.Length,
    pch = 19,
    col = cols
)

Created on 2024-01-29 with reprex v2.1.0

Better version that uses a rescaling function to get the colour mapping right. (Helps to avoid finicky label matching code too.)
library(plot2)

# rescaling function
rescale_func = function (x, from = NULL, to = NULL) {
    if (is.null(from)) from = range(x)
    if (is.null(to)) to = c(1, 100)
    (x - from[1])/diff(from) * diff(to) + to[1]
}

# data and input columns

dataset = iris
xlab = "Petal.Length"
ylab = "Sepal.Length"
collab = "Sepal.Length"

xvar = dataset[[xlab]]
yvar = dataset[[ylab]]
colvar = dataset[[collab]]

# color palette choices and funcs

ncolors = 100L
nlabs = 5L
pal = hcl.colors(ncolors, "inferno", alpha = 1)
palramp = colorRampPalette(pal, alpha = TRUE)

# generate 'ncolors' (here: 100) distinct color categories for the plot
cols = palramp(ncolors)

# legend color ramp

## Identify the pretty break points for our labels
ucolvar = unique(colvar)
colvar_range = range(ucolvar)
pcolvar = pretty(colvar_range, n = nlabs)
pcolvar = pcolvar[pcolvar >= colvar_range[1] & pcolvar <= colvar_range[2]]
# if (length(pcolvar)>nlabs) pcolvar = pcolvar[-1] # optional
# optional thinning
if (length(ucolvar)==2 && all(ucolvar %in% pcolvar)) {
    pcolvar = ucolvar
} else if (length(pcolvar)>nlabs) {
    pcolvar = pcolvar[seq_along(pcolvar) %% 2 == 0]
}

## Find the (approximate) location of our pretty labels
pidx = rescale_func(c(colvar_range, pcolvar), to = c(1, ncolors))[-c(1:2)]
pidx = round(pidx)
lgd_labs = rep(NA, times = length(cols))
lgd_labs[pidx] = pcolvar
# We have to reverse the order since the legends are in decreasing sequence
lgd_labs = rev(lgd_labs)
lgd_cols = rev(cols)

# Add "padding" on either side, otherwise the y.intersp adjustment
# below will cause the labels to look funny
lgd_labs = c(NA, lgd_labs, NA)
lgd_cols = c(NA, lgd_cols, NA)

## draw the legend using our bespoke color ramp and pretty labels

intersp_adj = rep(1 / ncolors * nlabs, times = length(lgd_cols))
intersp_adj[1] = 1
intersp_adj[length(intersp_adj)] = 1
draw_legend(
    legend = "right!",
    lgnd_labs = lgd_labs,
    legend.args = list(
        title = collab,
        # bty = "o",
        y.intersp = intersp_adj,
        adj = c(0,0),
        pt.cex = 3.5
    ),
    type = "p",
    pch = 22,
    col = NA,
    bg = lgd_cols
)

# Manually add the points and other plot region elements
# (mostly to show what the final plot would look like)

plot.window(xlim = range(xvar), ylim = range(yvar))
axis(1); axis(2); grid()
title(xlab = xlab, ylab = ylab, main = "Continuous legend")
points(
    x = xvar, y = yvar,
    pch = 19,
    col = cols[round(rescale_func(colvar))]
)

Created on 2024-02-01 with reprex v2.1.0

Note to self: This intersp trick probably won't work for horizontal legends (incl. "top!" and "bottom!"). We can just exclude those for now.

@zeileis As our resident colour expert: Do you have a recommendation for the default continuous palette? Right now, it's "viridis" but I'm not the biggest fan TBH. Do you perhaps think "cividis", or one of the single palette HCL colors like "blues3" would be a better choice? Something else?
Background: I have the basic code working for native continuous legends in tinyplot now. So it seems a good time to decide the default palette. Happy to share some screenshots if that's helpful.

It depends what you want to use the palette for.

If it is for shading areas (e.g., in a heatmap), then the viridis palettes typically have too much chroma. Then it is better to have a palette like "YlGnBu" that only has high chroma for the dark colors and low chroma for the light colors. See
bottom left panel in Figure 5 from the paper you mention above. The comparison in Figure 6 also brings out the contrast between YlGnBu and Viridis quite clearly.
However, if you use the continuous palette for coloring points or lines (rather than shading areas) then the high-chroma property of viridis is actually useful. It assures that all points/lines can be seen reasonably well.
Instead of one of the viridis family palettes one can also use a restricted range from another sequential palette. The restriction is typically necessary to assure that no colors become too light (which would make the corresponding points/lines fade into the background). The advantage is that the plot will be calmer and not so busy as with the strong hue changes of viridis. The disadvantage is that it will be harder to tell the different ends of a spectrum apart.

In short: For shading areas I would use YlGnBu. For points and lines I would go with a multi-hue sequential palette with a reasonable range of hues and relatively high chroma throughout. Maybe Mako or Rocket are a bit less busy compared to viridis.
I'm happy to play around with this a bit if you provide code for a couple of typical examples you have in mind.

Thanks @zeileis! Right now, we don't support heatmaps, so it's mostly for points and similar plot types. (Exception: Adding continuous color support for line plots is v. tricky with the base graphics scaffolding, so I don't plan on supporting line plots yet.)
I do like the Mako and Rocket palettes—and use them a lot in my own plots—so just from a pure aesthetic perspective it would be between those and Cividis for me. But I defer to your expert knowledge...
Let me tidy up this prototype code a little bit and push the changes to the continuous-legend branch that I'm working on. I'll ping you here when it's ready, so you can pull and play around with it on your local machine.

Re: heatmaps. We don't support them _yet_ ;-) More seriously, for me the question is more whether we will have a conceptual difference somewhere for default continuous palette for shading areas vs. points/lines. Or whether the defaults are set per function anyway.
Re: cividis. My personal opinion is that this is a very bad choice for almost all situations. It collapses many color contrasts that would help trichromats (with "normal" color vision) to better distinguish the colors in a palette. Also, it's a weird combination between sequential and diverging palette.
Re: pinging later. :rocket:

Hey @zeileis I ended up doing a bit more work on the branch, so that it was ready for PR in #122. Even though I've marked it as [WIP], it's ready to kick the tires. (I just need to clean up some things internally and add tests, etc.) Feel free play around and lmk what you think.


Is llvm-assignment using llvm/clang version 4.0.0?

Hi, I'm trying to do something with function-pointer-analysis but couldn't compile LLVMAssignment.cpp using clang/llvm 4.0.0:
Compiling LLVMAssignment.cpp
/home/yves/Workspace/c-function-pointer/clang-llvm-tutorial/function-pointer-analysis/LLVMAssignment.cpp:15:10: fatal error: 'llvm/Bitcode/ReaderWriter.h' file not found
#include <llvm/Bitcode/ReaderWriter.h>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

Turns out version 4.0.0 already separated this header into different files. I've also tried 3.9.0 which is before this commit, or just copying the 3.9.0 headers to compile and use later versions of clang/g++ to link, but these didn't work either; there was a lot of API changes.

@yvesyy Thanks for your report.
I have already fixed this error.
As mentioned in this commit history: https://reviews.llvm.org/D26502,
Just comment out the old header file and replace them with the two separate header:
//#include <llvm/Bitcode/ReaderWriter.h>
#include <llvm/Bitcode/BitcodeReader.h>
#include <llvm/Bitcode/BitcodeWriter.h>


[HTD-10] Feat: Add Icon folder and Custom icons

Pull Request Description
Description

Assets

before
after

Before Merge Checklist
The following steps were checked before merging a PR

[x] checked and fixed code style issues
[x] checked and removed unnecessary/junky code
[x] manually tested introduced solution
[ ] added needed tests to automate testing this code in the future

@nephlin7 this PR is waiting for logo SVG resizing


Outer arc color on MeterSubMenu different to Melbourne Menu for Demo program

On demo program outer arc color is different on Melbourne menu style.

Also thickness


Migrate to ZNPCsPlus

 N/A
The output of command /version on my server is: N/A
The output of command /version citizens on my server is: N/A
The output of command /version sentinel on my server is: N/A
A pastebin.com link to my (full!) Sentinel/config.yml file is: N/A

wait…

it didn’t save my actual explanation…

bear with.

... Thanks.


"Press enter to proceed" should be a flaggable option to turn off the prompt

When running through something like for example ansible there shouldn't need to be any required human input prompt.
IE. On https://kurl.sh/docs/install-with-kurl/advanced-options it should be classed as "no-prompt".
Otherwise a workaround has to be done with expect or editing the install.sh script to remove the prompt.

Hi @evilmonkeyslayer! All of the prompts in kurl should be on a timeout to accept the default answer after 20 seconds, so unattended installs should work fine.

Are you running into a specific point in the install where this isn't the case?
Are you just asking to ignore the prompt all together? IMHO it's better to have this information in the logs.

Hi @evilmonkeyslayer! All of the prompts in kurl should be on a timeout to accept the default answer after 20 seconds, so unattended installs should work fine.
1. Are you running into a specific point in the install where this isn't the case?

2. Are you just asking to ignore the prompt all together? IMHO it's better to have this information in the logs.

 Here I was making workarounds for something that has a timer on it.

You can also check out the installer flags here which can often control the outcome of the prompts in advance: https://kurl.sh/docs/install-with-kurl/advanced-options


Cb predict2

Hello @camillebrianceau! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file clinicadl/utils/maps_manager/maps_manager.py:

Line 1207:17: E722 do not use bare 'except'

In the file clinicadl/utils/task_manager/task_manager.py:

Line 232:21: E722 do not use bare 'except'


Discussion: Feedback for MDX compilation failure

With a syntax error in a markdown/MDX file, the build gives no feedback as to what authored file is the cause of the problem. Could this be addressed  through a strategy along the lines of the proposal in this PR? This will report the file at fault, and an attempt at the line location (unfortunately an attempt that usually doesn't match up with the actual line, for reasons I don't understand).
For example:
raidocs:build: info  - Loaded env from /home/robbear/dev/robbear/rai-ux/raidocs/site/.env.production
raidocs:build: info  - Checking validity of types...
raidocs:build: warn  - The Next.js plugin was not detected in your ESLint configuration. See https://nextjs.org/docs/basic-features/eslint#migrating-existing-config
raidocs:build: info  - Creating an optimized production build...
raidocs:build:
raidocs:build: Error compiling /home/robbear/dev/robbear/rai-ux/raidocs/site/pages/rel/primer/basic_syntax.md
raidocs:build: 17:3: Could not parse expression with acorn: Unexpected token
raidocs:build:
raidocs:build: (node:2594893) UnhandledPromiseRejectionWarning
raidocs:build: (Use `node --trace-warnings ...` to show where the warning was created)
raidocs:build: (node:2594893) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
raidocs:build: (node:2594893) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Are there other approaches you're thinking about for giving MDX debugging feedback?

can we merge this soon? it's kind of blocking any next build we are trying to make on our documentation site that uses nextra..
thanks.

Thanks and this is definitely helpful, I actually had the same problem.

Hey @shuding is it possible to create a release with this fix?


ARROW-8616: [Rust] Turn explicit SIMD off by default

We will be removing explicit SIMD in #7037, this PR removes it from the default features in preparation of removing it completely.

LGTM subject to fixing CI failure

We have to rewrite the divide kernel for tets to pass. I've done this as part of #7037 by creating a slower path if the LHS array has nulls.


Bump time limit for clean_source Celery job

For larger accounts, I've hit SoftTimeLimit exceptions before completion of this celery job. Bumping up the time limit on this job.

Coverage remained the same at 58.836% when pulling e25f97fce7da04b316ba2f6fc7359630f236f99f on castrapel-patch-2 into 0c02ddec3c2f0d84962f7527834450b72078acd0 on master.


BEP-038: Atlases

This PR proposes the inclusion of BEP-038 into the BIDS specification.
The BEP is hosted on its own branch in the main repository, and BEP leads have been given write permissions to the branch. If you are a BEP lead and having issues writing to the branch, please let a maintainer know and we can make sure you have access.
At present this is a starting point, and I anticipate significant rewriting and reorganization before final merge. There is extensive discussion in #1281 that needs to be turned into concrete proposals. I would suggest keeping the discussion on this PR minimal so that newcomers can follow the thread. When opening PRs against this branch, please include a reference to this PR (#1714) so that it shows up in the thread.
Rendered draft
https://bids-specification--1714.org.readthedocs.build/en/1714/
Related discussions

#1281
... (to be added to)

@erdalkaraca @tsalo this has passed the review period now, can this be checked and merged? thx

I'm working on a review. Please hold on.

I also have not finished my review/proposed changes. I am unlikely to get to it before the meeting next week as I am traveling for another meeting this week.

This BEP currently needs:

Schema implementation of required checks and filename rules
Examples implementing all significant (ideally all) features proposed to https://github.com/bids-standard/bids-examples
Implementation of all rules in https://github.com/bids-standard/bids-validator and tested on the examples.
A two week public review period announced on all communication channels.

I'm converting this to draft to reflect this status. I'm going to temporarily restrict comments, pending synchronous discussion.

Hi, Folks,
Thanks for helping with this BEP. It was great to see several of you at OHB<
I would like to kindly ask to go back to this BEP and make a decision before OHBM. We have a few proposals to pick from (see here), most of them would be fine with @PeerHerholz and myself.
What are the pending issues that would need to be resolved?
@effigies @CPernet @oesteban @PeerHerholz @melanieganz @sappelhoff @christinerogers @tsalo @erdalkaraca @jdkent


Gradle 4.0 Support

As detailed in the Gradle 4.0 Release Notes there are a few deprecations
Using the attached demo project you receive the following warning:

Gradle now uses separate output directories for each JVM language, but this build assumes a single directory for all classes from a source set. This behaviour has been deprecated and is scheduled to be removed in Gradle 5.0

The demo project was created using the Spring Initializr defaults for a java gradle project.

Spring Boot's Gradle plugin managed in https://github.com/spring-projects/spring-boot. There are already issues for this: https://github.com/spring-projects/spring-boot/issues/9559 and https://github.com/spring-projects/spring-boot/issues/9516.


CASMPET-6151 Update versions

Summary and Scope

Update vault to 1.12.1
Update vault-operator to 1.16.0

Issues and Related PRs
List and characterize relationship to Jira/Github issues and other pull requests. Be sure to list dependencies.

Resolves CASMPET-6151

Testing
Tested on:

Virtual Shasta

Test description:
Adeed test data into vault. Validated that data was accessible after both upgrading and downgrading vault and the vault-operator

Were the install/upgrade-based validation checks/tests run (goss tests/install-validation doc)?
Were continuous integration tests run? If not, why? Y
Was upgrade tested? If not, why? Y
Was downgrade tested? If not, why? Y
Were new tests (or test issues/Jiras) created for this change? N

Risks and Mitigations
When vault is downgraded the --pre-flight-checks needs to be manually removed from command line options in the cray-vault-configurer deployment. If this isn't removed then the pod will crash due to this not being a valid option in bank-vaults 1.8.0.
Pull Request Checklist

[X] Version number(s) incremented, if applicable
[X] Copyrights updated
[X] License file intact
[X] Target branch correct
[ ] CHANGELOG.md updated
[X] Testing is appropriate and complete, if applicable
[ ] HPC Product Announcement prepared, if applicable

The persistentVolumeReclaimPolicy: Retain option was removed due to it no longer being a valid option. This needs further investigation.

Dug into the persistentVolumeReclaimPolicy: Retain option. Looks like this was never valid and was ignored in previous releases. I checked a few systems and it was always set to Delete. This option is safe to remove.


Use C99 flexible array member notation in parser memory struct

The usage of a single byte sized array as a flexible array member can lead to
compiler/analyzer errors or warnings. Not specifying the size in the array is
correct as per C99 standard.
Flexible array members are defined in the C Standard, <IP_ADDRESS> (ISO/IEC 9899:1999).

Without this the following error was triggered with gcc 10.2.0:
$ ./tools/build.py --clean --stack-limit=96 --cmake-param=-DCMAKE_BUILD_TYPE=Release

In function ‘parser_stack_iterator_write’,
    inlined from ‘parser_parse_if_statement_end’ at jerry-core/parser/js/js-parser-statm.c:871:3,
    inlined from ‘parser_parse_statements’ at jerry-core/parser/js/js-parser-statm.c:3354:15:
jerry-core/parser/js/js-parser-mem.c:733:5: error: writing 16 bytes into a region of size 1 [-Werror=stringop-overflow=]
  733 |     memcpy (iterator->current_p->bytes + iterator->current_position - length,
      |     ^
jerry-core/parser/js/js-parser-statm.c: In function ‘parser_parse_statements’:
jerry-core/parser/js/js-parser-internal.h:333:11: note: at offset 0 to object ‘bytes’ with size 1 declared here
  333 |   uint8_t bytes[1];                           /**< memory bytes */
      |           ^
lto1: all warnings being treated as errors


Stripe CardError does not seem to be set up correctly

According to Stripe Docs,
rescue Stripe::CardError => e
  # Since it's a decline, Stripe::CardError will be caught
  body = e.json_body
  err  = body[:error]

In spec:
StripeMock.prepare_card_error( :card_declined, :new_charge )

The issue is that e.json_body is nil.

:+1:


Support multiple MirrorURL entries in the image definition file

For a richer bootstrap please support multiple MirrorURL entries in the image def file.

Please test [master d077169] when you have a chance... MultipleURL's should now work. :)
Thank you for your patience!

I am closing this, but if for any reason it doesn't work please let me know and I will reopen.
Thanks!


How to bypass all permission ?

Hi, this package is awesome.. but sometimes i need to bypass all permission check for debugging. how to achieve that with this package ?

Hello and thanks. I probably understand, but could you please give me an example to be clear? Thanks!

Ok, on every function of my apps i put permission check like
add_post
edit_post
delete_post
now when i still developing my apps, i do not add role permission on my database
but i put my code to check on my function..  like,
if(! Auth::user()->can('edit_post'))
{
Session::flash('alert', 'you do not have permission to edit this page')
return Redirect::back();
}
// code to store to database
so for now i want to bypass all permission check on my apps until all feature complete then i put real permission to database and it's my time to check my permission working properly

Well, there is now way how to achieve that at this moment. If you perform a check, it will return false if user has no role or permission.
Do you have any idea, how to implement this feature?

maybe you can check in your method
if( level == x ) return true
and
if (role == 'admin') return true
on every check can() is() level()
sorry i cannot help to code because i still learning to code better

I'll consider it.

My 2 cents on this is make a config file and make option "pretend" something like Laravel's mailer have.

Done. Please have a look at version 1.5.0.

Wow.. nice..
thanks anyway


Precedence for ambiguous parsings?

Can't figure out how to change precedence for ambiguous parsings. My grammar is ambiguous because it includes emoji (a subset of unicode) and all unicode characters.
Because of this emoji can be parsed as a single emoji or as two constituent unicode characters--but I can't figure out how to prefer parsings where emoji are parsed as emoji (and not as their constituent characters).

Ah, interesting question. Here's one way to do it:
text -> textchar:*
textchar -> ":-)" | [^:] | ":" [^-] | ":-" [^\)]

If your emojis are all exactly two unicode characters, then you have another option using the reject feature:
text -> digraph:+ .
digraph -> "=)" | "=(" | "=/" | . . {%
function(data, location, reject) {
  if (isAnEmoji(data.join("")) {
    return reject;
  } else {
    return data;
  }
}
%}

My grammar looks like this:
@import "./emoji.pegjs" as Emoji

Unicode
 -> Symbol:*

Symbol
 -> Emoji
  | SurrogatePair
  | [\u0000-\uD799]

SurrogatePair
 -> [\uD800-\uDBFF][\uDC00-\uDFFF]

Emoji
 -> PhoneButton {% id %}
  | EmojiCharacter VariationSelector:? {%
      function (data, location, reject) {
        var e = data[0];
        var v = data[1];

        return (e.join ? e.join('') : e) + (v ? v.join ? v.join('') : v : '');
      }
    %}

PhoneButton
 -> [0-9#*] VariationSelector:? [\u20E3] {%
      function (data, location, reject) {
        return data.join('');
      }
    %}

EmojiCharacter
 -> [\uD83C] [\uDDE6-\uDDFF] [\uD83C] [\uDDE6-\uDDFF]
  | [\uD83C] [\uDC04-\uDFFF]
  | [\uD83D] [\uDC00-\uDE4F]
  | [\uD83D] [\uDE80-\uDEC5]
  | [\u203C-\u3299]
  | [\u24C2]
  | [\u2702-\u27B0]
  | [\u00A9\u00AE]

VariationSelector
 -> [\uFE0E\uFE0F]

The idea is that it can parse (or split) strings containing any unicode character, while being emoji-aware.
The flag emojis are actually four unicode characters long, the phone button emojis are three unicode characters long, some emojis are two unicode characters long (and so are ambiguous because alone they're each a valid unicode character).
So it seems like it is possible to add a regex for the 8 types of emoji constructions in EmojiCharacter, and use the reject but I'd like to avoid that if possible to keep things DRY. :)
Maybe just sorting the parsed outputs by least number of characters would suffice?
But I had hoped there was some other way (the bit on the website about returning all of the parsings in a deterministic order made me wonder what that order was and if I could set that order myself).

Ah, I see.
Firstly, what's up with @import "./emoji.pegjs" as Emoji? Curious. :-)
I've been thinking, and I think I can hack in precedence if I think about it. The question is more about how the interface should be presented to the user. Where do you declare precedence? How?  Should it be implicit in the order in which you declare the rules (which is, I think, how it works right now)? Or should you be able to assign ranks to production rules?
Math -> [1] Number "+" Number
      | [2] Number "*" Number

Lots of questions to answer. Let me know your opinion.
As it stands, though, this feature is probably a few days' work (and even more for writing rigorous test-cases!). Meanwhile, I would suggest going with your trick of picking the parsing with the fewest number of "characters".

(For posterity,) the cleaner reject way to do it is:
Unicode -> (Char Emoji):* Char
Emoji -> …
Char -> .:* {%
function(data, location, reject) {
  if (regex_test_for_emoji) {
    return reject;
  } else {
    return data;
  }
}
%}

Oops, the @import line was a remnant from the PegJS version (which is achieved by using pegjs-import because PegJS does not natively support the @import statement). :)
I did try changing the order of the alternates but it didn't seem to affect the order of the found parsings (which made me think there was some other ordering happening).
Implicit declaration makes sense to me, but I also like how the explicit version looks so I don't have much of a preference. I'm not a parsing guru so I will defer to others here!

@Hardmath123 Do you have any ideas for a syntax for this? :)

I was thinking a strict arrow -!> that assigns the production rules separated by | precedence in the order they are specified.
char -!> ":-)" | .

(This example would be better served by a tokenizer, of course.)

As an alternative to that arrow that doesn't require you to indent by another character 😉
=>

No. nearley already allows => as a substitute for -> (you can even do a -===-----=> b if you want). Backwards-compatibility matters.

Whoops, didn't know that. Is that documented?

No. </offtopic.>

Do I understand this thread correctly? The hypothetical -!> would fix this ambiguous grammar?
INPUT: "catsdasfdfasfeca
tsn23kj42342jk34nkcats"
MAIN -> CATSFTW
CATSFTW -> null
  | "cats" CATSFTW
  | [\s\S] CATSFTW

So the pipe | doesn't just take the first found correct pattern but always also goes through all other possibilities? I want to create a relatively small jsx, which only manipulates some special occurences in the input code. It works already pretty good, but my problem is that I have many [\s\S] cases... and therefore i get 30k different results even when I test a input file with 13 lines or so. This makes the parsing horrible slow xD.
Thanks a lot in advance!

@katywings I don't think ordered choice aka. -!> is what you want there. You're probably better off restructuring your grammar not to be ambiguous! One way of doing this might be to use a tokeniser. (Also, I should note that in nearley, left recursion is slightly faster than right recursion.) If you need more help, open a fresh issue :-)

(Also, I think . would match the same as [\s\S].)

@tjvr Thanks for the tip with the left recursion, didnt know that. A tokenizer doesnt help because it would need the same complexity as my nearley grammar. Except from the -!> the only solution in nearley i can think of is to use not- Rules which would be kinda stupid:
CATIFY -> null
  | "cat" CATIFY
  | [\s\S] CATIFY {% (d, l, r) => {
if d startswith "cat" reject
}
%}

I don't think this is efficient because postprocessors get applied in the post process when I understand it correctly, therefore the not rule would need to go through all 30k different parser results.
So under the current circumstances I need to use an other parser library ;(.
@Hardmath123 Werent you the guy who somewhere in this thread used the word offtopic? :).  However: Thx I know... For prototyping I sometimes prefer the char class because the dot constantly gets ignored by my eyes ;)

@katywings Can you show your grammar (on a new issue)? I don't understand what you're trying to do. Thanks.

@tjvr Thank you for your help. I can do that, probably at the weekend ;).
Have a good night!
Am 18. April 2017 1:16:24 nachm. schrieb "Tim (blob8108)"
<EMAIL_ADDRESS>
@katywings Can you show your grammar (on a new issue)? I don't understand
what you're trying to do. Thanks.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/Hardmath123/nearley/issues/81#issuecomment-294789340


Check that<EMAIL_ADDRESS>works

Arosha and Sanith will be taking responsibility for this. Tharaka is the recipient of emails from this address.


Add support for reloading chrome extensions

option: isChromeExtension=true
Closes: #61

If you want I can draft some documentation on how to use in the context of a chrome extension.


Dependabot is not fetching the latest version of a dependency from repo.maven.apache.org

Package manager/ecosystem
java:gradle
Manifest contents prior to update
build.gradle.kts
Updated dependency
org.springframework.cloud:spring-cloud-dependencies
What you expected to see, versus what you actually saw
When checking in  repo.maven.apache.org, dependabot should determine that the latest version is 2020.0.0, released on 2020-12-22, 7 days ago as the time of writing this (2020-12-29).
Images of the diff or a link to the PR, issue or logs
Dependabot logs state that the latest version is still Hoxton.SR9, when according to https://repo.maven.apache.org/maven2/org/springframework/cloud/spring-cloud-dependencies/maven-metadata.xml it's not true (that maven link is exactly the one dependabot says it is using, see logs below):

Dependabot logs from today (2020-12-29):
updater | INFO <job_79275963> Checking if org.springframework.cloud:spring-cloud-dependencies Hoxton.SR9 needs updating
  proxy | 2020/12/29 07:06:04 [038] GET https://repo.maven.apache.org:443/maven2/org/springframework/cloud/spring-cloud-dependencies/maven-metadata.xml
  proxy | 2020/12/29 07:06:04 [038] 200 https://repo.maven.apache.org:443/maven2/org/springframework/cloud/spring-cloud-dependencies/maven-metadata.xml
updater | INFO <job_79275963> Latest version is Hoxton.SR9
updater | INFO <job_79275963> No update needed for org.springframework.cloud:spring-cloud-dependencies Hoxton.SR9

Note, if needed, I can tell you in which repository I'm experiencing this, but it's a private one.

Update: I updated manually the library to the 2020.0.0, immediately after merge I pressed the "check for updates" button and got this:
updater | INFO <job_79456388> Checking if org.springframework.cloud:spring-cloud-dependencies 2020.0.0 needs updating
  proxy | 2020/12/30 23:32:18 [032] GET https://repo.maven.apache.org:443/maven2/org/springframework/cloud/spring-cloud-dependencies/maven-metadata.xml
  proxy | 2020/12/30 23:32:18 [032] 200 https://repo.maven.apache.org:443/maven2/org/springframework/cloud/spring-cloud-dependencies/maven-metadata.xml
updater | INFO <job_79456388> Latest version is 2020.0.0
updater | INFO <job_79456388> No update needed for org.springframework.cloud:spring-cloud-dependencies 2020.0.0

My feeling is that at least my builds were hitting some kind of cache.

Closing as this unfortunately is old enough that we don't have all the necessary logs to figure out exactly what happened. My guess is the job queue got stuck somehow for a bit. Anyway, if you see it happen again, please file an issue and we'll try to get to it quicker to understand what specifically is breaking.


fix(ssr): Memory leak in poll method, take 2 (fix #2606)

Fix #2606.
Unlike https://github.com/vuejs/vue-router/pull/2867, this fix does not depend on the following being merged first: https://github.com/vuejs/vue/pull/9479
Removed poll method, which was causing a memory leak when a Vue app is created per request, which is typical in SSR.
The leak happens when:

The router-view is conditioned to appear upon a variable that never becomes true.

    <router-view />

A beforeRouteEnter guard's next is passed a cb:

export default {
  beforeRouteEnter(to, from, next) {
    // Poll happens only if you pass in a function to next(...)
    next(vm => {} /* cb */)
  }
}

Instead of polling we try to call the cb in History#confirmTransition, otherwise add the cb to RouteRecord#enteredCbs, and call it instead upon route registration (see components/view.js).
I don't know whether or not it is ok to add enteredCbs to RouteRecord. I don't know whether or not we are ok with mutating the route record inside of History#confirmTransition. I also don't really know if this will cause problems elsewhere outside of running npm test.
The apps my team builds here in Bloomberg are thoroughly E2E tested. If you don't see any problems with this approach I can try to get our tests run against this fix version, if that helps any.

Ah I see, the E2E tests didn't run locally for some reason. Let me see if I can fix these errors.

Could you rebase against dev? There were a few things in between

@posva This still does not work. I created an E2E test for the out-in transition problem (#750), and the test fails. I will continue to play with it, but this in its current state should not be merged.

I believe I have a solid fix now. Will clean up and commit new E2E test hopefully tomorrow.

@posva There are some edge cases I'm a little worried about, such as the possibility of the beforeRouteEnter next callbacks getting called before transitionTo's onComplete hook gets called. handleRouteEntered is also called upon instance registration in the component's init hook now so it seems possible. I also will still likely run this fix against the memory leaking builds I had in my apps a few months ago. You can wait for that if you want, but otherwise I feel somewhat confident about this fix.

I finally got around to testing a past build that had the memory leaks against this fix, here are the results.
E2E Tests
All E2E tests pass for both builds
With memory leak:

Without memory leak:

Memory Leak Test
With memory leak
We do not build with the fixed version of vue-router (no arrow)

We siege a route with the condition detailed above with 1000 hits

CPU profile shows a busy CPU filled with polls

An examination of New Relic shows that the memory stays at ~600MB for 40 minutes after the siege. It also shows 90% CPU utilization and an event loop with 10k ticks per minute even though the website is not being accessed at all.

Without memory leak
We build with the fixed version of vue-router (see the arrow pointing outwards)

We siege the same route with 1000 hits

CPU profile shows that it is doing nothing

New Relic shows that the memory does not accumulate above 100MB, a low GC pause frequency and a serene event loop after sieging.

I can play around with the fix some more to see if there are any edge cases to deal with, let me know if you are waiting on this and I will get to it sooner rather than later.

@ronald-d-rogers  oh wow, thanks a lot for such a detailed report. If you think all is ready, I will give it a look this week see if we can get it merged and released in a patch

@posva I still want to feel around the edges to see if there are any issues but I don't think there will be and even if there are it will only affect this particular use case (next callbacks in beforeRouteEnter hooks), so I think I'm ok with it. I will try to test that one edge case that I am slightly worried about soon anyways, probably this weekend.

@posva I put console log statements in the beginning of confirmTransition, onComplete, handleRouteEntered, ran all E2E tests, and saved all the browser's console statements to a file. They consistently run in order in all tests with the exception of lazy-loading-before-mount, where Homes next callbacks (handleRouteEntereds) are called after Foo's confirmTransition starts. Given the way the test is written I think that is expected. That's the only thing I was kind of worried about, I think this is safe to merge now.

Thank you so much!! I will take a look to get it merged next week!

Also run CI after rebasing against dev with some extra tests against browsers: https://circleci.com/gh/vuejs/vue-router/tree/fix%2F2606%2Fpoll-leak
@yyx990803 Could you get a look at this one? I want to be sure we are not missing a case that was supposed to be covered by the old poll function

While you guys are all taking a look, a major optimization I thought of the other day was to try to extract and call the entered cbs in the router view and take it out of history completely. It's hard for me to tell whether or not everything would still happen in the correct order (and don't know if we care if it differs slightly). Perhaps you guys can say. I've been busy unfortunately so haven't had time to try.

@posva FYI, I spent the time to actually try and do what I said in the above comment, and realized it is not possible. The cb's have to extracted in confirmTransition when the hooks are called. So please disregard.

@ronald-d-rogers thank you for that! I haven't forgotten about this PR and I will try to review it in a few weeks

@posva: No worries, last thing I want to be is at all responsible for breaking the internet! Just FYI, I did not have a patch running on my end, I just laid out rules to avoid this feature, use workarounds, etc.


About firmware 3.69

The first answer in your FAQ is not correct anymore.
Firmware 3.69 is unhackable (at least for a long time).
So you should change the answer from "Yes!" to "No, at least not yet."

Fixed!


[BUG] Unable to deploy the Fragments using the publisher

Release version
2.1
Describe the bug
Issue when we deploy a policy fragment that has C# code. It gives the below error
System.InvalidOperationException: HTTP request to URI https://management.azure.com/subscriptions/***/resourceGroups/OVHWEDEV-APIM-RG/providers/Microsoft.ApiManagement/service/ovhwedevapim/policyFragments/msc-addcalledbyheader-fragment?api-version=2021-12-01-preview&format=rawxml&asyncId=63d3f0ef217d201980afe25b&asyncCode=200 failed with status code 400. Content is '{"error":{"code":"ValidationError","message":"The policy fragment is not a valid XML: An error occurred while parsing EntityName. Line 37, position 40.","details":null}}'.
at common.HttpPipelineExtensions.Validate(Response response, Uri requestUri) in /home/vsts/work/1/s/AzAPIMPOC/v2.0/tools/code/common/Http.cs:line 87
at common.HttpPipelineExtensions.WaitForLongRunningOperation(HttpPipeline pipeline, Response response, CancellationToken cancellationToken) in /home/vsts/work/1/s/AzAPIMPOC/v2.0/tools/code/common/Http.cs:line 112
at common.HttpPipelineExtensions.PutResource(HttpPipeline pipeline, Uri uri, JsonObject resource, CancellationToken cancellationToken) in /home/vsts/work/1/s/AzAPIMPOC/v2.0/tools/code/common/Http.cs:line 73
at publisher.Program.<>c__DisplayClass12_0.<b__0>d.MoveNext() in /home/vsts/work/1/s/AzAPIMPOC/v2.0/tools/code/publisher/Program.cs:line 168
Sample policy:

@{
string[] jwtArr;
Jwt jwt;
var appId = "";
            var calledByName = "";
            if (context.Request.Headers.TryGetValue("Authorization", out jwtArr))
            {
                if(jwtArr != null && jwtArr.Length > 0)
                {
                    jwt = jwtArr[0].Split(' ').Last().AsJwt();
                    appId = jwt.Claims.GetValueOrDefault("azp", string.Empty);
                    var dictMappingsAll = JsonConvert.DeserializeObject<Dictionary<string, string>>((string)context.Variables.GetValueOrDefault<string>("CalledByMappings1"));

                    dictMappings1.ToList().ForEach(x => dictMappingsAll.Add(x.Key, x.Value));

                    if (dictMappingsAll.TryGetValue(appId, out calledByName))
                    {
                        return calledByName;
                    }
                    else
                    {
                        return "";
                    }
                }
            }
            return "";
        }</value>
</set-header>

Expected behavior
Able to deploy policies with the APIOps Publisher
Actual behavior
System.InvalidOperationException: HTTP request to URI https://management.azure.com/subscriptions/***/resourceGroups/OVHWEDEV-APIM-RG/providers/Microsoft.ApiManagement/service/ovhwedevapim/policyFragments/msc-addcalledbyheader-fragment?api-version=2021-12-01-preview&format=rawxml&asyncId=63d3f0ef217d201980afe25b&asyncCode=200 failed with status code 400. Content is '{"error":{"code":"ValidationError","message":"The policy fragment is not a valid XML: An error occurred while parsing EntityName. Line 37, position 40.","details":null}}'.
at common.HttpPipelineExtensions.Validate(Response response, Uri requestUri) in /home/vsts/work/1/s/AzAPIMPOC/v2.0/tools/code/common/Http.cs:line 87
at common.HttpPipelineExtensions.WaitForLongRunningOperation(HttpPipeline pipeline, Response response, CancellationToken cancellationToken) in /home/vsts/work/1/s/AzAPIMPOC/v2.0/tools/code/common/Http.cs:line 112
at common.HttpPipelineExtensions.PutResource(HttpPipeline pipeline, Uri uri, JsonObject resource, CancellationToken cancellationToken) in /home/vsts/work/1/s/AzAPIMPOC/v2.0/tools/code/common/Http.cs:line 73
at publisher.Program.<>c__DisplayClass12_0.<b__0>d.MoveNext() in /home/vsts/work/1/s/AzAPIMPOC/v2.0/tools/code/publisher/Program.cs:line 168
Reproduction Steps

Create a policy fragment based on the above attachment
Publish the policy using the publisher
Error will be thrown

@ashwin2024 that policy worked fine in the lower environment? Meaning you have it successfully working in a apim Dev environment and then you extracted it but it's failing to publish when you try to promote the policy to a production environment?

@waelkdouh using the publisher version 4.0.2 we are still facing the issue.


added a new web development youtube tutorial resource channel link

Hey can you please tag your repo with the topic "hacktoberfest"? Due to
lots of spam, the rules have been changed this year. Only those PRs count
which are submitted to a repo with the topic "hacktoberfest", and the PR
has been labelled as "hacktoberfest-accepted" or it has been merged.
On Sat, Oct 3, 2020, 23:40 Championrunner<EMAIL_ADDRESS>wrote:

Merged #1052
https://github.com/Ishaan28malik/Hacktoberfest-2020/pull/1052 into
master.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Ishaan28malik/Hacktoberfest-2020/pull/1052#event-3836827177,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANPNZ3DLMKM4S5XR75C3WK3SI5SKVANCNFSM4SCOKAGQ
.

Hey can you please tag your repo with the topic "hacktoberfest"? Due to lots of spam, the rules have been changed this year. Only those PRs count which are submitted to a repo with the topic "hacktoberfest", and the PR has been labelled as "hacktoberfest-accepted" or it has been merged.
…
On Sat, Oct 3, 2020, 23:40 Championrunner @.***> wrote: Merged #1052 <#1052> into master. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1052 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPNZ3DLMKM4S5XR75C3WK3SI5SKVANCNFSM4SCOKAGQ .

Oh I see , yeah i need to make those changes.

Do you know if my PR would count even though it was submitted and merged
before the changes were made?
On Sat, Oct 3, 2020, 23:48 Championrunner<EMAIL_ADDRESS>wrote:

Hey can you please tag your repo with the topic "hacktoberfest"? Due to
lots of spam, the rules have been changed this year. Only those PRs count
which are submitted to a repo with the topic "hacktoberfest", and the PR
has been labelled as "hacktoberfest-accepted" or it has been merged.
… <#m_6172375002682947490_>
On Sat, Oct 3, 2020, 23:40 Championrunner @.***> wrote: Merged #1052
https://github.com/Ishaan28malik/Hacktoberfest-2020/pull/1052 <#1052
https://github.com/Ishaan28malik/Hacktoberfest-2020/pull/1052> into
master. — You are receiving this because you authored the thread. Reply to
this email directly, view it on GitHub <#1052 (comment)
https://github.com/Ishaan28malik/Hacktoberfest-2020/pull/1052#event-3836827177>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANPNZ3DLMKM4S5XR75C3WK3SI5SKVANCNFSM4SCOKAGQ
.
Oh I see , yeah i need to make those changes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Ishaan28malik/Hacktoberfest-2020/pull/1052#issuecomment-703143768,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANPNZ3DBOD5XXXWYTTG6K7TSI5TF7ANCNFSM4SCOKAGQ
.

Oh I see , its hard to say in this case.
Because I no idea about this.
Maybe you should try to solve any of the existing issues and then try it.


Add CI/CD

Summary

Add some automation for the repo

Issue
GitHub Actions is free for open-source projects. It'd be nice to add some automation.
Proposed Solution
Add a few GitHub Actions that run on push that performs checks. This will make it easier for reviewers if they can see if changes worked

Looks good, went ahead and merged.


fix(breadcrumb): update aria role to now have the value of navigation

Related Ticket(s)
Closes #10730
https://jsw.ibm.com/browse/ADCMS-3670
Description
When running the Accessibility checker on bx-breadcrumb and bx-breadcrumb-items, it complains about the bx-breadcrumb assigned role, where it is role="nav" saying that "The The role='nav' defined on the element is not valid per ARIA specification".
Changelog
New
breadcrumb.ts code edited to now define the aria role as role="navigation"

I have read the DCO document and I hereby sign the DCO.

Test failure appears to be unrelated. Closing/re-opening to make it try again.


[Add] Backlog new apis for projects

This PR added the support for newly introduced APIs for backlog projects.

@biplobice
Thank you!!!!!1


PDF does not render correctly on Retina screens

Attach (recommended) or Link to PDF file here: test-pdf.pdf
Configuration:

Web browser and its version: Chrome 109.0.5414.119, Firefox 109.0.1
Operating system and its version: MacOS 13.1
PDF.js version:  3.3.122 (tested on https://mozilla.github.io/pdf.js/web/viewer.html)

Steps to reproduce the problem:

Open https://mozilla.github.io/pdf.js/web/viewer.html on retina screen
Upload test-pdf.pdf
Switch scale to 50% and scroll right

What went wrong?
PDF looks bad on Retina screens - looks like part of it rendered correctly (black border), but the rest is too small:

What is the expected behavior?
This looks good on non-retina screens:

Duplicate of #14982


Added name/ first contribution

Related issue

What changes does this PR do?
Screenshots (If any)
Questions

Looks good & Congrats🎉


Add note to Readme to indicate that OpenTelemetry.Extensions.Hosting must be installed

Installing the NuGet package isn't sufficient in itself to also assemble the example as provided in the readme. Rather, one must also install the OpenTelemetry.Extensions.Hosting package in order to have the AddOpenTelemetry extension method available against IServiceCollection.

Thanks for bringing this to our attention @WhitWaldo! Looks like there are a number of things out of sync in our readme. As OpenTelemetry is still in beta, the likelihood of this continuing to get out of sync is high.
In the meantime, I think what I will do will be to remove the code samples from the readme and instead link to our sample projects which we keep current and ensure compiles against the correct OpenTelemetry dependencies.
Here's our AspNetCore example.


Integration tests and framework

Once we have stabilized the front end, we need to start doing proper testing of the front-end application.
My suggestion is to use Cypress.
This is needed as part of the Web3 Grant Delievery

git fetch origin
git checkout 40-integration-tests-and-framework


Cache widened types

Fixes #29902
Probably fixes #29564 (doesn't have a full repro)
Notably does not fix #29597 - that has some more stuff going on - chart.min.js is uuuuuuge.

@typescript-bot test this
@typescript-bot run dt
@typescript-bot user test this

@typescript-bot test this now that that lint is fixed 🤦♂

DT passes, as expected 🌞

@RyanCavanaugh All the test suites are gucci

@typescript-bot perf test this - this should make for some perf gains, even in older style code (but moreso in JS).

@weswigham
Do you think #31612 is related?
I think get an infinite loop, I have a repository+commit link in that issue with a repro (not minimal)

Considering this wasn't published in a nighly until around... Now? I doubt it? Unless you mean the new nightly fixes your problem and you think this fixed it.


typo in setup.py

it is common mistake. Nothing special, just another typo of "language" word.

Thanks!


[BUG][NOWEB] - SCAN_QR_CODE WhatsApp Notification Issue

Hello,
We are using NOWEB, and when we create SCAN_QR_CODE, the WhatsApp notification often doesn't appear, causing users to have issues linking their numbers. Could you assist us with this problem?

Does Copy Code work in your workflow? I remember WA apps doesn't allow to paste the code :thinking:

Could you try it on Dashboard? Also a suggestion - there's a manual flow if you don't get a notification, just remember to put this

Tested it with latest 2024.11.5 + Android latest WhatsApp - it works

Does the flow work at all when you attach it manually via steps on Dashboard?
Do you connect regular or Business account?
Could you test it on the latest WAHA + app?

I'll close the issue, feel free to add the details, we'll reopen if found the root cause !


broken link in ecolab/docs/demo.ipynb

In ecolab/docs/demo.ipynb replace
View all available imports in the code: https://github.com/google/etils/tree/main/etils/ecolab/lazy_imports.py;l=412

with
View all available imports in the code: https://github.com/google/etils/tree/main/etils/ecolab/lazy_imports.py#l=412

Also can you please add https://github.com/pgmpy/pgmpy


--no-prompt not working with ee site delete sitename

This issue tracker is only for issues related to EasyEngine. Please use http://community.rtcamp.com/c/easyengine for support questions.
running
sudo ee site delete ee1.MYDOMAIN --no-prompt
Are you sure you want to delete ee1.mycontent.top? [y/n]
If you feel the issue is a EasyEngine core specific issue, please attach the output of the following commands.
System Information

[ ] lsb_release -a
Ubuntu 18.04.1 LTS
[ ] ee cli version
EE 4.0.0-beta.6
[ ] ee cli info
+-------------------+----------------------------------------------------------------------------+
| OS                | Linux 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 |
| Shell             | /bin/bash                                                                  |
| PHP binary        | /usr/bin/php7.2                                                            |
| PHP version       | 7.2.11-2+ubuntu18.04.1+deb.sury.org+1                                      |
| php.ini used      | /etc/php/7.2/cli/php.ini                                                   |
| EE root dir       | phar://ee.phar                                                             |
| EE vendor dir     | phar://ee.phar/vendor                                                      |
| EE phar path      | /home/sspadmin/ee-sites                                                    |
| EE packages dir   |                                                                            |
| EE global config  | /opt/easyengine/config.yml                                                 |
| EE project config |                                                                            |
| EE version        | 4.0.0-beta.6
[ ] wp --allow-root --info
not found

@devbhosale This is an entirely a new version of EasyEngine, so the parameters for usage have been changed a little. As far as the backward compatibility is concerned, the site create parameters of EEv3 are accepted in EEv4. Apart from that there are slight changes in the parameters for other commands.
Until the documentation is completely prepared and launched, you can use ee help <command-name> or ee help <command-name> <sub-command-name>, in your case you can use ee help site delete for more info, for site delete specifically instead of --no-prompt, the new flag is --yes to skip the prompt.
Also, for other ee subcommands you can browse throught their README in each case or use ee help for more info. All the sub-commands have thier own repo. It would be helpful for us if you open issues regarding a particular command in it's own repo. You can browse through here to view all the command repos. Thank You, keep reporting issues, we would love to resolve them as soon as possible.

@devbhosale This is an entirely a new version of EasyEngine, so the parameters for usage have been changed a little. As far as the backward compatibility is concerned, the site create parameters of EEv3 are accepted in EEv4. Apart from that there are slight changes in the parameters for other commands.
Until the documentation is completely prepared and launched, you can use ee help <command-name> or ee help <command-name> <sub-command-name>, in your case you can use ee help site delete for more info, for site delete specifically instead of --no-prompt, the new flag is --yes to skip the prompt.
Also, for other ee subcommands you can browse throught their README in each case or use ee help for more info. All the sub-commands have thier own repo. It would be helpful for us if you open issues regarding a particular command in it's own repo. You can browse through here to view all the command repos. Thank You, keep reporting issues, we would love to resolve them as soon as possible.

@devbhosale This is an entirely a new version of EasyEngine, so the parameters for usage have been changed a little. As far as the backward compatibility is concerned, the site create parameters of EEv3 are accepted in EEv4. Apart from that there are slight changes in the parameters for other commands.
Until the documentation is completely prepared and launched, you can use ee help <command-name> or ee help <command-name> <sub-command-name>, in your case you can use ee help site delete for more info, for site delete specifically instead of --no-prompt, the new flag is --yes to skip the prompt.
Also, for other ee subcommands you can browse throught their README in each case or use ee help for more info. All the sub-commands have thier own repo. It would be helpful for us if you open issues regarding a particular command in it's own repo. You can browse through here to view all the command repos. Thank You, keep reporting issues, we would love to resolve them as soon as possible.

@devbhosale This is an entirely a new version of EasyEngine, so the parameters for usage have been changed a little. As far as the backward compatibility is concerned, the site create parameters of EEv3 are accepted in EEv4. Apart from that there are slight changes in the parameters for other commands.
Until the documentation is completely prepared and launched, you can use ee help <command-name> or ee help <command-name> <sub-command-name>, in your case you can use ee help site delete for more info, for site delete specifically instead of --no-prompt, the new flag is --yes to skip the prompt.
Also, for other ee subcommands you can browse throught their README in each case or use ee help for more info. All the sub-commands have thier own repo. It would be helpful for us if you open issues regarding a particular command in it's own repo. You can browse through here to view all the command repos. Thank You, keep reporting issues, we would love to resolve them as soon as possible.

@devbhosale This is an entirely a new version of EasyEngine, so the parameters for usage have been changed a little. As far as the backward compatibility is concerned, the site create parameters of EEv3 are accepted in EEv4. Apart from that there are slight changes in the parameters for other commands.
Until the documentation is completely prepared and launched, you can use ee help <command-name> or ee help <command-name> <sub-command-name>, in your case you can use ee help site delete for more info, for site delete specifically instead of --no-prompt, the new flag is --yes to skip the prompt.
Also, for other ee subcommands you can browse throught their README in each case or use ee help for more info. All the sub-commands have thier own repo. It would be helpful for us if you open issues regarding a particular command in it's own repo. You can browse through here to view all the command repos. Thank You, keep reporting issues, we would love to resolve them as soon as possible.

@devbhosale This is an entirely a new version of EasyEngine, so the parameters for usage have been changed a little. As far as the backward compatibility is concerned, the site create parameters of EEv3 are accepted in EEv4. Apart from that there are slight changes in the parameters for other commands.
Until the documentation is completely prepared and launched, you can use ee help <command-name> or ee help <command-name> <sub-command-name>, in your case you can use ee help site delete for more info, for site delete specifically instead of --no-prompt, the new flag is --yes to skip the prompt.
Also, for other ee subcommands you can browse throught their README in each case or use ee help for more info. All the sub-commands have thier own repo. It would be helpful for us if you open issues regarding a particular command in it's own repo. You can browse through here to view all the command repos. Thank You, keep reporting issues, we would love to resolve them as soon as possible.

@devbhosale This is an entirely a new version of EasyEngine, so the parameters for usage have been changed a little. As far as the backward compatibility is concerned, the site create parameters of EEv3 are accepted in EEv4. Apart from that there are slight changes in the parameters for other commands.
Until the documentation is completely prepared and launched, you can use ee help <command-name> or ee help <command-name> <sub-command-name>, in your case you can use ee help site delete for more info, for site delete specifically instead of --no-prompt, the new flag is --yes to skip the prompt.
Also, for other ee subcommands you can browse throught their README in each case or use ee help for more info. All the sub-commands have thier own repo. It would be helpful for us if you open issues regarding a particular command in it's own repo. You can browse through here to view all the command repos. Thank You, keep reporting issues, we would love to resolve them as soon as possible.


Feature: TypeScript Updates

Closes #23

Updated typing for Props.
Added typing for useCurrentWidth().
Added typing for useCurrentBreakpointName().
Cleaned up inconsistent indentation within the file.

@nutboltu Looks good to me. Do you may be want to review this PR?

@nutboltu I'll just go ahead and export an interface called DefaultBreakpoint. It will look like the following:
export interface DefaultBreakpoint {
  [key: string]: number
}

export function setDefaultBreakpoints(breakpoints: DefaultBreakpoint[]): void;

If you name it Breakpoint you'll get some errors from TS. Otherwise, love the library and would be glad to contribute if you guys need any help.

I updated the usage of that interface to be more inline with your project's coding style. Now it reads as the following:
export interface DefaultBreakpoint {
  [key: string]: number;
}

export function setDefaultBreakpoints(breakpoints: ReactSocks.DefaultBreakpoint[]): void;

I think DefaultBreakpoint a bit confusing naming as it seems it might be the default type. We can call it either BreakpointInterface or BreakpointType.
@flexdinesh and @dbryantm  What's your thought?

@nutboltu I agree, default sounds a bit misleading. @dbryantm thoughts?
We're close to merge. Once we get a fix on this naming, we could merge and release.

@flexdinesh @nutboltu, if I had to choose one I would go with BreakpointType. I can look at that sometime this morning and pass that along. Thanks!

@flexdinesh @nutboltu Fixed!

Changes published in v2.0.1. Thanks @dbryantm @nutboltu @guschnwg! 🎉

try to set up an breakpoint component, but get only this. Whats can be wrong?

Hi,
I'm experiencing the same issue as @glook.
When I take a look to the types I see :
interface Props<T = { [key: string]: boolean }> {
    children?: React.ReactNode;
    up?: boolean;
    down?: boolean;
    only?: boolean;
    tagName?: string;
    className?: string;
  }

Maybe there is something missing or wrong ?
I think we can type like (not really good) :
interface Props {
    [ key: string ]: React.ReactNode | boolean | string;
    children?: React.ReactNode;
    up?: boolean;
    down?: boolean;
    only?: boolean;
    tagName?: string;
    className?: string;
  }

Or simply can we declare the default breakpoints ?
interface Props<T = { [key: string]: boolean }> {
    children?: React.ReactNode;
    up?: boolean;
    down?: boolean;
    only?: boolean;
    xsmall?: boolean;
    small?: boolean;
    medium?: boolean;
    large?: boolean;
    xlarge?: boolean;
    tagName?: string;
    className?: string;
  }

What do you think guys ?
Thanks a lot,
Aurélien

@glook @sugardarius Would you be able to create a sample repo to replicate this error? Also can you double check if you're using the latest version v2.0.1?
I'll get a fix on this tomorrow.

@glook @SugarDarius, I've already been looking at the fix for that and should be creating a pull request shortly. It will just be pending review from @flexdinesh and @nutboltu. I believe we're going to have to change the typing of Props to be the following:
interface Props {
  children?: React.ReactNode;
  up?: boolean;
  down?: boolean;
  only?: boolean;
  tagName?: string;
  className?: string;
  [key: string]: React.ReactNode | string | boolean;
}

If you need a temporary fix you can create react-socks.d.ts in your src folder with the following contents:
import * as React from 'react';

export = ReactSocks;
export as namespace ReactSocks;

declare namespace ReactSocks {
  interface Props {
    children?: React.ReactNode;
    up?: boolean;
    down?: boolean;
    only?: boolean;
    tagName?: string;
    className?: string;
    [key: string]: React.ReactNode | string | boolean;
  }

  interface BreakpointProviderProps {
    children: React.ReactNode;
  }

  interface BreakpointAndModifierProps {
    breakpoint?: string;
    modifier?: string;
    tagName: string;
    className: string;
  }

  export interface BreakpointContextProps {
    currentWidth: number;
    currentBreakpointName: string;
  }

  export interface BreakpointType {
    [breakpoint: string]: number;
  }

  export function setDefaultBreakpoints(breakpoints: ReactSocks.BreakpointType[]): void;
  export function useCurrentWidth(): number;
  export function useCurrentBreakpointName(): string;

  export class Breakpoint extends React.Component<ReactSocks.Props> {
    static extractBreakpointAndModifierFromProps(allProps: ReactSocks.Props): ReactSocks.BreakpointAndModifierProps;
  }

  export class BreakpointProvider extends React.Component<ReactSocks.BreakpointProviderProps> {
    static handleResize(): void;
  }
}

Thanks @dbryantm. If you could create a PR I'll be able to review it in the morning. We'll verify and release a patch tomorrow.

@flexdinesh Done. You can view it at #26.

@glook @SugarDarius Fix released 2.0.2.
@dbryantm Thanks for the quick fix on this. Do you think we could create a TypeScript example code in examples dir? I would be able to review and run the changes in my local as well before release in case future issues like this pops up.

@flexdinesh , It would be nice to update our README.md where we need to update the import. as below
import { Breakpoint, BreakpointProvider } from 'react-socks';

Hello Guys,
Thanks a lot for fixing the issue :D
Have a good day,
Aurélien


I want to create line chart like this.

Hello, everyone.
I am learning flutter, and I am creating the simple flutter application.
I tried to add line chart like this, but I can't find the chart package for this one.
How can I create this chart?

Closing with the above comment, you have higher chance of getting help with questions at one of our communities such as StackOverflow


162 get documentation working

Resolves #162
Notable Changes:

Added site/

These files were pulled over from the gh-pages branch and will now be hosted within the same branch
They've been put in a subdirectory just to avoid a bit of clutter in the root
It has its own package.json & uses grunt for the build

Makefile

Publishes the docs

documentjs.json

This file was removed in a previous commit.

index.html

Pulled over from gh-pages and is the only part of that old branch that lives outside of site/

docs/ -> doc/

Existing web references are pointing to "docs" (from gh-pages), but since the two live together, we had to change one.  The raw .md files now live in doc/.

They've been put in a subdirectory just to avoid a bit of clutter in the root

Does this change the URLs?  If so that will cause SEO problems.

All of the generated /docs and /guides are still in the root (that's why I had to change the original docs/ to doc/.  The things in the site/ directory are all the assets for the site, the examples, the templates, and the demo app thing.


Readme update

Our readme seems some TLC. Modifications to this PR are welcome

Closing and resubmitting w/ single commit


boot fails with amdgpu kernel module

Boot fails when I add amdgpu module in booster.yaml
modules:
  -*,amdgpu,nvme,ext4,serio_raw,atkbd,xhci_pci,i8042,wmi,video,crc32c_generic,crc32c_intel

The last message I see on boot screen is Switching to the userspace now., wherein keyboard doesn't work.
Journalctl shows this errors:
$ jrc -kb -1 -o short-precise -p warning
Dec 18 14:09:22.016768 hp kernel: amdgpu 0000:04:00.0: loading /lib/firmware/amdgpu/green_sardine_sdma.bin failed with error -4
Dec 18 14:09:22.016838 hp kernel: amdgpu 0000:04:00.0: Direct firmware load for amdgpu/green_sardine_sdma.bin failed with error -4
Dec 18 14:09:22.016848 hp kernel: [drm:sdma_v4_0_early_init [amdgpu]] *ERROR* sdma_v4_0: Failed to load firmware "amdgpu/green_sardine_sdma.bin"
Dec 18 14:09:22.016856 hp kernel: [drm:sdma_v4_0_early_init [amdgpu]] *ERROR* Failed to load sdma firmware!
Dec 18 14:09:22.016864 hp kernel: [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* early_init of IP block <sdma_v4_0> failed -4
Dec 18 14:09:22.016918 hp kernel: amdgpu 0000:04:00.0: amdgpu: Fatal error during GPU init
Dec 18 14:09:22.016974 hp kernel: amdgpu: probe of 0000:04:00.0 failed with error -4

The file /lib/firmware/amdgpu/green_sardine_sdma.bin exists on disk, but I don't see any mention of it in logs when loading into mkinitcpio with amdgpu.
Kernel: x86_64 Linux 5.15.6-zen2-1-zen
CPU: AMD Ryzen 7 5800U with Radeon Graphics @ 16x 1.9GHz
GPU: [integrated] [AMD/ATI] Cezanne (rev c1)

This amdgpu issue suppose to be fixed by https://github.com/anatol/booster/issues/104
What is the content of mkinitpcio generated image? Does it even try to load the green_sardine_sdma.bin firmware? Could you please post the full listing of mkinitpcio image that works for you?

mkinitcpio.conf:
MODULES=(amdgpu nvme ext4)

HOOKS=(systemd autodetect)

Mkinitcpio content. I dont see any green_sardine_sdma.bin in logs when loading with mkinitcpio.

Thanks. So the bin file is in mkinitcpio version as well. It probably successfully and silently loaded and not printed to the logs.
$ jrc -kb -1 -o short-precise -p warning
Dec 18 14:09:22.016768 hp kernel: amdgpu 0000:04:00.0: loading /lib/firmware/amdgpu/green_sardine_sdma.bin failed with error -4
Dec 18 14:09:22.016838 hp kernel: amdgpu 0000:04:00.0: Direct firmware load for amdgpu/green_sardine_sdma.bin failed with error -4
Dec 18 14:09:22.016848 hp kernel: [drm:sdma_v4_0_early_init [amdgpu]] *ERROR* sdma_v4_0: Failed to load firmware "amdgpu/green_sardine_sdma.bin"
Dec 18 14:09:22.016856 hp kernel: [drm:sdma_v4_0_early_init [amdgpu]] *ERROR* Failed to load sdma firmware!
Dec 18 14:09:22.016864 hp kernel: [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* early_init of IP block <sdma_v4_0> failed -4
Dec 18 14:09:22.016918 hp kernel: amdgpu 0000:04:00.0: amdgpu: Fatal error during GPU init
Dec 18 14:09:22.016974 hp kernel: amdgpu: probe of 0000:04:00.0 failed with error -4

@hxss do you see any interesting debug messages before or inbetween these ^^ logs? Anything related to loading files/firmware/booster/...

And the error itself comes from kernel_read_file_from_path_initns() here  https://github.com/torvalds/linux/blob/abfecb39092029c42c79bacac3d1c96a133ff231/drivers/base/firmware_loader/main.c#L476
It is not clear why this function returns EINTR error.

I added full logs for booster and mkinitcpio in gist. Only info messages exist before the sardine error.

@ishitatsuyuki san maybe you have any ideas what is going on here

I'm running booster-git 21bafff (one commit behind master, from chaotic-aur) and it has been working fine.
@hxss Are you running the latest version? Try the git version if you have not already. If you have already updated, then try the following config:
modules_force_load: amdgpu

(This is the only line I have in config btw)

Yeah, it works with modules_force_load, thanks!
So the amdgpu fails only when I listed it in modules.
I tested 21bafff and 3d08a89.

Thanks for the help @ishitatsuyuki and @hxss
The difference between modules and modules_force_load is:

loading modules from the modules list is triggered by udev events. Once some hardware (e.g. AMD GPU) is detected then booster starts loading the corresponding module. modules_force_load starts loading at booster start independently of hardware and udev.
modules_force_load waits till its modules are fully loaded before switching to userspace. modules does not, any module from this list starts loading asynchronously and booster does not wait for its completion.

Item 2 is what triggers this problem. amdgpu is a heavy driver with firmware blobs. If it starts as part of modules it takes time to complete. In case of non-LUKS root partition its detection and mount happens quickly before amdgpu is fully loaded. It actually explains why loading firmware returns EINTR error. The load process is interrupted because booster process is killed while moving to userspace init. And in this case amd driver is half-loaded and it causes GPU issues.
I think that item 2 is too confusing for users. It should wait for modules loading completion from modules as well.

I added a possible fix for the root of this problem. With the commit above AMD GPU drivers should be able to boot even if it added to modules instead of modules_force_load.
@hxss please try wip branch, amd driver should be able to load successfully with your previous config (modules: amdgpu).

@anatol works great 👍

Thank you for confirmation  @hxss.
Note that modules_force_load is still the right way to pre-load GPU drivers. If amdgpu added to modules then there is race condition. Theoretically booster might mount root partition and switch to it before PCI enumerates GPU devices.


DesiredLength not working

Video Recording is not automatically stopping at the time set in DesiredLength
var file = await CrossMedia.Current.TakeVideoAsync(new StoreVideoOptions { Directory = "CameraAppVideos", DesiredLength = TimeSpan.FromMinutes(1) })
Version Number of Plugin: 3.0.1
Device Tested On: Nexus 5

Most likely device specific or camera that you are using doesn't support the feature. Works on my Nexus 6 without any issues and the default camera app.


[Simple AA in NewDot] Make sure optimistic Next Steps & report action are set for Control mid-level "Approvals" in NewDot

Tracking issue: https://github.com/Expensify/Expensify/issues/393839
Design doc section: Make sure optimistic Next Steps & report action are set correctly, for “Approve” (old term “Forward”) in NewDot
Goals:

Set optimistic next steps for approvals, when policy is Control and on Advanced Approval mode

Specifically new for mid-level approvers

Need to build basic approval chain from policy employeeList in order to be able to figure out who should optimistically be the next approval
Also needs to optimistically add Approved <total> report action to workspace chat

Background:
We currently generate optimistic Next Steps when approving a report in NewDot here. The current possible next steps are:

“Finished! No further action required”
“Next steps: Waiting for you to pay the expenses”

Problem:
There are now more possible cases when a report is getting approved!
When a Control policy has "Advanced Approvals" enabled, there can be multiple "mid-level" approvers. When these members approve the policy, we actually call this "forwarding" - because we "forward" the report to the next person in line. The final approver actually does the "approving".
Solution:

Build the report's approval chain any time someone approves a report on a Control workspace with advanced approvals enabled

Note: For v1 we will only consider submitsTo, forwardsTo, and overLimitForwardsTo. Later, we'll add in rule approvers (tag & category)

Optimistically add a report action saying approved <total> even when forwarding the report

Approval Chain Logic:
When building out the approval chain logic, logic should look like this:

Get policy's employeeList
Get report submitter, get their policy data with employeeList[submitterEmail]
The first member of the approval chain is the employee's submitsTo - like submitsToEmail = employeeList[submitterEmail]?.submitsTo ?? policyOwnerEmail
Next, get the submitsTo person's policy data with submitsToEmployeeData = employeeList[submitsToEmail]
From here on, we get the next approver by looking at forwardsTo, overLimitForwardsTo, and approvalLimit

If submitsToEmployeeData has an approvalLimit and overLimitForwardsTo, do this:

Get the report total
If the report total is > approvalLimit, then the next approver in line is the email address in submitsToEmployeeData?.overLimitForwardsTo
If the report is <= approvalLimit, then the next approver in line is submitsToEmployeeData?.forwardsTo

If submitsToEmployeeData doesn't have either approvalLimit or doesn't have overLimitForwardsTo, the next approver in line is submitsToEmployeeData?.forwardsTo
Note: If we ever run into a missing approver here (a.k.a. if submitsToEmployeeData doesn't have a forwardsTo), we're done!

Now we get the forwardsTo or overLimitForwardsTo's policy data with forwardsEmployeeData = employeeList[forwardsToEmail]
Repeat steps 5 & 6 until you either:

End up with an email address you already added to the approval chain
Run into some employee's data that doesn't have a forwardsTo

This looks something like this:

Where $policy->getForwardsTo looks like this:

Examples:
Say, for example, we have this Control employeeList policy setup (with advanced approvals enabled):

Member Email
policy role
submitsTo
forwardsTo
overLimitForwardsTo
approvalLimit

<EMAIL_ADDRESS>admin
<EMAIL_ADDRESS>

<EMAIL_ADDRESS>admin
<EMAIL_ADDRESS>

<EMAIL_ADDRESS>employee
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>10000

<EMAIL_ADDRESS>employee
<EMAIL_ADDRESS>

<EMAIL_ADDRESS>employee
<EMAIL_ADDRESS>

Each member's approval chain looks like this:

Policy Member
Approval Chain (if report total <= approvalLimit)
Approval Chain (if report total > approvalLimit)

<EMAIL_ADDRESS><EMAIL_ADDRESS>same

<EMAIL_ADDRESS><EMAIL_ADDRESS>same

<EMAIL_ADDRESS><EMAIL_ADDRESS>same

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

Keeping internal for now, will make this external soon once all details are added here

Gotta get the held issue done, then will open this up!

I think we're off hold! cc @Beamanator yeah?

Hmm yes this is off hold, @youssef-lr I don't think we need you on this one since it can be worked externally (see my messages above) - I'm planning to finish writing up the necessary details & assigning this one out today or tomorrow!

Asked @rushatgabhane for a review of the requirements to make sure it makes sense 🙏

Okay so I was able to build the approval chain and it tests well for employee, manager, and both owners -

@Beamanator it is okay to always make the reportTotal a positive number, right?

The accounts owed money, so the report total was -X

@Beamanator I've added optimistic steps in the PR, but I'm facing a backend issue.
When a manger approves the report, im getting a 400 error for ApproveMoneyRequest.

https://github.com/Expensify/App/assets/29673073/ff581cb8-93f8-4e05-9387-ec29767c6323

@rushatgabhane it looks like that is thrown when our backend thinks you're trying to "Forward" the report, but you SHOULD be trying to "Approve"
This is actually expected for right now, since @marcochavezf is working on adding changes so that mid-level approvers can always "Approve" OR "Forward" a report from NewDot. So you probably can't actually test out the full "Submitter -> submitsTo -> forwardsTo" approval flow YET (with the backend working) but you can test that it optimistically works probably?

@Beamanator yeah optimistic is no problem :)
It works offline

Groovy - but ya probably sadly we can't get your PR merged till the backend stuff is done. sorry for that, thanks for getting this done quick!

working on adding changes so that mid-level approvers can always "Approve" OR "Forward" a report from NewDot

makes sensee, thank you for digging into it : )

Groovy - but ya probably sadly we can't get your PR merged till the backend stuff is done. sorry for that, thanks for getting this done quick!

No worries

Can we state what issue/PR this is on hold for in the title, so that's clear?

^^ bump on the above! :)

Sorry for the delay! We're basically holding on https://github.com/Expensify/Expensify/issues/404206, where @marcochavezf will be enable clicking Approve (no matter if it's approving or forwarding) in NewDot

Still held.

Still held, but getting close!

Can we remove the hold based on Marco's most recent merged PRs?

https://expensify.slack.com/archives/C06ML6X0W9L/p1722354497413689?thread_ts=1722319732.404769&cid=C06ML6X0W9L - according to @Beamanator not quite, but Marco's Web PR in the linked issue is on staging, so I think we're pretty much there.

Ooh yes even the App PR is on staging! I think it's time to take this off hold!

@rushatgabhane can you pull main & start testing on staging? 🙏  there may be a few bugs which @marcochavezf and I can work out, but as long as this optimistic stuff can be tested now, that would be amazing 🙏

Boom this is completely off hold as the ApproveMoneyRequest stuff should be on prod!

PR was most likely deployed to prod yesterday

I thinkkkk payment is due here 🚀

Okay, so this is the PR: https://github.com/Expensify/App/pull/44940

What happened here with the review, it was merged before @mananjadhav's C+ review, but completed after, hence no checkmark? 🤔
Was this considered a regression?

What happened here with the review, it was merged before @mananjadhav's C+ review, but completed after, hence no checkmark? 🤔

Yep exactly 👍

Was this considered a regression?

Hmm seems like ifffff it was, we didn't consider it a big deal since it hasn't been worked on yet, so i would say we don't need to consider that a payment slashing regression, what you think?

Alright, so payment summary as follows:

$250 to @rushatgabhane for the fix
$250 to @mananjadhav for the C+ review

Closing it out!

$250 approved for @rushatgabhane

$250 approved for @mananjadhav


sai: sai_v1 patch and sai peripheral apply to H7. Fix FSDEF

SAI peripheral applies to the H7 also. Note that we introduce the very slightest difference with RM0433 (single core 743/753) by setting [AB]CR1.NOMCK -> [AB]CR1.NODIV. Whilst RM0433 uses NOMCK, both RM0399 (later dual core parts) and sai/sai.py use NODIV.
The description in sai/sai.py has text from both the old and new definitions, and it appears the functionality of the bit is unchanged.
[AB]FRCR.FSDEF is marked as read only in the SVD and the register diagram in the RM. However, in the prose text in RM0399 it is clearly noted as read-write "This bit is set and cleared by software."

Ugh, a pain that they renamed the bit. I'm a little hesitant to rename valid bits in the older devices just to match the existing peripheral file, but if this also makes life easier for HALs it might be worth doing. Any thoughts?

Pragmatically the answer is to rename it for consistency, but it does break the rule of matching  the best interpretation of the RM. My opinion is the RM isn't invariant either (ST release new versions!), nothing will ever be perfect, practicality wins in a trivial case like this..


:bug: Modify the kafka HA by operand

Summary
When I set the availability with Basic mode
apiVersion: operator.open-cluster-management.io/v1alpha4
kind: MulticlusterGlobalHub
metadata:
...
spec:
  availabilityConfig: Basic
  dataLayer:
    kafka:
      topics:
        specTopic: gh-spec
        statusTopic: gh-status.*
    postgres:
      retention: 18m
  enableMetrics: true

Still get the high availability configuration of the Kafka cluster
❯ oc get pods
NAME                                                READY   STATUS    RESTARTS   AGE
inventory-api-5547c8fb4-h9mgx                       1/1     Running   0          25m
kafka-entity-operator-7774786575-69lfj              2/2     Running   0          26m
kafka-kafka-0                                       1/1     Running   0          26m
kafka-kafka-1                                       1/1     Running   0          26m
kafka-kafka-2                                       1/1     Running   0          26m
kafka-zookeeper-0                                   1/1     Running   0          27m
kafka-zookeeper-1                                   1/1     Running   0          27m
kafka-zookeeper-2                                   1/1     Running   0          27m

Related issue(s)
Fixes #
Tests

[ ] Unit/function tests have been added and incorporated into make unit-tests.
[ ] Integration tests have been added and incorporated into make integration-test.
[ ] E2E tests have been added and incorporated into make e2e-test-all.
[ ] List other manual tests you have done.

/test test-integration

Did you test switch from High to Basic?
@hchenxa any risks for your view? Thanks.

@clyang82 I am not sure if the issue https://strimzi.io/blog/2024/01/03/prevent-broker-scale-down-if-containing-paritition-replicas/ will be happened when scale down the brokers.
why we want to scale down the kafka??

I'm testing on it, the kafkatopic does not support scaling the replicas, but the Kafka and Zookeeper cluster seems can.
status:
  conditions:
  - lastTransitionTime: "2024-09-27T01:42:03.095201991Z"
    message: Replication factor change not supported, but required for partitions
      [0]
    reason: NotSupported
    status: "False"
    type: Ready
  observedGeneration: 2
  topicId: KwkoLLGtRpGCGKu_r7T2fQ
  topicName: gh-status.global-hub

After discussing with @clyang82 , We will not support the HA configuration for the Kafka cluster


Turn off CNP node status GC when CNP status updates are disabled.

CNP Node Status GC was still running in cilium-operator even though by default CNP Node Status updates were disabled.
This GC periodically made unnecessary API calls (one call per 10 policies) to k8s apiserver, which were going directly to underlying Etcd.
Disable by default CNP Node Status GC in cilium-operator.

/test


Migrate existing submissions data

Context
Currently the system does not have the existing metadata for submissions data. Need to pull over and archive previous submissions data in cloud.gov.

@JanellC add more context on why we are doing this work

@JanellC can we talk about this ticket DSU Thursday? We need to add more details, thanks.

@jwhitehead77 add information on what needs to be completed here. DPC will complete this work


Warn user that they won't be able to sign back in if they sign out while offline

Currently we only warn that unsynced data will be lost. We should also inform the user that:

Offline surveys will no longer be available until their sign back in
They won't be able to sign in until they're back online

@amegantz Suggestions here?

If you sign out:

Any unsynced data will be discarded
You won't be able to sign in if you’re offline
Offline surveys won’t be available until you sign in again

Are you sure you want to sign out?

Need to add that you can't log back in if offline


SPIKE -- Understand Needs and Potential Solutions for Managing Values & Value Sets

Problem Statement
Let's get with Mo to understand where we are with moving the values to the DB and what the needs are for managing them.

@sean-usds do you have enough information from our meeting with the other teams to create some tickets for this epic? Here is the mural board to refresh your memory

@loripusey do you have a sense of which value sets need are edited most frequently? That'll help prioritize where we start.
@drew-usds we can start on something fast and loose here similar to settings admin UI, but wanted to put this on your radar since we'll eventually want UI design input

@sean-usds values sets edited most often would be a good question to ask @mauricereeves and @rhood23699

Notes from 1/10

Goal it move off value sets and move to lookup tables
Can prioritize building support for editing lookup tables
Lookup tables already have an API

Supports full CRUD
Doesn't edit, just replaces records (can make it slow)
No lock version support

Assumption is that Rick Hood will be primary (only) user
Database has been replaced with command line tools
Can load lookups from csv tables
Should support field validation
One use case is supporting uploading a csv to a table
Use case 1: tweak

Pull current version, make a tweak, send it back

Use case 2: bigger table changes

Table lookups are defined in a csv locally, csv need to be uploaded

Zip code table

Ideal to pull all data into the browser so missing zips can be searched for
If zip is missing, it can be added in the web UI

Right now the API doesn't support editing one row, just updating the entire table
Web UI could start with small tables

Example: Dr name lookup based on facility

Small tables that would be good to start with: dr lookup, sender automation value set (seth), LIVD supplemental
API should support looking up all table name options
Large table examples:

HCA, need to expand to all body parts (will be thousands of records). Official version is on SNOMED
Specimen type, source
Possible tests (all reportable diseases)

Rick is initial customer

I broke the work into eng tasks that can be seen in the epic https://app.zenhub.com/workspaces/experience-607d9d5e68b95200150fec37/issues/cdcgov/prime-reportstream/3489