create a gpu metrics (internal) registry

if this approach is palatable, this can be rolled to other areas as well
the objective is to separate the cpu and gpu implementations (where they digress significantly) such that they evolve independently. to that end, this approach will:

preserve the same metrics configuration (from the end user perspective)
internally delegate the responsibility to the gpu metrics builder when there is a
valid device present
decouple the gpu metrics builder from the cpu ones to prevent misuse (thus not impacting other areas of the code). the locality of gpu reference is strictly within the metric builders registered with the metric registry
move away from including the cuda file from within the cc file and segregate the code
via ifdef's

next, i'll create a pr for the ranking metric implementation on the gpu
@RAMitchell @trivialfis - please review

the objective is to separate the cpu and gpu implementations (where they digress significantly) such that they evolve independently

Do you have a concrete use case in mind?
@sriramch

Codecov Report

Merging #5387 into master will increase coverage by 0.12%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5387      +/-   ##
==========================================
+ Coverage   84.07%   84.19%   +0.12%
==========================================
  Files          11       11
  Lines        2411     2411
==========================================
+ Hits         2027     2030       +3
+ Misses        384      381       -3

Impacted Files
Coverage Δ

python-package/xgboost/tracker.py
95.18% <0.00%> (+1.20%)
:arrow_up:

Continue to review full report at Codecov.

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

the objective is to separate the cpu and gpu implementations (where they digress significantly) such that they evolve independently

Do you have a concrete use case in mind?
@sriramch

@hcho3 the metrics and the objective ranking implementations are the ones i'd in mind for this.

In other situations like this we have been deferring configurations of GPU/CPU algorithms to the learner and I'm wondering if we should do the same here. The learner holds most information about the learning task and configuration and might be better suited to dispatching the correct algorithm.

[sc] the reason i did this here is for the specific component - metric/objective etc. to choose independently if it needs to be accelerated on the gpu, as opposed to having the learner choose it for them. not all metrics are accelerated on the gpu and it was best left for that metric to decide independently.

Another disadvantage of this approach is having to define duplicated code in each CPU metric for dispatching GPU algorithms.

[sc] further, even within a given metric, we only move the computation on the gpu only when a certain condition is met. this also has to be decided independent on a metric-by-metric (or by a component) basis by that component. punting all this to the learner could increase coupling significantly.

Possibly another way to do this without the registry would be to create metrics.h metrics.cc metrics.cu, put the struct EvalAuc : public Metric declaration in the header and define methods for GPU/CPU computation, with implementations in respective cc/cu files. I guess this only works when the class has no GPU only member variables.

Possibly another way to do this without the registry would be to create metrics.h metrics.cc metrics.cu, put the struct EvalAuc : public Metric declaration in the header and define methods for GPU/CPU computation, with implementations in respective cc/cu files. I guess this only works when the class has no GPU only member variables.

[sc] some of the metrics use the template method pattern that drives the logic in one place, and deferring part of functionality to the sub classes or other meta types (to prevent virtual on device). this can get hairy with this approach.
the gpu registry approach keeps it fairly isolated and can easily delegate responsibility to the gpu classes as long as they are registered with the same name as their cpu counterparts (which is its only requirement). what is the main objection to this approach (other than that it is non traditional)?

In other situations like this we have been deferring configurations of GPU/CPU algorithms to the learner

Please don't.  The Learner is already very complicated as it's.
Just out of curious, why do we need a class to carry out computing metric?  Looking through the code there's no class states.  Looking at https://github.com/dmlc/xgboost/pull/5326 , the whole class is just a function.

Just out of curious, why do we need a class to carry out computing metric? Looking through the code there's no class states. Looking at #5326 , the whole class is just a function.

[sc] the metric class has state and there is ranking config (parsed out of the metric name). these can evolve, and if we made them as free functions, we would have to pass them all to every metric function that is supported on the gpu. hence, they do have some state.
further, upon looking closely, i find that this pattern isn't without precedent. it looks like page formats, tree io etc. all leverage the registry mechanics to cleanly delegate responsibility.


Ignoring checkstyle autogenerated files

Tables under root table are created with internal indexes on (did) and on (did, seq).

Current coverage is 10.49% (diff: 12.50%)

Merging #117 into devel will decrease coverage by <.01%

@@              devel       #117   diff @@
==========================================
  Files           649        649
  Lines         24682      24683     +1
  Methods           0          0
  Messages          0          0
  Branches       2760       2761     +1
==========================================
  Hits           2590       2590
- Misses        21840      21841     +1
  Partials        252        252

Powered by Codecov. Last update 89bc650...68c7590


DoChat failed to start after system reboot

Ubuntu 20.04. DoChat occasionally fails to start after system reboot. Removing HOME/DoChat/Applcation Data/Tencent/WeChat/All Users/config/configEx.ini directory resolves the issue.

Thank you very much for submitting this issue and provide PR for fixing it!
Could you please share the configEx.ini content by posting it to this issue so that we can learn more from this case?
It would be more helpful if you can post the before and after so that we can get more details about it!

Thank you very much for submitting this issue and provide PR for fixing it!
Could you please share the configEx.ini content by posting it to this issue so that we can learn more from this case?
It would be more helpful if you can post the before and after so that we can get more details about it!

There is no official doc from the WeChat team regarding how this file works, but I managed to collect the following clues:

On a clean installation of DoChat, this file does not exist. Nor is it generated immediately. It is only produced after some time of running, which I believe means that it is not essential for starting DoChat (or I guess in general WeChat on Windows).
Googling "微信 configex.ini" suggests misconfiguration (not necessarily by user, but could be by WeChat itself, maybe during update) in this file could lead to WeChat not able to run on Windows 10.
A zhihu user reported a similar issue to Tencent and got a call back. He/she resolves it by delete this same file, but did not explicitly say if this was done following Tencent's support instructions.
The wechat package for Arch Linux seems to delete this file as well. See countstarlight/deepin-wine-wechat-arch#1 Though I have not been able to locate the exactly line to handle this.

There is no official doc from the WeChat team regarding how this file works, but I managed to collect the following clues:

On a clean installation of DoChat, this file does not exist. Nor is it generated immediately. It is only produced after some time of running, which I believe means that it is not essential for starting DoChat (or I guess in general WeChat on Windows).
Googling "微信 configex.ini" suggests misconfiguration (not necessarily by user, but could be by WeChat itself, maybe during update) in this file could lead to WeChat not able to run on Windows 10.
A zhihu user reported a similar issue to Tencent and got a call back. He/she resolves it by delete this same file, but did not explicitly say if this was done following Tencent's support instructions.
The wechat package for Arch Linux seems to delete this file as well. See countstarlight/deepin-wine-wechat-arch#1 Though I have not been able to locate the exactly line to handle this.

Thank you very much for providing these reference links, they are very valuable because it can help us keep understanding what files do what in the future!
Have a good day, and I hope your update can help our DoChat to be more robust in the next version.

Thank you very much for providing these reference links, they are very valuable because it can help us keep understanding what files do what in the future!
Have a good day, and I hope your update can help our DoChat to be more robust in the next version.


Reflect GPC choices in the privacy center

As a user, when I have a global privacy control signal, then I want my opt-out status reflected the first time a visit the privacy center, so that I can confirm the signal is being respected.
AC

Given that I have a global privacy control opt-out signal set on my browser, when I access a Fides privacy center, then I am automatically opted out of any use cases which are indicated as use cases in the privacy center.
Given that I have a global privacy control opt-out signal set on my browser, when I access a Fides privacy center and the default consent choices are set according to GPC, then I see an indicator on each use case telling me that I am opted out because of GPC.

Designs
https://www.figma.com/file/dmEwdK3xZwjKfGVQ9t66xe/Fides-v.2-Master-Working-Files?node-id=1680%3A33346
1/11/23 - Linked designs are WIP.

For the first time user - we opt follow the GPC signal and opt them out of use cases automatically.
For returning users that have a consent preference saved with their identity - we show the saved consent and then update the use case indicators appropriately if there is a conflict with GPC.
Indicators:

Pausing to work on some bugs, left off on this branch: https://github.com/ethyca/fides/compare/ssangervasi/fides/2230/pc-gpc-ui

enabled

disabled


LIBDRUM-662. Restoration of "Unit" functionality

Update of "Unit" functionality for DSpace 7.
https://issues.umd.edu/browse/LIBDRUM-662

Closing without merging as this pull request has been superseded by Pull Request #157


Website

Before submitting a PR please:

Make sure you have based your branch off the dev branch.
Submit your PR against the dev branch.
Run npm run build and check that the build succeeds.
Ensure that the PR hasn't been submitted before.

PR Template
Objective
This PR...
Closes Issue
It closes Issue #...

The build fails for this PR.

@trueadm Are you happy with the the change in .gitignore?

@LukeSheard fine with me


Fixed Table header

I have a long table content. So scrolling down is making the header to go up and as a user, I am not able to see the header. So can I fix the header?

@Sandip-pal, try to configure height on <BootstrapTable>, default is 100%, so there's no any vertical scroll bar there.
Let me know if you still have any question :)


fix User is able to add new tax rate using deep link

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/42925
PROPOSAL: https://github.com/Expensify/App/issues/42925#issuecomment-2143543949
Tests

Pre-requisite:
Account should be integrated with a xero account which already had configured some taxes

