imsprog: init at 1.3.9

Description of changes

Things done

Built on platform(s)

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

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

[x] sandbox = relaxed
[x] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

@GrahamcOfBorg build imsprog

@patka-123 Thank you for the review, I adjusted accordingly!
@GrahamcOfBorg build imsprog

@GrahamcOfBorg build imsprog

Done considering https://github.com/NixOS/nixpkgs/pull/291442. I opted against reusing the module, I think having a module which in the end adds one udev rule is not worth the extra file in the tree.
@sund3RRR  Can you check this build on darwin? I see a chance that it might just work.
@GrahamcOfBorg build imsprog

Done considering #291442. I opted against reusing the module, I think having a module which in the end adds one udev rule is not worth the extra file in the tree.
@sund3RRR Can you check this build on darwin? I see a chance that it might just work. @GrahamcOfBorg build imsprog

I don't know why NixOS can't enable udev rules from package without manually adding this in configuration. I think using it without a module is bad idea because new users may not understand why imsprog can't detect their programmer, because they don't know how to enable the rules.
I tested this thing on macOS and this doesn't work by imsprog design. This program needs additional feature to add macos device detection, so I set meta.platforms = linux for this package.
About your package: great job with autopatch hardcoded paths. But do you really need qt5.wrapQtAppsHook and qt5.qttools in buildInputs?

I don't know why NixOS can't enable udev rules from package without manually adding this in configuration.

Because adding packages to the store is an unprivileged action (available to all users), while adding udev rules is a privileged action (requiring elevated privileges, as one create privilege escalation schemes from modifying device access rules).

I think using it without a module is bad idea because new users may not understand why imsprog can't detect their programmer, because they don't know how to enable the rules.

I believe it is fairly well understood among Nix users what a package can do, and what it can't do. And hence any user that used some non-standard peripheral (think UART transceiver, JTAG ports, ...) already knows the drill of plugging in their stuff to services.udev.packages. However, there is a first time for everyone, and people trying this for the first time will most likely run into friction. I still prefer exposing users to the detail of "adding a udev rule to the system config" then to "enable the some magical configuration via programs.xyz.enable = true. However, this is purely my own take on the matter.

This program needs additional feature to add macos device detection

What would that be?

About your package: great job with autopatch hardcoded paths. But do you really need qt5.wrapQtAppsHook and qt5.qttools in buildInputs?

Thank you for pointing this out. wrapQtAppsHook in nativeBuildInputs definitely is an oversight on my end. I'll nix build .\#pkgsCross.aarch64-multiplatform.imsprog --print-build-logs to find out if cross compilation works, that'll provide sufficient evidence whether qt5.qttools is required in buildInputs at all.

However, there is a first time for everyone, and people trying this for the first time will most likely run into friction. I still prefer exposing users to the detail of "adding a udev rule to the system config" then to "enable the some magical configuration via programs.xyz.enable = true. However, this is purely my own take on the matter.

This is a huge problem of NixOS I think. This distro is really painful for new users. I want NixOS to become more popular, but it is impossible with current system design and attitude towards newbies.

This program needs additional feature to add macos device detection

What would that be?

Idk. I asked the darwin maintainers, they said that the program needs to detect devices darwin-way like. There is no udev rules on macOS.

@Pandapip1 Done! I also bumped the version and added a missing qt5.qtwayland dep.

@Lassulus would you mind taking a look if this can be merged?

Result of nixpkgs-review pr 312900 run on x86_64-linux 1

1 package built:

imsprog

Result of nixpkgs-review pr 312900 run on x86_64-linux 1

1 package built:

imsprog

@Pandapip1 Thanks for the note, found and fixed :)


docs: add 'Tinkering' section

Beta testers working with the device should have a good first explanation of the steps we are using in development regularly, but could be hard to figure out without guidance.

adds a 'Tinkering' section to the technical documentation
extends the 'Helper scripts' docs with additional details for
'bbb-config.sh'
fixes some broken links

I'll extend this pull-request to contain more references and also update the rest of the documentation.


cleanup repo

Issue
Repo content is currently inconsistent with actual repo status
Problem to solve
search for all wrong references:

[x]  pykube-ng -> pykube  - decision needed - response from namespace owner of pykube on PyP is curently pending
[x] Deprecated Elements: Identify all deprecated references and ensure they are either updated or removed.

Proposal
Replace old information with updated
Who can address the issue
Everyone, but solving the PyPI package namespace first is necessary

From the last PR discussion:

In order to keep track, here are the remaining references, right?

README.md
docs/index.rst
docs/users.rst
docs/write-an-operator.rst
pykube/config.py
pykube/http.py
pykube/test_config.py
pykube/test_http.py

Pretty much. Just keep in mind that it's docs/howtos/write-an-operator.rst to avoid confusion.

Information should be up to date for now.


Install and anaconda-

Hi Maju,
when install platypus I have the following message
Error: Installation of TensorFlow not found.  ....
Have install tensorflow with anaconda therefore tensorflow is not in /usr/bin/python.   The installation of tensorflow was done with:  method = 'conda', envname = 'r-reticulate'.
Do you have any flags which as in tensorflow will allow anaconda environment?
Thanks a lot
Alain

Hi,
I had this problem. I suggest you run the following commands:
install.packages("keras")
install.packages("tensorflow")
library(keras)
library(tensorflow)
install_keras()
install_tensorflow()

Thanks,
I love it with Rstudio 1.4 set the default Python to anaconda.
Alain


Combines all 5 open dependabot PRs in to one.

renovate, dependabot, it's all the same in the dark.


Enabling root access to s3 bucket fails with NoCredentialProviders error

