Cargo fails to rebuild some crates on rustc update

I've seen this twice now in the stdarch repo:

Build stdarch with one version of rustc
Wait a few days or weeks
rustup update && cargo check
Now the build fails
cargo clean && cargo check
Now the build succeeds

Seems like somehow it is using an outdated build cache?
The build errors end in
error[E0412]: cannot find type `c_uint` in module `c`
   --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/ioctl/mod.rs:308:22
    |
308 | type _RawOpcode = c::c_uint;
    |                      ^^^^^^ not found in `c`
    |
help: consider importing one of these items
    |
17  + use core::ffi::c_uint;
    |
17  + use std::ffi::c_uint;
    |
17  + use std::os::raw::c_uint;
    |
help: if you import `c_uint`, refer to it directly
    |
308 - type _RawOpcode = c::c_uint;
308 + type _RawOpcode = c_uint;
    |

error[E0412]: cannot find type `InputModes` in this scope
  --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/termios/types.rs:14:22
   |
14 |     pub input_modes: InputModes,
   |                      ^^^^^^^^^^ not found in this scope

error[E0412]: cannot find type `OutputModes` in this scope
  --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/termios/types.rs:18:23
   |
18 |     pub output_modes: OutputModes,
   |                       ^^^^^^^^^^^ not found in this scope

error[E0412]: cannot find type `ControlModes` in this scope
  --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/termios/types.rs:22:24
   |
22 |     pub control_modes: ControlModes,
   |                        ^^^^^^^^^^^^ not found in this scope

error[E0412]: cannot find type `LocalModes` in this scope
  --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/termios/types.rs:26:22
   |
26 |     pub local_modes: LocalModes,
   |                      ^^^^^^^^^^ not found in this scope

error[E0271]: type mismatch resolving `<Opaque as Pointee>::Metadata == ()`
   --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/backend/linux_raw/conv.rs:90:13
    |
90  |     raw_arg(null_mut())
    |             ^^^^^^^^^^ expected `()`, found associated type
    |
    = note:    expected unit type `()`
            found associated type `<Opaque as Pointee>::Metadata`
    = help: consider constraining the associated type `<Opaque as Pointee>::Metadata` to `()`
    = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html
    = note: required for `Opaque` to implement `Thin`
note: required by a bound in `null_mut`
   --> /home/r/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:571:35
    |