Open app
Import taxes on Accounted page if not already imported
Go to taxes page and deep link to add new tax rate page (i.e change the url to look like this: https://staging.new.expensify.com/settings/workspaces/<WORKSPACE_ID>/taxes/new
Verify not found page shows up

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/113963320/ae9b9636-7866-4151-838f-dbbf5f3d55de

Android: mWeb Chrome

https://github.com/Expensify/App/assets/113963320/b2885dbe-050e-4243-ae7c-70c2ca1f8457

iOS: Native

iOS: mWeb Safari

https://github.com/Expensify/App/assets/113963320/de0331df-1eda-4a0e-8f37-e8ac0e7e66e9

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/113963320/e09a7d69-9f64-47ee-b976-9500c72d6be5

MacOS: Desktop

https://github.com/Expensify/App/assets/113963320/5a1a71fb-ae69-4062-9e2f-b7a46b870006

🚀 Deployed to production by https://github.com/luacmartins in version: 1.4.81-11 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


feat: add vercel-blob driver

resolves https://github.com/unjs/unstorage/issues/264

Is there anything I can do to help get this merged? @pi0

@pi0 Can this be merged or is anything missing? Vercel is VERY popular and they have their own file storage Vercel Blob

Vercel blob uses upstash redis and upstash driver  is available on nightly channel (via #500) and soon the next release, which gives same functionality.
While Vercel blob is still in Beta, there is a chance that it will be merged to upstash directly.
(PR, please read this before asking for "merge" 🙏🏼)

Thanks for PR. I've pushed a few refactors and improvements.
While tests pass against prod, what really concerns me is that we have to make every piece of data publicly accessible, and implementation also requires that we disable random suffixes.
I've added a warning to docs and runtime also but still users might mistakenly leak private info as only and only this driver on server-side has this behavior today. (netlify Blob for example in contrast, AFAIK encrypts and makes them always private).
I will contact vercel team as followup but in the meantime, anyone can directly use @vercel/blob in their projects and there is KV storage as well powered by upstash.

Update: Private access will eventually be supported.
For now updated driver to require access: "public" config explicitly to make sure devs know the fact.


New version: AWSS3 v0.6.3

Registering package: AWSS3
Repository: https://github.com/JuliaCloud/AWSS3.jl
Created by: @mattBrzezinski
Version: v0.6.3
Commit: 68aca91dbf4aee50a35ef23e9ec0c9d104d5731a
Reviewed by: @mattBrzezinski
Reference: https://github.com/JuliaCloud/AWSS3.jl/commit/68aca91dbf4aee50a35ef23e9ec0c9d104d5731a#commitcomment-35710186

Your new version pull request does not meet all of the guidelines for automatic merging.
Specifically, your pull request does not meet the following guidelines:

The following dependencies do not have a compat entry that has an upper bound: DataStructures, EzXML, HTTP, MbedTLS, Retry, SymDict, XMLDict

If you want to prevent this pull request from being auto-merged, simply leave a comment.
(If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.)

It is important to note that if your pull request does not meet the guidelines for automatic merging, this does not mean that your pull request will never be merged. It just means that your pull request will require manual review by a human.

These guidelines are intended not as requirements for packages but as very conservative guidelines, which, if your new package or new version of a package meets them, it may be automatically merged.

On a separate note, I see that you are registering a release with a version number of the form v0.X.Y.
Does your package have a stable public API? If so, then it's time for you to register version v1.0.0 of your package. (This is not a requirement. It's just a recommendation.)
If your package does not yet have a stable public API, then of course you are not yet ready to release version v1.0.0.

[noblock]


Devicetree doc improvements 2022 04

@MaureenHelm if you have any suggestions for the 3rd patch in particular, I'd appreciate them. I'm trying to avoid going around and around on how default is used, and sensor driver devicetree bindings reviews are the place where I have to do that the most. This docs PR is in attempt to make this easier on contributors.

@mbolivar-nordic can you rebase this please?

@mbolivar-nordic can you rebase this please?

@carlescufi done

Can you give an example of some properties that you'd advise against defining a default due to a dependency?

@MaureenHelm this rule was originally suggested by Peter Bigot. If we have
properties:
   foo: ...
   bar: ...

And changing foo from its power on reset value can only be done safely with an accompanying change in bar, then his argument was that making them both required forces the user to make a conscious choice, whereas allowing defaults for both foo and bar would allow the user to change foo without also having to change bar at build time, resulting in an incorrect configuration.
I find the argument convincing but don't know of any hardware like that off the top of my head.


[Metrics] Improvements to Powertools Metrics

Is your feature request related to a problem? Please describe.
The following requests are based on a recent experience I had using Powerttools Metrics having used https://github.com/awslabs/aws-embedded-metrics-java in different projects before and the workarounds we had to implement and hoping they should be taken care of by Powertools so we can move our older projects to Powertools and have a consistent experience among the different projects.
As such, I'll mention a few points below
Describe the solution you'd like

Improve documentation/warnings about the fact that powertools annotations require the Lambda handler method to be called handlerRequest

I use CloudGuru Profiler with the setup described in https://docs.aws.amazon.com/codeguru/latest/profiler-ug/lambda-custom.html. This implementation overrides/hides handleRequest and instead exposes requestHandler method that users should override to add their logic
It took me a lot of time debugging/investigating this; time that could've been saved if there was better documentation or warnings about where the annotations are.
My workaround was to create a new BaseHandler that extends RequestHandlerWithProfiling, override handleRequest calling super.handleRequest and annotating it with the powertools annotations. Then implementing my concrete handlers as subclasses of BaseHandler

Metrics emitted by MetricsUtils.metricsLogger should have a property for the requestId

The Metric EMF entity emitted does not contain a property for the requestId. It has other useful things like traceId
I think the LambdaMetricsAspect can be updated to add a requestId property by default

Metrics emitted by MetricsUtils.metricsLogger should allow dimensions to be overriden or unset

By default, they get the following dimensions "Dimensions":[["LogGroup","ServiceName","ServiceType","Service"]].
For ServiceName and Service; that's unnecessary, I believe one to be coming from the EMF Library and the other from Powertools

https://github.com/awslabs/aws-embedded-metrics-java/blob/master/src/main/java/software/amazon/cloudwatchlogs/emf/logger/MetricsLogger.java#L174
https://github.com/awslabs/aws-lambda-powertools-java/blob/master/powertools-metrics/src/main/java/software/amazon/lambda/powertools/metrics/internal/LambdaMetricsAspect.java#L51

We in our existing setups with EMF, we don't find value in any of those default dimensions. We're simply able to override them using setDimensions() and giving it zero arguments if we don't need any of the default dimensions. Unfortunately this cannot be done for Powertools MetricsUtils.metricsLogger() as it fails validation if dimensions count is equal to 0

MetricsUtils.withSingleMetric should have improved properties and namespace configs

withSingleMetric requires the setting of a namespace. In most cases, one would want to use the default namespace which is not easily accessible (beyond grabbing it explicitly from the environment variables). I believe there should be a version of this method which simply reuses the namespace configured for MetricsUtils.metricsLogger
withSingleMetric should also add the requestId property
In our projects that use EMF, we have an abstraction similar to MetricsUtils. It provides the same general capabilities - a default metricsLogger that gets flushed at the end of a request + one off metrics. The one thing we have on top of that is that we're able to set some default properties that will be written to both types of metrics e.g. defaultProperties that we can append to at any time. It adds to the MetricsUtils.metricsLogger, but gets applied to the equivalent of withSingleMetrics when they're instantiated. This allows us to have a consistent set of properties common across all our EMF metrics.

Additional context
It's likely that each of topics above should be addressed in a different issue and I'm happy to break it down further if you think that's useful.
I'm also happy to attempt to contribute after discussions if needed.

Thanks for this great feedback!

Really great feedback @humanzz , If you are happy to contribute, we will be more than happy to take above suggestions. If not,  I will spend some time next week incorporating some of those.

MetricsUtils.withSingleMetric should have improved properties and namespace configs
withSingleMetric should also add the requestId property

I believe since we expose logger object as a Consumer function, clients of the API have access to it and thus can always set requestId or any other related property on for the emf logger.

Thanks everyone. Really appreciate the prompt actions on addressing the feedback.
@pankajagrawal16
I've left you a comment on https://github.com/awslabs/aws-lambda-powertools-java/pull/305
I do get the concern around over complicating things with the last quoted paragraph. I wouldn't call this a must have, it's easily achievable on user-side by wrapping the MetricsUtils if some users want to use this.
I think the 2 most important things on my mind right now are

All metrics from MetricsUtils should have properties for requestId and traceId. This ensures good observability and tracing
All metrics from MetricsUtils should enable overriding the default dimensions to set them to no dimensions

Thanks everyone. Really appreciate the prompt actions on addressing the feedback.
@pankajagrawal16
I've left you a comment on #305
I do get the concern around over complicating things with the last quoted paragraph. I wouldn't call this a must have, it's easily achievable on user-side by wrapping the MetricsUtils if some users want to use this.
I think the 2 most important things on my mind right now are

All metrics from MetricsUtils should have properties for requestId and traceId. This ensures good observability and tracing
All metrics from MetricsUtils should enable overriding the default dimensions to set them to no dimensions

I agree with the thoughts. Default dimension part is something which I will have a look at next. This has been one of items that I have wanted to fix for a while already and now that we have community feedback as well around it, I sure will.

I believe most of these suggestion are incorporated except for point 3

Awesome progress. Thanks a lot @msailes and @pankajagrawal16
I have a couple of comments to add

Re #3 (the ability to remove the default dimensions)

@msailes mentioned it might be a good idea to open an issue for EMF library to consider dropping those default dimensions - or simply add them as properties
My feeling is that this will likely take sometime. Meanwhile, the ability to override the dimensions for all MetricsUtils loggers would be really appreciated. It allows us users to be in control if we want to override it and remove dimensions

Regarding requestId and traceId, I think between logging and metrics, they have different field names which is not ideal because ideally I - as a user - would want to use requestId or traceId to filter for all log entries in CloudWatch Logs Insights. When the field names between logging and metrics are different this unnecessarily complicates such types of queryes

Metrics: https://github.com/awslabs/aws-lambda-powertools-java/blob/master/powertools-metrics/src/main/java/software/amazon/lambda/powertools/metrics/internal/LambdaMetricsAspect.java#L31
Logging

https://github.com/awslabs/aws-lambda-powertools-java/blob/master/powertools-logging/src/main/java/software/amazon/lambda/powertools/logging/internal/DefaultLambdaFields.java#L45
https://github.com/awslabs/aws-lambda-powertools-java/blob/master/powertools-logging/src/main/java/software/amazon/lambda/powertools/logging/internal/LambdaLoggingAspect.java#L91

Regarding requestId and traceId, I think between logging and metrics, they have different field names which is not ideal because ideally I - as a user - would want to use requestId or traceId to filter for all log entries in CloudWatch Logs Insights. When the field names between logging and metrics are different this unnecessarily complicates such types of queryes

Metrics: https://github.com/awslabs/aws-lambda-powertools-java/blob/master/powertools-metrics/src/main/java/software/amazon/lambda/powertools/metrics/internal/LambdaMetricsAspect.java#L31

Logging

https://github.com/awslabs/aws-lambda-powertools-java/blob/master/powertools-logging/src/main/java/software/amazon/lambda/powertools/logging/internal/DefaultLambdaFields.java#L45
https://github.com/awslabs/aws-lambda-powertools-java/blob/master/powertools-logging/src/main/java/software/amazon/lambda/powertools/logging/internal/LambdaLoggingAspect.java#L91

Makes sense, Since Logging already had those fields, it will make sense to just reuse the same names for metrics module. I will fix that before new release

I have a couple of comments to add

Re 3 (the ability to remove the default dimensions)

@msailes mentioned it might be a good idea to open an issue for EMF library to consider dropping those default dimensions - or simply add them as properties
My feeling is that this will likely take sometime. Meanwhile, the ability to override the dimensions for all MetricsUtils loggers would be really appreciated. It allows us users to be in control if we want to override it and remove dimensions

Yeah rite, thats the next thing which I plan to look at next. It might be a good idea to open a issue on EMF lib as well so that we can simplify powertools implementation once its natively available as well

My personal taste would be for the new names used in metrics to be honest but it's not a big deal if we don't go with that option

My personal taste would be for the new names used in metrics to be honest but it's not a big deal if we don't go with that option

Yeah, But in order to avoid this being a break change for logging clients, it makes sense to reuse the same for metrics lib.

I agree - from a compatability point of view - but I still do think the new names are slightly better so I wonder if we can either/or

Emit both and mark something as deprecated for a few versions
Have a separate issue to track these names for an upcoming major version that might introduce breaking changes

Regardless, unification is that thing we should go for.

@humanzz Most of the stuff is available in 1.3.0 now. I will keep this open for fixing the last bit on default dimensions.

That's great, about the dimensions @pankajagrawal16
Will you also support overriding to set no dimensions?

That's great, about the dimensions @pankajagrawal16
Will you also support overriding to set no dimensions?

Not at this point. Since this is a core validation which is present in python version as well and if we allow it then we have to do it across. So best will be to open a separate RFC for it.

All of the suggestions are available in 1.4.0 now

Thanks a lot @msailes and @pankajagrawal16
Thanks a lot for addressing all of this. I actually have some follow up comments on MetricsUtils.defaultDimensionSet which I did not notice when the PRs were going.

I like the idea that now there's a way to set a default for the dimensions from @Metrics and withSingleMetric
However, I think there's still some room for improvement here
a. The current interface does not permit setting no dimensions as a default
b. The current interface does not permit setting multiple dimension sets as a default
Instead of MetricsUtils.defaultDimensionSet(DimensionSet dimensionSet), a MetricsUtils.defaultDimensions(DimensionSet... dimensionSets) method would address both problems above
a. Calling MetricsUtils.defaultDimensions() (no arguments) should set the default dimensions to no dimensions
b. Calling MetricsUtils.defaultDimensions(ds1, ds2,...) allows setting the default to have multiple dimension sets

If you agree, I think a way forwards can be to implement MetricsUtils.defaultDimensions, make MetricsUtils.defaultDimensionSet use it while marking is as deprecated for removal in a coming major version release.
What do you think?

I believe I agree to allow multiple. By the way, you can just pass new DimesnsionSet() and that should set it with no dimensions


[FEATURE] Add dry-run option for ism actions

Is your feature request related to a problem?
Currently, when creating an ism policy, user can't test directly if the configuration is working as expected.
They can only trigger the policy, let the action fail in the policy to see if the configs are not fine.
In elasticsearch-curator, there is a supported parameter for this:
dry-run: It can help you see which indices will be caught by operations without actually performing those operations.
What solution would you like?
Can we have a similar dry-run option added in ism as well?  Perhaps adding it at the policy level, or for every action that just mentions the matched indices but not perform the action?
(There was a similar tkt raised for notification action alone ,but i ask this as a general feature)
Does this seem like a value-addition for ism? Pls let us know your thoughts!
Do you have any additional context?
Dry-run option in elasticsearch-curator

[Catch All Triage - 1, 2, 3, 4]


Fix HF model loading/lora on low memory accelerators

We now intelligently decide between loading a model on CPU or GPU, and we put out_axis_resources back in a few places that really shouldn't need it, but do

Fixes #508


cli: Next.js 15

Closes #
✅ Checklist

[ ] I have followed every step in the contributing guide (updated 2022-10-06).
[ ] The PR title follows the convention we established conventional-commit
[ ] I performed a functional test on my final commit

Changelog
[Short description of what has changed]

Screenshots
[Screenshots]
💯

The new ESLint installer could works by:

Having an imports (imported plugins) array that can dynamically change based on the selected packages (currently drizzle only).
Marking the imported plugins with "%%PLUGIN_NAME%%" in the JSON object and stripping "%% and %%" from them. The marker could be anything. I chose something that wasn't likely to be used.
The plugins section is also dynamic and must use the marker.
Formatting the end result with prettier.

Note: At the moment we're not reading the CLI's generated Prettier config. We could do that and we'd get a more accurate formatting. I'm not sure if we could apply the Prettier plugins though (e.g. @ianvs/prettier-plugin-sort-imports) so we'll have to handle the order of the imports array manually.

@juliusmarminge

I don't understand the linting errors we're getting

@juliusmarminge drizzle needs updating. Any breaking changes I need to know of?

I think we should upgrade tsup as well while we're at it

I think we should upgrade tsup as well while we're at it

The only breaking changes between major versions 6 to 7 to 8 seems to be node version support drops so I'll just bump the version.

@juliusmarminge I think we're only pending on drizzle.

Hey, thank you for your work on this! I'm just curious as to whether you know if this is on Drizzle's roadmap? I saw the issue you linked to their repo, but it seems that hasn't had any activity since.

Hey @ahkhanjani, thank you for your work on this!

I appreciate your words.

I'm just curious as to whether you know if this is on Drizzle's roadmap? I saw the issue you linked to their repo, but it seems that hasn't had any activity since.

I don't remember the issue you're mentioning. Can you send the link here?

@juliusmarminge Why are we not merging btw?

Hey @ahkhanjani, thank you for your work on this!

I appreciate your words.

I'm just curious as to whether you know if this is on Drizzle's roadmap? I saw the issue you linked to their repo, but it seems that hasn't had any activity since.

I don't remember the issue you're mentioning. Can you send the link here?

Oh, apologies, I thought you had linked the issue but I had actually found it myself.
There's an issue with Drizzle about supporting the new flat config, which forgive me if I'm wrong since I've not looked into the ESLint 8 to 9 migration, is what I thought you meant about waiting for Drizzle?
(quick note to also mention that I've only just seen your later commit to update Drizzle which could be what you had meant you was waiting for)


Enabling gcp APIs if not enabled

Description
Changes proposed in this pull request:

adding gcp enabling apis step to scope reconciler
adding unit test for enableApis action
Please note that the testing hasn't been finished hence the draft PR

Related issue(s)
https://jira.tools.sap/browse/PHX-62

Tested locally and it works. Ended Up changing flow to some extent as the existing flow of scope reconciler was preventing proper implementation.


Add API diff between .NET Core 3.0 preview6 and preview7.

cc @leecow, @danmosemsft, @joshfree, @stephentoub, @maryamariyan, @ahsonkhan, @Anipik, @tannergooding, @safern
PTAL to see if the diffs make sense (no need to do any manual inspection of binaries, just see if the diffs called out in the PR match what you would expect, given what we changed in preview7).

I don't think the System.Threading.Channels mentioned here are new to preview 7. How did you generate the diff between preview 6 and 7?
CC @stephentoub

@tarekgh I compare the ref assemblies from Microsoft.NETCore.App.Ref, using the package shipped with each preview. For the OOB packages, I build locally using the commits that we shipped with each preview, and compare the ref assemblies for the OOB libraries. I use APIReviewer to generate the diffs.

@wtgodbe the Channel APIs introduced long ago https://github.com/dotnet/corefx/commit/c8ec3a850bd05aa8d8a6067071b723366b5648a3#diff-e72deaafbcf8f04d6025fbbb1ddf406a

the Channel APIs introduced long ago

I expect this is because the assembly was moved in-box.

Any last concerns? CC @ahsonkhan @GrabYourPitchforks @tarekgh @GrabYourPitchforks @Anipik

@wtgodbe System.Text CodePagesEncodingProvider class is not new in preview7 but we have moved the package System.Text.Encoding.Codepages to be inbox. I am not sure if we want to keep it or not. otherwise, LGTM.

@tarekgh I removed the diff for System.Threading.Channels for the same reason, so I'll remove Codepages as well. Thanks!

I've put up https://github.com/dotnet/core/pull/3001/commits/2f72f2fb70737e546f025a76741de176a0d8190b after talking w/ @ahsonkhan - I used a bad release tag to get the commit for preview6, leading to an incorrect diff (the p6 commit I used was actually from 2 weeks after preview6, so my initial diff missed 2 weeks worth of preview7 changes for the OOB packages). PTAL at the changes in the following areas -
System.Data.OleDb - @saurabh500
System.IO.Pipelines - @davidfowl, @halter73, @jkotalik, @anurse
System.Resources.Extensions - @krwq, @tarekgh
System.Security.AccessControl - @bartonjs, @GrabYourPitchforks
System.Security.Permissions - @bartonjs, @GrabYourPitchforks
System.Xaml.Permissions - @bartonjs, @GrabYourPitchforks

@ericstj I have looked at System.Resources.Extensions changes and looks good to me. could you please have a quick look just in case I missed anything?

cc @terrajobst


Question: How can we localize all texts ?

Is there an easy way to localize texts in any language ?

Hey @tjaskula, there is not any localization support as it stands today. It is a feature that is definitely in the future roadmap

Could we use https://github.com/stefalda/localized-strings ?

@victorbueno I think to start I will provide something in the options that will allow you to start overriding the default language as opposed to storing different language sets
const options = {
   textLabels: {
      pagination: {
         labelRowsPerPage: "Zeilen pro Seite:",
      },
      toolbar: {
        viewColumns: ""
     }
   }
};

@gregnb that's even better!

I'm going to finish this feature today and here's what I have so far for options:
Pass in a property named textLabels via options prop
      textLabels: {
        pagination: {
          next: "Next Page",
          previous: "Previous Page",
          rowsPerPage: "Rows per page:",
          displayRows: "of" // 1-10 of 30
        },
        toolbar: {
          search: "Search",
          downloadCsv: "Download CSV",
          print: "Print",
          viewColumns: "View Columns",
          filterTable: "Filter Table"
        },
        filter: {
          title: "FILTERS",
          reset: "reset",
        },
        viewColumns: {
          title: "Show Columns"
        },
        selectedRows: {
          text: "rows(s) deleted",
          delete: "Delete"
        }
    }

This issue is resolved in 2.0.0-beta-6 which will also require upgrade to the latest material-ui


gamesPlayed fails to actually load non-steam game?

I simply have user.gamesPlayed("some string"); (where user is a SteamUser object) but it doesn't load into game.
The module does not throw an error either, it just does nothing.

Works for me.
client.on('loggedOn', function(details) {
	console.log("Logged on, SteamID: " + client.steamID);
	client.setPersona(Steam.EPersonaState.Online); // did you remember this?
	client.gamesPlayed("Half-Life 3");
});

I'm guessing you're calling gamesPlayed before logging in, or, as @DoctorMcKay said, before going setting your state to online.

Left out the client.setPersona(Steam.EPersonaState.Online);, sorry. I shouldn't have opened an issue for this, closing it now.

Steam is not defined error please help me @DoctorMcKay


[question] Any plans to publish the ecflow Python module to PyPI?

Hi,
I noticed that PyFlow has a dependency on ecflow, but instead of having the dependency listed in setup.py, it's using an environment.yml and Conda.
Would it be possible to publish the ecflow module to PyPI? This way it would be possible for contributors to use just pip to install everything (or just conda, without mixing both unnecessarily).
Thanks.
-Bruno

Hi @kinow, ecFlow's Python bindings are not a separate Python package, but they are generated by boost-python from the C++ code. Therefore they are built specifically for different versions of Python and I'm not sure if it's possible to have them as a PyPi package. This is a situation we may want to change in the future, but for now this is how it is at the moment, so PyFlow is doing the right thing - it needs ecFlow from conda.
Cheers,
Iain

Hi @iainrussell ,
I don't know boost or boost-python well enough. But I think it should be possible to build it for multiple platforms.
I found a post that describes what a process that includes several steps that may be similar to what is used to prepare the Conda package, I think: https://thomastrapp.com/posts/building-a-pypi-package-for-a-modern-cpp-project//
Then, for building it against multiple platforms, maybe cibuildwheel could be used. It is used to build PyZMQ, that publishes the platform specific wheels for their Python binding for zeromq: https://pypi.org/project/pyzmq/#files
PyZMQ also uses Circle CI on a free tier, I think (quite sure they have been using it for a long time. CircleCI offers different platforms to build the packages before uploading to PyPI ^1). So technically I believe it's doable, but I understand if there is no interest and, or, bandwidth to try that.
Cheers,
Bruno

Forgot to mention that I'd be happy to help with review/test/docs/etc :+1:


Move Counters into Latest

The only place Counters are used is in rendering, for the number of nodes under a topology, so the overhead of holding a unique data structure in every Node is unwarranted.
Counters are not set in the probe, so we don't need any backwards-compatibility in report decoding. Similarly they are not set until after all nodes are merged, so we don't need that logic.
(It was a bug if we did use it - merges are supposed to be idempotent).

It turned out this needed more work because ContainerHostnameRenderer was relying on the additive merge behaviour, also this wasn't being checked in unit tests.
So I extended the unit tests to check counts and to cover the case where the count is not 1.
Then re-did ContainerHostnameRenderer as a Renderer so it didn't need additive merge.


Toggle Button POC

/release-pr

/release-pr

release-pr on

🦋  success packages published successfully:
🦋<EMAIL_ADDRESS>🦋<EMAIL_ADDRESS>🦋<EMAIL_ADDRESS>

🦋 success packages published successfully: 🦋<EMAIL_ADDRESS>
Tested above snapshot release (3d old), no breaking change, standalone ToggleButton as well as ToggleButtonGroup works as expected, except keyboard left/right on group doesn't react with below code. It could be due to code is old (given it works on latest Storybook preview), or i'm using it controlled.
  const [selectedIndex, setSelectedIndex] = useState<number>(0);

  const handleChange: ToggleButtonGroupChangeEventHandler = (_, index) => {
    setSelectedIndex(index);
  };

...

            <ToggleButtonGroup
              onChange={handleChange}
              selectedIndex={selectedIndex}
            >
              <ToggleButton
                aria-label="Vertical direction"
                tooltipText="Vertical direction"
              >
                <VerticalIcon />
              </ToggleButton>
              <ToggleButton
                aria-label="Horizontal direction"
                tooltipText="Horizontal direction"
              >
                <HorizontalIcon />
              </ToggleButton>
            </ToggleButtonGroup>


Apply to admin users only

Hi,
How do I apply this excellent gem to a single devise user model, in my case Admins, I don't want general Users to go through the same security?

Assuming your model is AdminUser,
Eg:
class AdminUser < ActiveRecord::Base
    devise :database_authenticatable, :trackable, :password_expirable, :password_archivable, :session_limitable, :secure_validatable, :lockable, :timeoutable
end

class AddDeviseSecurityResourcesToAdminUsers < ActiveRecord::Migration
  def change
    add_column :admin_users, :password_changed_at, :datetime
    add_column :admin_users, :unique_session_id, :string, limit: 20
    add_index :admin_users, :password_changed_at
  end
end

Just add the modules you want in the Admin model and do the appropriate migration for the Admin model.

I have same problem, but in my case I do not have a separated model for Admin, but an attribute that contains the role of a single User model. Do you have some idea how can I only apply some of this rules only to one or two kinds of roles?

This is an issue for me as well, and I think the source of the problem is that the behavior is not easily customizable.
I like the approach this repository takes - by moving the check to a method on the model, it's easily overridden to customize the behavior.
@zxr90 What do you think about that, seems like a fairly trivial change to implement.

Hello @creativetechnologist. We are having similar issue as yours. We tried to call devise method in the class_eval to override devise settings but no luck so far. Did you find a solution for your question?
Thanks,
Ruslan

Curious if anyone found workaround for this....

@drewBI I ended up extracting the portion of code I needed to customize out to my lib directory, including it, and then discarding the gem since it was not possible for me to customize the behavior of the gem.

@jaredmoody thanks for your response.  That is a bummer.


Revoked Dataset table is still available to the user in table preview

Describe the bug
For one of the table in "Shares", access has been Revoked and status updated to "REVOKE_SUCCEEDED".

User, who had requested the share access, could access the same table data in Table preview,
even after "REVOKE_SUCCEEDED".
User following these steps to access revoked table: Environments -> DATASETS -> TABLE -> PREVIEW -> Revoked Table data is VISIBLE

BUG: Revoked table data should not be visible to user.
How to Reproduce
1)From "Shares" section revoked access to a table
2)Wait till the status changed to REVOKE_SUCCEEDED
3)Log in as a user who has requested for the share access
4)Go to Environments -> DATASETS -> TABLE -> PREVIEW -> Revoked Table data is VISIBLE
Expected behavior
Revoked table data should not be visible to user.
Your project
No response
Screenshots
No response
OS
Mac Sonoma 14.5
Python version
3.8
AWS data.all version
2.0.0
Additional context
No response