What's going on?
By default, when Terragrunt creates the S3 remote state bucket, it enables root access by inserting a bucket policy (pr that added the feature: https://github.com/gruntwork-io/terragrunt/pull/978). I'm receiving an error during the creation of the root access policy;
terragrunt version: v0.23.8
terraform version: v0.12.24
[terragrunt] 2020/05/21 12:02:12 Create S3 bucket myawesomebucket
[terragrunt] 2020/05/21 12:02:12 Creating S3 bucket myawesomebucket
[terragrunt] 2020/05/21 12:02:13 Waiting for bucket myawesomebucket to be created
[terragrunt] 2020/05/21 12:02:13 S3 bucket myawesomebucket created.
[terragrunt] 2020/05/21 12:02:13 Enabling root access to S3 bucket myawesomebucket
[terragrunt] 2020/05/21 12:02:13 Create S3 bucket myawesomebucket returned an error: NoCredentialProviders: no valid providers in chain. Deprecated.
For verbose messaging see aws.Config.CredentialsChainVerboseErrors. Sleeping for 10s and will try again.
[terragrunt] 2020/05/21 12:02:23 Create S3 bucket myawesomebucket
[terragrunt] 2020/05/21 12:02:23 Creating S3 bucket myawesomebucket
[terragrunt] 2020/05/21 12:02:23 Looks like someone is creating bucket myawesomebucket at the same time. Will not attempt to create it again.
[terragrunt] 2020/05/21 12:02:23 Waiting for bucket myawesomebucket to be created
[terragrunt] 2020/05/21 12:02:24 S3 bucket myawesomebucket created.
[terragrunt] 2020/05/21 12:02:24 WARNING: Versioning is not enabled for the remote state S3 bucket myawesomebucket. We recommend enabling versioning so that you can roll back to previous versions of your Terraform state in case of error.

I'm supplying AWS credentials using the ~/.aws/config file
[profile developer]
credential_process = /opt/bin/awscreds-custom --username helen

Why is this happening?
In the pull request https://github.com/gruntwork-io/terragrunt/pull/978, the GetAWSCallerIdentity function is creating a session that does not use the same configuration that is used to create the S3 client.
This does not allow Terragrunt to add the root access policy when a user is sourcing their credentials like I have above.
The first commit in the pull request did not introduce this bug. Once the commit was made to use the config util/helper functions, was the moment the bug was introduced.
Possibly Related Issues

https://github.com/gruntwork-io/terragrunt/issues/671
https://github.com/gruntwork-io/terragrunt/issues/616

@bwhaley @yorinasub17

Thank you for the detailed bug report! The information you provided helped me to develop a fix quickly. Hopefully we'll have the fix in #1193 merged soon.

@KadenLNelson Out of curiousity, do the built-in get_aws_* functions work for you? E.g.
get_aws_account_id
get_aws_caller_identity_arn
get_aws_caller_identity_user_id
These functions do not include any session configuration, so I'm guessing that your credential configuration wouldn't work with them.


Detach git clone from the GitRepo initializer and other behavior changes.

I really think that the API build over the GitRepo class is kinda confusing, at least for myself. Between some of the issues one of the most obvious is the clone of the repo being done on the initializer of the repo. I really think that this shouldn't be done this way, as it provides a confusing behavior not expected by the sense of the method itself.
I have some ideas in mind in following PRs, but before starting to work I'd like to get some feedback:

First of all, detach the clone from the initializer. This should be manually triggered by the developer. Also, the GitRepo should store its internal state on load. (i.e., a GitRepo on initialization time should know if the repo is already cloned, which branch is checked out, and what commit sha it is).

Second of all, a GitRepo can have several states on it self through the repo_config property. We have a root_path, but if a Project uses a single repo_config and uses several triggers (manually, commit, nightly) the GitRepo should have sub-clones that depends on its internal state.

I want my GitRepo being setup on branch master, the clone_path then should be root_path/master/latest_sha_of_master/
I want my GitRepo being setup on sha abcd, the clone_path then should be root_path/branch_of_the_sha/abcd/
I do not provide any setup information, the clone_path then should be root_path/master/latest_sha_of_master/.

The behavior of the current checkout_branch and checkout_commit behaves the same way provided above. So from root_path, every variant of branch and sha are built.

clear_directory would behave as it does now, deleting all the root_path tree. but we can extend it to clear_directory(sha: nil, branch: nil) which will delete just certain paths.

clear_directory(sha: "abcd") will delete root_path/branch_of_the_sha/abcd.
clear_directory(branch: "master") will delete root_path/master/**.

I'm really into this little refactor (which will break almost anything of the current setup) and provides a more robust and reliant architecture).
Benefits

Won't need to have conflicts when different workers might be working with the same repo_config but different sha, branch or general state of the repo itself.
All the explanation given above.

Cons

Cloning won't longer be on the initializer.
New clone api: clone(branch: nil, sha: nil, shallow: true).

cc @taquitos @KrauseFx

Discussion on this? We can manage to split this into small pieces and don't end up with a massive PR. Let me know if a call is required if something is not clearly explained here.

I ping again @taquitos and @KrauseFx , should this be done for beta? Or just close this


[$1000] Inconsistency in dragging attachments into composer

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

drag and drop multiple attachments in to composer.
observe in the composer only one attachment is visible.
another attachment is not visible.

Expected Result:
if you are allowing multiple attachments we should send multiple attachments or else we should allow only one attachment at a time.
Actual Result:
composer is allowing multiple attachments and showing only one attachment or sending only one attachment.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: v1.3.52-3
Reproducible in staging?: yes
Reproducible in production?: yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/38435837/4d8e4ea2-7986-41c7-80d9-8d6fb46086d0
https://github.com/Expensify/App/assets/38435837/fdf97dc9-c285-445d-a368-b606aeb710b9
Expensify/Expensify Issue URL:
Issue reported by: @immadisetty-jaya-surya
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1691132393227349
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0186c6898bf1b539df
Upwork Job ID:<PHONE_NUMBER>909872128
Last Price Increase: 2023-08-14

I just had a chat with @Julesssss and @luacmartins and it sounds like this behavior isn't a bug. The act of dragging/selecting multiple files and uploading them to the composer does not result in uploading multiple files. We currently only support uploading a single file at a time.
That said, I do agree that we should support multiple file uploads in a single drag since it would feature-match OldDot's upload limit of up to 10 files at a time. But I think that would make this more of an Improvement than a Bug.

@johncschuster I reported this as bug because I feel we're only allowing one file at a time.. but we're not showing it to the user anywhere or any alert is there so I reported this as a bug.

I do agree that we should support multiple file uploads in a single drag since it would feature-match OldDot's upload limit of up to 10 files at a time. But I think that would make this more of an Improvement than a Bug.

Since this is a new feature, I think we should discuss design first.
@johncschuster do we have design doc for multiple uploads support?

Asking about how we should move forward in Slack

The discussion in Slack is ongoing. I'll be back with an update shortly.

Ok, we've come to a consensus. The bug described here is not a bug – it's a behavior that has not yet been built into NewDot. Given that it hasn't been designed yet, I'm going to close this issue until we discuss how we want to treat the ability to upload multiple image attachments into the same chat message.


refactor: rename EthConsensus

Closes #566

Codecov Report

Merging #572 (277f5a9) into main (c070e77) will increase coverage by 0.09%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #572      +/-   ##
==========================================
+ Coverage   72.92%   73.01%   +0.09%
==========================================
  Files         244      244
  Lines       24690    24690
==========================================
+ Hits        18004    18028      +24
+ Misses       6686     6662      -24

Flag
Coverage Δ

unit-tests
73.01% <0.00%> (+0.09%)
:arrow_up:

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

Impacted Files
Coverage Δ

bin/reth/src/node/mod.rs
0.00% <0.00%> (ø)

crates/consensus/src/consensus.rs
0.00% <ø> (ø)

crates/consensus/src/lib.rs
100.00% <ø> (ø)

crates/stages/src/stages/bodies.rs
93.69% <0.00%> (+0.38%)
:arrow_up:

crates/transaction-pool/src/pool/txpool.rs
58.73% <0.00%> (+0.52%)
:arrow_up:

crates/transaction-pool/src/test_util/mock.rs
60.37% <0.00%> (+6.66%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


All Spots Panel: default selection

When you first open the all spots panel, it should by default be scrolled down to the spot that is currently open in the notebook. That spot should be outlined in blue to show it is selected.
This way, users can quickly navigate to the spots chronologically nearby the current spot.

@nicolasmroberts Are you still thinking the All Spots Panel will be useful? Without the swipe gestures it's not as quick to open. I gravitate towards using the Spots Lists in the main menu but not sure about everyone else. Just double checking before we put more work into this.

@jessicagood I agree. I think we can get rid of the all spots panel. Between the "RECENT SPOTS" that displays in the notebook when no spot is selected and the spots list in the main menu, I think we've got navigating the spots list covered.

Removed AllSpotsPanel with commit 9c88522586970529b722b7f0367cb354e9a7239d and a30945c08efa54a289e6f5291d84d1978d38d31e


feat: possibility to render directly to stdout and render cli command

🔗 Linked issue
#2466
❓ Type of change

[ ] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[x] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
Added a new option to nitro.prerender called stdout (default: false). When that option is set, the routes are generated to console output instead of written to files.
Added a new command line tool called render that will render a single given route. It can have an option --stdout and then it will output the route to console.
📝 Checklist

[x] I have linked an issue or discussion.
[x] I have updated the documentation accordingly.

You can test this feature like this:

Add a route to playground/routes/, for example abba.ts that has this

export default eventHandler(async (event) => {
  return "AbbA";
});

run pnpm nitro build --dir playground to first build the playground
run pnpm nitro render --dir playground --stdout abba
you should now see "AbbA" in the output of the previous render command

You can test this feature like this:

Add a route to playground/routes/, for example abba.ts that has this

export default eventHandler(async (event) => {
  return "AbbA";
});

run pnpm nitro build --dir playground to first build the playground
run pnpm nitro render --dir playground --stdout abba
you should now see "AbbA" in the output of the previous render command

Is there possibility to get this forward? It will fall behind the main, again. Please let me know if something else is needed to get it merged.

Hi dear @jrutila thanks for your pull request and sorry for late review. I really appreciate it. ❤
I cannot accept it as-is for some reasons:

Nitro has already a CLI preset intended for same thing (standalone output that can render to stdout without depending in nitro builder core) -- PR welcome to improve it
Before thinking about considering a new sub-command like this, we need to implement a smart rebuild functionality that avoid nitro rebuild if source has not been changed to avoid extra rebuilds otherwise it will be an impractical feature
The proposed API should (prerenderRoute()) also be possible with programmatic API to be usable with other meta frameworks used in conjunction with nitro

For maintenance i am closing this PR (for now) let's keep tracking about the idea via #2466 i definitely love to work on this in the futur.


How to push changes to shared types?

In graphql federation, if a value type is shared across multiple subgraphs, then it has to be defined identically on each subgraph to be able to push the schemas to the schema registry.
However, if we want to push a change on that type to the schema registry, how are we expected to do that? The /push endpoint fails because of validation, which is understandable.
However in this case, we would want to be able to push the change, accept the validation failure, and push the other subgraphs until the type becomes identical once again.
That does not seem to be possible with the current API. Could it make sense to have a new endpoint or an extra parameter to the /push endpoint to skip validation?
This scenario is documented in the apollo graphql federation as well: https://www.apollographql.com/docs/federation/v1/value-types#modifying-a-value-type

Hello @abc-moviestarplanet , that is certainly true with GraphQL Federation V1 and one of the main problems addressed by Federation V2, which the schema registry supports. There is now a set of new directives, such as @shareable and @inaccessible, that allow you to evolve value types in a pretty easy fashion. Here's the documentation:
https://www.apollographql.com/docs/federation/federated-types/sharing-types
Specifically, the section Adding new shared fields describes the process.

right, and we have an API test for this :)
https://github.com/tot-ra/graphql-schema-registry/blob/master/test/functional/schema/push.test.ts#L14

Thank you both for the responses and the useful links.
Our subgraphs are unfortunately using some libraries that don't yet support apollo federation v2. But I suppose that will suffice as a solution to the question.


Pathfinder prevents the PostgreSQL container from shutting down gracefully.

If the postgres container needs to be shut down for any reason (could be a node being drained for maintenance, upgrade, etc. as an example) Pathfinder appears to prevent postgres from shutting down gracefully. We always run up to the grace period timeout on the container and postgres gets killed leading to risk of corruption or data loss.
After some investigation it's my understanding that the container runtime for Kubernetes/OpenShift sends SIGTERM to stop the process. https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination
PostgreSQL will wait forever for all connections to terminate before shutting down when it receives SIGTERM
https://www.postgresql.org/docs/current/server-shutdown.html
We're not setting a grace period on the PostgreSQL container so we're getting the default terminationGracePeriodSeconds: 30.
Meanwhile the quarkus.datasource.jdbc.idle-removal-interval default is 5m.
I upped the grace period to about 120s and reduced the idle-removal-interval to 60 seconds using the environment variable and the DB has thus far stopped cleanly after about 80-90 seconds each time. I think we need to come up with a reasonable set of values for both of these with the grace period being a fair bit larger than the removal interval and I'm looking for some input for what would be acceptable on the JDBC side.
I'm also curious if we have any means to keep the use of any single connection in the pool fairly short as I think the grace period needs to exceed non-idle time + idle time with some reasonable duration to spare.

Any other approach to allow cleanly shutting down the DB would also be welcome as well.

I have asked @m-brophy to look into this. Thanks.


IRGen: Don't output the full file path in the withoutActuallyEscaping…

… verification
At Odebug we will now print only the file name (not the full path to the
file) and in optimized mode no file name will be included.
This mirrors what we do in Swift's asserts.
rdar://47880964

@swift-ci Please test

I believe assertions generally do print the full filename (though people are talking about changing #file to do something else).

@jrose-apple You are right. I just happened to test swiftc filename.swift.

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - f28c2f5feb41e4999c97cf971c068e1344b6da43

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - 637818ab94321446c88dd3ff27f5de137ecb48a8

Build failed
Swift Test OS X Platform
Git Sha - 637818ab94321446c88dd3ff27f5de137ecb48a8

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - 637818ab94321446c88dd3ff27f5de137ecb48a8

Build failed
Swift Test OS X Platform
Git Sha - 637818ab94321446c88dd3ff27f5de137ecb48a8

@aschwaighofer should this be fixed in Swift 5.0 / Xcode 10.2? My test steps still emit a full path in an optimized build: SR-9895

No this change is not in Xcode 10.2


Make UI tests run on travis.

Make UI tests run on Travis.

Build seems to be failing with the following error.
com.android.builder.testing.ConnectedDevice > No tests found.[test(AVD) - 5.1.1] FAILED

I am not able to figure out the exact issue. It works perfectly when I run it locally. It would be great if someone could help me out here. :)

As far as I understand this PR and #2897 are related and both of them don't work because #2897 doesn't work. Please feel free to reopen them if I got them wrong


[Feature Request] Scheduled Backup

A backup of the DB that runs on a schedule and that can be downloaded and imported

+1

+1

I see a fellow assassin is hanging out here

+1

Or even just some commands that can be run (from external, or before a system backup) to dump a backup file to disk.
Ie if in docker a:
docker exec -it lubelog my backup command

To a mounted folder

No scheduled backup yet, but as of 1.0.6 there is a function to create and restore backups:
https://youtu.be/r_n9ncgv31E?si=Q8xxWaMnmcJWAPYl&t=293

Is there a way of calling that rather than doing via giu?  Means it could be scheduled with external command

@psyciknz I'm currently working on the API controller for it, when it's released you will be able to hit the API endpoint using cURL and it will return a link to download the db zip file.

@psyciknz there is now an api endpoint you can hit with cURL and it will return a download link for the zip file.
it's /api/makebackup
You have to use root user credentials and basic auth to hit it.

Nice work.  Will have to pull a new version and try it out

I'm gonna close this since this feature is now released.

I'm using the docker image and I'd prefer to set a backup schedule and include the file with my backup tool. Having the application create the backup is one less thing I have to worry about if/when there are breaking API changes.
@hargata No pressure to add a schedule to the app as the API works fine. I'm just curious to hear your thoughts to avoid opening a duplicate issue.

Personally I'd use deck-chores.   Allows the use of cron In various container.  But it's set up from the compose file for the container.
Ie your lubelog container definition. Would have a cron and cron command to create the backup and store it somewhere.
It's quite a handy way of doing things and keeps the configuration in the relevant container compose.
Eg here is a deckchores set up to run a command in a download container I have called ytdl
labels:
deck-chores.job-ytdl.command: bash -c "/config/runupdate.sh"
deck-chores.job-ytdl.cron: "* * * */6 1 0 "
And so this runs a command in the ytdl container at /config/runuodate.sh
Might be a way of doing it.


Fix bug when running multiple databases migrations

Fix https://github.com/WhyNotHugo/django-mercadopago/issues/23.
For test it, for example, add a DATABASES config:
DATABASES = {
    'another': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    },
    'default': {
        # your configs
    },
}