571 | pub const fn null_mut<T: ?Sized + Thin>() -> *mut T {
    |                                   ^^^^ required by this bound in `null_mut`

error[E0271]: type mismatch resolving `<Opaque as Pointee>::Metadata == ()`
   --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/backend/linux_raw/conv.rs:139:21
    |
139 |             None => null_mut(),
    |                     ^^^^^^^^^^ expected `()`, found associated type
    |
    = note:    expected unit type `()`
            found associated type `<Opaque as Pointee>::Metadata`
    = help: consider constraining the associated type `<Opaque as Pointee>::Metadata` to `()`
    = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html
    = note: required for `Opaque` to implement `Thin`
note: required by a bound in `null_mut`
   --> /home/r/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:571:35
    |
571 | pub const fn null_mut<T: ?Sized + Thin>() -> *mut T {
    |                                   ^^^^ required by this bound in `null_mut`

error[E0271]: type mismatch resolving `<Opaque as Pointee>::Metadata == ()`
   --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/backend/linux_raw/conv.rs:232:25
    |
232 |         None => raw_arg(null_mut()),
    |                         ^^^^^^^^^^ expected `()`, found associated type
    |
    = note:    expected unit type `()`
            found associated type `<Opaque as Pointee>::Metadata`
    = help: consider constraining the associated type `<Opaque as Pointee>::Metadata` to `()`
    = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html
    = note: required for `Opaque` to implement `Thin`
note: required by a bound in `null_mut`
   --> /home/r/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:571:35
    |
571 | pub const fn null_mut<T: ?Sized + Thin>() -> *mut T {
    |                                   ^^^^ required by this bound in `null_mut`

error[E0699]: cannot call a method on a raw pointer with an unknown pointee type
   --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/backend/linux_raw/arch/mod.rs:98:17
    |
98  |             $a2.into(),
    |                 ^^^^
    |
   ::: /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/backend/linux_raw/io/syscalls.rs:251:15
    |
251 |     ret_c_int(syscall!(__NR_ioctl, fd, c_uint(request), arg))
    |               ---------------------------------------------- in this macro invocation
    |
    = note: this error originates in the macro `syscall` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0699]: cannot call a method on a raw pointer with an unknown pointee type
   --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/backend/linux_raw/arch/mod.rs:257:17
    |
257 |             $a2.into(),
    |                 ^^^^
    |
   ::: /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/backend/linux_raw/io/syscalls.rs:260:15
    |
260 |     ret_c_int(syscall_readonly!(__NR_ioctl, fd, c_uint(request), arg))
    |               ------------------------------------------------------- in this macro invocation
    |
    = note: this error originates in the macro `syscall_readonly` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0699]: cannot call a method on a raw pointer with an unknown pointee type
  --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/ioctl/patterns.rs:99:16
   |
99 |         Ok(ptr.cast::<Output>().read())
   |                ^^^^

error: could not evaluate constant pattern
  --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/io/errno.rs:68:17
   |
68 |             Err(Errno::INTR) => (),
   |                 ^^^^^^^^^^^

But it turns out those errors are nonsense, scrolling further up reveals
error[E0514]: found crate `linux_raw_sys` compiled by an incompatible version of rustc
   --> /home/r/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.21/src/backend/linux_raw/c.rs:239:34
    |
239 | pub(crate) const SIGSYS: c_int = linux_raw_sys::general::SIGSYS as _;
    |                                  ^^^^^^^^^^^^^
    |
    = note: the following crate versions were found:
            crate `linux_raw_sys` compiled by rustc 1.78.0-nightly (a84bb95a1 2024-02-13): /home/r/src/rust/stdarch/target/debug/deps/liblinux_raw_sys-7b950b5e918f9d9b.rmeta
    = help: please recompile that crate using this compiler (rustc 1.78.0-nightly (397937d81 2024-02-22)) (consider running `cargo clean` first)

However clearly cargo should be realizing that the rustc version changed, and rebuild the dependencies, right?
$ rustc --version
rustc 1.78.0-nightly (397937d81 2024-02-22)
$ cargo --version
cargo 1.78.0-nightly (194a60b29 2024-02-21)

Hm, without a reproduction it'll be pretty hard to figure out what happened.
I'm a bit confused why it is building or having errors for rustix and liblinux_raw_sys. Those are not dependencies in the stdarch repository that I can see. Is that maybe an older checkout? Where are those coming from?

It's latest stdarch. I had the same in a different project, https://github.com/RalfJung/rustc-build-sysroot/, so it's not stdarch-specific.
"rustix" and "linux-raw-sys" by appear in my lockfile for stdarch, so they are dependencies of some crate in that workspace:
$ cargo tree -i linux-raw-sys
linux-raw-sys v0.4.10
└── rustix v0.38.21
    └── is-terminal v0.4.9
        └── env_logger v0.10.0
            └── pretty_env_logger v0.5.0
                └── intrinsic-test v0.1.0 (/home/r/src/rust/stdarch/crates/intrinsic-test)

This is the rustup update after which I got the errors
$ rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: latest update on 2024-02-23, rust version 1.78.0-nightly (397937d81 2024-02-22)
info: downloading component 'rust-std' for 'wasm32-unknown-unknown'
info: downloading component 'miri'
info: downloading component 'rust-src'
info: downloading component 'clippy'
info: downloading component 'rustfmt'
info: downloading component 'rustc'
 63.3 MiB /  63.3 MiB (100 %)  28.9 MiB/s in  2s ETA:  0s
info: downloading component 'rust-std'
 26.4 MiB /  26.4 MiB (100 %)  26.1 MiB/s in  1s ETA:  0s
info: downloading component 'cargo'
info: removing previous version of component 'rust-std' for 'wasm32-unknown-unknown'
info: removing previous version of component 'miri'
info: removing previous version of component 'rust-src'
info: removing previous version of component 'clippy'
info: removing previous version of component 'rustfmt'
info: removing previous version of component 'rustc'
info: removing previous version of component 'rust-std'
info: removing previous version of component 'cargo'
info: installing component 'rust-std' for 'wasm32-unknown-unknown'
info: installing component 'miri'
info: installing component 'rust-src'
info: installing component 'clippy'
info: installing component 'rustfmt'
info: installing component 'rustc'
 63.3 MiB /  63.3 MiB (100 %)  22.8 MiB/s in  2s ETA:  0s
info: installing component 'rust-std'
 26.4 MiB /  26.4 MiB (100 %)  21.1 MiB/s in  1s ETA:  0s
info: installing component 'cargo'
info: checking for self-update

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.76.0 (07dca489a 2024-02-04)
   nightly-x86_64-unknown-linux-gnu updated - rustc 1.78.0-nightly (397937d81 2024-02-22) (from rustc 1.78.0-nightly (a84bb95a1 2024-02-13))

info: cleaning up downloads & tmp directories

Sadly it does not seem to show the previously installed versions...

Okay it seems like RA is somehow involved.
Steps to reproduce, in a checkout of https://github.com/RalfJung/rustc-build-sysroot/:

rustup override set nightly
run cargo +nightly-2024-01-15 check
now open this project in vscode with rust-analyzer; it will try to do a check-build which fails
now on the terminal run cargo +nightly check, shows the same errors as vscode

Skipping the vscode step makes the error go away.
Cc @Veykril

Setting "rust-analyzer.cargo.buildScripts.useRustcWrapper": false makes the error go away. So definitely seems like an RA bug.

This is somewhat known to us, but not something we can consider a r-a bug since it's cargo not rebuilding things when it should imo. The wrapper is basically just passing build invocations through for build script and proc-macro crates, any other crate is unconditionally succeeded and skipped. We need to do that since cargo still has no option to just build build scripts and proc-macros without building everything else. https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/bin/rustc_wrapper.rs

I'd say the wrapper is clearly violating cargo's expectations of what a "wrapper" does (it's supposed to behave like rustc, which in particular means not doing nothing), so it's hard to argue that this is not an RA bug.

Is there even any reasonable way that cargo could detect what happens here? I don't know what exactly is causing the fingerprints to go stale here. Clearly it has to do with rustc unexpectedly doing nothing, but then where does that violate assumptions cargo is making?

Closing in favor of https://github.com/rust-lang/rust-analyzer/issues/14722 and https://github.com/rust-lang/rfcs/pull/3344.


Configuring alerts with more conditions on Threshold - shown in the video

In the example shown I see sales target and regions, now can I create a alert on target for North America region? Is that functionality supported or any other way that it can be accomplished?
Data alerts in the Power BI service
Reference Youtube

Hi @ashumedi . Thanks for reaching out to us with your question. You've reached the documentation team, I am not %100 sure of the answer but I think you can only put set alerts on three types of tiles, gauges, KPIs, and cards, as mentioned in the documentation page and the video. I would imagine that you'd have to make a special report and then put in a tile on that that you'd set the alert on. Still, I suggest that you try further on the Power BI Community or support page - there may be someone with specific experience with your case. Thanks and good luck!
@maggiesMSFT


Spack v0.18.1

This PR introduces the new c2sm-spack infrastructure (v0.18.1) that is recommended to all users. Additionally, int2lm, cosmo and icon are compiled via spack dev-builds since this is similar to what users usually do (and thus should be tested). With that, no more hacky spack location commands within the config files are used to access the executables.

launch jenkins

launch jenkins

launch jenkins

launch jenkins

launch jenkins

launch jenkins

launch jenkins

launch jenkins

launch jenkins

@efmkoene This is now ready for review as all tests are green ✅


Update ClusterLogging CR collection spec

Update the 'ClusterLogging' CR collection spec
according to the updated spec as documented here:
https://docs.openshift.com/container-platform/4.16/observability/logging/log_collection_forwarding/cluster-logging-collector.html#configuring-logging-collector_cluster-logging-collector

/retest-required


Depth First Search of graph in Java

🚀 Feature
(A clear and concise description of what the feature is.)
Have you read the Contributing Guidelines on Pull Requests?
I want to add depth-first search of graph in java.

/assign


Consolidate duplicate postgresql keys in the values.yml file

The postgresql key appears twice in the galaxy section of the values.yml file.  However, the YAML specification requires that keys be unique. So either:

The second postgresql section is overwriting the first, or
We are relying on non-standard behaviour that may change in the future.

This PR consolidates the two sections into a single entry to remedy the above two situations.

This got fixed elsewhere since the PR was opened.


Emit event on rolling-update

@rohansingh

how do you tell this DeploymentGroupEvent (DGE) apart from other DGEs?
I.e. how do I tell this DGE apart from a DGE emitted when a rollout is started due to more hosts being added to the deployment group?


NSI-3133 ECO backscattering

Description
Adds ECO beta for backscattering
Closes: NSI-3133
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?
Select the type of tests you added for these changes

[ ] Unit
[ ] Integration
[ ] Component
[ ] E2E
[x] User

Did you test these changes on all platforms (if applicable to the JIRA item?)

[x] Windows
[ ] MacOS

Checklist:

[x] My code follows the style guidelines of this project
[x] I have cleared any run data/output from the ipynb file(s)
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] My code is up to date with the branch I'm requesting to merge into

I'm going to hold off on this PR since there is going to be a rework of how we're handling ECO

Won't merge in, will create a generic ECO function in the future.


Add radiation diffusion plotting script

PR Summary
Add script for making comparison plot of moment solution to analytic solution of boosted radiation diffusion problem
PR Checklist

[x] Explain what you did.

Sounds like you should merge when ready @lroberts36


update() timeout BUT find() ok

simple query
db.inventory.updateOne( {rating:{$exists:true}},{$unset:{rating:''}});
causes this error but any find() query works. MongoDB Shell through Command Prompt or Power Shell work without issue
I see several other very similar issues have been logged - I am in New Zealand and the cluster is listed as in N.Virginia - is this more a distance thing?

Action: cosmosDB.executeMongoCommand
Error type: string
Error Message: Timed out executing MongoDB command "use test"
Version: 0.10.1
OS: win32
VS Code Version: 1.33.1

Hi @futurenz ,
The error implies it was unable to set up the shell to run the command. Can you try a command like db.inventory.findOneAndUpdate(<fields>) and let us know if the issue exists?
Also, please let us know if these commands run properly : findOne, count, insertOne
Again, thanks for using our extension.
--Prashanth

Hi Prashanth,
findOneAndUpdate fails
findOne is good
count is good
insertOne is good
Thanks for the prompt response.
regards
------ Original Message ------
From: "Prashanth"<EMAIL_ADDRESS>To: "Microsoft/vscode-cosmosdb"<EMAIL_ADDRESS>Cc: "Chris Barraclough"<EMAIL_ADDRESS>"Mention"
<EMAIL_ADDRESS>Sent: 23/04/2019 11:47:59 AM
Subject: Re: [Microsoft/vscode-cosmosdb] update() timeout BUT find() ok
(#1092)

Hi @futurenz https://github.com/futurenz ,
The error implies it was unable to set up the shell to run the command.
Can you try a command like db.inventory.findOneAndUpdate() and
let us know if the issue exists?
Also, please let us know if these commands run properly : findOne,
count, insertOne
Again, thanks for using our extension.
--Prashanth
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode-cosmosdb/issues/1092#issuecomment-485591005,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK3AEGPDUIW2L2P76PE5FIDPRZFC7ANCNFSM4HHNF35A.

@futurenz I've made a fix that kept us from showing the real error in certain cases when the Mongo shell was used for a query (which would be the case for findOneAndUpdate).  Hopefully you will now get the correct error message (after next release) and be able to figure out the problem.  Please let us know if it doesn't.  Thanks!

Fixed by #1162


Refactor bq/simplify operators rename hooks

Make sure you have checked all steps below.
Jira

[ ] My PR addresses the following Airflow Jira issues and references them in the PR title. For example, "[AIRFLOW-XXX] My Airflow PR"

https://issues.apache.org/jira/browse/AIRFLOW-XXX
In case you are fixing a typo in the documentation you can prepend your commit with [AIRFLOW-XXX], code changes always need a Jira issue.
In case you are proposing a fundamental code change, you need to create an Airflow Improvement Proposal (AIP).
In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

Description

[ ] Here are some details about my PR, including screenshots of any UI changes:

Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[ ] My commits all reference Jira issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters (not including Jira issue reference)
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[ ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain docstrings that explain what it does
If you implement backwards incompatible changes, please leave a note in the Updating.md so we can assign it to a appropriate release

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@1ef56df). Click here to learn what that means.
The diff coverage is 43.47%.

@@            Coverage Diff            @@
##             master     #500   +/-   ##
=========================================
  Coverage          ?   83.84%
=========================================
  Files             ?      668
  Lines             ?    37543
  Branches          ?        0
=========================================
  Hits              ?    31478
  Misses            ?     6065
  Partials          ?        0

Impacted Files
Coverage Δ

airflow/config_templates/airflow_local_settings.py
61.7% <43.47%> (ø)

Continue to review full report at Codecov.

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

Can you also improve TestBigQueryHookSourceFormat,  TestBigQueryExternalTableSourceFormat? They should use assertRaisesRegex
Many test methods  stil use hook.BigQueryBaseCursor.init


C++ Pair up Header and Implementation files

Type: Feature Request
On the Tab bar of currently open files, with C & C++ & other languages where there are Header Files (e.g. .h / .hpp) and Implementation files (e.g. .c / .cpp), it would be nice to pair up the files as a conjoined tab, the .H could be much smaller as it would not need the file name, just the extension.
VS Code version: Code 1.83.0 (e7e037083ff4455cf320e344325dacb480062c3c, 2023-10-03T16:12:16.321Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Remote OS version: Linux x64 <IP_ADDRESS>-microsoft-standard-WSL2

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Changes after release

Update to development version number
Update of install instructions

Pull Request Test Coverage Report for Build 389

0 of 0   changed or added relevant lines in 0 files are covered.
10 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.1%) to 55.511%

Files with Coverage Reduction
New Missed Lines
%

goodman_pipeline/core/tests/test_check_version.py
2
80.95%

goodman_pipeline/core/core.py
4
66.03%

goodman_pipeline/core/check_version.py
4
75.0%

Totals

Change from base Build 388:
-0.1%

Covered Lines:
2196

Relevant Lines:
3610

💛  - Coveralls


fix text in hamburger menu for mobile devices

this PR fix style text in hamburger menu for different devices.
Before:

After:

@Simek i test for different iphone sizes and android and looks better!:

cc: @Simek

@Simek could you take a look for this PR?

Hi @luism3861, thank you for working on this!
I think that adding a viewport breakpoint and changing navbar-sidebar size on very small screens is bit more universal solution that adding bunch of overwrites for navbar-sidebar children. I have also switched the media breakpoint to the lowest value already used in the styles which is 480px.
To be honest I don't like the navbar transformation and how the mobile menus are implemented in Docusaurus right now. There are two menus, one for navigation content and other for the sidebar content, also the ToC content is missing, which is a bit confusing to the users. But it looks like the refactor/improvement is already in progress:

https://github.com/facebook/docusaurus/pull/4273

Hi @luism3861, thank you for working on this!
I think that adding a viewport breakpoint and changing navbar-sidebar size on very small screens is bit more universal solution that adding bunch of overwrites for navbar-sidebar children. I have also switched the media breakpoint to the lowest value already used in the styles which is 480px.
Please confirm if the mobile menu works for you correctly now (after the size change), after confirmation I will merge the changes, if there will be no issues with changed solutions.
Also to be honest I don't like the navbar transformation and how the mobile menus are implemented in Docusaurus right now. There are two menus, one for navigation content and other for the sidebar content, also the ToC content is missing, which is a bit confusing to the users. But it looks like the refactor/improvement is already in progress:

facebook/docusaurus#4273

Preview

hi @Simek  thank you for the review , after test for all mobile devices looks better with, width: 100%  in media querie 480px you can merge this . yeah for me i don't like the navbar, i hope to merge the new PR for the new navbar


Yle - audio  support

Is it possible to get support for Yle audiobooks?
YLE AUDIOBOOKS

@callecolor Seems to be using RTMPE and seems like the RTMPE urls are encrypted.

Oh, thats sad. otherwise it would be awesome :)

HTML5
https://player.yle.fi/api/v1/media.jsonp?id=6-72bcaeeebad144dcbdf3ee9856766a7a&protocol=PMD&client=areena-html5-player

https://yleeapmdw.akamaized.net/world/f2/f29b086ad6323f6887eb1d208cf0c63d.mp3?primaryToken=[...]

I don't understand what that is 0880. :D

@callecolor yle-dl is for Yle downloads, so open the issue here: https://github.com/aajanki/yle-dl/issues


Scala 3

Hi there!
Scala 3 is finally pretty solid, so it might be worth considering publishing scanamo for Scala 3! I didn't spot an issue for it, so I figured I would create one for discussion/blockers/etc.

How to can I use scanamo with Scala 3 right now?

If you are Scala-CLI user
//> using scala "3.2.2"
//> using lib "org.scanamo::scanamo:1.0.0-M25"

import org.scanamo._
import org.scanamo.generic.auto._
import software.amazon.awssdk.services.dynamodb.DynamoDbClient

case class Foo(i:Int,j:String)

@main def run =
    val scanamo = Scanamo(DynamoDbClient.create())
    val record = Foo(1,"")
    val db = Table[Foo]("tablename")
    val program = for {
    _ <- db.put(record)
    } yield ()
    scanamo.exec(program)

This issue was closed by https://github.com/scanamo/scanamo/pull/1577 / https://github.com/scanamo/scanamo/pull/1596 , first released as v1.0.0-M23.


bumping version

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

No valid build backend found for Python recipe for package soxspipe using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.


confirm if SSA still accepts letters to their offices

It is no longer listed as an available option to report changes per the SSA Website. I understand from the HLC that they prefer recipients to contact them via phone (which is the primary option on the site) or fax.

confirmed & updated next steps template for changes

updated status to show completed versus closed status


Invoke apt call in a non deprecated way.

https://docs.ansible.com/ansible/latest/porting_guides/porting_guide_2.7.html#using-a-loop-on-a-package-module-via-squash-actions

@isakrubin,
Thanks for contributing.
I'm happy to merge this though I'd prefer to make sure the changes are reflected in the CentOS and Fedora setup files. If you aren't interested in doing so can you let me know?

I'd prefer to make sure the changes are reflected in the CentOS and Fedora setup files.

Sure, will sort that out.

@fubarhouse
Sorry for the delay, busy with..well .. life..
there is no file for Fedora? :)
Did you mean RedHat?
By checking the docs it doesn't seem like the dnf command supports this method yet.
I've updated it for CentOS though.