Hi @srisri97 thanks for opening the issue. This problem was already reported https://github.com/data-dot-all/dataall/issues/1173 and solved in https://github.com/data-dot-all/dataall/issues/1173. It was released as part of 2.5 https://github.com/data-dot-all/dataall/releases/tag/v2.5.0.


Add tag with pre-alignment score to unaligned reads

I set --pre-align-min-score 200 and had a read fail to align, however the read aligned with minimap2. When I dropped the threshold to 100, the read aligned.
It would be useful to know the pre-alignment scores of reads that are expected to align but fail to do so, so that --pre-align-min-score can be adjusted intelligently.
I don't see any reason why AS couldn't be used.

How about the XS or xs tag, with the latter as per the README:

the sub-optimal alignment score, practically the maximum of any pre-alignment and secondary chain

then one could get the xs tag for all reads

perfect


DCD: Add Cessation cost to offshore Facilities

For Assets:

Surf
Topside
Substructure
Transport

There should be possible to add another Cost Profile (Cessation).
This affects Backend, frontend and Excel.
Model update command needs also to be ran sometime.

npm run autogenerate-models

Acceptance criteria:
Given that there is a project and a case with asset surf/topside/substructure/transport, when the engineer have calculated cessation costs for an asset then it should be possible to add the cost profiles to the individual assets.
Given that cessation costs have been added to an asset, when the concept architect want to compare business cases then the cessation cost should be included in the CAPEX/Cost for that case.
Given that cessation costs have been added to an asset, when the concept architect want to export data to STEA the cessation cost profile should be included in the export.
...