then run
python manage.py migrate --database another

Sorry for the slow reply.
Okay, I get it, makes sense.

As a kind of backup of the structure.

That's a bit redundant though; that's exactly what migrations are for, since they're a scripted recipe to create the exact same structure.

But, the important thing is that, simply, anyone who manages at least 2 almost cloned databases

Yeah, an odd scenario, but no reason to keep breaking it.
I'm happy to merge this if you can rebase it (sorry, I was fed up of untidy code and reformated all of it with black).

Thanks!


i18n(id) Update components.mdx

Description
Updating outdated and fix small error in translation

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

id
guides/components.mdx
Localization changed, will be marked as complete.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

Hi @yudyananda are you still interested in updating this page? Let us know if you have any issues with @HiDeoo’s suggested changes!

Thanks again for opening this PR @yudyananda — as we haven’t seen any updates recently, I’ll close this PR so it doesn’t get stale, but happy to receive any future PRs if you have time!


Ensure we handle all knowledge panel actions: I spotted this the other day

What

Ensure we handle all knowledge panel actions: I spotted this the other day
Products with missing ingredients photo, it seems

Next time, please provide the barcode.

Even links like "Know more about Nutriscore, EcoScore…" should be a button.
Text links are for browsers.
There's a huge amount of work to "beautify" KPs.


Common cache should only cache resources within watch-namespace

The watch-namespace option specifies which KIC should watch for.
https://github.com/Kong/kubernetes-ingress-controller/blob/ab7a79428d927de82e25f2a9b1f778f17ebd957a/internal/manager/config.go#L150-L152
However, due to the following implementation, namespace for the publish-service is implicitly added to watch-namespace. The modification was made to implement Gateway API. https://github.com/Kong/kubernetes-ingress-controller/pull/1998
https://github.com/Kong/kubernetes-ingress-controller/blob/ab7a79428d927de82e25f2a9b1f778f17ebd957a/internal/manager/setup.go#L63
https://github.com/Kong/kubernetes-ingress-controller/blob/ab7a79428d927de82e25f2a9b1f778f17ebd957a/internal/manager/setup.go#L98
https://github.com/Kong/kubernetes-ingress-controller/blob/ab7a79428d927de82e25f2a9b1f778f17ebd957a/internal/manager/config.go#L155-L156
This behavior is unexpected as KIC needs lots of extra permission to access resources in publish-service namespace as well.
Especially, the permission to access Secret resource is too strong. Since kong-proxy needs to provide TLS configurations, role of kong-proxy needs permission to access Secret resources across namespaces. Furthermore, since publish-service needs to be in the same namespace as kong-proxy, the above implementation implies KIC service account also automatically gains permission to Secret resources, which kong-proxy can access to. This situation is not desirable in multi-tenancy environment. (With service account token of KIC, service account token for kong-proxy can be obtained, and with service account token of kong-proxy, a wide range of Secret resources can be accessed to.)
In conclusion, the namespace of publish-service should not be included in watch-namespace. Originally, in order to implement Gateway API, only permission for accessing Service resource in publish-service is needed. However, the current implementation also requires access to Ingress/Service/Endpoints/Secret/UDPIngress/TCPIngress/KongIngress/KongPlugin/KongConsumer, which is insecure. The gateway controller should use its own cache to meet the principle of least privilege.

Thanks for the report @mkgrei.
Just wanting to confirm: in your multi-tenant environment with multiple deployments of the KIC are you able to mitigate this problem by using different namespaces for the different ingress controller deployments?
Also as far as impact goes, I expect the impact of this problem you're expecting here is that if someone were to wrest control of the controller/gateway pods they would be able to read resources (Secrets, namely) from other deployments. Are there any other impacts your foresee here that you want to enumerate?