Emotion Detection Model

💥 Emotion Detection Model
This model is designed solely to identify the human emotions (Angry, Happy, Sad, Surprised, Normal).
Using  Unsupervised Models of Machine Learning
Kindly Assign this work to me  @khusheekapoor
Thank You.
@gssoc23

Hi, I am very much interested and would like to contribute as a part of @GSSOC'23.
Please assign the task to me. Thank you.

Hi, I am very much interested and would like to contribute as a part of @GSSOC'23. Please assign the task to me. Thank you.

Hey Tushti!!
I have raised the issue for myself for GSSOC 23'. Kindly raise an issue for yourself related to another topic or Issue. Thank You

@AlapanDas - you can go ahead! We are assigning you 21 days for this project, after which it will be assigned to someone else if not completed. All the best!
Name the file as: algorithm_dataset.ipynb and link it in the readme of the labeled directory as algorithm - dataset.
@tushtithakur  - since we are following the first-come-first-serve policy, we will not be able to assign you this issue. However, you can create another issue on the similar lines.


Add functional tests

We have a testing framework, but no actual tests.
Add tests to validate basic guideline functionality.
The tricky part is verifying that the guidelines actually show up.

Dupe of #48


Optimize ai-rag plugin

配置优化：使用 FQDN Cluster 替换 DNS Cluster
新增 topk, threshold, field 三个dashvector相关的配置，用户可以更灵活对接dashvector
新增 enableTracing 配置字段，该字段开启后在使用链路追踪时会添加rag检索到的文档添加到链路追踪的attribute中
添加响应头 x-envoy-rag-recall，表明是否有在rag阶段检索到额外资料

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

Project coverage is 35.95%. Comparing base (d5a9ff3) to head (9c3428c).
Report is 20 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1170      +/-   ##
==========================================
+ Coverage   35.88%   35.95%   +0.07%
==========================================
  Files          69       69
  Lines       11576     9483    -2093
==========================================
- Hits         4154     3410     -744
+ Misses       7106     5757    -1349
  Partials      316      316

see 67 files with indirect coverage changes


MD033 being flagged for elemenents with _

I believe this wasn't the case before 0.14. Elements like <parameter_name> do not need to be escaped because markdown doesn't recognize strings with _ as elmements. Maybe due to the new Email handling since that added an _ to a regex in the rule. This also doesn't so in VS Code as an issue, just from the Markdown-CLI 0.16.0

Valid, but picky. :)
Reproduction: https://dlaa.me/markdownlint/#%25m%23 Heading

<abc_def%2F>

I believe this comes from the new custom detection (for better accuracy) vs. letting the parser handle this.


IOBJ: Remove number range objects and return error during delete

Number ranges for BW objects are local to a system and will cause errors when duplicates occur
Check return code when deleting InfoObject

thanks 👍


rotp and mathn

Hi,
We are using this gem with Ruby version 2.5.9, but we have the gem mathn manually installed (which was included by default until ruby 2.5)
We've had trouble debugging but we notice that with the mathn gem, dividing numbers gives you fractions instead of integers, therefore in this part on the code of rotp, we had to monkey patch timeint(time) / interval and use (timeint(time) / interval).to_i (which is the same result) to make it work, as later on it was trying to compare fractions with byte strings which caused some issues.
Would it be something you would like to include in the original code to avoid problems with older versions of ruby ?
Thank you !

I think in this case it's probably best to keep monkey patching ROTP for this use case. Mathn was deprecated ~9 years ago in Ruby 2.2.0, so it seems like it's probably not an issue for most users today. There's actually a few places where we do math operations with the assumption that it will be an integer, so it would actually require a few more code changes to cover all the areas where mathn changes the default behavior of Ruby.


State::Idle should be State::Initialized

Idle vs Initialized state
Accordingly to this answer on StackExchange, the current State::Idle that we set after the initialisation process is actually an Initialised state.
https://electronics.stackexchange.com/a/602106
Clock initialise speed
It also seems that this initialisation process should be made in 100 - 400 kHz SPI clock speed (acquire) and should later be increased to the running clock speed.
I suggest that we at least include this in the documentation and later improve (if possible) the crate to handle the clock speed.
Since there isn't any Config for the spi interface in embedded-hal (0.2) I see documentation as the only option for now.

Yes we should document the clock speed requirements if it's not currently clear. Happy to take a PR which changes #80.

Replaced with an Option as it's either initialised or it isn't.


Remove obsolete/insecure algorithms

Algorithms like MD5, SHA1, and RC4 have no business in a modern crypto library.

I'm going to have to respectively disagree. I would agree that no one should be designing new protocols using these primitives. However, I feel that most users probably shouldn't even use something as low level as rust-crypto in the first place, and instead opt for something like a libsodium wrapper.
For individuals educated enough about crypto to decide which primitives to use, avoiding the ones you mentioned is a given.
There is a use case, however, for those interested in implementing legacy (or just poorly designed) systems in Rust. A great deal of (arguably insecure) software uses these primitives and it's at least worthwhile to have them around for those diminishing cases. This is a library, and not a browser or other similar piece of software, after all.

Hello drbo and zsck, it did cross my mind to flag these weak algorithms somehow. I have no idea, however, on how to establish a threshold for that kind of flagging (or as drbo suggested, removing the algorithms altogether). Should AES256 also be flagged/removed because the biclique attack reduced its effective length from 256 to 254.4 bits? Obviously not, but what about 200 bits? and 180? Where do you draw a line?
Maybe (as zsck said) developers who do not understand the limitations really  should not be designing protocols or systems using these primitives at such low level.
I, however, also believe that crypto in general should have very large security margins and the implementations should strive to be resistant to misuse or bad practices by design. In the case of rust-crypto, a warning to the developer might help in that regard. It might prevent bad design decisions or maybe give a hint to the clueless developer that the subject is full of caveats and he or she needs to study a bit before writing production code.
Rust-crypto should not remove the primitives. I can think of at least a few relevant use cases for implementing such algorithms:

testing the integrity of files which had been hashed with md5 or sha1 in the past (real use case for me)
Supporting old SHA1 certificates (IIRC) while they are stil valid. Not everyone has migrated already.
More generally, allow compatibility with legacy systems and hardware. Some latest hardware still does not support sha2 (or sha1 for that matter). My specific usage involves hard drive cloning devices. Others may want to implement decrypting data in legacy formats.

I propose a small paragraph be inserted at the readme.md explaining explaining the caveats and pointing the developer to some kind of updated security reference. What do you think?

I could get behind the idea of adding some information to the documentation describing the risks/tradeoffs of algorithms.  I would suggest that, in the opening paragraph for each primitive's documentation, an explanation or at least a link to some modern literature regarding that primitive's strengths, weaknesses, and recommended use cases be provided. For example, in the case of MD5, SHA1, and other outdated hashes, I would note:

That developers of modern systems with no ties to legacy systems use a more reliable alternative and include a recommendation.
That it is included for legacy purposes and should only be used to interface with legacy software.
A link to some literature describing the weaknesses of the primitive.

This could be extended to cover different modes of block ciphers, achieving a level of granularity suitable to that which one would require when designing their own systems.

Hello, @zsck.
I made a suggestion on issue #296 to add this information to a table alongside other implementation metadata. I believe that would be most useful not only to the clueless developer, but also to the seasoned cryptographer. There would be information not only about the algorithms' security status, but about the security of the implementations themselves.