Fix docker start -i work even if without -i when container on creation

Signed-off-by: Lei Jitang<EMAIL_ADDRESS>@estesp If your fix is better, I'll close this. I don't think mine is a good one.
relate #10549
Fixes #10514
This fixes will overwrite Config.OpenStdin to true if docker start with stdin  attached.

Test failure

Also seems like we should be working around using stdinOnce instead of setting the container's OpenStdin?

@cpuguy83 Thanks for the tips.  But if don't set Config.OpenStdin to true, the container's Stdin will not open on creating pipes when starting (see https://github.com/docker/docker/blob/master/daemon/monitor.go#L132   if I understand the code correcly).

Sorry I haven't had much time to look at this today, but it does require a bit more work; first of all you haven't handled the "-i" flag (which should turn Tty on), or else you won't really get an interactive shell if the run command happened to be something like /bin/bash.  Basically, the crux of the matter is that this line: https://github.com/docker/docker/blob/master/daemon/attach.go#L104 reads the config for several parameters which should be more connected to the API input (e.g. stream=1 indicates Tty == true from the client side, but config.Tty is relied on instead).

Update as @estesp suggestion, turn on Tty when -i is set. This will overwrite the Config.Openstdin and Config.Tty. If all is ok, I'll add tests.

Actually I don't like this fix, I have another fix locally which will not overwrite the Config, which will change
https://github.com/docker/docker/blob/master/daemon/monitor.go#L132  from
pipes := execdriver.NewPipes(m.container.stdin, m.container.stdout, m.container.stderr, m.container.Config.OpenStdin) to pipes := execdriver.NewPipes(m.container.stdin, m.container.stdout, m.container.stderr, true) , container.Config.OpenStdin is to keep stdin open or not but https://github.com/docker/docker/blob/master/daemon/daemon.go#L242 has done this(Plesae correct me if I what I understand is wrong).
I think stdin pipe should always be created just as stdout and stderr, and if user want to attach to it, it can be attached. And this change can also fix the docker attach work even if a container create and start without -i

Ping @cpuguy83 @estesp: any idea what's the next step on this? Do you need more eyes on it?

Hey @icecrime; my hangup is I don't like the way the current code and config interactions force this to be fixed in an awkward way.. I need more time (if it's me) to try and think through a cleaner re-work, as I strongly think that it really should be possible to do start -ai even if the original run/create didn't set up the container.Config as attaching stdin or having a tty.
If I'm in the minority on that, then I'll switch to strongly thinking that -ai need to be removed as options from start :) , which is obviously an easier path from a code perspective, but removes "documented" functionality that currently doesn't work.