Thank your for your response @shaneutt .
We are using "workspace" in Kong Gateway to realize multi-tenancy. (https://docs.konghq.com/gateway/2.8.x/configure/auth/kong-manager/workspaces/#main) Different user uses different (kong) workspaces and different KICs in different (k8s) namespaces, while sharing the same kong-proxy. The problem above cannot be mitigated by using different namespaces of k8s but can be mitigated by using publish-status-address option.
https://github.com/Kong/kubernetes-ingress-controller/blob/ab7a79428d927de82e25f2a9b1f778f17ebd957a/internal/manager/config.go#L157-L159
As we are using KIC since 1.x, the behavioral change in publish-service option is confusing and especially in multi cluster environment, publish-service can be configured identically by provisioning the same namespace and service, while service address IP cannot. (Not to mention in order to use Gateway API resource, publish-service is needed.)
Basically we leave multi tenant users to deploy KIC by themselves, because KIC needs the user's kong account token to use their workspace. Thus with the current implementation and the use of publish-service, users will be able to gain extra permission to access cluster scoped Secrets, as most ingress proxy products have the permission to. The permission to view Ingress/Service etc. is not problematic, but only Secrets is our concern.

I create the issue from code view, so I missed the issue template. Sorry about that.
We are using,

kubernetes v1.22
KIC

currently using: 1.2
trying to upgrade to: 2.2.1

steps to reproduce

install multiple KIC with publish-service option

It sounds like "Steps to reproduce" are basically just "deploy multiple instances of the KIC, they will all have excessive secret permissions", but if you have any additional details or steps to add here please do.

Yes, that is the case.
Also I might found another problem. I did not test this yet, but just from the code reading. If there are Ingress resource in k8s namespace: kong-proxy, as all KIC will try to create corresponding kong Route, there will be host name collision. And in my understanding, kong cannot create Route with same host name in different workspaces. This problem can be avoided by not creating Ingress in the namespace of kong-proxy, but still this will be a limitation.

To have collisions of this sort would be somewhat expected when using the same namespace in a multi-tenant setup like this. We advise when deploying multiple instances and separate tenants of the ingress controller in v2.x.x+ currently to put each of them in their own namespace, and use --watch-namespaces to define the boundaries of namespaces which the individual tenants should be responsible for. If I'm not mistaken making such a change would alleviate the problems you originally reported? Note that we would still consider making future changes that would support a restricted multi-tenant deployment when using a single namespace, but as I currently don't have a sense of how long that would take to get released I would like to provide an interim solution, let me know your thoughts.

Yes, I agree. watch-namespace options should set the boundary for the tenant's responsibility.
The issue I was addressing is that publish-service implicitly expands watch-namespace when kong-proxy does not belong to watch-namespace.
We will use publish-service-address instead of publish-service to mitigate this problem for now.
As publish-service is expected to be set when using Gateway API resource, I hope the problem will be fixed before its release.

Understood, glad you have a workaround for the moment. I'm going to queue this for review by maintainers in one of our upcoming grooming (internal) grooming sessions and we'll look at getting this into a sprint for an upcoming release.

Can you clarify the issue/which Secrets you would not want to grant KIC access to?
There is no separate kong-proxy ServiceAccount, only the single KIC ServiceAccount (it's typically accessible to both since it's bound at the Pod level rather than per-container, but only KIC uses it).
The proxy does not talk to the Kubernetes API at all. KIC is responsible for reading Kubernetes resources and translating them into proxy configuration on the proxy's behalf: it reads the TLS Secrets referenced by Ingress/HTTPRoute/etc. resources, not the proxy.
You may have a ServiceAccount for the Deployment that runs the proxy because we create one by default (assuming the more common configuration where there's a single proxy and controller instance in the same namespace), but if you run only the proxy in that namespace and KIC instances in other namespaces, you can remove the ServiceAccount and associated Roles attached to the proxy deployment.
Normally the only Secrets I'd expect to live in the proxy Deployment's namespace are for the default proxy certificates (the certificates served when there's no matching SNI/certificate combination), the image pull/license Secrets, and the certificate Secrets for the Manager/Portal/admin API Ingresses if in use. Access to the proxy Service namespace would grant access to those only, not other Secrets used by the proxy--the proxy does not pull those from the API, the various controller instances push them to the proxy.
I wouldn't expect the default certificates to be in use for most multi-tenant environments (on the assumption that they wouldn't match any of the tenants' domains), though you could bake them into the image rather than mounting from a Secret if needed. For the rest, hybrid mode would allow you to isolate the other Secrets in a namespace (where the control plane instances reside) other than the publish Service namespace (where the data plane instances reside), though you'd still need to bake the cluster certificate into the dataplane images.

Thank you for your explanation, @rainest.
I see that there were two misunderstanding in my side. First, I thought the kong-proxy (data plane) was the one needed to list Secret resource, which is not the case. Second, what I thought as Service Account for kong-proxy (data plane) was actually Service Account for kong (control plane).
So the permission to list Secret is not necessary for kong-proxy (data plane) Service Account. As for kong (control plane), we are using hybrid mode at the moment, and deployed kong (control plane) and kong-proxy (data plane) in the same namespace.
We will consider separating the namespaces for control plane and data plane. I would still wish if namespace of publish-service can be excluded from watch-namespace.

From my end, there are two considerations for changing that current implementation:

It's probably cumbersome to rework the controllers to only watch Services in the publish namespace. The watched namespace set is a manager-level setting (we currently only instantiate one of those and I don't think it's easy to make multiple managers talk to one another), and I'm not sure how well the controllers work without homogeneous permissions. I don't expect there's a one-size-fits-all approach in the code either for handling both configurations that want to watch the publish namespace (probably most single-tenant installs) and those that do not.
We intend to rework the way that multi-tenancy works, with a view towards supporting it within a single controller instances that manages multiple data plane groups, with each group only receiving a subset of the visible configuration (e.g. the controller would read configuration for all tenants and then only deliver tenantA's configuration to tenantA's data planes, etc.).

Centrally managing the controller should obsolete this issue, though I'd note from there that the change is more on of convenience. There shouldn't be a reason tenants need to manage their controller instances currently--there's nothing I would expect in the controller-level settings that they'd need to manage. A provider-managed controller can still ingest tenant-created Ingresses and such. Do you know of a reason that requires direct user management of the controller Deployment, and if not, does managing those centrally address the security concerns?

Do you have the ticket number in question? That's not correct regarding our RBAC requirements: KIC only needs access to the workspace it's configured to use so long as that workspace already exists. IIRC there were some bugs related to improper handling of workspaced requests that incorrectly sent some requests to default in the past, but I'm not aware of any at present. The single-workspace RBAC users are fine for it.
You can create am admin invite for your users to use the GUI, where only they would know the token, and a separate RBAC user for the controller that you manage. You already have de facto access to their system by virtue of managing, and having access to, the central database where it resides, as well as having the super admin credentials you use to create new users. Guarding that is a matter of internal access controls, and you'd apply the same controls to the individual instance RBAC users as you apply to the higher-level credentials that grant access to the entire system.

I see. I confirmed that RBAC account can be used for KIC (2.2.1).

It seems as though this is resolved, let us know if this is not the case and we will re-open it. :+1:


Export lint output to file

Is your feature request related to a problem? Please describe.
It's very exciting to see linting become a first class citizen of Bicep with @johan-lindqvist's work on https://github.com/Azure/bicep/pull/10819
My understanding of this feature (which I hope to be able to use when it ships with the Azure CLI https://github.com/Azure/azure-cli/pull/27378) is that it outputs errors and warnings to stdout, in two possible formats; the default one and Sarif.
Whilst this is great, it means there's a job of parsing work to do if you'd like to interrogate the results, perhaps to surface them in an Azure Pipeline.  We tackle this with arm-ttk at the moment with this extension by @sam-cogan: https://github.com/sam-cogan/arm-ttk-extension-xplatform
Describe the solution you'd like
The idea I have in mind, is the ability to output lint results to a file.  And possibly expand the formats available to include say JUnit.  You can kind of see the scenarion that I have in mind in this blogpost that demos surfacing test results from Vitest (could be anything really) in Azure Pipelines
What do you think?
I can see the lint options currently look like this:
  {exeName} lint [options] <file>
    Lints a .bicep file.
    Arguments:
      <file>        The input file
    Options:
      --no-restore                   Skips restoring external modules.
      --diagnostics-format <format>  Sets the format with which diagnostics are displayed. Valid values are ( {string.Join(" | ", Enum.GetNames(typeof(DiagnosticsFormat)))} ).
    Examples:
      bicep lint file.bicep
      bicep lint file.bicep --no-restore
      bicep lint file.bicep --diagnostics-format sarif

Imagine an extra --outfile option as well, which if supplied passes the text output into that file?

@johnnyreilly as a stopgap, have you tried converting from sarif -> junit xml format?
For example:
~/.azure/bin/bicep lint main.bicep --diagnostics-format sarif 2> lint.sarif
npx -y sarif-junit -i lint.sarif -o lint.xml

oh nice! let me try!
What do you think about the file output option?
I'm doing this right now:
az bicep build --file ${{ value.path }} > ${{ value.path }}.lint-output.txt 2>&1

What do you think about the file output option?

I think that's a great suggestion - redirecting stderr has pitfalls as it's not straightforward to distinguish between success (sarif format output) and failure (for example, failing to find the .bicep file on disk).

BTW I'm using az bicep build as the az bicep lint isn't available yet (see https://github.com/Azure/azure-cli/pull/27378)
In the interim I'm planning to build a mini parser which will read the build output - I can throw it away in future

Built a mini bicep build output -> JUnit JavaScript script that we're running in Azure Pipelines until az bicep lint lands later this year.   Not perfect, but good enough for our needs.
//@ts-check
const fs = require("fs");

// This is necessary until direct lint support lands in the Azure CLI for Bicep
// See: https://github.com/Azure/bicep/issues/11960

/**
 * @typedef {Object} BicepLintWarningsOrError
 * @property {string} type
 * @property {string} typeAndMessage
 * @property {string} filePath
 * @property {string} lineNumber
 * @property {string} columnNumber
 * @property {string} line
 */

async function convertBicepOutputToJUnit() {
  // Check if there is at least one command-line argument
  if (process.argv.length < 4) {
    console.error(
      "Example usage: node scripts/bicep-lint-to-junit.js containerapps.bicep.lint-output.txt containerapps.bicep.lint-output.junit.xml"
    );
    process.exit(1); // Exit with an error code
  }

  // Get the first command-line argument (index 2 because 0 and 1 are reserved for node and script file paths)
  const bicepOutputPath = process.argv[2];
  const bicepOutputJUnitPath = process.argv[3];

  const dirname = process.cwd();

  console.log("Loading:", bicepOutputPath, "from:", dirname);

  const bicepOutput = await fs.promises.readFile(bicepOutputPath, "utf-8");

  const bicepOutputLines = bicepOutput
    .replace(/\r/g, "")
    .split("\n")
    .filter((line) => line.trim().length > 0)
    .map((line) =>
      line
        .replace("WARNING: ", "")
        .replace("ERROR: ", "")
        .replace(dirname, "")
        .replace(/"/g, "")
    );

  if (bicepOutputLines.length === 0) {
    console.log("No issues found in:", bicepOutputPath);
    return;
  }

  /** @type {Map<string, BicepLintWarningsOrError[]>} */
  const bicepLintWarningsAndErrors = bicepOutputLines
    .map((line) => {
      try {
        const [filePathAndLine, typeAndMessage] = line.split(" : ");
        const [filePath, lineParts] = filePathAndLine.split("(");
        const [lineNumber, columnNumber] = lineParts
          ?.replace(")", "")
          .split(",");

        const type = typeAndMessage.startsWith("Error")
          ? "Error"
          : typeAndMessage.startsWith("Warning")
          ? "Warning"
          : "Unknown";

        return {
          type,
          typeAndMessage,
          filePath,
          lineNumber,
          columnNumber,
          line,
        };
      } catch (error) {
        console.error("Error parsing line:", line);
        console.error(error);
        return undefined;
      }
    })
    .reduce(
      (groupedByFilePath, curr) =>
        curr === undefined
          ? groupedByFilePath
          : groupedByFilePath.set(curr.filePath, [...(groupedByFilePath.get(curr.filePath) || []), curr]),
      new Map()
    );

  if (bicepLintWarningsAndErrors.size === 0) {
    console.log("No issues parsed in:", bicepOutputPath);
    return;
  }

  console.log("Parsed issues:", Array.from(bicepLintWarningsAndErrors.values()).flat());

  const entries = Array.from(bicepLintWarningsAndErrors.entries());

  const junit = `<?xml version="1.0" encoding="UTF-8"?>
<testsuites>
${entries.map(([filePath, bicepLintWarningsAndErrors]) => {
  return `    <testsuite name="${filePath}">
  ${bicepLintWarningsAndErrors
    .map((lintOrError) => lintOrError.type === "Error"
        ? `        <testcase name="${lintOrError.line.replace(filePath, "")}" classname="${filePath}" file="${lintOrError.filePath}" line="${lintOrError.lineNumber}">
            <failure message="${lintOrError.typeAndMessage}" />
          </testcase>`
        : `        <testcase name="${lintOrError.line.replace(filePath, "")}" classname="${filePath}" file="${lintOrError.filePath}" line="${lintOrError.lineNumber}" />`
    )
    .join("\n")}
    </testsuite>
`
}).join("\n")}
</testsuites>`;

  console.log(`
JUnit output:

${junit}`);

  console.log("Saving:", bicepOutputJUnitPath);

  await fs.promises.writeFile(bicepOutputJUnitPath, junit);

  console.log("Done!");
}

convertBicepOutputToJUnit().catch((error) => {
  console.error(error);
  process.exit(1);
});

// node scripts/bicep-lint-to-junit.js containerapps.bicep.lint-output.txt containerapps.bicep.lint-output.txt.junit.xml

Parking the junit conversation for a moment @anthony-c-martin, I've been having a quick gander at what an implementation might look like for a potential --outfile option.
By the looks of it, the relevant code sits in https://github.com/Azure/bicep/blob/main/src/Bicep.Cli/Logging/BicepDiagnosticLogger.cs
A simple implementation could take this code:
https://github.com/Azure/bicep/blob/d7b6bebbacca3f87cc71ae9f745699465f798b46/src/Bicep.Cli/Logging/BicepDiagnosticLogger.cs#L130-L132
which turns the SARIF output into JSON and flushes it to the log, and also (if an --outfile option was provided) writing to that file as well.
Is something like that what you had in mind?  Or something different?  Of course with the current implementation that would only work if you had SARIF format selected; so that would have to change.  But I wanted to get a sense of whether that would be the sort of thing you felt worked?
Also to add, I'm imagining that outputting to file will not replace outputting to console; it will be additional.  So if --outfile is supplied, you would get results in the console and in a file.  This would mean that in a CI context you'd see the linting failures in the output and then be able to do more specific visualisation things with them by interrogating the file.
What do you think?

Sorry for the long delay in responding!

Is something like that what you had in mind? Or something different? Of course with the current implementation that would only work if you had SARIF format selected; so that would have to change. But I wanted to get a sense of whether that would be the sort of thing you felt worked?

Yeah, I believe this would work. However I'm wondering if we need it - instead could we just output to stdout instead of stderr? That way you'd be able to just to run: bicep lint main.bicep --diagnostics-format sarif > lint.sarif, and there wouldn't be a need for an --outfile option.

Also to add, I'm imagining that outputting to file will not replace outputting to console; it will be additional. So if --outfile was supplied, you would get results in the console and in a file. This would mean that in a CI context you'd see the linting failures in the output and then be able to do more specific visualisation things with them by interrogating the file.

My opinion is that it would give more flexibility to just log to file if the --outfile option is used; sarif isn't very human-readable, so logged to the CI output doesn't feel that helpful by default. However, if someone does want that behavior, they can always use cat:
bicep lint main.bicep --diagnostics-format sarif > lint.sarif
cat lint.sarif

I will respond to this soon - promise!

FWIW here's how I've set this up with the latest Bicep release (0.24.24):
https://github.com/anthony-c-martin/bicep-on-k8s/blob/8281ba0fbb4efe42bcb6b282f925936ea468598d/.github/workflows/ci.yml#L36-L48
Example PR with warnings/errors raised by the linter:
https://github.com/anthony-c-martin/bicep-on-k8s/pull/1

This looks quite promising! Let me give it a try on ADO pipelines

Just doing some experimentation now @anthony-c-martin.  I'm not sure whether this should be regarded as a bug or something that makes the case for a dedicated output to process mechanism.
Consider a bicepconfig.json like this:
{
  // See https://aka.ms/bicep/config for more information on Bicep configuration options
  // Press CTRL+SPACE/CMD+SPACE at any location to see Intellisense suggestions
  "analyzers": {
    "core": {
      "rules": {
        "no-unused-params": {
          "level": "warning"
        },
        "no-unused-vars": {
          "level": "warning"
        },
        "secure-secrets-in-params": {
          "level": "error"
        }
      }
    }
  },
  "experimentalFeaturesEnabled": {
    "sourceMapping": true
  }
}

Running az bicep lint --file infra/main.bicep --diagnostics-format sarif > $(System.DefaultWorkingDirectory)/biceplint.sarif 2>&1 will result in output like this:
WARNING: WARNING: The following experimental Bicep features have been enabled: Source mapping. Experimental features should be enabled for testing purposes only, as there are no guarantees about the quality or stability of these features. Do not enable these settings for any production usage, or your production environment may be subject to breaking.

{
  "$schema": "https://schemastore.azurewebsites.net/schemas/json/sarif-2.1.0-rtm.6.json",
  "version": "2.1.0",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "bicep"
        }
      },
      "results": [
        {
          "ruleId": "no-unused-vars",
          "message": {
            "text": "Variable \"unusedX\" is declared but never used. [https://aka.ms/bicep/linter/no-unused-vars]"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file:///home/vsts/work/1/s/infra/main.bicep"
                },
                "region": {
                  "startLine": 67,
                  "charOffset": 5
                }
              }
            }
          ]
        }
      ],
      "columnKind": "utf16CodeUnits"
    }
  ]
}