Perhaps it would be reasonable to move them behind an "insecure" feature gate? So that people would explicitly have to point out that they're aware they're insecure to use them?

I like that idea, @Spencer-H.  I might even go a bit further and store legacy and known-insecure algorithms in an insecure module, and encourage people to refer to that module explicitly in their code. That way people end up writing things like
use crypto::insecure;

insecure::md4(...)

The goal being to make it easy to remind users in the code that the algorithm is not safe. Obviously it could be circumvented by useing the algorithm one wants directly, but it could do some good.

Sorry, rather late to the party. If you want a modern crypto library that's relevant to every day use then you need to support algorithms in common use. Remove them at your peril.
I'd avoid going down the strongly opinionated route. Let the end-user decide on what is appropriate. They are responsible for educating themselves and for the design choices they make. In the real world insecure algorithms tend to linger and we still need to work with them.
If you really do want to inform the user about potential pitfalls, do so in the documentation. However what constitutes an unsafe algorithm? SHA1 was considered unsafe back in 2005, would we have removed it from a crypto library or marked it as unsafe back then? What about NIST curves and potential back doors, are they unsafe too? It's a can of worms that I'm not sure you want to open.

Hi @horrorho, this is the suggestion I made here and on issue #296:

Document the implementation status of the various ciphers in a table in readme.md (actually @tarcieri's suggestion, see issue #296 on why is that important). It could contain data such as whether the implementation was audited, whether it is constant time, and an whether there are known better alternatives/known security issues, as @zsck suggested in may 25.
Generate/update that table automatically from the code documentation itself. Cryptographic primitives that do not have the necessary keywords/markup in the documentation should generate a warning upon trying to regenerate the table or running the tests. Under the DNRY principle, updating this information should be done manually at a single location. A good location would be probably be right next to the code it refers to.
Compiler could generate a warning if the application code used a primitive from rust-crypto documented as "unsafe", and the warning should be easy to suppress from within the application code.

Now to the core of this issue, maybe we could settle on three arguments:
a) Whether the obsolete/flawed/unsafe algorithms should be removed. I am also strongly opinionated that the primitives should not be removed.
b) Whether the compiler should issue a warning in case these are used. I have no idea on how to implement that. I used to think it would be a good idea, now not so sure.
c) Whether the "unsafe" status should be documented. @tarcieri already volunteered to document the implementation status on issue #296, I think the documentation is a great idea and could also include the security status. No one has volunteered to write code that builds the table automatically from documentation, however.

Hi, thank you for the feedback. It sounds like we agree more than we disagree.
Implementation details/ auditing should be documented but this could be considered separate from criticisms of the algorithm itself. A flawed implementation of a insecure cipher is not the same as a perfect implementation of an insecure cipher. Well I'm nitpicking now and documenting security concerns of the algorithm itself is not unreasonable. Either way, you've addressed my main concerns. Thank you and keep up the good work!

This is practically necro-posting at this point, so I appologize if anyone feels that adding to this discussion is a waste, but I'd like to throw another idea into the ring.
It has occurred to me that, while simply documenting that algorithms are unsafe for modern applications, we have a much more effective means of helping developers to understand the risks they are taking built into Rust: the unsafe keyword.  I feel that it may actually be appropriate to define implementations of known insecure algorithms using the unsafe keyword for a couple of reasons:

Having unsafe in the code itself means the documentation cannot fail to adequately alert a developer that what they are doing is potentially dangerous.
Using the unsafe keyword forces developers to observe the risk they are imposing upon themselves- their code will not compile if they do not acknowledge it.
Usage of the unsafe keyword would propagate to all uses of an insecure algorithm, meaning that the developer who uses it and all who follow them will be confronted with the fact that they are using unsafe code and may be compelled to read the documentation to understand why

Of course, there is the caveat that this is a slightly unconventional use of the keyword, but I feel the benefits I mentioned above outweigh the unusualness of this usage.

@zsck Whilst interesting my own view is that this would be a violation of the unsafe keyword semantics. Unsafe is for code that doesn't meet certain compile time guarantees, not for expressing the suitability of code for any particular purpose. A rust developer seeing an unsafe error would assume that the code itself is unsafe, not the algorithm.
Over the years do we apply the unsafe keyword to additional algorithms as vulnerabilities are discovered? This would force developers to recode applications that would otherwise remain functional, or would they just continue to use older versions of the library which may contain bugs.
Documentation would be a more appropriate place to voice concerns over the viability of algorithms. Call me heartless, but if the designer of a new crypto protocol doesn't want to read documentation or educate themselves on modern cryptography standards, then they deserve any heartache that may come their way.
Also are the developers of new crypto protocols not in the minority? I suspect, possibly incorrectly, that most users will be implementing protocols based on clearly predefined use cases.
Again just my two cents. I'm no crypto guru so please interpret my opinions in that context and feel free to disregard any points I make.

Yeah, unsafe is for memory safety, and changes the semantics of the language.
However, there is something I think could be useful: cargo features. You could potentially require people to opt into unsafe/legacy ciphers.

@zsck brings an interesting point in that we are discussing this issue for some time already.
In the name of simplicity, I propose the following actions for solving this issue:

Keep the primives. Except for the @DemiMarie, the original poster, everyone else seems to think the obsolete primitives should be kept, and the original poster has been silent in this discussion.

Add a paragraph in the readme.md.
After: "Rust-Crypto has not been thoroughly audited for correctness, so any use where security is important is not recommended at this time."

We could add something along the following lines: "Weaknesses have been steadily found in cryptographic algorithms over the years which belong to the algorithms themselves and are present even if the implementation is found to be flawless. Some of the algorithms implemented in Rust-Crypto have known vulnerabilities of that kind and are kept for compatibility. The developer should do his or her own research and choose appropriately."

Then we could either close this issue or, if there are volunteers (preferably with pull requests), implement the other suggestions (document each primitive security status, "feature gate" the unsafe ones, etc.).

By the way, I also think the unsafe keyword should not be used for guarding against using obsolete primitives.
And, @zsck, posting to an active issue, even if it's old, should probably not be considered necroposting, you are helping with the solution and even displayed some code :-)

I'm with @tarcieri here. cargo features do the job.
Although simply leaving warnings in the docs sounds more important, perhaps with references if the attack is kinda one canonical, as opposed to a slowly increasing  trend, folklore, etc.

Hi everyone, I submitted pull request #388 to include a warning about known vulnerabilities in readme.md.
Suggestion for possible steps from here (volunteers needed):

You may submit a pull request with a better message. Mine still seems a bit awkward.
Submit a pull request, preferably in a different file, documenting the security status of each primitive.
Submit a pull request with a proposal for implementing "feature gating" (using cargo features) the obsolete primitives.
@DaGenix or whoever else has commit access to this repo can take a look into it.
Hopefully close this issue.

  I'm wondering if those authors are sending pull requests because they used internal features here.  If so, then maybe forking off a "rust-crypto-legacy" crate would be good way to make sure that ciphers, hash functions, modes, etc. do not need to be incorporated into this crate to be usable.

@burdges I think the simpler solution is for those who are enthusiastic about "legacy" crypto to make their own crates for algorithms they are willing to support, as opposed to some sort of omnibus "broken crypto" library.
In general, I feel a lot better about libraries whose maintainers are willing to draw some sort of line in the sand regarding what cryptography they're willing to support.

Note that the notion of "unsafe" or "insecure" depends on which security properties you need.
E.g. algorithms vulnerable to timing attacks are still useful for offline uses.
Even MD5 is essentially secure if you only need is preimage resistance. And unsuitability for signatures and password hashing stem from entirely different reasons - collisions and performance, respectively.
Under some threat models authenticated encryption schemes could be less secure than unauthenticated ones. E.g. when you need deniability.
So categorically labeling those primitives as unsafe and tossing them out seems wrong, especially when their security guarantees are sufficient for the protocols in which they are used.

So categorically labeling those primitives as unsafe and tossing them out/hiding them behind flags seems wrong

I think if you were to take a straw poll among cryptographers as to whether MD5 is "broken" or "insecure", the answer would overwhelmingly be yes. Almost all useful purposes of hash functions depend on collision resistance. Claiming it's not broken because it's still preimage resistant is grasping at straws.

I think if you were to take a straw poll among cryptographers as to whether MD5 is "broken" or "insecure", the answer would overwhelmingly be yes.

And what if they question instead asked "Is MD5 broken or insecure for all applications"? Would you still claim that this hypothetical poll is a forgone conclusion?
I'm saying that sweeping claims are not helpful when working with cryptography where nuances matter.
If you are allergic to md5, let's pick something more palatable: Argon2. Would you label Argon2i as categorically unsafe because it is susceptible to timing attacks, even though it has uses in areas where timing attacks are not a concern?

And what if they question instead asked "Is MD5 broken or insecure for all applications"?

The question is: is MD5 a secure hash function?
The answer is: no, because it's not collision resistant. A secure hash function, by definition, must be collision resistant.
Anything else is conflating the issue, and irrelevant.

@tarcieri MD5 isn't that broken for all applications. HMAC-MD5 is still in use and doesn't suffer the same levels of weakness, Apple for one still use it. Yes, they would be unlikely to use it if designing a new protocol today, but what compelling evidence is there that they should immediately revoke it's current usage?
As @the8472 also mentioned how do you audit algorithms for selection?
I think you have a two broad camps here. Those pushing for a tight/ highly opinionated library and those pushing for a more relaxed approach. I guess you could list some advantages/ disadvantages for both.
Tight:

pros: Less code to maintain. Safe algorithms. Reduced resource cost/ cheap.
cons: Narrower use case coverage/ audience. Algorithm selection/ removal auditing requirements/ conflicts.

Relaxed:

pros: Wider use case coverage/ audience.  Unsafe algorithms. High resource cost/ expensive.

I'll just leave this here:
https://www.kb.cert.org/vuls/id/836068

Do not use the MD5 algorithm
Software developers, Certification Authorities, website owners, and users should avoid using
the MD5 algorithm in any capacity. As previous research has demonstrated, it should be
considered cryptographically broken and unsuitable for further use.