@estesp hmm do you thing we should close and wait for a different implementation or....

Oh, sorry, I almost forget this PR....
Maybe we can think of a different implementation

Yeah, my hangup is that the "expectations" for stdin, stdout, stderr attachment are in the container's config (which is good for restart), but the /attach endpoint allows the desire of the caller to be specified for them as well.  Both the docker start command and API users should expect that these requests are honored, but the attach implementation combines the container config settings and the specified "requests" of the user, and it's messy..
I think a clean implementation is rethinking how attach handles the requested streams/tty settings to honor start -ai as well as API callers.

I remember I has another implementation which will not overwite the 'config' on local in my office machine, maybe I can update it to this PR tomorrow when I get to the office

@coolljt0725 I definitely not fan of overwriting config. Let's try your other solution.

ping @coolljt0725 are you working on this? (https://github.com/docker/docker/pull/10680#issuecomment-88260361) (just a friendly reminder :smile:)

@thaJeztah  I working on that, but a bit busy these day, I'll update this PR later :)

@coolljt0725 no worries, just checking in :smile:

@coolljt0725 I'm closing this until you're ready: please ping us here when you need us to reopen before you force push your changes.


Allow Fleet to schedule with Conflicts against units not scheduled with fleet or that are not certain machine id's

I have some machines with some unit files placed into /etc/systemd/system.
These machines have physical drives attached and unit files to mount file systems and start databases.
Although these machines are part of the CoreOS cluster and can run other things, some units I wouldn't want to schedule there.
Unfortunately, suppose I have a unit /etc/systemd/system/mysql.service and then schedule another unit with fleet and place Conflicts=mysql.service, it causes the scheduler to hang when trying to schedule the unit.
Also, fleet only has the ability to work with glob patters in Go which seem to be very limited.
It would seem natural to me to be able to specify things like:
MachineOf = ! machineA
But I understand that doesn't make sense for the way MachineOf works.  Because the inverse of ! machineA would be every other machine in the cluster.  I suppose if you are only scheduling a single unit then this would make sense.
Another option would be to have Conflicts= take a machine id as well.
Are there any planned improvements in the pipeline around this area?

Could you use the machine metadata feature to do this? You could tag all safe machines with something like role=schedulable, or the inverse, tag the unsafe machines as role=unschedulable, then create units with matching Metadata options. It might be cleaner if we could use a != operator in the metadata, which is coming in https://github.com/coreos/fleet/pull/1294

I suppose the question was already answered. Closing.


Update test runners to Fedora 39

This pull request includes:

[ ] adequate testing for the new functionality or fixed issue
[ ] adequate documentation informing people about the change such as

[ ] submit a PR for the guides repository if this PR changed any behavior described there: https://www.osbuild.org/guides/

Watching the filesystem test closely.

Same failure as before unfortunately.

I puhsed a tiny commit to help debug this, the failure happens when f39 tries to mount the generated xfs partitions. The error code 32 from mount indicates a mount failure - context_mount.c generates some error output that appears to be swallowed by the way we call mount, I may push a small tweak to our code for this as well (if the current commit does not indicate the error already).

I also opened https://github.com/osbuild/osbuild/pull/1490 in osbuild to make sure we get better error reporting from MountGuard in osbuild.

@mvo5 you can update this section in Schutzfile
  "fedora-39": {
    "dependencies": {
      "osbuild": {
        "commit": "433515cff898168b204833941a6d32399152128b"
      }
    },

and reference your new osbuild commit, d0c917f7d1dddc82b99c12bb73d19cf2c6e81400. That should give you the error output in the context of this PR.

@mvo5 you can update this section in Schutzfile
  "fedora-39": {
    "dependencies": {
      "osbuild": {
        "commit": "433515cff898168b204833941a6d32399152128b"
      }
    },

and reference your new osbuild commit, d0c917f7d1dddc82b99c12bb73d19cf2c6e81400. That should give you the error output in the context of this PR.
Update: I see that you've opened your PR from a fork. Maybe try a branch in the osbuild repo instead!

Thank you! The PR is scheduled for merging so hopefully just updating to osbuild@latest will be possible in a little bit :)

Now it fails with:
...
Dec 11 17:22:20 ip-10-31-18-230.us-east-1.aws.redhat.com osbuild-worker[22946]: time="2023-12-11T17:22:20Z" level=info msg="    /run/osbuild/tree/etc/vconsole.conf written." jobId=acb0d67b-6055-459a-b3d2-0e2acde648fc
Dec 11 17:22:20 ip-10-31-18-230.us-east-1.aws.redhat.com osbuild-worker[22946]: time="2023-12-11T17:22:20Z" level=info msg="    Traceback (most recent call last):" jobId=acb0d67b-6055-459a-b3d2-0e2acde648fc
Dec 11 17:22:20 ip-10-31-18-230.us-east-1.aws.redhat.com osbuild-worker[22946]: time="2023-12-11T17:22:20Z" level=info msg="      File \"/run/osbuild/bin/org.osbuild.keymap\", line 114, in <module>" jobId=acb0d67b-6055-459a-b3d2-0e2acde648fc
Dec 11 17:22:20 ip-10-31-18-230.us-east-1.aws.redhat.com osbuild-worker[22946]: time="2023-12-11T17:22:20Z" level=info msg="        r = main(args[\"tree\"], args[\"options\"])" jobId=acb0d67b-6055-459a-b3d2-0e2acde648fc
Dec 11 17:22:20 ip-10-31-18-230.us-east-1.aws.redhat.com osbuild-worker[22946]: time="2023-12-11T17:22:20Z" level=info msg="      File \"/run/osbuild/bin/org.osbuild.keymap\", line 107, in main" jobId=acb0d67b-6055-459a-b3d2-0e2acde648fc
Dec 11 17:22:20 ip-10-31-18-230.us-east-1.aws.redhat.com osbuild-worker[22946]: time="2023-12-11T17:22:20Z" level=info msg="        configure_xkb(tree, x11_keymap)" jobId=acb0d67b-6055-459a-b3d2-0e2acde648fc
Dec 11 17:22:20 ip-10-31-18-230.us-east-1.aws.redhat.com osbuild-worker[22946]: time="2023-12-11T17:22:20Z" level=info msg="      File \"/run/osbuild/bin/org.osbuild.keymap\", line 77, in configure_xkb" jobId=acb0d67b-6055-459a-b3d2-0e2acde648fc
Dec 11 17:22:20 ip-10-31-18-230.us-east-1.aws.redhat.com osbuild-worker[22946]: time="2023-12-11T17:22:20Z" level=info msg="        with open(f\"{tree}/etc/X11/xorg.conf.d/00-keyboard.conf\", \"w\", encoding=\"utf8\") as f:" jobId=acb0d67b-6055-459a-b3d2-0e2acde648fc
Dec 11 17:22:20 ip-10-31-18-230.us-east-1.aws.redhat.com osbuild-worker[22946]: time="2023-12-11T17:22:20Z" level=info msg="    FileNotFoundError: [Errno 2] No such file or directory: '/run/osbuild/tree/etc/X11/xorg.conf.d/00-keyboard.conf'" jobId=acb0d67b-6055-459a-b3d2-0e2acde648fc

which got fixed as part of https://github.com/osbuild/osbuild/pull/1441 in https://github.com/osbuild/osbuild/pull/1441/commits/6e3ca59657465b7b930c122e0efa7f984c27ff2c so  I suspect the worker is using a slightly older version of osbuild.

And we finally have a more decent error message:
Traceback (most recent call last):
  File "/usr/libexec/osbuild-composer-test/image-info", line 2883, in <module>
    main()
...
osbuild.host.RemoteError: RuntimeError: b'mount: /tmp/tmp1mo2j31_/app: wrong fs type, bad option, bad superblock on /dev/mapper/rootvg-applv, missing codepage or helper program, or other error.\n       dmesg(1) may have more information after failed mount system call.' (code: 32)

All RHEL 8 and RHEL 9 failure is caused by ansible upgrade. The PR https://github.com/osbuild/osbuild-composer/pull/3845 fixed this issue. Could you please make a rebase? Thanks.

All edge-simplified test failure is not caused by this PR. Issue has been fixed by PR https://github.com/osbuild/osbuild-composer/pull/3854

I logged into the system now and managed to get hold of the failing image. It looks like mount in fc39 is behaving differently, I can also reproduce this on an debian/unstable system. The issue happens when image-info calls mount '-t', 'xfs', '-o', 'ro,norecovery', '--source', '/dev/rootvg/applv', '--target', '/tmp/tmpngmoxtqq/app'. The jounrnal shows: no-recovery mounts must be read-only.
When I run the following:
$ dd if=/dev/zero of=/tmp/xfs.img bs=1M count=500
$ mkfs.xfs /tmp/xfs.img
$ sudo mount -o "ro,norecovery" /tmp/xfs.img /mnt

the mount fails. Doing the same for ext4:
$ dd if=/dev/zero of=/tmp/ext4.img bs=1M count=500
$ mkfs.ext4 /tmp/ext4.img
$ sudo mount -o ro,norecovery /tmp/ext4.img /mnt

works just fine.
However the strace output is different:
$ sudo strace mount -o ro,norecovery /tmp/xfs.img /mnt
...
fsopen("xfs", FSOPEN_CLOEXEC)           = 3
...
fsconfig(3, FSCONFIG_SET_STRING, "source", "/dev/loop1", 0) = 0
fsconfig(3, FSCONFIG_SET_FLAG, "ro", NULL, 0) = 0
fsconfig(3, FSCONFIG_SET_FLAG, "norecovery", NULL, 0) = 0
fsconfig(3, FSCONFIG_CMD_CREATE, NULL, NULL, 0) = -1 EINVAL (Invalid argument)
close(3)

which is fine on ext4:
fsopen("ext4", FSOPEN_CLOEXEC)          = 3
....
fsconfig(3, FSCONFIG_SET_STRING, "source", "/dev/loop0", 0) = 0
fsconfig(3, FSCONFIG_SET_FLAG, "ro", NULL, 0) = 0
fsconfig(3, FSCONFIG_SET_FLAG, "norecovery", NULL, 0) = 0
fsconfig(3, FSCONFIG_CMD_CREATE, NULL, NULL, 0) = 0
fsmount(3, FSMOUNT_CLOEXEC, 0)          = 5

Now if I compare this with fc38 strace there is just the "old" mount(2) syscall used and the output is essentially: mount("/dev/loop0", "/mnt", "xfs", MS_RDONLY, "norecovery"). So it looks like the support for the new mount syscalls in xfs is incomplete?

This is an upstream patch on the xfs mailing list<EMAIL_ADDRESS>but AFAICT this is not yet applied to Linus tree :/

This was a difficult one, thank you for your patience!

Thank you SO MUCH for all the effort you put into this! :heart:

Comments addressed.
RHEL 9.4 nightly failures are being addressed in #3883.
We can admin merge if we're in a real hurry to get this in, but it looks like the other PR should be passing soon too so maybe it can wait.


Implement platform agnostic requirements.txt lock file support.

Pex should be able to generate a lock file for all the Pythons and Platforms implicated by --python, --interpreter-constraint and --platform in a resolve in requirements.txt --hash format. The locked requirements.txt should only be constrained by the valid interpreter versions implied by --python, --interpreter-constraint and --platform and the input requirements and constraints.

Depends on #1401 for the lock datastructure and requirements.txt --lock emitting code.

The relevant Pip debug log line for the download command for foreign wheels is matched by:
match = re.search(
    r"Skipping link: none of the wheel's tags \([^)]+\) are compatible \(run pip "
    r"debug --verbose to show compatible tags\): (?P<url>[^\s]+) ",
    line,
)

Notes:
There are legacy sdists whose setup.py asserts it's being run by an appropriate Python interpreter and this causes problems during a download where Pip is forced to run python setup.py egg_info to get dependency metadata (For a bit on why its forced to do this and can't use the PKG-INFO that ships in sdists, see 1). An example of an sdist like this is functools32: https://github.com/michilu/python-functools32/blob/ad90fa86e2f4f494a3aedb0571274f3bbc6d7ab5/setup.py#L8-L10 This is a problem for universal locks. There are only two ways to solve afaict:

Patch pip to just use the PKG-INFO in the sdist when present and thus skip executing python setup.py egg_info. This has all the problems mentioned in 1.
Patch marker evaluation to consider interpreter constraints. Currently marker evaluation is patched to always return True so that all possible dependency branches for all possible target environments are gathered (thus forming a universal lock). If the resolve is constrained by an effective Requires-Python though, this implies a universe of python_version and python_full_version environment values that should evaluate True as well as the converse. So some way to both form these universes and then evaluate just those two markers and no others could trim out these problem dependencies in the 1st place.

[1]: https://discuss.python.org/t/why-isnt-source-distribution-metadata-trustworthy-can-we-make-it-so/2620


Linuxbrew formula

Looks like this package is being published as a cask in Homebrew. It would be really great if this package was available as a Formula within Homebrew so that it can be installed on Linux as well. For instance, neovim-qt is available as a Formula in Homebrew, making it really convenient to install on Linux.

Agree, I use Homebrew as my package manager for both macOS and Linux

Thanks for this issue.
I am not yet familiar with homebrew, but I assume the following.
brew install goneovim // It treats and installs goneovim as a CUI program in Linux and MacOS.

brew install --cask goneovim // This is valid only for MacOS and installs goneovim as a GUI program.

Also, the following formula may be helpful:
formula for neovim-qt
https://github.com/Homebrew/homebrew-core/pull/85526/files
formula for rust
https://github.com/Homebrew/linuxbrew-core/blob/master/Formula/rust.rb

Thanks for this issue. I am not yet familiar with homebrew, but I assume the following.
brew install goneovim // It treats and installs goneovim as a CUI program in Linux and MacOS.

brew install --cask goneovim // This is valid only for MacOS and installs goneovim as a GUI program.

Also, the following formula may be helpful:
formula for neovim-qt
https://github.com/Homebrew/homebrew-core/pull/85526/files
formula for rust
https://github.com/Homebrew/linuxbrew-core/blob/master/Formula/rust.rb

Your assumption is correct.
Casks are macOS applications (mostly GUI) and they are typically launched from Launchpad, Spotlight etc.
Formulae are normal packages that are mostly launched from Terminal. They can be CLI/TUI/GUI/Services etc.
E,g, vimr is installed as a brew cask but in addition it provides a script to help launch the application from the terminal.
For vimr, distributing through a cask is ideal as it's closely tied to macOS. On the other hand, goneovim is cross-platform and it's more appropriate for it to use a brew formula recipe instead (or in addition to Cask).


test(NODE-2422): Validate that mongocryptd is not spawned if bypassAutoEncryption=true

Description
What is changing?

implement spec tests for bypassing spawning mongocryptd

Is there new documentation needed for these changes?

no

What is the motivation for this change?
Spec compliance
Double check the following

[X] Ran npm run check:lint script
[X] Self-review completed using the steps outlined here
[X] PR title follows the correct format: type(NODE-xxxx)[!]: description

Example: feat(NODE-1234)!: rewriting everything in coffeescript

[X] Changes are covered by tests
[ ] New TODOs have a related JIRA ticket

Win/Node 14 issues unrelated to this PR.


Configure Azure Pipelines

This pipeline configuration builds the application and produces a build for the Release configuration.

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

merge code-flow to master


Images May Be Removed from Disk Cache for Not Being in Memory Cache

If we attempt to fetch an image from the memory cache but it isn't there, we will remove it from the disk cache:

This kills the disk cache 💀 . This issue is with version 2.1.2 which is currently shipping with AsyncDisplayKit. Not sure if it affects latest, sorry =/

Dang, this is a bad one :( I'll get it fixed up immediately.

Luckily it doesn't happen in many code paths.

Fixed in 2.1.3 which just got published. Fix is here:
https://github.com/pinterest/PINRemoteImage/commit/f15ca03ece954b4712b2c669c849245617e73e08
Will fix in master next.

Thanks for the fast fix!


[grpc-java-client] grpc java client call brpc server get INTERNAL: HTTP/2 error code: FLOW_CONTROL_ERROR

Describe the bug (描述bug)
I use a grpc-java-client to call brpc server, And I just use one grpc's managed channel, but i have multi threads to use this managed channel to init grpc's blocking stub.  and call the brpc server. But i get a FLOW_CONTROL_ERROR. my request and response is small enough.
I am curious about if my behavior is correct
To Reproduce (复现方法)
just above
Expected behavior (期望行为)
I expect the call can return successfully
Versions (各种版本)
OS: CentOS 7.4
Compiler: gcc 8.3
brpc:0.9.5
protobuf: 3.6.1
Additional context/screenshots (更多上下文/截图)
io.grpc.StatusRuntimeException: INTERNAL: HTTP/2 error code: FLOW_CONTROL_ERROR
Received Rst Stream
at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:233)
at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:214)
at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:139)