The presence of WARNING: WARNING: The following experimental Bicep features have been enabled... at the start of the biceplint.sarif file breaks usage of the output.
What would the advice be on how to handle this?  As I said at the top, I'm not sure whether this should be regarded as a bug or something that makes the case for a dedicated output to process mechanism.  What do you reckon?

Additional thoughts: I took a look at the linting in GitHub Actions here: https://github.com/anthony-c-martin/bicep-on-k8s/actions/runs/7224883231/job/19687151956?pr=1
By the looks of it, in the case of an error you just get a hard fail with no output. The pull request: https://github.com/anthony-c-martin/bicep-on-k8s/pull/1 initially got me very excited, as I thought it was the lint failures being surfaced into the PR. Unless I'm reading it wrong, it seems like the messages in the PR like this:

are actually coming from somewhere else. Certainly if I fail a lint with an error using Bicep 0.24.24, the bicep.sarif is as simple as:
ERROR:

Given you'll generally get the full error later when a bicep build takes place, it's still relatively straightforward to get to the reason for a build failure.  It does feel unfortunate that lint fails without revealing too much though.

@johnnyreilly the difference is that I'm using the bicep CLI directly - it looks like the AzureCLI implementation has a bug if Bicep returns a non-0 exit code (e.g. there are any build errors). Would you mind raising an issue in https://github.com/Azure/azure-cli for this?
Here's what the relevant part of my CI pipeline looks like:
https://github.com/anthony-c-martin/bicep-on-k8s/blob/e6dfa61fe7eae6fd6b148670f940041f3e294b20/.github/workflows/ci.yml#L36-L50

The presence of WARNING: WARNING: The following experimental Bicep features have been enabled... at the start of the biceplint.sarif file breaks usage of the output.
What would the advice be on how to handle this? As I said at the top, I'm not sure whether this should be regarded as a bug or something that makes the case for a dedicated output to process mechanism. What do you reckon?

The problem here is the stderr redirect - as of version 0.24.24 of Bicep, you want to make sure you're not doing 2>&1 (which redirects stderr to stdout, and causes errors + sarif output to get mixed up). This also has the added benefit of making sure errors are logged properly to your console or CLI.
The fix I made was to solve exactly this problem - giving the caller a way to accurately read sarif output whilst being able to accurately differentiate it from errors.

Would you mind raising an issue in https://github.com/Azure/azure-cli for this?

Yup - I'm travelling right now, but I'll try and do this when I get to my destination. I'll link back to this and @ you

The lint issues are indeed being surfaced into the PR!

You're saying the code scanning messages on the PR come from the bicep task? And that if the Azure CLI didn't have a bug, I could expect similar behaviour?

You're saying the code scanning messages on the PR come from the bicep task? And that if the Azure CLI didn't have a bug, I could expect similar behaviour?

Yes, exactly. The github/codeql-action/upload-sarif@v3 action in the code link I shared above is responsible for converting the .sarif file into the user-visible messages on the PR.

That is cool!

I realised that in the other discussion we missed the potential other bug @anthony-c-martin.  I'm not sure whether this should be regarded as a bug or something that makes the case for a dedicated output to process mechanism.
Consider a bicepconfig.json like this:
{
  // See https://aka.ms/bicep/config for more information on Bicep configuration options
  // Press CTRL+SPACE/CMD+SPACE at any location to see Intellisense suggestions
  "analyzers": {
    "core": {
      "rules": {
        "no-unused-params": {
          "level": "warning"
        },
        "no-unused-vars": {
          "level": "warning"
        },
        "secure-secrets-in-params": {
          "level": "error"
        }
      }
    }
  },
  "experimentalFeaturesEnabled": {
    "sourceMapping": true
  }
}

Running az bicep lint --file infra/main.bicep --diagnostics-format sarif > $(System.DefaultWorkingDirectory)/biceplint.sarif 2>&1 will result in output like this:
WARNING: WARNING: The following experimental Bicep features have been enabled: Source mapping. Experimental features should be enabled for testing purposes only, as there are no guarantees about the quality or stability of these features. Do not enable these settings for any production usage, or your production environment may be subject to breaking.

{
  "$schema": "https://schemastore.azurewebsites.net/schemas/json/sarif-2.1.0-rtm.6.json",
  "version": "2.1.0",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "bicep"
        }
      },
      "results": [
        {
          "ruleId": "no-unused-vars",
          "message": {
            "text": "Variable \"unusedX\" is declared but never used. [https://aka.ms/bicep/linter/no-unused-vars]"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file:///home/vsts/work/1/s/infra/main.bicep"
                },
                "region": {
                  "startLine": 67,
                  "charOffset": 5
                }
              }
            }
          ]
        }
      ],
      "columnKind": "utf16CodeUnits"
    }
  ]
}

The presence of WARNING: WARNING: The following experimental Bicep features have been enabled... at the start of the biceplint.sarif file breaks usage of the output.
What would the advice be on how to handle this?  As I said at the top, I'm not sure whether this should be regarded as a bug or something that makes the case for a dedicated output to process mechanism.  What do you reckon?
  But generally there's probably a need to handle this in a way that affords consistent output?
I'm guessing this is unrelated to the az bicep bug already discussed?

The problem here is the stderr redirect - as of version 0.24.24 of Bicep, you want to make sure you're not doing 2>&1 (which redirects stderr to stdout, and causes errors + sarif output to get mixed up). This also has the added benefit of making sure errors are logged properly to your console or CLI.
The fix I made was to solve exactly this problem - giving the caller a way to accurately read sarif output whilst being able to accurately differentiate it from errors.

Take a look at this comment. This should work with Bicep CLI, and should be unrelated to the AzCLI bug.

Looks good!

hey @anthony-c-martin!
I'm back from travelling now and just catching up on this.  I think there's a few separate things happening in this discussion and I realise from reading it back it's a little confusing. Herefollows an attempt by me to disambiguate the different topics under discussion.
Bug in Azure CLI around surfacing output when exit code is non-0
From here: https://github.com/Azure/bicep/issues/11960#issuecomment-1902696228
You asked if I could raise an issue with the Azure CLI project.  I'm just trying to replicate this so I can raise a descriptive issue.
Exporting lint output to file
You've outlined that it's possible to output lints to a file using > bicep.sarif:
az bicep lint --file ./infra/main.bicep --diagnostics-format sarif > bicep.sarif

This works.  But there are gotchas. Consider the following from a GitHub Action:
      - name: Lint Bicep
        uses: azure/CLI@v1
        with:
          inlineScript: |
            az bicep lint --file ./infra/main.bicep --diagnostics-format sarif > bicep.sarif

Ideally this would run and output lints to bicep.sarif format.  However, if other output comes along for the ride, this will also be included. Consider this GitHub action: https://github.com/johnnyreilly/blog.johnnyreilly.com/actions/runs/7616182236/job/20742359365?pr=817
The contents of bicep.sarif in this case were:
Installing Bicep CLI v0.24.24...
Successfully installed Bicep CLI to "/root/.azure/bin/bicep".
{
  "$schema": "https://schemastore.azurewebsites.net/schemas/json/sarif-2.1.0-rtm.6.json",
  "version": "2.1.0",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "bicep"
        }
      },
      "results": [],
      "columnKind": "utf16CodeUnits"
    }
  ]
}

So because Bicep wasn't initially installed on the GitHub Actions server, the bicep lint output was prefixed by:
Installing Bicep CLI v0.24.24...
Successfully installed Bicep CLI to "/root/.azure/bin/bicep".

Which means that the subsequent upload task fails like this:

It's possible to work around this initial issue by say running az bicep install before you run az bicep lint, like so:
      - name: Lint Bicep
        uses: azure/CLI@v1
        with:
          inlineScript: |
            az bicep version
            az bicep lint --file ./infra/main.bicep --diagnostics-format sarif > bicep.sarif

But, whilst this works around the particular "bicep was not installed" issue that surfaced in this case, it doesn't solve the "there is other output coming from az bicep lint besides the lint output" issue in general.
Maybe that's okay; maybe it's fine to tackle each other issue that might present in the same way as it comes.  My own instinct is that the redirect to file output approach isn't as reliable as I'd like for this reason.  But maybe you feel it's good enough?  What do you think?

Maybe that's okay; maybe it's fine to tackle each other issue that might present in the same way as it comes. My own instinct is that the redirect to file output approach isn't as reliable as I'd like for this reason. But maybe you feel it's good enough? What do you think?

I think this is another AzCLI bug - Bicep is very strict about only writing the SARIF output to stdout for this exact reason. It looks like there's actually a PR open to fix this: https://github.com/Azure/azure-cli/pull/28188.

okay cool - fingers crossed it lands!


API: New callable indexing makes storing functions in a Series difficult

Example of something that previously worked (before 7bbd031104ee161b2fb79ba6f5732910661f94f8):
>>> s = pd.Series([lambda x: x] * 10)
>>> s[s.index > 5] = lambda x: x + 1

But now the second line tries to apply the function in the rhs to the elements of the Series, rather than assigning them (and throws an exception). This is very counter-intuitive when using __setitem__ rather than calling Series.where directly.

this is quite odd to store callables in a Series
what is the purpose of doing that?