@tarcieri That note needs to be reviewed in context. At no point do they mention, discuss or provide any solid evidence of an exploitable HMAC-MD5 vulnerability.
The safety of HMAC in regards to the collision weakness of it's underlying hash algorithm has been discussed in more specific terms.
Bruce Schneier on SHA1 although the point also applies to MD5:
It pretty much puts a bullet into SHA-1 as a hash function for digital signatures (although it doesn't affect applications such as HMAC where collisions aren't important).
Also:
https://www.ietf.org/rfc/rfc2104.txt
http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html
Either way as I'm sure you've figured, the point I'm trying to make is that there are differing opinions by experts/ corporations on what is and what isn't acceptable in regards to cryptography. The real question is how opinionated does this library want to be? It's an honest question, hence my thoughts on tight/ relaxed above.

@horrorho cryptographic best practice is clear: don't use MD5. If you disagree, please point to one cryptographer or organization specializing in cryptography who disagrees. Bruce Schneier talking about a completely different algorithm which hasn't yet seen a hash collision doesn't count. There is no controversy about MD5 in the in the cryptographic community: it is broken and shouldn't be used.
While there aren't specific attacks against particular constructions using MD5 like HMAC, the evidence against MD5 is massive and damning: it is broken, and shouldn't be used. Just because every last usage of MD5 hasn't been demonstrated insecure is not an argument that it is secure.
The debate in this thread comes down to "well recognized cryptographic best practices" versus "excuses to persist in using insecure cryptography". There is only one excuse for the latter: legacy interop in situations where whatever circumstances prevent upgrading algorithms.

I for one have to agree with @tarcieri. MD5, SHA1, etc. are considered broken by the cryptography community and an argument that they are still somehow suitable for some applications is irrelevant to this discussion.  Surely we can all agree that any newly designed crypto system should not use algorithms like MD5, because stronger alternatives exist and have been standardized, and which can be used in fundamentally the same way.
@horrorho also makes an important point that what we're trying to discern here is basically the stance that this crate should take with regards to supporting broken crypto at all.  However, I don't think the question is one of strictness.  Instead, we should think about things from users' perspectives.
Continuing along that line of thought, I have a few questions that I think we'd do well to try to answer in order to make it clear what solution we should follow.
Suppose someone is coming to Rust from a language/ecosystem/background without a solid history in crypto fundamentals.  If someone thinks "I want to make X in Rust and need a way to hash things like I did before. Where is the MD5 function?" Do we want them to end up going to some other crate and immediately using its implementation of MD5? Do we want rust-crypto to be something of a one-stop-shop for crypto primitives in Rust? We could leverage the fact that people would be likely to land upon rust-crypto to educate them that MD5 should be avoided and teach them about an alternative.

=\ Surely everyone knows that MD5 is broken by now, and won't use it unless they have a good reason? I'm not sure if this is correct and idiomatic use of the attribute, but an idea to consider if you haven't already would be to mark "broken" methods as #[deprecated].

@quadrupleslap Unfortunately not everyone does know this. Even if they did, I think that any library that would support legacy crypto should do its part in ensuring such functionality isn't misused. Try to put the onus on users to know everything they should about what crypto they should and shouldn't use, and you'll see a lot of people making the wrong choices.
Using #[deprecated] feels similar to my older (flawed) idea of using unsafe- it's a case of misusing a language feature. An MD5 function supported by rust-crypto isn't deprecated until the API for it is deprecated by rust-crypto, not by global standards around safe primitives.

I wonder if the Rust community could settle on a documentation convention that certain documentation warnings should be pass through so long as a call path exists, potentially all the way up to the user interface.  In principle, Rust implementation of git might contain a warning about SHA-1 in it's manual page, while code that used SHA-1 in a safer way might not.  If you do not understand the crypto well enough to know if the warning applies to you, then you simply put in a warning saying this fact.

I've been doing some work related to this issue in the RustCrypto/hashes project (a modular fork of rust-crypto).
We just added a security level indicator to each hash function in the project, each of which ships as an independent crate.
/cc @newpavlov


Load url tags removed - deprecated in django 1.9

@yunti thanks. we will probably merge this when Django 1.9 release

No problem thanks - I couldn't wait to start using JSONField!

@luzfcb, considering this version of Cookiecutter is for 1.8, is there any reason why we shouldn't just merge it in right now?

merged.
Thanks @yunti @pydanny


Updating res.fetching doesn't trigger Context consumer updates

Describe the bug
Hi folks! Big fan of Urql here. In the update to 1.6.0, interaction between useQuery and the React Context API stopped working in the same way. Here's the relevant code (pulled out from my own project, codesandbox link below):
// viewer-context.tsx

export const ViewerContext = createContext<ViewerContextValue>({
  fetching: true,
  viewer: null
})

export function ViewerProvider({ children }: { children: ReactNode }) {
  const [res] = useQuery<{ viewer: User | null }>({
    query: viewerQuery
  })

  const value = {
    fetching: res.fetching,
    viewer: res.data && res.data.viewer ? res.data.viewer : null
  }

  return (
    <ViewerContext.Provider value={value}>{children}</ViewerContext.Provider>
  )
}

// Main.tsx, which consumes that context using `useContext`

export default function Main() {
  const { viewer, fetching } = useContext(ViewerContext)
  console.log(fetching)

  // Still loading
  if (fetching) return null

  return
Hi!

}

I'm able to reliably reproduce differing behavior between 1.5.1 and 1.6.0. In the former, when res.fetching changes, consumers of the context are updated (the console.log in Main.tsx follows the updates). That is not the behavior I'm seeing in 1.6.0 - the Context API checks for object equality using Object.is, so I'm guessing something has changed there (presumably in #447)? That doesn't really make sense, but updating urql is the only change I've made while testing this out.
In setting up the below codesandbox, I've realized that maybe using a Context for not repeating the same query is unnecessary thanks to urql's caching - I'd love your opinion there, but either way I'm bringing this up as a likely unintentional regression in 1.6.0!
Steps to reproduce
A codesandbox link (thanks for the template below!): https://codesandbox.io/embed/urql-issue-template-client-vj73c
Expected behavior
I'd expect consumers of a Context that sets a value using res.fetching to correctly update consumers of the context.
Actual behavior
The value is updated in the provider itself, but not in the consumers. You can toggle between 1.5.1 and 1.6.0 in the Codesandbox link to see it in action!
Thanks! Let me know how I can help ❤

This is indeed very odd! 🤔
I’ve checked the CodeSandbox and the parent component with useQuery seems to be updating reliably — after a while I’m seeing res.fetching === True there.
But this update somehow doesn’t trigger a context change, although a new context value is created on every render. Instead the change seems to be swallowed and the child never receives the update.

Ok, I was able to reproduce this on react-wonka in isolation, so I should be able to figure out how to fix this. This kind of seems like a weird edge-case, since the component with useStreamValue (in the case of urql, useQuery) does update correctly.

@kitten can we get new patch release, i have similar problem

The hotfix has been merged and 1.6.1 has been published. Also verified that it's fixed here: https://codesandbox.io/s/urql-issue-template-client-6sbwx
@JasonEtco Nice catch! :tada: And thanks for reporting it this promptly with such a nice reproduction 🙏

Amazing, that was so fast! ⚡⚡⚡ Thank you for the quick fix @kitten ❤ I've confirmed that 1.6.1 works as expected in my project!

@kitten thanks for the quick fix, working great now ^^


the transforms property seems not to work

Hello,
First of all, thank you for this great package, really helpful !
I've got some troubles with transforms property. It seems that it does not apply the transform function on outbound state. Maybe my configuration is not set properly ?
Here is the configuration:

Here is my transforms:

Reseller.fromCloud(data) is a function which instanciate a new Reseller class.
But after verification, no class is instantiated...
Could you help me please ?
Thank you for your answer

Hi @ajeanjean-vivlio, thank you for catching this up. I may take a look at this tomorrow.

Hi @PiotrKujawa , thanks for your answer. What I can see today by comparing the two configurations is that the rehydration of the store by the transforms property seems to be faster using the redux-persist configuration than using the redux-deep-persist configuration. I don't know why it takes more time but thank you for your help.

Well, slower rehydration is expected since redux-deep-persist is also based on transforms, and lots of operations are done during rehydration. But I also will take performance into account when checking your issue.

Thank you for your answer, it helps me understand why it takes a little longer. In the above case, in the first render, the data is not transformed, and in the second render I get the data transformed into class type. This takes just a few milliseconds, but it caused my application to crash, because the expected type was not of the class Reseller in the first render.
Thank you for your help.

Hi @ajeanjean-vivlio, sorry I didn't get back to you yesterday but I had a lot of work.
Looking at your configuration I see you still use a nested config which is fine but you must be very careful when naming your root reducer key in your nested config and then whitelist reducer key in your transform method.
I took a look at custom transforms, and how they work together with redux-deep-persist and I don't see any issues. Everything works as expected. The problem may be with your configuration. Resellers transform will work for auth.resellers key in your rootReducer. If you have resellers at any different level then your transform won't be invoked.
I would suggest creating a flat config that would look cleaner and you could define a blacklist or whitelist with a little deeper nesting level. Of course, if the performance of saving a few milliseconds is important to you I would keep it as you have.
Please let me know if this was helpful for you.

Hi @PiotrKujawa , thank you very much for your help and time. Finally we found another way which fits our needs. I think as you said that the issue was on our side, but I did not understand yet why we receive transformed data with a little rendering shift.
Thank you for your answer and your work.


Composer doesn't kill bots on shutdown

Describe the bug
Composer is not consistently killing running bots on shutdown.  Gif of the behavior is below.  Oddly, you can also see that once Composer shuts down, a second bot process appears in task manager, which I cannot explain either.
Bot process in this case is ContosoInsurance.
Version
Version:  2.0.0-nightly.240870.919a971
Electron: 8.2.4
Chrome: 80.0.3987.165
NodeJS: 12.13.0
V8: 8.0.426.27-electron.0
OS
Windows 10
To Reproduce
Steps to reproduce the behavior:

Open Composer, start the bot
Open task manager and find the bot process
Kill Composer with the x in the top right
Process doesn't end.