Did the RPC succeed when there's only one thread?


⚠ Minecraft has degraded performance

In 5d5cedb, Minecraft (https://www.minecraft.net) experienced degraded performance:

HTTP code: 200
Response time: 1145 ms

Resolved: Minecraft performance has improved in e24eaf9.


Incorrect links in generated docs for packages with submodules

Description
When generating documentation for a Roc package using roc docs, submodules (e.g., Sub.Module) result in incorrect links. While the module name is correctly identified as Sub.Module, the corresponding HTML file is placed in a directory structure like Sub/Module. However, the generated links in the documentation point to Sub.Module, resulting in 404 errors.
Steps to Reproduce

Create the following file structure:
main.roc:
package [Sub.Module] {}

Sub/Module.roc:
module []

Run roc docs to generate the documentation.

Open the generated documentation and inspect the links for Sub.Module.

Expected Behavior
The generated links in the documentation page should point to the correct location, such as href="Sub/Module".
Actual Behavior
The links incorrectly point to Sub.Module, causing 404 errors.
Additional Information
The docs pages are generated correctly, it is just the links that are broken.

This issue can also be observed in the wild at: https://www.imclerran.com/roc-openrouter/

Closed by #7418


Change Cohort Component

Update metadata with the following changes:

[ ] The table currently reflects values extracted from the reference of the paper on cohort studies. Update these entries with the actual values from the participant-level data.
[ ] The FollowUpIntervals column currently uses days, years, and months. Update the entries so that they will use days (if less than 30 days) and months.
[ ] Add Idiopathic PD column.

@marjanniazpoor for now tackle the first two items, then we can check if there is still a need to implement the third item.

@marjanniazpoor please also remove UK Biobank as this is not a PD cohort.


feature: Make #value discoverable

get is docuented to return a GetResponse. IDEs won't see it if it's only in a subclass. Add it to GetResponse.
Closes #44

There's nobody else around this week, so I'm going to merge without review.


Fix subdomain inheritance for nested blueprints.

When child blueprints are mounted onto parents, they don't inherit the subdomain set by the parent.
This PR ensures that routes in child blueprint will be available at the same subdomain set by the parent.
However, children can also specify their own subdomain if necessary.

fixes #4834

Checklist:

[x] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[x] Add or update relevant docs, in the docs folder and in code.
[x] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
[x] Add .. versionchanged:: entries in any relevant code docs.
[x] Run pre-commit hooks and fix any issues.
[x] Run pytest and tox, no tests failed.

Could you retarget this to the 2.2.x branch (as bugfix)

@pgjones Sorry my bad, it's done.

Closed this in favor of #4856


Multi get, pluggable hashing and some code cleanup (#1)

This change implements multi-get, pluggable hashing and some (but not complete) code cleanup
pluggable hashing

removes the failover options which would be hard to make work with pluggable hashing (if this is important to keep, I will figure out a way to add it back)
implemented with the idea in mind of being able to use https://www.npmjs.com/package/hashring
lots of tests added!

code cleanup

move to tap v14 so tap.only works
introduce a constants file, change most (but not all) magic numbers in memjs to use named constants
start using "server" in many places rather than "serv"

I'd really like to move the eslint version forward so we can use const,  let, =>, and array destructuring, but that seemed like it would be better suited to a separate PR

Hey @blackmad, thanks so much for all the work.
I have only looked at the pluggable hash function so far.
I don't think removing failover is a good idea for a couple of reasons.

Without failover, you will be dogpiling servers whenever there is an issue... and in the cloud, there is always an issue eventually.
For MemCachier caches, servers have a consistent view of the cache, so failovers are highly desirable since you will get the same answer from any server.

The good thing is that I don't think it is hard to keep failover at all. For the default function, you can just leave the "use next server" failover. Personally, I would also recommend the same failover for hashring as it is common practice. Btw. feel free to add the hashring function to choose a server to memjs in a future PR as well. I think @alevy has a TODO about adding one in the code anyway. The good thing about having both in memjs is that you can reuse the "use next server" failover.

Thanks for the review!
I originally had a version with hashring but noticed that the project had
zero external dependencies so thought you might want to keep it that way,
rewriting it to be pluggable ended up with cleaner code so I'm glad I did
it, but awesome can add back in hashring in the future.
re: failover, sounds like a simple change - I'll try to get in back in
today.
On Mon, Mar 29, 2021 at 4:51 AM Sascha @.***> wrote:

Hey @blackmad https://github.com/blackmad, thanks so much for all the
work.
I have only looked at the pluggable hash function so far.
I don't think removing failover is a good idea for a couple of reasons.

Without failover, you will be dogpiling servers whenever there is an
issue... and in the cloud, there is always an issue eventually.
For MemCachier caches, servers have a consistent view of the cache,
so failovers are highly desirable since you will get the same answer from
any server.

The good thing is that I don't think it is hard to keep failover at all.
For the default function, you can just leave the "use next server"
failover. Personally, I would also recommend the same failover for
hashring as it is common practice. Btw. feel free to add the hashring
function to choose a server to memjs in a future PR as well. I think
@alevy https://github.com/alevy has a TODO about adding one in the code
anyway. The good thing about having both in memjs is that you can reuse
the "use next server" failover.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/memcachier/memjs/pull/145#issuecomment-809197945, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADMZMBP3J2QQUWYDXPW2WDTGBETNANCNFSM4Z3LJ37Q
.

--
David Blackman
creative technologist & wandering
help me find my purpose http://purpose.blackmad.com

Any update on re-adding failover?

apologies, the failover change is almost done here: https://github.com/makenotion/memjs/pull/7 but we've been making more substantial changes to the library that's taken precedence - converting to typescript, deprecating the callback API, and removing code to support deprecated options APIs.
It's worth a conversation to see if you would be interested in upstreaming this major change at some point or if we should more officially fork it.

These are more substantial changes indeed ;-)
We are happy to see interest and activity in memjs and memjs can definitely use some modernization. We are thus open to quite a few options such as

Transfer ownership of memjs
Add you as a collaborator
Upstreaming changes without (1) or (2)

What is important to us is that certain features/options such as failover are not removed since there are many people using those. @blackmad what do you think about that?

Is the pluggable Hash going to be rolled into the main branch anytime soon? I'd love to be able to use this but need to write our own Hash support at the moment (horrible old PHP memcache compatible CRC32 hash urgh).

@blackmad any update? Have you thought about the 3 options above?


Completed the Social Data Usage analysis

Completed the Social media usage analysis project. I have used a different and better dataset. Documentation is also added in the notebook.
Dataset Link: https://www.kaggle.com/code/salmaneunus/social-media-analysis-dataset-extracting-cleaning/input
Dataset link is also mentioned in the notebook

Hey @AadeshKabra, there's no need to commit the datasets. keep only notebook.ipynb there.
Also, after reviewing your notebook, I believe it would be beneficial to include some docs/notes within it so that other contributors can understand it as well.

Hey @AadeshKabra Kindly also add some docs to your notebook..

Now added the readme.md file which contains the documentation for the notebook. Also, some documentation is present in the notebook in the form of comments

Hey @AadeshKabra, great! One last change: there's no need to create a separate README.md, so please delete that and add Markdown notes directly in notebook.ipynb.

Hi, Made the suggested changes

Great work, @AadeshKabra  ! 👏
Congratulations 🎉, your pull request has been successfully merged!
If you find this repository helpful, please consider giving us a star by clicking ⭐.
And don't forget to share your achievement with your friends and us in Discussions ! 🚀


Update awkward wording in multi-project page

This pr just changes a slightly confusing sentence into what I believe captures the original intent in a clearer way.

Hi @ckipp01,
Thank you for your contribution! We really value the time you've taken to put this together.
Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:
http://www.lightbend.com/contribute/cla


[AIRFLOW-367] fix imports for github enterprise authentication

Dear Airflow Maintainers,
Please accept this PR that addresses the following issues:

https://issues.apache.org/jira/browse/AIRFLOW-367

issue summary:
login is broken in GHE for new users:
[2016-07-26 22:11:43,077] {github_enterprise_auth.py:199} ERROR -
Traceback (most recent call last):
  File "/opt/virtualenvs/airflow/lib/python3.5/site-packages/airflow/contrib/auth/backends/github_enterprise_auth.py", line 188, in oauth_callback
    'Null response from GHE, denying access.'
airflow.contrib.auth.backends.github_enterprise_auth.AuthenticationError: Null response from GHE, denying access.
[2016-07-26 22:12:12,313] {app.py:1423} ERROR - Exception on / [GET]
Traceback (most recent call last):
  File "/opt/virtualenvs/airflow/lib/python3.5/site-packages/flask/app.py", line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/opt/virtualenvs/airflow/lib/python3.5/site-packages/flask/app.py", line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/opt/virtualenvs/airflow/lib/python3.5/site-packages/flask/app.py", line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/opt/virtualenvs/airflow/lib/python3.5/site-packages/flask/_compat.py", line 33, in reraise
    raise value
  File "/opt/virtualenvs/airflow/lib/python3.5/site-packages/flask/app.py", line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/opt/virtualenvs/airflow/lib/python3.5/site-packages/flask/app.py", line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/opt/virtualenvs/airflow/lib/python3.5/site-packages/airflow/contrib/auth/backends/github_enterprise_auth.py", line 215, in oauth_callback
    login_user(GHEUser(user))
NameError: name 'login_user' is not defined```

Commit nazi here: please adhere to guidelines next time makes for tidy history. Thanks


Make PSP rendering conditional for 1.25+ compatibility

Towards https://github.com/giantswarm/roadmap/issues/2533
Checklist

[x] Update changelog in CHANGELOG.md.

closing this as the repo is unmaintained


Icinga Web: Add module graphite

Install and configure module graphite

Is there an update for this issue?

Thanks for the "ping", I checked it the code is still compatible. I tried to implement installation from git and therefore waited with the merge.


Domain activation is Failed - [BRIEF DESCRIPTION]

App Id: d2tpfomiiu71lo
Region: ap-southeast-1
Step: Domain activation
Status: Failed

Note: Do not include information that is sensitive in nature such as your domain name, company etc.

Issue/question
A clear and concise description of what the issue/question is.
Error message
If there is an error message, please include it here.
Note: Be sure to check the message for sensitive information.
Additional information
Please add any other relevant information. Please feel free to include screenshots.

Hi @Gddeveloper , would you mind paste the error message here? Thanks!


odroid xu4 reports itself as armv7l

can you please upload the 32 bit arm with that suffix too? :/

@ibuildthecloud (or give me moar powa :D )

to work around this, I'm changing the Dockerfile.dapper's like:
        @echo Downloading dapper
-       @curl -sL https://releases.rancher.com/dapper/latest/dapper-`uname -s`-`uname -m` > .dapper.tmp
+       @curl -sL https://releases.rancher.com/dapper/latest/dapper-`uname -s`-`uname -m|sed 's/v7l//'` > .dapper.tmp
        @@chmod +x .dapper.tmp


Add documentation on how to run instamatic over the network

For complex setups, where the camera and TEM control software are not on the same PC, it would be useful to have some documentation on how to set this up.

See also #59


[Bug report]: pin incorrect

Platform
Desktop
Version
1.7.0
Description
I cant acces with my Pin and I dont have my 24 words seed!
What can i do
Expected behaviour
Acces my account
Actual behaviour
No accesing
Can the issue reliably be reproduced?
Yes
Steps to reproduce the issue

Put correct pin
No acces

Operating System
Mac
Diagnostics
.

Developer Profile
No
Profile Type
Software (Stronghold)
Staking
Previously staked
Crash Status
None of the above
Error Messages
Incorrect pin
Error Logs
.

Duplicate declaration

[X] I have searched the issues tracker this issue and there is none

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hey there,
If you have the sronghold backup, you can create another profile in firefly and restore > then use the stronghold backup. Then creater another profile and send your iotas to other profile.

Look, iota, I love you, but this is 2023 and I have same PIN issue in both firefly and firefly shimmer. I'm 100% sure I have correct pin, but my wallets keep to tell that it is incorrect.
-Windows 10
-Inactive period without login is around 2 months
-for both same issue: firefly and firefly shimmer

Hi, is this still an issue in the latest version?

I think that
El El mié, 20 sept 2023 a las 15:58, Begoña Álvarez de la Cruz <
@.***> escribió:

Hi, is this still an issue in the latest version?
—
Reply to this email directly, view it on GitHub
https://github.com/iotaledger/firefly/issues/5643#issuecomment-1727790092,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A5NJCLALITS7LB7KEW7564DX3LY6ZANCNFSM6AAAAAAUDYUVJ4
.
You are receiving this because you authored the thread.Message ID:
@.***>

@goded40 you stll cant access your profile? You can always recover your funds from mnemonic and stronghold, you can create a new one with the latest backup you have, as written above in the thread

Hey there,
If you have the sronghold backup, you can create another profile in firefly and restore > then use the stronghold backup. Then creater another profile and send your iotas to other profile.

The network was recently upgraded, please download the latest firefly iota version 2.0.2

Closing due to inactivity, please update to the latest version (2.0.3 as of now) and let us know if the issue persists 🌷


[MISC] Cross-collection/ table Listener; trigger downstream task via insert

For use-cases such as this:
https://docs.superduperdb.com/docs/use_cases/items/video_search
We have a Listener / .predict with outputs in an output collection, and with a downstream Listener listening to that collection.
This needs to be repaired, because currently we assume that the downstream listeners act over the same Collection and
as the upstream.

An idea - return a BulkUpdate instance from model_update and then execute this - this will trigger the downstream tasks.
class BulkUpdate(Update):
    ...

db.execute(BulkUpdate(...))


CRD for TLSOption doesn't support documented spec.alpnProtocols

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What version of the Traefik's Helm Chart are you using?
10.3.2
What version of Traefik are you using?
2.5.1
What did you do?
Tried adding the following TLSOption using kubernetes, as suggested by https://doc.traefik.io/traefik/https/tls/#alpn-protocols
apiVersion: traefik.containo.us/v1alpha1
kind: TLSOption
metadata:
  name: placeholder-star-tlsoption
spec:
  alpnProtocols:
    - http/1.1
  minVersion: VersionTLS12
  maxVersion: VersionTLS13
  cipherSuites:
    - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
    - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
    - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
    - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  sniStrict: false
  preferServerCipherSuites: true

Helm chart 10.3.2 claims to use traefik 2.5.1, in which the ALPN protocol configuration was added
What did you see instead?
I got an error message claiming that spec.alpnProtocols is not a valid property.
I confirmed by looking in the helm chart's CRD in github that it is not expecting the new property that the documentation says should be there.
What is your environment & configuration?
Including traefik via helm:
- name: traefik
  version: 10.3.2
  repository: https://helm.traefik.io/traefik

Running on Docker for Desktop on Windows
Additional Information
I realize the 2.5.1 release is less than a month old, but I really need to disable http2 for one of my services because the wildcard certificate combined with http2 connection reuse is confusing Safari.

Hi,
Sorry for the delay, you are right.
Could you try with that one instead: https://github.com/traefik/traefik-helm-chart/blob/e3c5e86ea2176bb7c7cc64e8e415a4476e9e53a7/traefik/crds/tlsoptions.yaml

Thanks! This does allow me to set the ALPN protocol option now.


Create pyjs.maxhelp

simple help patch. just enough to become aware of how to work with pyjs.
this refers to #2

Yes, and it still opens your other patch directly 👍
Feel free to merge.


Give pagination some breathing room in reporting node

Add a little breathing room around the newly returned pagination component in scan history.
Before:

After:

@SEAjamieD Thank you for the CSS! I will merge this in.


Fix MCE processor now that Schema may have two types

Coverage remained the same at 27.176% when pulling de65c36eb016eb11fcbb29a0cc73e2dbcbdbdd92 on alyiwang:master into 15de751c389279de14de78b1a78957bbf6b4aa47 on linkedin:master.

Codecov Report

Merging #885 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #885   +/-   ##
=======================================
  Coverage   35.26%   35.26%
=======================================
  Files         307      307
  Lines        8231     8231
  Branches     1532     1532
=======================================
  Hits         2903     2903
  Misses       5328     5328

Continue to review full report at Codecov.

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


Consider publishing the language server to npm

Hello,
Have you considered publishing the Volar language server to npm, so it can be reused in other editors as well?

It's planned but still need some works. See https://github.com/yaegassy/coc-volar-experimental/issues/2, https://github.com/johnsoncodehk/volar/discussions/338.

Thanks for the reply!
If you don't mind I would leave this issue open until it is published to npm.

It's here: https://www.npmjs.com/package/@volar/server

Top 🔝🙂