hmm, this is simple to fix (we just don't evaluate a callable for other in .where).
@sinhrks do we have a valid use of other as a callable?

We're choosing a function based on some columns in a DataFrame, and then applying them on other column values / external data. Since there might be a different function for each row, it's convenient to store them in the same place.

@evanpw I think you might be able to just remove the _maybe_callable(other...) and this will work. Not really sure of the original purpose of testing for a callable on the other (e.g. it works, but IMHO not that useful).
If you want to give this a shot and see what it looks like would be great.

Yes, deleting this line from where in generic.py fixes the problem for me:
other = com._apply_if_callable(other, self)

The usage in my mind was chaining like:
pd.DataFrame({'A': [1, 2, 1, 2], 'B': [1, 2, 3, 4]}).groupby('A').sum().where(lambda x: x < 5, lambda x: -x)
#    B
# A
# 1  4
# 2 -6

I think it is more likely rather than storing callable.
CC: @TomAugspurger

I think that makes sense when calling where directly. What about making it configurable, and turned off when using __setitem__?

yes that is a bug I think.


inclusion of 'num_points' into stop filed metadata to indicate how many succesful points where completed.

Is it possible to include the number of successful points in the stop field in the metadata after a scan is finished. This is important for 'aborted' or 'stopped' scans where not all of the points indicated in the start field are completed.

Related: https://github.com/NSLS-II/databroker/issues/188


Use DynamoDB DocumentClient from AWS SDK for JavaScript (v3)

Fixes: https://github.com/maxday/lambda-perf/issues/112

Thanks for your contribution! 🥳


Footer not staying on bottom of div

This is a really long title for my page that should be 3 lines long

Category: FunnyComment | Share

So I loop through the above statement to get a 9x9 grid of cards. The cards are all the same size when viewing them which is perfect! However the Category line will be right below the title instead of at the bottom of every card. It will look like:
This is a really long title for
my page that should be 3
lines long
Category: Funny
line break
line break
line break
How do I fix it so it is after all the line breaks?

It's pretty hard to say without seeing your code, can you give a link?

vijeos.com/indextest.php

Why not using flexbox?


Possible Additions

These are some possible additions to this list; various things I have found but never tried. They look awesome, but I can't know for sure until I try them.
If you have used any of the tools on this list, please comment about your experience (good or bad) below. If you've had a good experience, I will probably add it to the list.

https://github.com/srph/npm-scripts-info
https://github.com/bahmutov/grunty
~~https://github.com/heldr/headr~~
~~https://github.com/substack/catw~~
~~https://github.com/stefanmaric/ntee~~

Added https://github.com/stefanmaric/ntee

https://github.com/srph/npm-scripts-info Looks interesting. Will try it out soon..

Added https://github.com/substack/catw

@tiaanduplessis Did you get a chance to try that?
Also, perhaps you want to try https://github.com/RyanZim/edit-script. Of course, I think it's good (because I wrote it), but would like someone else's thoughts on it.

@tiaanduplessis ping?

Added https://github.com/heldr/headr.


Feature/issue 937 array and custom update filter support

Closes https://github.com/gregnb/mui-datatables/issues/937.

Add support for array of values in custom filter list rendering, so as to support custom multiselect workflows
Add custom update for custom filter list rendering, as this is needed to support the feature
Create new API for custom filter list options and deprecate the old API

Coverage decreased (-0.6%) to 76.66% when pulling 77e80d3c01cea2463ca52d79eb10c456ae0d5c34 on feature/issue-937-array-and-cusotm-update-filter-support into 2d37c383beeebb039fae2b6e0b531ddb7959e2ce on master.

is there an example of the usage somewhere?

Yes, customize-filter was updated to use the new API.


:lady_beetle: plans details vms, use same icons in expanded view

Pland details vms expended pipline
icon should be the same as the progress icons in the none expended view
Screenshots:

addressed by https://github.com/kubev2v/forklift-console-plugin/pull/1163


Question: Why is TitleBar customisation not coming to Win32 WinUI 3 Windows?

Regarding the API Spec being proposed here Window_and_Application_API_Spec.md.
Could you provide some information as to why the ability to customise or replace the TitleBar and Window Controls is not being ported/enabled for Win32 created Windows?  I understand this is part of the CoreWindow which is reserved for UWP applications, but Win32 should typically be a superset of UWP features, but with more customisation.
I realise there is a way to access the Hwnd underlying for the window, but it could be beneficial to wrap up some of this ability in a simple to use API, accessible from XAML and code - which does not require such deep access to window drawing - in a way that enables the same scenarios that CoreWindow enables.
https://github.com/thomasclaudiushuber/microsoft-ui-xaml-specs/blob/patch-1/active/Win32/Window_and_Application_API_Spec.md#windowsettitlebaruielement-method
Visual examples:

with NavigationView Extended into TitleBar area

customised but not Extended into TitleBar area

without extending into TitleBar

There are other proposed APIs proposed that will be part of the future phases.

Titlebar customization might be part of the future APIs. If I recall correctly, the team stated that it is having in mind the UWP-style titlebar customization APIs for future WinUI support: https://github.com/microsoft/microsoft-ui-xaml/issues/1323#issuecomment-542785441
That might or might not mean support for WinUI desktop.

Then the questions are:
Will the TitleBar API come in the future?
Will it be there for WinUI 3.0 release?
If its not coming, why was that decision made?
Will there be code guidence to achieve the same effect of colourising the window controls, extending Acrylic into the titlebar area, and using custom Xaml elements as the grabbable title area - using HWND access.

@marb2000 @YuliKl as FYI

I wish they wouldn't bring the customizations over in order to keep the title bar consistent. It isn't consistent even in UWP apps.

I wish they wouldn't bring the customizations over in order to keep the title bar consistent. It isn't consistent even in UWP apps.

By default, the app window gives you the typical TitleBar you would see with Win32 mostly.  But many apps use the NavigationView, and that does not look good when it does not extend into the TitleBar.
UWP makes it easy to achieve this, but WInUI Desktop (as of the current spec) will not have a way to achieve this.

with NavigationView Extended into TitleBar area

customised but not Extended into TitleBar area

without extending into TitleBar

With all of those apps, the title bar behavior isn't consistent when you put them in Tablet Mode.

With all of those apps, the title bar behavior isn't consistent when you put them in Tablet Mode.

Tablet Mode "should" autohide the Window Controls/TitleBar - This is to have a full-screen experience.  I would expect the same behaviour for all WinUI apps, UWP or Win32.

It should but isn't consistent. See Microsoft Store, People app, Photos, and Feedback Hub.
In regards to Win32, I figure that has a lot to do with Sets returning. Programs such as Word were great offenders, obstacles in the way of that initiative.

It should but isn't consistent. See Microsoft Store, People app, Photos, and Feedback Hub.
In regards to Win32, I figure that has a lot to do with Sets returning. Programs such as Word were great offenders, obstacles in the way of that initiative.

Different apps will have different needs.  You will never get 100% rigid consistency with TitleBars, but there will be a disparity between UWP app capabilities and WinUI Desktop apps - unless there is sample code for achieving the same effects with HWND interfaces - or these capabilities are introduced.
WPF Windows have options for transparency and titlebar displays - so you should expect WinUI Desktop apps to be capable of matching both UWP behaviours, WPF behaviours, as well as traditional Win32 window behaviours.

I write an issue for that in #microsoft/ProjectReunion/49 Project Reunion may be the good place for this issue I think

The technical difficulty with this in WinUI3 is enabling a custom title bar that the user can still drag and double-click on. This is enabled in WinUI2 with Window.SetTitleBar, which registers with the shell the system (WinUI2) Visual behind the specified element. But with WinUI3 we need a new mechanism because we don't currently have a system Visual there.

Could WinUI / Reunion include a TitleBar xaml control, with built in behaviours and the ability to re-colour and theme/re-template?

@MikeHillberg  when will titlebar costimizing come to winui3 is very help full feature

#4835

We have a problem with using xBind converters in MainWindow.xaml - they are not working. #4966 pushes to use UI in another file. This make united title and UI impossible.

I'm curious what the state of this issue is. Today, in Win UI 3 it's possible to set a custom titlebar and extend the view into the titlebar area.
There are, however a lot of issues I've seen; I am unable to get any elements in the title bar to respond to click events in the same way they did with UWP, and if you set a background it paints over the min/max/close boxes.
From my (uninformed) perspective, the most obvious thing to do for the system when setting a custom titlebar would be to paint the system min/max/close boxes over the top of the element that is set as the titlebar. This would then allow things like a custom background to be set.
I really like the idea @mdtauk raised above about having a custom TitleBar xaml control. Another possibility would be to make a templated property (not sure if this is the right term) on the window.

I'm curious what the state of this issue is. Today, in Win UI 3 it's possible to set a custom titlebar and extend the view into the titlebar area.
There are, however a lot of issues I've seen; I am unable to get any elements in the title bar to respond to click events in the same way they did with UWP, and if you set a background it paints over the min/max/close boxes.
From my (uninformed) perspective, the most obvious thing to do for the system when setting a custom titlebar would be to paint the system min/max/close boxes over the top of the element that is set as the titlebar. This would then allow things like a custom background to be set.
I really like the idea @mdtauk raised above about having a custom TitleBar xaml control. Another possibility would be to make a templated property (not sure if this is the right term) on the window.

I'm experiencing a similar issue on my end while exploring WinUI 3 for the first time. I'm having to recreate the TitleBar entirely in order to achieve the same thing that you could use CoreApplication for on UWP for example. It also (seemingly) means I have to implement drag and drop again for titlebar if you extend it the entire width of the window?
Perhaps my ignorance here is causing my issues. There aren't many resources on WinUI 3 from developers at large so I can better understand certain practices. I'm not creating a UWP app, so this also causes issues.

@knightmeister not sure if this helps at all, but this doc explains how to properly set colors in custom title bar. Apologies if this isn't your issue.
Also in agreement that for custom title bars to have any purpose, we should be able to customize them. That means controls that can exist in that space, i.e. sliding NavigationView into that area, or the occasional button, searchbox, etc. I tend not to like to put anything in the bar, except the aforementioned NavView as @mdtauk points out.

Hi @tuggernuts, cheers yes I have seen that doc. Getting this all working is very nuanced and would be great if it could be slightly less so.

I just simply wanting to color the title bar so it fits my app themes

You can now customize the titlebar of a WinUI app by setting your own UI Element as a custom titlebar. The background of of the titlebar can be set by defining resource keys here https://docs.microsoft.com/en-us/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.window.settitlebar?view=windows-app-sdk-1.1#colors. You can also set WindowCaptionBackground as Transparent and just set background of your uielement which is set as titlebar.
Hopefully this helps. I am closing this issue. Feel free to open it if it doesn't work.


Support passing credentials option to appConfig.bootstrapOptions

Fixes OlegIlyenko/graphiql-workspace#38

thx

@OlegIlyenko Thank you! Would it be possible to release a new version on NPM? I tried to install from GitHub but it's leading to obscure issues when I try to include the module.

Published https://github.com/OlegIlyenko/graphiql-workspace/releases/tag/v1.1.5


Morder Hobo fixes and stuff

Changed Display of Murder Hobo (a Width(4000) HorizontalScope, few)
Fixed Swarms in Leapers Smile not being killed on engange (and possibly other units?)
Fixes #822

I am not sure what I think of the really wide buttons.  How about going back to the original size and wrapping the text in the Murder Hobo Toggle?


Replace dlp_verdict with tls_status

Probably a copy and paste error when copying from another hunting query.
Change(s):

Updated syntax for CiscoSEGInsecureProtocol.yaml

Reason for Change(s):

Fix for non-existing column 'dlp_verdict' referenced in line 19

Version Updated:

No, not required because it is a hunting query

Testing Completed:

Yes

Checked that the validations are passing and have addressed any issues that are present:

Yes

@aprakash13 : Please review the PR and provide your comments. Thanks!

Reviewed and commented. Thanks

@aprakash13 : Please review the PR and provide your signoff. Thanks!

@aprakash13 : Please review the PR and provide your signoff. Thanks!

@aprakash13 : Please review the PR and provide your signoff. Thanks!

@aprakash13 : Please review the PR and provide your signoff. Thanks!


#1806 clojure crashes on the following code

up to date with master
such exceptions will be shown in the cell output

:+1:


Transformation and solving of arithmetic expressions

In the case described in #160 we can resolve the length to true as it is unknown yet but only depends on itself. We can use the following facts:

(1) Payload'Last = Message'Last This is valid if Payload is the last field of the message.
(2) Payload'Last = Type_Length'Last + Payload'Length The last of a field is always the last of its predecessor added to the fields length.
(3) Payload'Length = Message'Last - Type_Length'Last This is the length property on the edge to Payload.

We can now transform this by plugging (1) into (2) and then (2) into (3) into

(4) Payload'Length = Type_Length'Last + Payload'Length - Type_Length'Last

This can be simplified to

(5) Payload'Length = Payload'Length

By evaluating the length of the payload to true we know that any length is valid.
Before implementing this behaviour we should add two tests. One should check that

(3).simplified({(1), (2)}) = (4)

and one should check that

(4).simplified() = TRUE

Fixed by #167.


All Trends Page Layout

Small changes to the layout can improve the home page a lot.
Currently, content cards are chosen based on the trends from the bar graph. Starting from the left most, grabbing a couple of tweets and articles, progressing down the chart to the right most trend.
Before the start of an array of content specific to a trend, add:

[x] div with style

display: flex;
text-align: center;
width: 100%;
float: left;

Wrap it around the h3 and a

[x] Trend as an h3 with the style

display: inline-block;
flex-grow: 1;
font-size: 14px;
font-weight: bold;
margin-top: 20px;
margin-bottom: 10px;

[x] a wrapped around an img arrow SVG pointing to the right

a has style
margin-top: 20px;
margin-bottom: 10px;

img has style
width: 16px;

[x] h3 and a onClick changes the page to that trend's page.
[ ] a href should link to the trend https://senti.social/{trend}, do not worry about this now. We shouldn't care about links and URL rewriting while the backend is deleting trend data.

Overall the heading should look something like this

Trend Name

This is a mockup.

Align the trend arrow button on the AllTrendsPage on non-mobile devices with the cards. It looks weird hanging near the edge.

Completed this task except for href which will be fixed once we use react-router.
Last task is merged with WebPack


Can't play videos in iOS's Safari browser

I now use the latest version of the plug -in, but I can’t make video playback on iOS’s Safari, only the sound

Does it work on 0.1.11+4 ?

I use [0.1.11+5] version

Can you try once with 0.1.11+4

I have tried this, but the same, only sound, no picture

Can you share the url you are trying to play if possible

https://websportplay.hngable.com/live/sd-1-3839195.m3u8

Are you here, I am very anxious, 🙏

Link has stopped working. Can you share a new one

okay，https://websportplay.hngable.com/live/sd-1-3836361/m3u8

After using this link I am getting CORS error

But there is no restriction on CORS in this side

And when running with your Example, it can be played normally in the simulator of the Chrome browser. Only the Safari browser cannot be played

Please help, thank you

Published 0.1.11+6. Try  running your app with this version

好的

Thank you, the problem has been solved。 👍

welcome. closing the issue


"ObjectMiddleware.register: serializer for mini-css-extract-plugin/dist/CssModule/null is already registered" after adding withVanillaExtract to next.config.js

Describe the bug
$ npm run dev

><EMAIL_ADDRESS>dev
> next dev

- ready started server on <IP_ADDRESS>:3000, url: http://localhost:3000
Error: ObjectMiddleware.register: serializer for mini-css-extract-plugin/dist/CssModule/null is already registered
    at Object.register (/Users/redacted/code/proj/apps/web/node_modules/next/dist/compiled/webpack/bundle5.js:28:1192877)
    at MiniCssExtractPlugin.getCssModule (/Users/redacted/code/proj/node_modules/next/dist/compiled/mini-css-extract-plugin/index.js:1:7516)
    at NextMiniCssExtractPlugin.apply (/Users/redacted/code/proj/node_modules/next/dist/compiled/mini-css-extract-plugin/index.js:1:10311)

next.config.js
const { createVanillaExtractPlugin } = require('@vanilla-extract/next-plugin');
const withVanillaExtract = createVanillaExtractPlugin();

/** @type {import('next').NextConfig} */
const nextConfig = {
  // reactStrictMode: false,
  reactStrictMode: true,
  swcMinify: true,
  eslint: {
    ignoreDuringBuilds: true,
  },
};

module.exports = withVanillaExtract(nextConfig);

Reproduction
See aboive
System Info
System:
    OS: macOS 13.4
    CPU: (8) arm64 Apple M1
    Memory: 779.94 MB / 16.00 GB
    Shell: 5.8 - /opt/homebrew/bin/zsh
  Binaries:
    Node: 20.5.0 - ~/Library/Caches/fnm_multishells/70155_1694527768381/bin/node
    Yarn: 1.22.19 - ~/Library/Caches/fnm_multishells/70155_1694527768381/bin/yarn
    npm: 9.8.0 - ~/Library/Caches/fnm_multishells/70155_1694527768381/bin/npm
    pnpm: 7.30.0 - ~/Library/pnpm/pnpm
  Browsers:
    Chrome: 116.0.5845.187
    Safari: 16.5

### Used Package Manager

npm

### Logs

```shell
See above

Validations

[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] The provided reproduction is a minimal reproducible example of the bug.

@olalonde I can't reproduce your issue in a simple next app using the config you provided. Please provide a full reproduction so we can attempt to diagnose the problem. Also, please ensure you're using the latest version of the next plugin.

I ran into this issue a while back, probably due to multiple versions of Next.js being installed, causing @vanilla-extract/next-plugin to duplicate adding the MiniCssExtractPlugin to webpack.
You can check if multiple versions of Next.js exist with the following command:
npm list --all | grep next@

The issues went away when i moved the project out of a npm workspace and into a standalone project.

Seems like maybe the instanceof check in the next plugin isn't effective.

i ran into the same error using Turborepo, this issue went away when i upgraded Next.js version all at the same time
before(this issue appeared)

web: ^14.0.1
docs: ^13.4.19
ui: ^13.4.19

after(this issue went away)

web: ^14.0.1
docs: ^14.0.1
ui: ^14.0.1

Seems like this was probably a project configuration issue. @olalonde Since you've fixed the problem, I'm going to close the issue. Please re-open if it's still a problem.


Weight normalization

Is there an equivalent to flax.optim.WeightNorm? As flax.optim is effectively deprecated in favor of optax, I would like to see it implemented in optax.

Wonder whether there has been any progress on this? Weight normalization would be a great feature to have.

any updates on this?


Store wakers in Vec instead of busy waiting

Description of changes
Store waiters in Vec instead of busy waiting
Checklist

[x] Created unit tests in tests/unit and/or in Rust for my feature if needed
[x] Ran make fix to format JS and apply Clippy auto fixes
[x] Made sure my code didn't add any additional warnings: make check
[x] Added relevant type info in types/ directory
[x] Updated documentation if needed (API.md/README.md/Other)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

For reference we should look at the watch.
Couple of improvements they made:

They have a shared struct with one arc, bit faster to create senders/receivers
It is built on top of the Notify primitive (https://docs.rs/tokio/latest/tokio/sync/struct.Notify.html)
They use an array of 8 Notify to avoid contention (BigNotify)

See https://docs.rs/tokio/latest/src/tokio/sync/watch.rs.html#1-1477

For reference we should look at the watch. Couple of improvements they made:

They have a shared struct with one arc, bit faster to create senders/receivers

Ah ofc. Didn't think of that!

It is built on top of the Notify primitive (https://docs.rs/tokio/latest/tokio/sync/struct.Notify.html)
They use an array of 8 Notify to avoid contention (BigNotify)

That could work but is an internal class, so can't use it

For a write heavy load like waker registration a mutex is more performant than a RwLock

Sure, but this isn't very write heavy, right?. The executor won't poll this future again until the waker is called so registration only happens once per copy of mc_oneshot no?

For reference we should look at the watch.
Couple of improvements they made:

They have a shared struct with one arc, bit faster to create senders/receivers
It is built on top of the Notify primitive (https://docs.rs/tokio/latest/tokio/sync/struct.Notify.html)
They use an array of 8 Notify to avoid contention (BigNotify)

See https://docs.rs/tokio/latest/src/tokio/sync/watch.rs.html#1-1477

We can use Notify though if we want.
Mutex is better for mixed workload.


Add support for Openstack Designate as a DNS provider

This PR adds support for Openstack designate as a DNS provider.

Hello, in order for a PR adding a DNS provider to be accepted, you have to:

[ ] add a description to your PR
[x] be able to maintain this provider
[x] have a homogeneous design with the other providers
[x] add tests ("live" and units)

make test

[x] add documentation
[ ] add CLI DNS help: https://github.com/xenolf/lego/blob/c938de68f262c057542d44bcb67ef961cefcc60e/cmd/cmd_dnshelp.go#L19
[ ] be able to do: (and put the output of this command to a comment in your PR)

rm -rf ./lego

./lego -m<EMAIL_ADDRESS>--dns YOUR_PROVIDER_NAME -s https://acme-staging-v02.api.letsencrypt.org/directory -d *.example.com -d example.com run

[x] pass the linter (golangci-lint must be installed):

make checks

Please enter your OpenStack Password:
wifournier@worker001:~$ ./lego --server=https://acme-staging-v02.api.letsencrypt.org/directory<EMAIL_ADDRESS>--domains="test-lego.dev-wifournier.xxxx" --dns designate  --dns.disable-cp run
2019/02/06 13:57:11 [INFO] [test-lego.dev-wifournier.xxxx] acme: Obtaining bundled SAN certificate
2019/02/06 13:57:12 [INFO] [test-lego.dev-wifournier.xxxx] AuthURL: https://acme-staging-v02.api.letsencrypt.org/acme/authz/xxxxxxxxxxxxxxxxxxx
2019/02/06 13:57:12 [INFO] [test-lego.dev-wifournier.xxxx] acme: Could not find solver for: tls-alpn-01
2019/02/06 13:57:12 [INFO] [test-lego.dev-wifournier.xxxx] acme: Could not find solver for: http-01
2019/02/06 13:57:12 [INFO] [test-lego.dev-wifournier.xxxx] acme: use dns-01 solver
2019/02/06 13:57:12 [INFO] [test-lego.dev-wifournier.xxxx] acme: Preparing to solve DNS-01
2019/02/06 13:57:13 [INFO] [test-lego.dev-wifournier.xxxx] acme: Trying to solve DNS-01
2019/02/06 13:57:13 [INFO] [test-lego.dev-wifournier.xxxx] acme: Checking DNS record propagation using [xxxx.xxx.:53]
2019/02/06 13:57:13 [INFO] Wait for propagation [timeout: 10m0s, interval: 10s]
2019/02/06 13:57:19 [INFO] [test-lego.dev-wifournier.xxxx] The server validated our request
2019/02/06 13:57:19 [INFO] [test-lego.dev-wifournier.xxxx] acme: Cleaning DNS-01 challenge
2019/02/06 13:57:19 [INFO] [test-lego.dev-wifournier.xxxx] acme: Validations succeeded; requesting certificates
2019/02/06 13:57:21 [INFO] [test-lego.dev-wifournier.xxxx] Server responded with a certificate.

The purpose of the command is to validate the generation of wildcard certificates.
So could you re-do the command:
$ rm -rf .lego

$ ./lego -m<EMAIL_ADDRESS>--dns designate -s https://acme-staging-v02.api.letsencrypt.org/directory -d *.dev-wifournier.xxxx -d dev-wifournier.xxxx run

Also the CLI DNS help is not complete.

2019/02/06 14:11:17 [INFO] [*.test-lego.dev-wifournier.xxxx, test-lego.dev-wifournier.xxxx] acme: Obtaining bundled SAN certificate
2019/02/06 14:11:18 [INFO] [*.test-lego.dev-wifournier.xxxx] AuthURL: https://acme-staging-v02.api.letsencrypt.org/acme/authz/xxxxxxxxxxxxxxxxx
2019/02/06 14:11:18 [INFO] [test-lego.dev-wifournier.xxxx] AuthURL: https://acme-staging-v02.api.letsencrypt.org/acme/authz/xxxxxxxxxxxxxxxxx
2019/02/06 14:11:18 [INFO] [*.test-lego.dev-wifournier.xxxx] acme: authorization already valid; skipping challenge
2019/02/06 14:11:18 [INFO] [test-lego.dev-wifournier.xxxx] acme: Could not find solver for: tls-alpn-01
2019/02/06 14:11:18 [INFO] [test-lego.dev-wifournier.xxxx] acme: Could not find solver for: http-01
2019/02/06 14:11:18 [INFO] [test-lego.dev-wifournier.xxxx] acme: use dns-01 solver
2019/02/06 14:11:18 [INFO] [test-lego.dev-wifournier.xxxx] acme: Preparing to solve DNS-01
2019/02/06 14:11:19 [INFO] [test-lego.dev-wifournier.xxxx] acme: Trying to solve DNS-01
2019/02/06 14:11:19 [INFO] [test-lego.dev-wifournier.xxxx] acme: Checking DNS record propagation using [<IP_ADDRESS>:53]
2019/02/06 14:11:19 [INFO] Wait for propagation [timeout: 10m0s, interval: 10s]
2019/02/06 14:11:24 [INFO] [test-lego.dev-wifournier.xxxx] The server validated our request
2019/02/06 14:11:24 [INFO] [test-lego.dev-wifournier.xxxx] acme: Cleaning DNS-01 challenge
2019/02/06 14:11:25 [INFO] [*.test-lego.dev-wifournier.xxxx, test-lego.dev-wifournier.xxxx] acme: Validations succeeded; requesting certificates
2019/02/06 14:11:28 [INFO] [*.test-lego.dev-wifournier.xxxx] Server responded with a certificate.

2019/02/06 14:11:18 [INFO] [*.test-lego.dev-wifournier.xxxx] acme: authorization already valid; skipping challenge

Could you do a rm -rf .lego before the run of the command?

2019/02/06 15:08:04 No key found for account wifournier@xxxx. Generating a curve P384 EC key.
2019/02/06 15:08:04 Saved key to /media/home/wifournier/.lego/accounts/acme-staging-v02.api.letsencrypt.org/wifournier<EMAIL_ADDRESS>2019/02/06 15:08:04 [INFO] acme: Registering account for wifournier@xxxx
!!!! HEADS UP !!!!

                Your account credentials have been saved in your Let's Encrypt
                configuration directory at "/media/home/wifournier/.lego/accounts".
                You should make a secure backup of this folder now. This
                configuration directory will also contain certificates and
                private keys obtained from Let's Encrypt so making regular
                backups of this folder is ideal.2019/02/06 15:08:05 [INFO] [*.test-lego.dev-wifournier.xxxx, test-lego.dev-wifournier.xxxx] acme: Obtaining bundled SAN certificate
2019/02/06 15:08:06 [INFO] [*.test-lego.dev-wifournier.xxxx] AuthURL: https://acme-staging-v02.api.letsencrypt.org/acme/authz/xxxxxxxxxxxxxxxxxxx
2019/02/06 15:08:06 [INFO] [test-lego.dev-wifournier.xxxx] AuthURL: https://acme-staging-v02.api.letsencrypt.org/acme/authz/xxxxxxxxxxxxxxxxxxx
2019/02/06 15:08:06 [INFO] [*.test-lego.dev-wifournier.xxxx] acme: use dns-01 solver
2019/02/06 15:08:06 [INFO] [test-lego.dev-wifournier.xxxx] acme: Could not find solver for: tls-alpn-01
2019/02/06 15:08:06 [INFO] [test-lego.dev-wifournier.xxxx] acme: Could not find solver for: http-01
2019/02/06 15:08:06 [INFO] [test-lego.dev-wifournier.xxxx] acme: use dns-01 solver
2019/02/06 15:08:06 [INFO] [*.test-lego.dev-wifournier.xxxx] acme: Preparing to solve DNS-01
2019/02/06 15:08:06 [INFO] [*.test-lego.dev-wifournier.xxxx] acme: Trying to solve DNS-01
2019/02/06 15:08:06 [INFO] [*.test-lego.dev-wifournier.xxxx] acme: Checking DNS record propagation using [<IP_ADDRESS>:53]
2019/02/06 15:08:06 [INFO] Wait for propagation [timeout: 10m0s, interval: 10s]
2019/02/06 15:08:12 [INFO] [*.test-lego.dev-wifournier.xxxx] The server validated our request
2019/02/06 15:08:12 [INFO] [*.test-lego.dev-wifournier.xxxx] acme: Cleaning DNS-01 challenge
2019/02/06 15:08:13 [INFO] sequence: wait for 1m0s
2019/02/06 15:09:13 [INFO] [test-lego.dev-wifournier.xxxx] acme: Preparing to solve DNS-01
2019/02/06 15:09:14 [INFO] [test-lego.dev-wifournier.xxxx] acme: Trying to solve DNS-01
2019/02/06 15:09:14 [INFO] [test-lego.dev-wifournier.xxxx] acme: Checking DNS record propagation using [<IP_ADDRESS>:53]
2019/02/06 15:09:14 [INFO] Wait for propagation [timeout: 10m0s, interval: 10s]
2019/02/06 15:09:19 [INFO] [test-lego.dev-wifournier.xxxx] The server validated our request
2019/02/06 15:09:19 [INFO] [test-lego.dev-wifournier.xxxx] acme: Cleaning DNS-01 challenge
2019/02/06 15:09:20 [INFO] [*.test-lego.dev-wifournier.xxxx, test-lego.dev-wifournier.xxxx] acme: Validations succeeded; requesting certificates
2019/02/06 15:09:21 [INFO] [*.test-lego.dev-wifournier.xxxx] Server responded with a certificate.


hook.service causes panic on shutdown

if hook.service is build into caddy using current master if caddy is run from command line in windows and then stopped by ctrl-c the following panic happens
panic: close of closed channel

goroutine 81 [running]:
github.com/mholt/caddy/vendor/github.com/mholt/certmagic.(*Cache).Stop(...)
        D:/godev/src/github.com/mholt/caddy/vendor/github.com/mholt/certmagic/cache.go:87
github.com/mholt/caddy/caddytls.NewConfig.func1(0x10694f0, 0xc0420cc340)
        D:/godev/src/github.com/mholt/caddy/caddytls/config.go:105 +0x35
github.com/mholt/caddy.(*Instance).ShutdownCallbacks(0xc04223c000, 0xc0420cc340, 0xc0420cc340, 0x0)
        D:/godev/src/github.com/mholt/caddy/caddy.go:169 +0xba
github.com/mholt/caddy.allShutdownCallbacks(0xbf02d0, 0x8, 0xad3bc0)
        D:/godev/src/github.com/mholt/caddy/sigtrap.go:100 +0x114
github.com/mholt/caddy.executeShutdownCallbacks.func1()
        D:/godev/src/github.com/mholt/caddy/sigtrap.go:80 +0x96
sync.(*Once).Do(0x1097820, 0xc042007f88)
        C:/Go/src/sync/once.go:44 +0xc5
github.com/mholt/caddy.executeShutdownCallbacks(0xbed72f, 0x6, 0x0)
        D:/godev/src/github.com/mholt/caddy/sigtrap.go:76 +0x7a
github.com/mholt/caddy.trapSignalsCrossPlatform.func1.1()
        D:/godev/src/github.com/mholt/caddy/sigtrap.go:66 +0x3d
created by github.com/mholt/caddy.trapSignalsCrossPlatform.func1
        D:/godev/src/github.com/mholt/caddy/sigtrap.go:65 +0xe3

In discussion @mholt thought perhaps

It looks like they're calling ShutdownCallbacks too, but the Ctrl+c handler does this already

Hmm... we do call ShutdownCallbacks when stopping the service. We call that and instance.Stop. Shouldn't we?
/cc @mholt

No, I don't believe so. The caddy package does that already.

@mholt hmmm... it does that when signals are emitted. What about services shutting down? I'm not sure how they work and if there's a signal being emitted. I can try removing them and see what happens tho.

Yeah... sorry, it is a little confusing in this case because of the whole service paradigm.
 (I'm not sure what Windows does.)

Due to the recent developments of Caddy (v2!) and the incompatibility of this plugin with newer versions, as well as not being maintained, I'm closing this issue and archiving the repository.


balance_claim operation is missing from Operation.jsx

Why do you need balance claim in Operation.jsx?

I'm sorry, I thought this was a builder... Yes, great to have this added to an Operation Summary object..