Expected behavior
Composer should correctly kill the process when shutting down.
Screenshots

Likely a repro for #7157

Shiproom - let's bottom out an approach and see where we land on the calendar

I can consistently repro this:

That's after 2 shutdowns, so it leaves an orphaned process for each shutdown if there is a bot running.

I am going to take a shot at implementing a listener on app quit that cleans up running bots.

May the 4th be with you.

Shiproom - approved.  please merge today.  thanks Tony


Generate azure environments

Purpose
This PR makes it so when you do azd up and then tools generate the environment variables, those variables are available to the app. Specifically the URI for the web app.
Does this introduce a breaking change?

[ ] Yes
[x] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

Example
// <autogenerated />
// Generated from ~/azure-search-openai-demo-csharp/app/maui-blazor/../../.azure/azure-search-openai-demo-csharp/.env

namespace MauiBlazor
{
    internal class AppSettings
    {
        public const string ServiceWebUri = "https://XXX.azurecontainerapps.io";
    }
}

This is so crazy it just might work!


Briefs

I made a bit of confusion with the branches: this one includes both the teaching material post and the briefings post...


Add current temperature as a sensor

Hello,
This PR implement the current temperature value as sensor for Velis NuosSplit (see #358).
Here is output on the panel:

Hope you can add this if your have time.
Kind regards,
Xavier

https://github.com/fustom/ariston-remotethermo-home-assistant-v3/wiki/Current-temperature-as-template-sensor


Stepper firstPanel is undefined

Describe the bug
I know that there's a already issue for that problem https://github.com/vmware/clarity/issues/4353, in my case thestepper seems to work correctly, but it throws a TypeError: can't access property "id", firstPanel is undefined which refers to the function openFirstPanel() found in clr-angular.js webpack bundle.
openFirstPanel() {
        const firstPanel = this.getFirstPanel();
        this._panels[firstPanel.id].open = true;
        this._panels[firstPanel.id].disabled = true;
        this.stepperModelInitialize = true;
    }

How to reproduce
Steps to reproduce the behavior:

Open any page with a clr-stepper-panel
See error on console

Expected behavior
The first panel gets opened without throwing a TypeError
Versions
App

Angular: 9.0.1
Node:12
Clarity: 3.1.5

Device:

OS: Debian
Browser: Firefox
Version 78

Hey @portothree thanks for reporting this but I can't reproduce it, did not saw any error anywhere, can you provide a StackBlitz example, you could find a startup template here: https://stackblitz.com/@clr-team
It will be a lot easier for us to find and fix if there are any issues.
Thanks.

Hey @portothree thanks for reporting this but I can't reproduce it, did not saw any error anywhere, can you provide a StackBlitz example, you could find a startup template here: https://stackblitz.com/@clr-team
It will be a lot easier for us to find and fix if there are any issues.
Thanks.

Thanks for the fast response. I have uploaded a similar case https://stackblitz.com/edit/clarity-v3-light-theme-bfft4r, and by doing so I realize what my problem was; forgot to use *clrIfExpanded and the second panel interacts/depents on the first one, so it was running before the user fills the first panel.

Thanks for the demo, will check it to see what is going on .. .

Nice!! Thank you for taking a look


Makemigration --merge fails - parse number attribute not found

AttributeError: 'MigrationAutodetector' object has no attribute 'parse_number'
$ python --version
Python 3.10.6
$ pip freeze | grep Django
Django==4.1
This PR should provide a dirty solution:
https://github.com/charettes/django-syzygy/pull/27

Thank you for your report, a proper traceback would have been appreciated. Superseded by #30 which includes a regression test. django-syzygy 0.1.0a10 should proper tested Django 4.1 and 4.2 support.


Drag and drop members

There seems to be an issue with dragging and dropping users between channels (As well as reordering channels), but only when using this wrapper. Would this be something that could potentially be worked around or is it just how the electron wrapper works which prevents the drag and drop from completing?

I'm not having issues with dragging members around. What distro and DE are you using?

I am using Ubuntu 15.10, I'm sorry what do you mean DE?

DE means desktop environment, and it would be Unity in your case on Ubuntu unless you changed it.
I also seem to be unable to reorder channels, I'll look into it soon.

I'm pretty sure this is related to https://github.com/atom/electron/issues/2897 and https://code.google.com/p/chromium/issues/detail?id=412373.
I'm not exactly sure how to go about applying the given workaround, nor am I sure if it's even possible given discord's various levels of obfuscation.

Hmm that's not good, oh well.. I guess it's time to close the issue if we can't do anything about it right now. Thank you for looking into it

It might not be that bad, I've asked for clarification elsewhere so maybe it'll be relatively easy. We'll see.


Slow command timeout didn’t work

Fixed debug message to include is_slow

Using only the first word of shlex.split when checking if command is slow.

Thanks for the fix!


Implement functions to control motors using decoded GCODE

[x] Run motors
[x] Rapid motion
[x] Normal motion

Rcode implemented in file rcode_test.py and rcode_test.ino


Update documentation to mention PARAMETRIC_DATETIME client capabilities header

The following query
SELECT cast(TIMESTAMP '2020-09-01 12:00:00.123456789' as TIMESTAMP(9))
gives the following result when run against the <coordinator_host>/v1/statement endpoint:
"2020-09-01 12:00:00.123"
on prestosql 340
This is in contrast to the documentation here which states that the result should be
"2020-09-01 12:00:00.123456789"
FWIW the presto CLI handles this query correctly:
presto> SELECT cast(TIMESTAMP '2020-09-01 12:00:00.123456789' as TIMESTAMP(9));
             _col0
-------------------------------
 2020-09-01 12:00:00.123456789

and even handles the non-parameterized version correctly as well:
presto> SELECT TIMESTAMP '2020-09-01 12:00:00.123456789';
             _col0
-------------------------------
 2020-09-01 12:00:00.123456789
(1 row)

When we added this feature, we had to preserve backward compatibility for old clients that did not support arbitrary precision. In order to get the new behaviors, client have to declare they support the PARAMETRIC_DATETIME capability via the X-Presto-Client-Capabilities header.

ah I see, thanks for the clarification.
do you think it makes sense to add this advice to either https://prestosql.io/docs/current/functions/datetime.html or https://prestosql.io/docs/current/language/timestamp.html?highlight=timestamp? or will this be a non-issue in 341 now that the PR breaking backcompat with legacy semantics is landed?

to close the loop I can confirm that the full results are returned when -H "X-Presto-Client-Capabilities: PARAMETRIC_DATETIME" is included so going to retitle this issue as a documentation update :)

do you think it makes sense to add this advice to either https://prestosql.io/docs/current/functions/datetime.html or https://prestosql.io/docs/current/language/timestamp.html?highlight=timestamp

No, that should be mentioned in the Clients or Developer section. It's something users shouldn't be concerned with, as it's an implementation detail of the client itself. We don't have any place for that information right now, so we'll have to create something. cc @mosabua

@alec-heif curious, do you use a client library or interact with REST API directly?

@findepi I use the pyhive client library

@alec-heif i created https://github.com/dropbox/PyHive/issues/363 as a follow up to this discussion.
thanks for reminding about this.


ES6 & ES7

Quick summary of new features of es6. Examples of how something is done in es5 and how can it be done in es6, i.e. how es6 solves some of es5 problems.
Depending on time more details on some of the features like:

module import/export
WeakMap/WeakSet
template literals (e.g. https://github.com/lukehoban/es6features/issues/49#issuecomment-146866137)
pattern matching and default parameters
rest/spread operator (e.g unique values in array using Set)
codepoints and RegExp in unicode
iterator and generator function - without too much details of asynch programming (e.g. Fibonacci)
class and inheritance

There are also other cool features like Symbols and Meta-programming but I guess it is a bit too much for the first presentation on es6 :)
Reference: https://github.com/lukehoban/es6features
Reference: http://es6-features.org/#Constants
Reference: http://exploringjs.com/es6/

Me and Luka can take this one :+1: A great excuse to learn some features I don't know about yet.

@lblazecki :100:


Refactor AppliableEvent interface

Issue description
AppliableEvent interface had methods, don't really needed for it.
Solution
Added StorableEvent in example service to represent interface with methods needed to save event to db or somewhere else.
Checklist

Created PR:

[x] Name contains issue reference
[x] Has type:  and kind:  labels applied

[x] Documentation is updated (if required)
[x] Tests are updated (if required)
[ ] Final commit message is posted

[ ] and approved

[x] review is completed and changes are approved
Before merge:

[x] Commits are squashed and rebased
[x] Milestone is set
[x] MR's name and description are correct and up-to-date
[x] All temporary labels are removed

FCM
Refactor `AppliableEvent` interface (#17)

- add `StorableEvent` interface in example service
- refactor `string`'s fot time representation to `time.Time` in example service


Build Frontend for Nostr Signature Signing and Verification

Description
Develop a simple frontend interface that allows users to sign and verify messages using Nostr-compatible browser extensions like Flamingo or nos2x.
The webapp has been initiated in joyboy-webapp directory. It currently has simple signing of messages using Nostr NIP-07 compatible extensions (tested with nos2x and keys.band).
Tasks

[ ] Design the UI/UX for signing and verification.
[ ] Implement the React components.
[ ] Integrate with browser extensions via API.
[ ] Conduct end-to-end testing

I would like to work on this issue

I would like to work on this issue

Thanks for your interest. Bare with us few more days please as we will soon announce the project and share the telegram group link to coordinate contributions. Once we do that please manifest again your interest and it will be a pleasure for us to onboard you on this exciting project.

@AbdelStark  alright, thank you. Please keep me updated


ign -> gz CMake, Python, Partial Source, and File Migrations : gz-msgs

See: https://github.com/gazebo-tooling/release-tools/issues/765

@osrf-jenkins run tests please!

@osrf-jenkins run tests please!

@osrf-jenkins run tests please!

@osrf-jenkins run tests please!


Compass Compile error when pushing to heroku

I'm trying to use ember-cli-compass-compiler package with Ember, but I get a problem when I try and push to Heroku:  Your Ruby version is 2.2.6, but your Gemfile specified 2.3.3 (Bundler::RubyVersionMismatch). It seems to use a different version of ruby than the one from my Gemfile, even when I override the compassCommand option for ember-cli-compass-compiler to use bundle exec.

-----> Caching build
       Clearing previous node cache
       Saving 3 cacheDirectories (package.json):
       - ember/node_modules
       - ember/bower_components
       - node_modules
-----> Build succeeded!
=====> Downloading Buildpack: https://github.com/heroku/heroku-buildpack-ruby
=====> Detected Framework: Ruby
-----> Compiling Ruby/Rails
-----> Using Ruby version: ruby-2.3.3
-----> Installing dependencies using bundler 1.13.7
       Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
       Fetching source index from https://gems.contribsys.com/
       Fetching gem metadata from https://rubygems.org/.......
       Fetching version metadata from https://rubygems.org/..
       Fetching dependency metadata from https://rubygems.org/.
       Fetching https://github.com/rails-api/active_model_serializers
       Fetching source index from https://gems.contribsys.com/
       Fetching https://github.com/aycabta/twitter
       Using json 1.8.3
       Installing i18n 0.7.0
       Installing minitest 5.10.1
[...long list of dependencies...]
       Bundle completed (102.36s)
       Cleaning up the bundler cache.
-----> Detecting rake tasks
-----> Preparing app for Rails asset pipeline
       Running: rake assets:precompile
       I, [2017-02-15T19:16:35.512702 #8049]  INFO -- : Celluloid 0.17.3 is running in BACKPORTED mode. [ http://git.io/vJf3J ]
       Visit http://ember-cli.com/user-guide/#watchman for more info.
       ember-cli: 2.8.0
       node: 6.9.5
       os: linux x64
       Could not start watchman; falling back to NodeWatcher for file system events.
       Visit http://ember-cli.com/user-guide/#watchman for more info.
       /tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/vendor/bundle/ruby/2.3.0/gems/bundler-1.13.7/lib/bundler/definition.rb:473:in `validate_ruby!': Your Ruby version is 2.2.6, but your Gemfile specified 2.3.3 (Bundler::RubyVersionMismatch)
       from /tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/vendor/bundle/ruby/2.3.0/gems/bundler-1.13.7/lib/bundler.rb:93:in `setup'
       from /tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/vendor/bundle/ruby/2.3.0/gems/bundler-1.13.7/lib/bundler/setup.rb:20:in `<top (required)>'
       from /tmp/tmp.0TS6hXAdas/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
       from /tmp/tmp.0TS6hXAdas/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
       Build failed.
       The Broccoli Plugin: [CompassCompiler] failed with:
       Error: Command failed: bundle exec compass compile --output-style=compressed --sass-dir=/tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/ember/tmp/compass_compiler-input_base_path-RWLrsVrJ.tmp/0/app/styles --css-dir="/tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/ember/tmp/compass_compiler-output_path-ae7LWwHa.tmp/assets"
       /tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/vendor/bundle/ruby/2.3.0/gems/bundler-1.13.7/lib/bundler/definition.rb:473:in `validate_ruby!': Your Ruby version is 2.2.6, but your Gemfile specified 2.3.3 (Bundler::RubyVersionMismatch)
       from /tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/vendor/bundle/ruby/2.3.0/gems/bundler-1.13.7/lib/bundler.rb:93:in `setup'
       from /tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/vendor/bundle/ruby/2.3.0/gems/bundler-1.13.7/lib/bundler/setup.rb:20:in `<top (required)>'
       from /tmp/tmp.0TS6hXAdas/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
       from /tmp/tmp.0TS6hXAdas/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
       at ChildProcess.exithandler (child_process.js:206:12)
       at emitTwo (events.js:106:13)
       at ChildProcess.emit (events.js:191:7)
       at maybeClose (internal/child_process.js:877:16)
       at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)
       The broccoli plugin was instantiated at:
       at CompassCompiler.Plugin (/tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/ember/node_modules/broccoli-compass-compiler/node_modules/broccoli-plugin/index.js:10:31)
       at CompassCompiler.CachingWriter [as constructor] (/tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/ember/node_modules/broccoli-compass-compiler/node_modules/broccoli-caching-writer/index.js:21:10)
       at new CompassCompiler (/tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/ember/node_modules/broccoli-compass-compiler/lib/compiler.js:17:17)
       at CompassCompiler (/tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/ember/node_modules/broccoli-compass-compiler/lib/compiler.js:10:52)
       at /tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/ember/node_modules/ember-cli-compass-compiler/index.js:67:23
       at Array.map (native)
       at CompassCompilerPlugin.toTree (/tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/ember/node_modules/ember-cli-compass-compiler/index.js:38:40)
       at /tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/ember/node_modules/ember-cli-preprocess-registry/preprocessors.js:184:26
       at Array.forEach (native)
       at processPlugins (/tmp/build_df50ef368d701deb826830bd5659a172/Latermedia-latergram-4b1355791dd31412fa517d369a1cbb8322bda226/ember/node_modules/ember-cli-preprocess-registry/preprocessors.js:182:11)
 !
 !     Precompiling assets failed.
 !
 !     Push rejected, failed to compile Multipack app.
 !     Push failed

Anyone have any thoughts? Is the node build pack (which I load first) setting a ruby version that conflicts?
Which operating system and version is the project developed on?
Mac
Which version of ruby is the project developed on?
2.3.3
Which version of npm is the project developed on?
7.3.0
Which version of ember-cli is the project developed on?
2.8.0
What is the rails version?
<IP_ADDRESS>
What is the ember-cli-rails version (from Gemfile)?
0.8.3
What is the ember-cli-rails-addon version (from package.json)?
0.8.0
Is your application server multi-threaded
(such as puma and unicorn) or is it multi-process (such as thin and webrick)?
puma
What are the contents of config/initializers/ember.rb?
EmberCLI.configure do |c|
  c.app :ember
end

What are the contents of the Rails' view that renders the Ember application?
<%= render_ember_app :ember do |head, body| %>
    <% head.append do %>
        <%= stuff%>
        <%= csrf_meta_tags %>
    <% end %>
    <% body.append do %>
        <%= stuff %>
    <% end %>
<% end %>

How are the EmberCLI-related routes defined?
  mount_ember_app :ember, to: "/(*ember_route)", controller: "app", action: "index", as: 'ember_app'
  mount_ember_assets :ember, to: "/"

How is the application deployed?
Heroku

Seems to have something to do with ember-cli-compass-compiler calling an exec which opens a new shell and might not be setting the ruby version correctly.
Closing issue here in lieu of more appropriate issue on https://github.com/quaertym/ember-cli-compass-compiler/issues/75


utility: convert typed_config to factory config

Signed-off-by: Yan Xue<EMAIL_ADDRESS>Description: convert typed_config to factory config
Risk Level: Low
Testing: Unit test
Docs Changes:
Release Notes:
[Optional Fixes #Issue]
[Optional Deprecated:]

@htuch I extracted the utility from https://github.com/envoyproxy/envoy/pull/10369


Feature: handle auto added tags from zotero

When putting tags as a mapped field to import into the yaml, only the manually added tags are imported.
This behavior seems like a bug, and if not, it is unpredictable and should be controllable by the user.

Tags imports filters are now customizable, you can now import tags from literature, in addition to manually added ones. Please check out the documentation for more details.


Users lose edit permission after visiting pages where they don't have it and getting back to previous page

Summary
User who is not superuser but is staff and has the access to making edits on some specific set of pages gets permission error after visiting the page where he doesn't have permissions and getting back. As I understand it can be related to #6335 issue.
Expected behaviour
When user (is_staff) logged in he can see 'Edit' button in toolbar and make some edits on the page. When he visits another page where he has no permissions to edit, he doesn't see the 'Edit' button anymore. After he gets back to previous page (where he has permissions) he expects to see 'Edit' button and continues to work.
Actual behaviour
After user gets back to previous page (where he has permissions to edit), he still doesn't see 'Edit' button. If he adds '?edit' to url, the "You do not have permission to edit this plugin" title is displayed in popup.
Environment

Python version: 2.7
Django version: 1.9.5
django CMS version: 3.5.1

Thanks for reporting!
Closing as duplicate of https://github.com/divio/django-cms/issues/6335


python312Packages.wled: 0.20.1 -> 0.20.2

Diff: https://github.com/frenck/python-wled/compare/refs/tags/v0.20.1...v0.20.2
Changelog: https://github.com/frenck/python-wled/releases/tag/v0.20.2
Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] 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

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

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

[ ] Fits CONTRIBUTING.md.

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

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

5 packages built:

home-assistant-component-tests.wled
python311Packages.wled
python311Packages.wled.dist
python312Packages.wled
python312Packages.wled.dist

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

5 packages built:

home-assistant-component-tests.wled
python311Packages.wled
python311Packages.wled.dist
python312Packages.wled
python312Packages.wled.dist


feat(organizations-access): new command to manage access for individu…

…al orgs
@janl @christophwitzko

@janl @christophwitzko pls review again/merge :)

LGTM :+1:

With @janl's issues addressed and @christophwitzko's +1 I'm going to release this now.


indent-blankline is overwriting characters in mixed space/tab indented files when shiftwidth does not equal tabstop

Hello,
To reproduce the issue, use a YAML test file with the following content:
test:
    test1: |
        [section]
        	key = "value"
# vim: shiftwidth=4 tabstop=2

:warning: All the file is indented with 4 spaces but there is one tabulation before key.
The indent-blankline configuration used is:
require('indent_blankline').setup{
  show_current_context = true,
  show_current_context_start = true,
}

Without indent-blankline, the file is displayed this way in neovim:
test:
    test1: |
        [section]
          key = "value"
# vim: shiftwidth=4 tabstop=2

This complies with the modeline.
With indent-blankline, the file is displayed this way in neovim:
test:
|   test1: |
|   |   [section]
|   |   |   y = "value"
# vim: shiftwidth=4 tabstop=2

It also complies with the modeline but if you look closely, the key word is missing its two first letters and only y remains.

:+1: mixed indentation like this is not well supported.
I want to implement this differently in v3. It probably won't get fixed in the current verison, sorry

Hello @lukas-reineke, thanks for your answer :+1:.
No problem, no need for apologies, you and the other contributors are the ones providing the effort :slightly_smiling_face:.
In the meantime, this issue might remind people to ensure that shiftwidth needs to equal tabstop to avoid strange behaviors like this.
Do you mind if this issue it is kept opened until v3?
You might perhaps also have some space where you are already tracking the items envisioned for v3?
Do you mind referencing this space here if this is the case?

You might perhaps also have some space where you are already tracking the items envisioned for v3?
Do you mind referencing this space here if this is the case?

I have, and it is already on the list for v3 Use tabstop and shiftwidth per indent level instead of global for the whole buffer
https://github.com/lukas-reineke/indent-blankline.nvim/discussions/462#discussion-4254869

Does anyone know a vim/nvim plugin or any other way to ensure that shiftwidth = tabstop?
That would help working around the issue in the meantime.
I am currently using vim-sleuth to configure these settings automatically but it does not provide a way to ensure this equality.

mixed indentation is now supported with version 3


codet5-base.jackson-databind.mid-5665.idx-40435.1.mutant

This is an edit in the format in the MutableInterval file.

Fix indentation LGMT!


Update tag text in transactions table

What
Two tickets completed here
Make tag text shorter to fit the table better AP-2205
Add a tag for disregarded benefits AP-2206
Checklist
Before you ask people to review this PR:

[ ] Tests and rubocop should be passing: bundle exec rake
[ ] Github should not be reporting conflicts; you should have recently run git rebase master.
[ ] There should be no unnecessary whitespace changes. These make diffs harder to read and conflicts more likely.
[ ] The PR description should say what you changed and why, with a link to the JIRA story.
[ ] You should have looked at the diff against master and ensured that nothing unexpected is included in your changes.
[ ] You should have checked that the commit messages say why the change was made.

Codecov Report

Merging #2603 (a7f7e08) into master (8cb8942) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master     #2603   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          525       525
  Lines        10703     10701    -2
=========================================
- Hits         10703     10701    -2

Impacted Files
Coverage Δ

app/helpers/transaction_type_helper.rb
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


as an organization who wants to allow for a zero knowledge proof I need to request proof based on a question about one or more attributes and list the schemas that they can come from

Implement "predicates"

Predicates are implemented. However, multiple ORed schemas are currently not supported in the UI


Bump the govuk frontend toolkit to 4.12.0

This will bring in the updated button padding, will remove the
@font-face declaration for Helvetica, and remove the @viewport
declarations (they’re added back in to govuk_template in 0.17.2).

cc. @robinwhittleton


HAXM does not work with Core 2 Duo CPU

I run Android emulator (latest Android development tools) with HAXM 7.0.0 and it looks like HAXM acceleration is not working since emulator boots really slowly e.g. it takes hours to boot and CPU usage is close to 100% all the time. Any idea how to proceed and diagnose problems with HAXM?
In emulator log it says:
Warning: Quick Boot / Snapshots not supported on this machine. A CPU with EPT + UG features is currently needed. We will address this in a future release.
emulator: CPU Acceleration: working
emulator: CPU Acceleration status: HAXM version 7.0.0 (4) is installed and usable.
Is this message coming from HAXM? How can I be sure that bug is or is not in HAXM? Any hint where to look? Full log attached.
Is there some debug mode in HAXM? Should I try to build locally on my computer some custom build for debugging purposes? How can I install built intelhaxm.kext, do I need to package it to .dmg? If so, how? Any hint is welcome. Thank you!
$ kextstat | grep intel
207    0 0xffffff7f83bbd000 0x1e000    0x1e000    com.intel.kext.intelhaxm (7.0.0) 823315F2-1275-377E-AFF9-E909857C3B2B <7 5 4 3 1>
emulator.log
macOS 10.13.3, MacBook mid 2010, Core 2 Duo 2.4GHz, 16GB RAM, 500GB SSD
EDIT: it doesn't work on Win 10 neither.

Hmm, https://software.intel.com/en-us/android/articles/installation-instructions-for-intel-hardware-accelerated-execution-manager-mac-os-x seems to miss one thing: regarding to https://www.qemu.org/2017/11/22/haxm-usage-windows/ , EPT is needed. EPT is not supported by Core 2 Due CPUs, only by Westmere CPUs.

I will check these articles, thank you.
Actually it works fine with 16GB of RAM.

@dmarjanovic Unfortunately, HAXM won't work well on your 2010 MacBook. The message you quoted (or the entire emulator.log) is from Android Emulator (which is an application/process) instead of HAXM (which is a kernel extension), and is not directly related to the slowness you are experiencing. But it does point out the fact that your CPU (Core 2 Duo) lacks two hardware virtualization features, namely Extended Page Tables (EPT) and Unrestricted Guest (UG). These features are available on all Core i-3/5/7 CPUs, but not on older models like Core 2 Duo.
EPT is crucial for memory virtualization performance. As you know, Android runs in a virtual machine as a guest OS, and therefore cannot see the 16GB of RAM in your host system. Instead, the guest RAM is virtualized by the hypervisor (HAXM) using a buffer (usually 1.5GB) allocated by the Android Emulator (or QEMU) process. Without EPT, HAXM intercepts pretty much every guest RAM access and redirects it to the buffer, which is just too much overhead and slows down the virtual machine dramatically. EPT eliminates this performance bottleneck by allowing guest RAM accesses to be handled by hardware without hypervisor intervention.
Moreover, EPT really simplifies the hypervisor implementation of memory virtualization. I believe the original authors of HAXM also preferred EPT, and did not implement the best non-EPT solution: they chose vTLB, yet there are faster (but probably more complex) algorithms for memory virtualization without EPT. As the current HAXM team, our priority is to improve the EPT code, and will eventually remove support for vTLB due to the code complexity and prevalence of EPT hardware.
In fact, I believe Android Emulator will soon require the UG feature, which is equivalent to requiring EPT since these two always come together. That requirement was first added to QEMU (so as to simplify HAXM support code in QEMU), and it seems Google has rebased Android Emulator onto the latest QEMU upstream. The article @mifritscher mentioned is about using HAXM with QEMU, so it was right about the EPT requirement.

Thank you for very detail answers, all is clarified now. Just to follow up with my conclusions with currently available Android development tools (tools 26.1.1, emulator 27.1.12, platform-tools 27.0.1):

Android Emulator (engine auto/qemu2) will not work nicely with x86 AVDs OS v5.0 or newer
Android Emulator (engine auto/qemu2) works just fine with x86 AVD OS v4.4
the same is on both macOS 10.13.3 and Windows 10 64bit
Android Emulator support for engine classic is broken and can't be used

Just to add: x86 AVD OS v5.0 is Google API Level 21+.

I just ran into this myself.  Might I suggest that instead of blue screening the system, that a more friendly type of error check would be warranted?  Just a thought.

Same thing happens to me on i3-3227U. Is it not having EPT + UG?

This contains EPT, which is your details, versions, steps and logs?

@VanshajDaga This contains EPT, which is your details, versions, steps and logs?

I had same problem on i3-2370M, here is the log come from android studio
8:05 PM	Emulator: emulator: ERROR: Running multiple emulators with the same AVD is an experimental feature.

8:05 PM	Emulator: Process finished with exit code 1

8:05 PM	Emulator: Warning: Quick Boot / Snapshots not supported on this machine. A CPU with EPT + UG features is currently needed. We will address this in a future release.

Same Problem with I3-2350M
Emulator: Warning: Quick Boot / Snapshots not supported on this machine. A CPU with EPT + UG features is currently needed. We will address this in a future release.

Same problem here with i3-3217U.
@raphaelning , maybe you mean "These features are available on all Core i-5/7 CPUs", not?

Yes, yours has it. What is your 'same problem'? Is it 'HAXM acceleration is not working since emulator boots really slowly e.g. it takes hours to boot and CPU usage is close to 100% all the time. '? And what is your everything's version? E.G. Emulator, HAXM, host OS?

Hey @raphaelning , I read the details above, but the Manual for Windows suggest
"the legacy code that enables HAXM to work in non-EPT and non-UG modes may be removed soon."
If this statement is true. How can I determine if the non-ept and non-ug modes are available for the master branch or tag. I would clone and compilation local it for my development?
If its not too late to ask for help locating a branch to clone, modify and compile locally.


Deploy the statics in the operator

The operator should receive CRDs of type Static and deploy them.
Deployment should happen creating a configmap from the crd, then an http server that will expose the content to the ingress controller.
Deployment should happen writing the content to s3-compatible buckets, since Kubernetes objects (hence CRDs) are limited to 1MB so they are not fit for deploying static content.
There will be an s3 bucket for each user.
There will be a nuv s3 put command able to write in that bucket.
All we need to do is to generate the taskfile that will invoke that command after buinding.

Hi! I watched the Italian community call and, if I understood correctly, you want some kind of dynamic static file server. You can give a look at NGINX Unit which is a dynamic application/static file server which can be configured via HTTP calls to its configuration socket (it can be a IPC socket but you can also expose it to a port). It allows you to change the configuration with zero runtime cost and it's really cheap.
The unitd server binary is ~400kb and links to openssl, libpcre2 and really nothing more:
lorenzo@Lorenzo-New ~/s/openwhisk (master)> ls -ls /usr/local/Cellar/unit/1.26.1/bin/unitd
768 -r-xr-xr-x  1 lorenzo  admin  389848  2 Dic 22:22 /usr/local/Cellar/unit/1.26.1/bin/unitd
lorenzo@Lorenzo-New ~/s/openwhisk (master)> otool -L /usr/local/bin/unitd
/usr/local/bin/unitd:
<EMAIL_ADDRESS>(compatibility version 1.1.0, current version 1.1.0)
<EMAIL_ADDRESS>(compatibility version 1.1.0, current version 1.1.0)
	/usr/local/opt/pcre2/lib/libpcre2-8.0.dylib (compatibility version 11.0.0, current version 11.4.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)

Not sure if it could solve your issue, but you can take a look: https://unit.nginx.org/configuration/#static-files

Actually this issue is pretty old and outdated - we moved to a different approach including an object storage so I do better to close it.

we are using a different approach with a proxy