asin(make_fvar<double, 1>(1.0));

This expression fails to compile for me in VS2017. The error I get is

C4789	buffer 'derivatives' of size 8 bytes will be overrun; 8 bytes will be written starting at offset 8

this occurs at the access of derivatives[1] inside the sqrt called by asin. This is because asin creates variable d1 with one less order than the fvar (i.e. with order 0) then calls sqrt which creates an array of derivatives of size 1 (i.e. order + 1).
It's worth noting at this point that visual studio by default does not specify /std:c++17 which means BOOST_NO_CXX17_IF_CONSTEXPR is true which means BOOST_AUTODIFF_IF_CONSTEXPR does nothing which means the else block still gets compiled. Manipulating this setting didn't make the constexpr work for me though I feel like it should so maybe there's an issue on my end there. Still in c++11 this error is expected. I can see two solutions to this:

go back to c++11 style template programming instead of constexpr if
change the 1 index to something like std::min(order, 1) remembering this code will never actually run for the non-1 case.

As a side note C4789 is supposed to be a warning but I described it as an error. By default, Security Developent Lifecycle checks are enabled in visual studio projects. This promotes certain security related warnings to errors including this one. Switching SDL off reverts this back to warning status.

Thanks. I believe I see the problem.
Not that this is the solution, but I am just wondering:
The following code is in boost/config/compiler/visualc.hpp
// C++17 features supported by VC++ 14.1 (Visual Studio 2017) Update 3
//
#if (_MSC_VER < 1911) || (_MSVC_LANG < 201703)
#  define BOOST_NO_CXX17_STRUCTURED_BINDINGS
#  define BOOST_NO_CXX17_IF_CONSTEXPR
#  define BOOST_NO_CXX17_HDR_OPTIONAL
#  define BOOST_NO_CXX17_HDR_STRING_VIEW
#endif

Without using /std:c++17 what are _MSC_VER and _MSVC_LANG and what is the actual version of your compiler?

Without specifying /std at all,
The issue is _MSVC_LANG = 201402
_MSC_VER is 1916.

Clang just started giving me a warning about this (locally), though I'm not sure why it does suddenly (no changes to my compilation method that should suddenly trigger this).

It will depend on your usage (it's not clear whether this has changed for you). For the warning to trigger you need to be nesting more operations (that reduce the order) than the order of your variable (maybe plus or minus one). So if you're started nesting operations more deeply or using fewer independent variables this might be the cause.

It looks like lambert_w0 has the same problem except rather than a warning it generates error C2078 "too many initializers" in the creation of coef

Pre-C++17 warnings I can live with, and would prefer over downgrading the code from C++17 in order to satisfy some compilers. I think the reported "error" in sqrt has been fixed.
If there are any:

Compiler errors
Compiler warnings with c++17 compiler flag on

then please let me know and I'll try to addresss, otherwise I'll close this issue.

Now that you mention it all of the unit tests are failing to compile for me because of an assertion in boost::mpl::aux::for_each which is used to iterate over the various numeric types under test. The failure complains that the input sequence all_float_types is not actually a sequence at all. I believe the reason for this is that mpl::begin does not have a specialization for mp11::mp_list (but I'm not certain this is true). Changing the type of bin_float_types from mp11::mp_list to boost::mpl::list seems to fix the problem.
I'm not sure what the relationship between these two libraries is or why they're both in use here. I'm also not sure what changed to cause this to start failing because it's a while since I tried to compile the tests. I also am yet to determine what compilation flag I'm using that the build system isn't that results in it not compiling for me but seemingly compiling fine here.

Actually how do I find out what command line appveyor is using to compile the code? I can't see it in the log but I'm sure I've seen it in the past.

Thank you for checking. It seems that appveyor is using Boost's b2 command to compile:

Download and run https://github.com/boostorg/boost-ci/blob/master/ci/appveyor/install.bat Notably %SELF%==autodiff in this case.
For this run for instance the compilation command is:
b2 libs/autodiff toolset=msvc-14.1 cxxstd=11,14,17,2a   threading=single,multi address-model=64,32 link=shared threading=single,multi variant=release -j3

Finally managed to figure it out. It turns out the version of boost I was using 1_69_0 was different to the one used by the build system (presumably the latest) in a way that caused this compiler error. Pointing my build at the boost-root folder created by the build system fixed the issue so no compiler issues (including warnings) on my end anymore that I'm aware of.


Not-node/iojs cmdname should also happen on Windows.

Hi,
I saw there is a special logic to handle cmdname which is not node or iojs. Such logic should also happen in Window if-branch.
/cc @evanlucas

Should be updated on master.  try npm i spawn-wrap@next to pull the 1.3 version.


Updates style.css for quotes to fit in perfect && added more quotes ( Fixed issue #72 )

Updates to the Project
Changes Made
1. Modifications to style.css

Improved styling for quote blocks to enhance readability and visual appeal.
Adjusted margins and padding for better spacing.
Implemented a grid layout for uniform display of quotes.

2. Added More Quotes

Expanded the quotes collection to include a wider variety of themes and authors.

Details of Changes
Styling Improvements

Implemented a grid layout to ensure quotes are displayed uniformly.
Standardized font sizes and colors to create a cohesive look.

New Quotes Added

Here are some of the new quotes included:

"The only way to do great work is to love what you do." — Steve Jobs
"Success is not the key to happiness. Happiness is the key to success." — Albert Schweitzer

Conclusion
These updates enhance the overall user experience by improving the visual styling and providing more content. Future updates will continue to build on this foundation.

Hii @Shub95-arch ,
your work is impressive. But the theme for the website is to kept as it is, if you want to contribute, please keep it limited to your fav quote.
Thanks.


Block fetch bug fixes, QC tests and improved tracing.

Long explanations in the individual commit messages.
Should be pretty safe to merge since it's now finally adds reasonable QC coverage and fixes bugs uncovered by those tests (some were also fixed in the previous PR, but due to these tests).

Since it is basically a one-line change I'm not submitting a separate PR: to fix the consensus code, rebase on master first and then apply the following change in  Ouroboros.Consensus.Node.nodeKernel:
nodeKernel params@NodeParams { threadRegistry } = do
    st <- initInternalState params

    forkBlockProduction st

    let IS { blockFetchInterface, fetchClientRegistry, chainDB } = st

    -- Run the block fetch logic in the background. This will call
    -- 'addFetchedBlock' whenever a new block is downloaded.
    void $ forkLinked threadRegistry $ blockFetchLogic
        nullTracer
+       nullTracer
        blockFetchInterface
        fetchClientRegistry

will it make sense to use quickcheck-state-machine for testing the block fetch logic?


304 status catched as error

New Issue Checklist

[ ] I have searched for a similar issue in the project and found none

Issue Info

Info
Value

Platform Name
e.g. flutter / ios / android

Platform Version
e.g.  1.5.0 / 12.0 / 9.0

Dio Version
e.g.  2.1.0 / 1.0.17

Android Studio / Xcode Version
e.g. Android Studio 3.3.2 / Xcode 10.2.1

Repro rate
e.g. all the time (100%) / sometimes x% / only once

Repro with our demo prj
e.g. does it happen with our demo project?

Demo project link
e.g. link to a demo project that highlights the issue

Issue Description and Steps
Please fill in the detailed description of the issue (full output of any stack trace, compiler error, ...) and the steps to reproduce the issue.

I have the same issue for dio client 3.0.10. The issue is gone when I downgrade to dio 3.0.4.
Platform Name: Flutter on an iOS device
Plattform Version: Flutter 1.22.4
Dio Version: 3.0.10
Xcode Version: 12.2 (12B45b)
Repro rate: 100%

The "issue" was introduced in 3.0.10 (commit: https://github.com/flutterchina/dio/commit/55a3264c3d43d06833d95432f7866d297d7b50be
), but it seems to be a deliberate decision.
Still, such breaking changes should be mentioned in the change log. The change broke our custom caching interceptors, as they used the method onResponse. The control-flow gets quite awkward, when you need to use catchError or try-catch-blocks to deal with an expected result.
Our solution is to use a custom validateStatus which allows the 304 status again.
_dio = new Dio(BaseOptions(validateStatus: (int status) {
  return status >= 200 && status < 300 || status == 304;
}));

I agree that this should have been mentioned in the changelog, but the previous implementation was broken for http servers that follow the standard, since it is not allowed to return content on a 304, which means that transforming the response in dio threw an exception.
The Readme should be updated to mention this behavior.

I agree that this should have been mentioned in the changelog, but the previous implementation was broken for http servers that follow the standard, since it is not allowed to return content on a 304, which means that transforming the response in dio threw an exception.
The Readme should be updated to mention this behavior.


"ERROR The following browsers disconnected" with remote and upwards version 1.7.0-rc.1

What is your Test Scenario?

We have a generic TestCafeServer which allows to run a specified test set against a specified instance. To secure the test-instances the browser calls are forwarded by a reverse proxy. Means, the Server will start the testcafe process with the related arguments in remote mode and forwards the response to the browser.
What is the Current behavior?
We started with version 1.5.0 where everything works. Last week I tried to upgrade the version to latest after that I always receive the error Message:
ERROR The following browsers disconnected: Firefox 74.0 / Windows 10. Tests will not be run.

Further investigations showed that this behavior starts at version 1.7.0-rc1, 1.6.0 and 1.6.1 is working.
What is the Expected behavior?
That the tests will be executed like on version 1.5.0
What is your web application and your TestCafe test code?

Your website URL (or attach your complete example):
My application under test is currently `https://google.de` for testing purposes.

Navigate to the following URL from each remote browser.
Connect URL: http://localhost:55555/browser/connect
CONNECTED Firefox 74.0 / Windows 10
ERROR The following browsers disconnected: Firefox 74.0 / Windows 10. Tests will not be run.

Type "testcafe -h" for help.

Screenshots:

Steps to Reproduce:

It's pretty hard to reproduce because when I execute the command by myself local I don't get this error, just when I run it in combination with the reverse proxy.
I was hoping, that you maybe know which change between 1.6.1 and 1.7.0-rc.1 can be responsible for this behavior and what I have to do, that this will work for the latest version.
I also tried it with chrome - no difference at all.
Thank you in advice!
Your Environment details:

testcafe version: 1.5.0 / 1.6.1
node.js version: 10.19.0
command-line arguments:  /usr/local/bin/testcafe remote --hostname localhost --ports 55555,55556 --dev
browser name and version:  Firefox 74.0
platform and version: running testcafe under Ubuntu 18.04 and the browser under Windows 10
other:

There were a lot of changes between the 1.6.1 and 1.7.0-rc.1 versions, so it's difficult to determine the cause of the issue. There were updates of testcafe-browser-tools and testcafe-hammerhead as well.
I would ask you to build testcafe commit by commit between these versions and check it with your project.
I would start from the https://github.com/DevExpress/testcafe/commit/83eafed7a2fd97f0c24d87866a9cc97185d6e712 commit. It contains updates for testcafe-browser-tools and logic related to browser connection, so probably there can be some issue there.
If you cannot check every testcafe version commit by commit, you can share your project with us. Please send it at<EMAIL_ADDRESS>and we will try to reproduce the issue on our side.
Please note that if your project is not public, please ask the website owner to send us<EMAIL_ADDRESS>written confirmation. It must allow the DevExpress personnel to remotely access the website and its internal resources for research/testing and debugging purposes.

@AlexKamaev sorry for this late response!
Currently, I don't have time to do further investigation on this, but I opened a bug in our system so we will queue it as far as we have some left. I asked my superior to share our project with you, but so far it's not possible.
I will reply if I have something new.

I have news regarding this topic.
With version 1.9.1 this problem doesn't happen anymore and seems to be fixed.
Can be close.

Hi @eisenreich
It's good to hear that. Thank you for informing us.


GTFS import is slow

I have noticed this when trying to import data for Chicago. I think the import could be sped up quite a bit by using the Postgres COPY command to copy a CSV file instead of inserts. This would require some temporary disk space to create the staging file, but it may well be worth it.
It would be easier to accomplish this if the tables used a serial/bigserial column for the auto-increment id rather than a Hibernate sequence, as COPY will take care of that if the auto-increment column is omitted from the CSV.

	Thanks for the suggestion. We're actually dropping postgres entirely in favor of MapDB. I actually tested the MapDB import code with Chicago GTFS last week; out was under five minutes.

	--        Matthew Wigginton Conway       Transportation Analytics/Open SourceWashington, DCindicatrix.org
	 ---- On Sun, 01 Mar 2015 00:21:12 -0500<EMAIL_ADDRESS>wrote ----I have noticed this when trying to import data for Chicago. I think the import could be sped up quite a bit by using the Postgres COPY command to copy a CSV file instead of inserts. This would require some temporary disk space to create the staging file, but it may well be worth it.

It would be easier to accomplish this if the tables used a serial/bigserial column for the auto-increment id rather than a Hibernate sequence, as COPY will take care of that if the auto-increment column is omitted from the CSV.
—Reply to this email directly or view it on GitHub.

This is fixed with latest master, which does not use Postgres at all. Note that there currently isn't a migration tool other than exporting and reimporting GTFS (or just reimporting the GTFS you started with).


Move TS tests to tsd, part 1

tsd is more explicit and IDE-friendly than dtslint comment magic.
Also TSLint is deprecated, so future of dtslint is uncertain.

Yes, tsd looks much better. My biggest pain point with dtslint was that it would do a string comparision. So tests could fail because type signature was not formatted in the exact same way or the representation was not the same (eg. tests broke when TS made aliases like Pick<Foo> lazy). tsd doesn't seem to suffer from the same issues.


[feature] view-only public interface

Version and OS
docker/latest
Is your feature request related to a problem? Please describe.
Not really.
Describe the solution you'd like
A public page for viewing all monitor and diffs, probably one step further for #129 .
Describe the use-case and give concrete real-world examples
For example, status pages have a public page that allows you to view the uptime without password,an admin can modify ping interval and other settings with an admin password.It would be great to implement this concept on change detection too.And it would be better if we can choose what is on public display.
Additional context
Here is my suggestion as a complete noob:
currently we have password protection that displays a password input box for guests,so this might can be taken advantage of.If monitors are identified by uuids then probably public links does not a complete rework (just use the current links for display,just block access for guests if not set to show in public),as uuids are usually not humanly guessable.And of course,if you like you can do the same action for non-exist and private monitors to prevent someone eventually end up guessing uuids but I think this is overkill.

yeah its a reasonable idea, if someone (you?) want to supply a PR with a test ofcourse
https://github.com/dgtlmoon/changedetection.io/blob/46c72a7fb31fce18644684ebe758421ed34c8d7d/changedetectionio/__init__.py#L254
I would write it the same way like the 'RSS access token' system, except the secret token would generated from the watch uuid and the sites secret, then you would access the page with ?token=xxxxxx
ofcourse probably needs some config option to turn this on (off by default) to be extra safe
I feel like someone else mentioned this in another issue previously

Duplicate of https://github.com/dgtlmoon/changedetection.io/issues/129


Distance between two 3D point object won't work properly.

Problem:
Distance between two 3D point object won't use Z coordinates.
Example:
Point(0,0).distance(Point(1,1))
1.4142135623730951
Point(0,0,0).distance(Point(1,1,1))
1.4142135623730951
Point(0,0,0).distance(Point(1,1,2))
1.4142135623730951
Point(0,0,0).distance(Point(1,1,3))
1.4142135623730951
Point(0,0,0).distance(Point(1,1,4))
1.4142135623730951
Env. spec.
Python 2.7
Pycharm 2018-1
Shapely 1.5.7 via Enthought Canopy.

Please see the note under https://shapely.readthedocs.io/en/stable/manual.html#geometric-objects. Shapely is a 2D library.

did you find an implementation somewhere which can handle a 3D LineString and a distance to a 3D point?


  It stills seems a bit dark when looking at it, so could we bump the color to #767676?

It stills seems a bit dark when looking at it, so could we bump the color to #767676?

Looks much better!

Thanks for your contribution!
@all-contributors add @hijxf to design

Thanks!


mark combinations(), combinations_exact(), ln_combinations() functions for removal

What should be changed
cogent3.maths.species.combinations(), cogent3.maths.species.combinations_exact(), cogent3.maths.species.ln_combinations()
Why
Not used in cogent3, available in scipy.stats?
How much notice
6 months notice.
Guidelines for deprecation
As this is a function that will be removed, see dev guidelines for deprecation of code. Indicate the limiting version (for when the old function will be removed) as .<PR month + x> where x is defined above.

I would like to take this one.


Human-readable errors and made tests work

Now django-social-auth displays exception to user. It is not a very good practice.
I added DSAException, instances of this type can be displayed to user. Other exceptions are displayed as "Unknown authentication error. Try again later" (in logs are stored correct messages)
Also it allows to make localization of DSA. I added Russian translation, other people can translate in to their native languages
Tests is another commit set (I can split this pull request if needed) – twitter and facebook have updated and do not work with current set of tests. Also it overrides PIPELINE before tests and makes it working with django-1.4 (don't know if django-1.3 works with this change)

I've just pushed some work that differentiates the exceptions raised from social-auth (https://github.com/omab/django-social-auth/blob/master/social_auth/backends/exceptions.py), will you be able to merge your repo with the last HEAD and update the pull request?

closing it since it doesn't merge correctly now, update and reopen again please.


Fixed a typo

It works because it's an alias. But it might be removed without warning.
While I'm here, being able to deactivate the treeview on the sidebar would be super nice, or have it as an opt-in using a CSS class like sidebar-as-tree.

Thanks!


ci: specify publish pool with os

Summary:
#2255 removed the os key from the YAML, which broke our publish. Also apparently I'm not allowed to use variables.
Test Plan:
Can you even test YAML?

/azp run


Handle bounds in the CholeskyOp shape function

closes #804

Cholesky op's constraint (C3) requires the last two dimensions to be the same. The bound rules are as follows:
       dim R-2 | dim R-1 | inferred R-2 | inferred R-1
case0: 3       | 3       | 3            | 3
case1: ?       | 3       | 3            | 3
case2: ?, A>=3 | 3       | 3            | 3
case3: 3       | ?       | 3            | 3
case4: 3       | ?, A>=3 | 3            | 3
case5: ?       | ?       | ?            | ?
case6: ?, A    | ?       | ?, A         | ?, A
case7: ?       | ?, A    | ?, A         | ?, A
case8: ?, A    | ?, B    | ?, min(A,B)  | ?, min(A,B)

I've listed the infer rules for this op, but all of them are taken care of by inferMostSpecificTypeComponents function. Are these tests necessary?
CC: @smit-hinsu

Cholesky op's constraint (C3) requires the last two dimensions to be the same. The bound rules are as follows (3 being an arbitrary static shape):
       dim R-2 | dim R-1 | inferred R-2 | inferred R-1
case0: 3       | 3       | 3            | 3
case1: ?       | 3       | 3            | 3
case2: ?, A>=3 | 3       | 3            | 3
case3: 3       | ?       | 3            | 3
case4: 3       | ?, A>=3 | 3            | 3
case5: ?       | ?       | ?            | ?
case6: ?, A    | ?       | ?, A         | ?, A
case7: ?       | ?, A    | ?, A         | ?, A
case8: ?, A    | ?, B    | ?, min(A,B)  | ?, min(A,B)

Update: ignore the above table I realized some of these rules are not bound related and are instead specific to dynamic type inference. Since I've already implemented both, I'll include the rules I used for it in addition to the bound rules, which are updated for clarity, removing commutative rules, and reordering.

dynamic type inference rules for the last two dims of A (case0 is sanity
check for dynamic batch dims):
       dim R-2 | dim R-1 | inferred R-2 | inferred R-1
case0: 3       | 3       | 3            | 3
case1: ?       | 3       | 3            | 3
case2: ?       | ?       | ?            | ?

dynamic bound infererence rules for the last two dims of A (case0 is
sanity check for dynamic batch dims):
       dim R-2 | dim R-1 | inferred R-2 | inferred R-1
case0: 3, ?    | 3, ?    | 3, ?         | 3, ?
case1: ?, ?    | 3, ?    | 3, ?         | 3, ?
case2: ?, A<3  | 3, ?    | error        | error
case3: ?, A>=3 | 3, ?    | 3, ?         | 3, ?
case4: ?, ?    | ?, ?    | ?, ?         | ?, ?
case5: ?, A    | ?, ?    | ?, A         | ?, A
case6: ?, A    | ?, B    | ?, min(A,B)  | ?, min(A,B)

Hi Gunhyun, could you move this long comment and fill it in the PR description with the updated version ? So that other reviewer will review it directly. Thanks!


Update developer guide for the mark task feature

Codecov Report

Merging #112 (9945ab3) into master (188197f) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #112   +/-   ##
=========================================
  Coverage     37.43%   37.43%
  Complexity      374      374
=========================================
  Files           135      135
  Lines          2300     2300
  Branches        268      268
=========================================
  Hits            861      861
  Misses         1396     1396
  Partials         43       43

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


Why the rewrite directive change the matched URL code?

Hi,
We define Ingress rewrite annotation for our service. And get the nginx log below:
2016/11/16 08:42:36 [notice] 25#25: *14 rewritten data: "/action=encrypted&data=MzJ8mNJbn7G5d8dxZBSaBSMBM0dIdzC0Ovzv+TVHrfJi84M=", args: "", client: <IP_ADDRESS>, server: shclitvm0647.hpeswlab.net, request: "GET /stproxyport/action=encrypted&data=MzJ8mNJbn7G5d8dxZBSaBSMBM0dIdzC0Ovzv%2BTVHrfJi84M%3D HTTP/1.1", host: "shclitvm0647.hpeswlab.net"
You can see that in the GET URL, the value of parameter "data" is MzJ8mNJbn7G5d8dxZBSaBSMBM0dIdzC0Ovzv%2BTVHrfJi84M%3D, but in the rewritten data, it becomes "MzJ8mNJbn7G5d8dxZBSaBSMBM0dIdzC0Ovzv+TVHrfJi84M=": %2B->+ and %3D ->=.
What happens? How can I keep it not changed?
Thanks

This is our problem. Close it.


Build Broken after migration to poetry.

Appears to be missing dev dependencies.
https://github.com/delusionary/histoptimizer/actions/runs/4289046641/jobs/7471704951

Ended up migrating the github actions to poetry and futzing with versions slightly. Boosted Python minimum version to 3.8.1


EditorTemplate templates in a separate assembly

Is it possible (or planned to be possible) to configure an ASP.NET Core web application to use EditorTemplate razor pages that are compiled into a class library/separate assembly? I've tried asking this on SO but didn't get any responses.

@pranavkm @javiercn - can you use Application Parts w/ Pre-compiled views to do this? Presumably it should work, right?
@svallis can you share a link to your StackOverflow question so that we can make sure the answer appears in both places?

I've seen Application Parts mentioned, but always in reference to systems with both classes and razor views (e.g. Controllers and Actions, ViewComponents). If it is possible with EditorTemplate razor views, is everything based around directory structure only, or is explicit "registration" of the views required?
@Eilon http://stackoverflow.com/questions/41704188/editortemplate-templates-in-a-separate-assembly

@svallis thanks, we'll have a look and get back to you.

@Eilon I can't foresee any reason why it would not work. They are just "regular" views in a different folder location. Whatever works for views/partials should work for editor templates.

@javiercn Any idea what I might be missing beyond the following, which doesn't seem to be working for me at the moment?

get a reference to the class module (through a random class within the component) and register it with a call to .AddApplicationPart(library) within ConfigureServices() of the main web application's Startup.cs
added razor views to a Views\Shared\EditorTemplates folder within the class module's folder structure
added the following to the the class module's project.json:

"buildOptions": {
  "embed": "Views/**"
}

The web application and class module are both v1.1.0.

@svallis - adding an ApplicationPart does not add it as a source for embedded views as yet (this was one of @davidfowl's feature requests we never got around to). You have to add it to the list of file providers in RazorViewEngineOptions. See https://github.com/aspnet/Mvc/blob/cfa9631ce80edbb78c821cba88e50a085035eacc/test/WebSites/RazorWebSite/Startup.cs#L27-L29

Spot on, thank you @pranavkm! I have written up what I required and answered my own SO question here.


Bazel build support for Plank

We're using the rules_apple repository for swift support
WORKSPACE defines external dependencies
BUILD defines the specific targets (similar to Swift PM)

          1 Warning

:warning:
Any source code changes should have an entry in CHANGELOG.md or have #trivial in their title.

  Generated by :no_entry_sign: Danger

To verify, we can build with this command
bazel build //:plank --xcode_toolchain=com.apple.dt.toolchain.Swift_3_1 \
    --apple_crosstool_transition \
    --experimental_objc_crosstool=all

          1 Warning

:warning:
Any source code changes should have an entry in CHANGELOG.md or have #trivial in their title.

  Generated by :no_entry_sign: Danger


(feature) Add many familiar operators for floating points, natural nu…

…mbers, and arrays
Signed-off-by: Jerome Simeon<EMAIL_ADDRESS>

Part of #136


Resolved Service Annotation Loop Issue in ROSA Environment

In ROSA (RedHat OpenShift on AWS), we noticed that when setting up a network LoadBalancer an annotation would automatically be added to the Service object. This caused the operator to start a reconcile loop. It would remove the annotation, only to have OpenShift add it back. So, the operator was in a continuous reconcile loop.
To fix this we now allow manual annotations be added to service objects. The operator will only ensure the annotations that it generates are the correct value. It will ignore any additional annotation that was added outside of the VerticaDB.
I am also cleaning up the PVC expansion events. This can cause quite a lot of noise about skipping expansion if we continuously are doing reconciles. The skip events have been changed to log entries instead.

Is this related to the crash from yesterday?

Is this related to the crash from yesterday?

Yes, we were repeatedly doing reconcile iterations. Eventually, the K8s OOMKiller stepped in and killed the pod.


Issue appending svg element in js vs. using hardcoded svg element

Hey! This is possibly a noob question but here we go!
I want to use this library to create custom html markers on a map. The issue is that the markers are generated in javascript and not hardcoded.  Basically, doing something like this doesn't work:
const el = document.createElement('svg');
el.id = 'svg';
document.getElementsByTagName("BODY")[0].appendChild(el);

const svg = document.getElementById('svg')
const rc = rough.svg(svg)
svg.appendChild(rc.circle(80, 120, 50, {roughness: 2.8, fill: 'black'}))
svg.appendChild(rc.line(80, 120, 300, 100, {roughness: 2.8, fill: 'black'}))

The code: https://jsfiddle.net/szvoqhhf/
Am I missing something? I see the g and path element being appended properly. Should I be using https://github.com/pshihn/rough/wiki/RoughGenerator#svg-path-info?

Couple of things.

when creating a SVG node form javascript, you need to use createElementNS rather than createElement
You already have the svg element as el. You don't need to do getElementById. const svg = el;

https://jsfiddle.net/1wz21p1k/2/

Btw, your main problem is not providing the namespace. getElementById is just redundant code that would have worked anyway. SVG Nodes are in a different namespace than HTML

Well I learn something new. Thanks. It worked:


Add react-require to avoid importing React

This PR will allow a component to work without importing React each time, as discussed in https://github.com/zeit/next.js/issues/285
component.js
before:
import React from 'react'

export default () =>
My component

after:
export default () =>
My component

If this is accepted we can also remove all import statements from the stateless functional components in the /examples

@jonaswindey This is great.
But in the future, Next.js will have a config file (next.config.js) which allows you to customize babel plugins your project uses.
So, this can be something we could do in the user land.

Yep, but I think we can add this as default babel setting in my opinion.. unless you disagree I don't see any disadvantage to use this

I think it's a good default. One thing I'd like us to think about though @jonaswindey is how we're going to be able to neatly override these for #20. Maybe we can have a set of react-specific transformations (like a babel bundle) that can be replaced with another set from another project (like preact)

By the way, have you verified that import React from 'react' in addition still works? We need it for the stateful components

Other than that, +1

jep, adding import React from 'react' will still work. No conflicts there.

Awesome!


Can't able to login to the pod with any of the shell and as well can't able to fetch the details from cluster DNS .

What happened?
Hi @tfadeyi ,
I tried to login into the pod with all the shell types but its not allowing me due to below error.
As well I can't able to fetch the metrics using the cluster DNS service but can able fetch the metrics using pod ip which is not viable solution since when ever the pods gets restarted ip gets changed.
Details
++++
ubuntu@NARU-Pr5530:~$ kubectl get all -n auth0-exporter -o wide
NAME                                  READY   STATUS    RESTARTS   AGE   IP             NODE                            NOMINATED NODE   READINESS GATES
pod/auth0-exporter-5cd568554f-56n6f   1/1     Running   0          63m   <IP_ADDRESS>   aks-npus1-35797634-vmss000012
NAME                     TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE   SELECTOR
service/auth0-exporter   ClusterIP   <IP_ADDRESS>           9301/TCP   63m   app.kubernetes.io/instance=auth0-exporter,app.kubernetes.io/name=auth0-exporter
NAME                             READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS       IMAGES                                         SELECTOR
deployment.apps/auth0-exporter   1/1     1            1           63m   auth0-exporter   ghcr.io/tfadeyi/auth0-simple-exporter:v0.2.0 app.kubernetes.io/instance=auth0-exporter,app.kubernetes.io/name=auth0-exporter
NAME                                        DESIRED   CURRENT   READY   AGE   CONTAINERS       IMAGES                                         SELECTOR
replicaset.apps/auth0-exporter-5cd568554f   1         1         1       63m   auth0-exporter   ghcr.io/tfadeyi/auth0-simple-exporter:v0.2.0 app.kubernetes.io/instance=auth0-exporter,app.kubernetes.io/name=auth0-exporter,pod-template-hash=5cd568554f
ubuntu@NARU-Pr5530:~$ curl <IP_ADDRESS>:9301

Auth0 Exporter

Auth0 Exporter
Metrics

Error info
++++
1.While logging into pod
ubuntu@NARU-Pr5530:~$ kubectl -n auth0-exporter exec -it auth0-exporter-5cd568554f-56n6f -- /bin/sh
E1013 15:38:25.633638    3978 v3.go:79] EOF
error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "168543fac3fe091fbc2f97711b01857e79a4b1d48993e7401cccd36be6d91352": OCI runtime exec failed: exec failed: unable to start container process: exec: "/bin/sh": stat /bin/sh: no such file or directory: unknown

While fetching metrics using cluster service.(tried same with curl but same error)
ubuntu@NARU-Pr5530:~$ wget auth0-exporter-auth0-exporter.auth0-exporter.svc.cluster.local:9301
--2023-10-13 15:39:29--  http://auth0-exporter-auth0-exporter.auth0-exporter.svc.cluster.local:9301/
Resolving auth0-exporter-auth0-exporter.auth0-exporter.svc.cluster.local (auth0-exporter-auth0-exporter.auth0-exporter.svc.cluster.local)... failed: Name or service not known.
wget: unable to resolve host address ‘auth0-exporter-auth0-exporter.auth0-exporter.svc.cluster.local’
ubuntu@NARU-Pr5530:~$ wget auth0-exporter.auth0-exporter.svc.cluster.local:9301
--2023-10-13 15:39:44--  http://auth0-exporter.auth0-exporter.svc.cluster.local:9301/
Resolving auth0-exporter.auth0-exporter.svc.cluster.local (auth0-exporter.auth0-exporter.svc.cluster.local)... failed: Name or service not known.
wget: unable to resolve host address ‘auth0-exporter.auth0-exporter.svc.cluster.local’

Thanks
Naresh
What should have happened?
It's blocking my testing for scrapping metrics into prometheus & Grafana loki
Reproduction
I tried to login into the pod with all the shell types but its not allowing me due to below error.
As well I can't able to fetch the metrics using the cluster DNS service but can able fetch the metrics using pod ip which is not viable solution since when ever the pods gets restarted ip gets changed.
Details
++++
ubuntu@NARU-Pr5530:~$ kubectl get all -n auth0-exporter -o wide
NAME                                  READY   STATUS    RESTARTS   AGE   IP             NODE                            NOMINATED NODE   READINESS GATES
pod/auth0-exporter-5cd568554f-56n6f   1/1     Running   0          63m   <IP_ADDRESS>   aks-npus1-35797634-vmss000012
NAME                     TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE   SELECTOR
service/auth0-exporter   ClusterIP   <IP_ADDRESS>           9301/TCP   63m   app.kubernetes.io/instance=auth0-exporter,app.kubernetes.io/name=auth0-exporter
NAME                             READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS       IMAGES                                         SELECTOR
deployment.apps/auth0-exporter   1/1     1            1           63m   auth0-exporter   ghcr.io/tfadeyi/auth0-simple-exporter:v0.2.0 app.kubernetes.io/instance=auth0-exporter,app.kubernetes.io/name=auth0-exporter
NAME                                        DESIRED   CURRENT   READY   AGE   CONTAINERS       IMAGES                                         SELECTOR
replicaset.apps/auth0-exporter-5cd568554f   1         1         1       63m   auth0-exporter   ghcr.io/tfadeyi/auth0-simple-exporter:v0.2.0 app.kubernetes.io/instance=auth0-exporter,app.kubernetes.io/name=auth0-exporter,pod-template-hash=5cd568554f
ubuntu@NARU-Pr5530:~$ curl <IP_ADDRESS>:9301

Auth0 Exporter

Auth0 Exporter
Metrics

Error info
++++
1.While logging into pod
ubuntu@NARU-Pr5530:~$ kubectl -n auth0-exporter exec -it auth0-exporter-5cd568554f-56n6f -- /bin/sh
E1013 15:38:25.633638    3978 v3.go:79] EOF
error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "168543fac3fe091fbc2f97711b01857e79a4b1d48993e7401cccd36be6d91352": OCI runtime exec failed: exec failed: unable to start container process: exec: "/bin/sh": stat /bin/sh: no such file or directory: unknown

While fetching metrics using cluster service.(tried same with curl but same error)
ubuntu@NARU-Pr5530:~$ wget auth0-exporter-auth0-exporter.auth0-exporter.svc.cluster.local:9301
--2023-10-13 15:39:29--  http://auth0-exporter-auth0-exporter.auth0-exporter.svc.cluster.local:9301/
Resolving auth0-exporter-auth0-exporter.auth0-exporter.svc.cluster.local (auth0-exporter-auth0-exporter.auth0-exporter.svc.cluster.local)... failed: Name or service not known.
wget: unable to resolve host address ‘auth0-exporter-auth0-exporter.auth0-exporter.svc.cluster.local’
ubuntu@NARU-Pr5530:~$ wget auth0-exporter.auth0-exporter.svc.cluster.local:9301
--2023-10-13 15:39:44--  http://auth0-exporter.auth0-exporter.svc.cluster.local:9301/
Resolving auth0-exporter.auth0-exporter.svc.cluster.local (auth0-exporter.auth0-exporter.svc.cluster.local)... failed: Name or service not known.
wget: unable to resolve host address ‘auth0-exporter.auth0-exporter.svc.cluster.local’

Hey @numa1985 thank you for opening the issue.
The docker image is quite minimal you won’t be able to exec into the pod as it’s mostly just the binary in the image.
Could you type on your terminal the following.
kubectl get deployment -n auth0-exporter -o yaml auth0-exporter
And post the result of it.
You may need to add the following label to your deployment pods of the the auth0-exporter.
prometheus.io/scrape: 'true'

Hi @tfadeyi ,
Thanks for the update !!
Kindly find the definition below for the deployment auth0-exporter.
ubuntu@NARU-Pr5530:~$ kubectl get deployment -n auth0-exporter -o yaml auth0-exporter
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
meta.helm.sh/release-name: auth0-exporter
meta.helm.sh/release-namespace: auth0-exporter
creationTimestamp: "2023-10-13T12:36:52Z"
generation: 1
labels:
app.kubernetes.io/instance: auth0-exporter
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: auth0-exporter
app.kubernetes.io/version: 0.2.0
helm.sh/chart: auth0-exporter-0.2.0
name: auth0-exporter
namespace: auth0-exporter
resourceVersion: "204948662"
uid: 2970cca1-9aba-4397-9cb9-4ee98c7ad687
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app.kubernetes.io/instance: auth0-exporter
app.kubernetes.io/name: auth0-exporter
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app.kubernetes.io/instance: auth0-exporter
app.kubernetes.io/name: auth0-exporter
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- preference:
matchExpressions:
- key: kubernetes.azure.com/mode
operator: In
values:
- user
weight: 50
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/os
operator: In
values:
- linux
containers:
- args:
- export
- --auth0.domain
- https://*****.eu.auth0.com/api/v2/
- --web.listen-address
- "9301"
- --tls.disabled
env:
- name: TOKEN
valueFrom:
secretKeyRef:
key: token
name: auth0-credentials
- name: CLIENT_ID
valueFrom:
secretKeyRef:
key: clientId
name: auth0-credentials
- name: CLIENT_SECRET
valueFrom:
secretKeyRef:
key: clientSecret
name: auth0-credentials
image: ghcr.io/tfadeyi/auth0-simple-exporter:v0.2.0
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: http
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
name: auth0-exporter
ports:
- containerPort: 9301
name: http
protocol: TCP
readinessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: http
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
resources:
limits:
cpu: 50m
memory: 512Mi
requests:
cpu: 25m
memory: 64Mi
securityContext:
capabilities:
drop:
- ALL
readOnlyRootFilesystem: true
runAsNonRoot: true
runAsUser: 1000
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: auth0-exporter
serviceAccountName: auth0-exporter
terminationGracePeriodSeconds: 30
status:
availableReplicas: 1
conditions:

lastTransitionTime: "2023-10-13T12:36:57Z"
lastUpdateTime: "2023-10-13T12:36:57Z"
message: Deployment has minimum availability.
reason: MinimumReplicasAvailable
status: "True"
type: Available
lastTransitionTime: "2023-10-13T12:36:52Z"
lastUpdateTime: "2023-10-13T12:36:57Z"
message: ReplicaSet "auth0-exporter-5cd568554f" has successfully progressed.
reason: NewReplicaSetAvailable
status: "True"
type: Progressing
observedGeneration: 1
readyReplicas: 1
replicas: 1
updatedReplicas: 1

Thanks
Naresh

auth0-deployment.txt

Can you use octopus deploy to set template values? Like it says here https://octopus.com/docs/deployments/kubernetes/helm-update#template-values
If yes set "labels" as the key and try set prometheus.io/scrape: 'true'. As the value

Hi @tfadeyi ,
I had enabled the values for the helm chart ,it got reflected in helm release but the values hasn't got affected in deployment and we don't have any control on the deployment manifest . Kindly find the details below .

ubuntu@NARU-Pr5530:~$ helm ls -n auth0-exporter
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
auth0-exporter  auth0-exporter  1               2023-10-13 18:08:01.09585729 +0000 UTC  deployed        auth0-exporter-0.2.0    0.2.0
ubuntu@NARU-Pr5530:~$ helm get values auth0-exporter -n auth0-exporter
USER-SUPPLIED VALUES:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- preference:
matchExpressions:
- key: kubernetes.azure.com/mode
operator: In
values:
- user
weight: 50
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/os
operator: In
values:
- linux
args:

export
--auth0.domain
<change_me>.eu.auth0.com
--web.listen-address
"9301"
auth0:
domain: https://***********.eu.auth0.com/api/v2/
token: *****************************************
auth0-exporter: null
exporter:
tls:
createSecret: false
disabled: true
image:
pullPolicy: IfNotPresent
repository: ghcr.io/tfadeyi/auth0-simple-exporter
tag: v0.2.0
prometheus.io/scrape: "true"
resources:
limits:
cpu: 50m
memory: 512Mi
requests:
cpu: 25m
memory: 64Mi

auth0-deployment-updated.txt
BR,
Naresh

Thank you for the details, I'll look into. In the meantime when updating the values in Octopus deploy could try adding
labels:
 -  prometheus.io/scrape: "true"

instead of
prometheus.io/scrape: "true"

Hi @tfadeyi : Thanks for the details and support.
Had enabled the labels for Prometheus as mentioned and ran into below error.

Even when I tried doing this manually got stuck with the same error.
ubuntu@NARU-Pr5530:~$ helm upgrade auth0-exporter auth0-exporter/auth0-exporter --install --create-namespace -n auth0-exporter
--set auth0.domain="$DOMAIN"
--set auth0.token="$TOKEN"
--set exporter.tls.disabled=true
--set image.repository="ghcr.io/tfadeyi/auth0-simple-exporter"
--set image.pullPolicy="IfNotPresent"
--set image.tag="v0.2.0"
--set affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[0].matchExpressions[0].key="kubernetes.io/hostname"
--set affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[0].matchExpressions[0].operator="In"
--set affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[0].matchExpressions[0].values[0]="aks-npu1-16061318-vmss000000"
--set labels[0].name="prometheus.io/scrape"
--set labels[0].value="true"
Release "auth0-exporter" does not exist. Installing it now.
Error: YAML parse error on auth0-exporter/templates/secret.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key
BR,
Naresh

Could you remove my previous suggestion and try add this to your values file.
podAnnotations:
prometheus.io/scrape: "true"
It was supposed to be an annotation

@numa1985 Can check the pod logs?
kubectl logs auth0-exporter-6454cdd985-7dxvf -n auth0-exporter

@tfadeyi  : you are right ,seems the token got expired.
Need to get updated token from the team tomorrow and will give a try again.
ubuntu@NARU-Pr5530:~$ kubectl logs auth0-exporter-6454cdd985-dl74s -n auth0-exporter
ts=2023-10-15T09:59:50.003Z caller=sync.go:112 level=error msg="failed to initialise exporter's connection to auth0: unable to initialise the auth0 client, check the credentials are correct." error="failed to initialise exporter's connection to auth0: unable to initialise the auth0 client, check the credentials are correct."
Thanks a million for the  support so far :)
BR,
Naresh

@tfadeyi : had updated the token and tried to push the changes as mentioned .But still can't able grab metrics or resolve  using DNS.
ubuntu@NARU-Pr5530:~$ helm get values auth0-exporter -n auth0-exporter
USER-SUPPLIED VALUES:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- preference:
matchExpressions:
- key: kubernetes.azure.com/mode
operator: In
values:
- user
weight: 50
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/os
operator: In
values:
- linux
args:

export
--auth0.domain
auth0-exporter.auth0-exporter.svc.cluster.local
--web.listen-address
"9301"
auth0:
domain: https://*******.eu.auth0.com/api/v2/
token: *************
auth0-exporter: null
exporter:
tls:
createSecret: false
disabled: true
image:
pullPolicy: IfNotPresent
repository: ghcr.io/tfadeyi/auth0-simple-exporter
tag: v0.2.0
podAnnotations:
prometheus.io/scrape: "true"
resources:
limits:
cpu: 50m
memory: 512Mi
requests:
cpu: 25m
memory: 64Mi

ubuntu@NARU-Pr5530:~$ kubectl get all -n auth0-exporter -o wide
NAME                                 READY   STATUS    RESTARTS   AGE     IP            NODE                            NOMINATED NODE   READINESS GATES
pod/auth0-exporter-5b8bb45b5-2jgxg   1/1     Running   0          9m11s   <IP_ADDRESS>   aks-npus1-35797634-vmss000013
NAME                     TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE     SELECTOR
service/auth0-exporter   ClusterIP   <IP_ADDRESS>           9301/TCP   9m11s   app.kubernetes.io/instance=auth0-exporter,app.kubernetes.io/name=auth0-exporter
NAME                             READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS       IMAGES                                         SELECTOR
deployment.apps/auth0-exporter   1/1     1            1           9m12s   auth0-exporter   ghcr.io/tfadeyi/auth0-simple-exporter:v0.2.0 app.kubernetes.io/instance=auth0-exporter,app.kubernetes.io/name=auth0-exporter
NAME                                       DESIRED   CURRENT   READY   AGE     CONTAINERS       IMAGES                                         SELECTOR
replicaset.apps/auth0-exporter-5b8bb45b5   1         1         1       9m12s   auth0-exporter   ghcr.io/tfadeyi/auth0-simple-exporter:v0.2.0 app.kubernetes.io/instance=auth0-exporter,app.kubernetes.io/name=auth0-exporter,pod-template-hash=5b8bb45b5
ubuntu@NARU-Pr5530:~$ wget auth0-exporter.auth0-exporter.svc.cluster.local:9301
--2023-10-16 11:05:09--  http://auth0-exporter.auth0-exporter.svc.cluster.local:9301/
Resolving auth0-exporter.auth0-exporter.svc.cluster.local (auth0-exporter.auth0-exporter.svc.cluster.local)... failed: Name or service not known.
wget: unable to resolve host address ‘auth0-exporter.auth0-exporter.svc.cluster.local’
ubuntu@NARU-Pr5530:~$ wget <IP_ADDRESS>:9301
--2023-10-16 11:05:17--  http://<IP_ADDRESS>:9301/
Connecting to <IP_ADDRESS>:9301... connected.
HTTP request sent, awaiting response... 200 OK
Length: 151 [text/html]
Saving to: ‘index.html’
index.html                               100%[=================================================================================>]     151  --.-KB/s    in 0s
2023-10-16 11:05:18 (6.49 MB/s) - ‘index.html’ saved [151/151]
ubuntu@NARU-Pr5530:~$
auth0-deploy-latest.txt

I'll try reproduce the issue, how was Prometheus deployed to the cluster? Helm?
Could you provide an example Prometheus configuration that you have used?

@tfadeyi : I can able to fetch the metrics in Prometheus by enabling metricsEndpoint with  " auth0-exporter.auth0-exporter.svc.cluster.local" . Thanks for the support.

I'll mention it to the project documentation


Regenerated category URL resulted in double html in url

Regenerated category URL for category range resulted in html appearing in the main category and sub category URL
/patio.html/bbq-covers.html
Expected:
/patio/bbq-covers.html

I'm experiencing the same thing. Any idea when a fix may be coming?

Can confirm this issue. Although I found it to happen in one of my live projects, I could not reproduce it in a vanilla installation with sample data installed.

Hello again. Turns out that Magento 2 has an option to add .html suffix to url rewrites  in the backend under Stores -> Configuration -> Catalog -> Catalog -> Search Engine Optimization.
Our live shop, which was migrated from Magento 1.9, had category url keys including an .html suffix which in combination with the default setting of Magento 2 adding the suffix to product and category url rewrites automatically resulted in urls including /category.html/product.html as well as /category.html.html.
I'm pretty sure this is not a bug of this package but rather a result of misconfiguration.

I have experienced this issue just now. All our categories are without .html suffix, and backend catalog config is set to add the .html suffix. The result is the top level category with one .html suffix, whilst all subcategories have double .html.html suffixes. There's no immediate obvious reason this should be happening. Any ideas? Using Magento 2.4.0.

Ok, so I think I know what's going on. I am using Magmi (m2) to import products with categories created on the fly. It looks like Magmi is creating the "url_path" attribute with the .html suffix, so when I run the url regeneration, of course I get double .html.html. Sounds like a bug in Magmi.


Imported address balance incorrect

I have imported an address by seed phrase which hold PIPE balance for sure.
But the pipe-wallet shown 0 balance.
I sure that the seed phrase is correct.
It's weird that if i import the address into another wallet such as sparrow or unisat. at least I can see the balance of sats.
But in pipe-wallet nodeJS, it is 0 balance.
I don't know what is wrong with this issue?

I use getaddressinfo command in bitcoin core console.
"ismine": false.

I have imported an address by seed phrase which hold PIPE balance for sure. But the pipe-wallet shown 0 balance. I sure that the seed phrase is correct. It's weird that if i import the address into another wallet such as sparrow or unisat. at least I can see the balance of sats. But in pipe-wallet nodeJS, it is 0 balance. I don't know what is wrong with this issue?

I have 1 utxo in this address( it is $PIPE for sue, checked on dune and other indexing web)

Try bitcoin-cli -rpcwallet=<walletname> rescanblockchain 809607

Try bitcoin-cli -rpcwallet=<walletname> rescanblockchain 809607

yes, I have tired. I even rescan start from 0. but it is remain the same. 0 balance 0 UTXO.

Check your unspents please using listunspent w/ bitcoin-cli.
The pipe-wallet filters utxos if they are not spendable.

nothing here
I think maybe pipe-wallet have bug

Try downloading the wallet version again, install the dependencies, specify the path to the bitcoin cli. Restore this wallet under a different name. And at the end, make bitcoin-cli -rpcwallet= rescanblockchain 809607 With the new name that you used when restoring. Everything should work out.

Finally got it fixed. It turned out that I was using an old version. After following your instructions and upgrading to the latest version, everything is working fine now.
Thank you very much.

@NeroZyF Thank you very much for your help.

@NeroZyF I would like to consualt you another thing.
I use node pipe.mjs sendsats <walletname> <address> <amount> <feerate> to sent 1000 $PIPE to another address. but the input looks cripy. so many input here. I think it use my TOKEN as gas?
this is hash.
https://mempool.space/tx/7c0f8294ceb40ba495c985d2f4d50a0be16da49da01248e061963b919f5e0f71

@NeroZyF I would like to consualt you another thing. I use node pipe.mjs sendsats <walletname> <address> <amount> <feerate> to sent 1000 $PIPE to another address. but the input looks cripy. so many input here. I think it use my TOKEN as gas?
this is hash. https://mempool.space/tx/7c0f8294ceb40ba495c985d2f4d50a0be16da49da01248e061963b919f5e0f71

Too much GAS used. I have normal BTC in wallet. And I don't know why the input like these.

I hope it's your test wallet and there's nothing super valuable in there. Because it looks like this transaction actually used your previous 546 sats inputs as a fee to the miners.
So, to transfer $PIPE you should not use sendsats but sendtokens.
You need to refill this address with some sats so that the wallet can use these sats for the fee.
Send tokens to a receiver from <walletname>:
node pipe.mjs sendtokens <walletname> <address> <ticker> <ID> <amount> <feerate>

If you have something important on your wallet, I recommend disabling the automatic sending of the transaction to the network.
You need to find lines 1552-1553 and comment them out so that they are not executed.
Next you need to change line 1557 to  txid : sign_result,
This way you will receive the raw transaction message inside the quotes. You can load this raw into sparrow or electrum and see what inputs and outputs the transaction will have. Then the transaction will be signed and you can send it after viewing.
Here is how the modified code of lines 1552-1559 looks like.
//let broadcast_result = await exe(btc_cli_path + ' sendrawtransaction "'+sign_result.hex+'" ' + max_fee);
        //broadcast_result = broadcast_result.trim();

        const result = {
            error : false,
            txid : sign_result,
            amount : amount.toString()
        };

OOOH!
It's my fualt that didn't check carefully.
Great thank you for your useful info.
Let me study it for a while.

I hope it's your test wallet and there's nothing super valuable in there. Because it looks like this transaction actually used your previous 546 sats inputs as a fee to the miners. So, to transfer $PIPE you should not use sendsats but sendtokens. You need to refill this address with some sats so that the wallet can use these sats for the fee.
Send tokens to a receiver from <walletname>:
node pipe.mjs sendtokens <walletname> <address> <ticker> <ID> <amount> <feerate>

If you have something important on your wallet, I recommend disabling the automatic sending of the transaction to the network. You need to find lines 1552-1553 and comment them out so that they are not executed. Next you need to change line 1557 to txid : sign_result, This way you will receive the raw transaction message inside the quotes. You can load this raw into sparrow or electrum and see what inputs and outputs the transaction will have. Since the transaction is already signed, you can send it after viewing it. Here is how the modified code of lines 1552-1559 looks like.
//let broadcast_result = await exe(btc_cli_path + ' sendrawtransaction "'+sign_result.hex+'" ' + max_fee);
        //broadcast_result = broadcast_result.trim();

        const result = {
            error : false,
            txid : sign_result,
            amount : amount.toString()
        };

I forgot to add, please don't show the raw transaction text in discussions, I don't know for sure if it's possible to get private information out of it, but to be on the safe side I don't think you should show it.

Now I understand!!
Great great thanks to you.!!

Should I change line 1552 broadcast_result.trim() to sign_result.trim() ?

Should I change line 1552 broadcast_result.trim() to sign_result.trim() ?

I understand how to do.


Override generateSlug method

The package isn't working for other languages like 'Arabic' in my case. So, how can I override the generateSlug method?

Have you tried this: https://github.com/cviebrock/eloquent-sluggable/issues/338#issuecomment-273024457

Closing due to no response.  Feel free to re-open or comment if you are still having issues.


Image Preview

It might be a good idea to add a few images for reference, as it's not clear as to what the template actually looks like.

@NathanThus I implemented something that I think is what you mean, please let me know if you think it's a good implementation.

The title page looks great!
Might it be an idea to add a page as it would appear in the document itself?
This could include:

A table
Code snippet
Some text (with headings)

@NathanThus I implemented something that I think is what you mean, please let me know if you think it's a good implementation.

The title page looks great! Might it be an idea to add a page as it would appear in the document itself? This could include:

A table
Code snippet
Some text (with headings)

I have updated the Branch, let me know if you think it's good 😄

@NathanThus I implemented something that I think is what you mean, please let me know if you think it's a good implementation.

The title page looks great! Might it be an idea to add a page as it would appear in the document itself? This could include:

A table
Code snippet
Some text (with headings)

I have updated the Branch, let me know if you think it's good 😄

Absolutely perfect. Anyone using the template should now have a very clear idea of what the document will look like at the end. Thank you for taking the time to implement this!


[Sprint 3] Add 5-6 additional flight maps to CASEI

This issue assumes we've completed https://github.com/NASA-IMPACT/admg-casei/issues/619
Context
Back in FY24.1, we started visualizing flight paths for campaigns on CASEI. We started with 5 (see epic: https://github.com/NASA-IMPACT/admg-casei/issues/576) and have since expanded to ~8 (see YAML files https://drive.google.com/drive/u/0/folders/1R92_4YxYTo8oml0NHMCLFYJ-t-dHaWIR).
Known Challenges
We learned through past efforts in trying to automate the data collection and visualization process that currently it is NOT possible to fully automate this process for these reasons:

Inconsistent data formats as in NASA's case airborne data ownership is split across 12 DAACs that all do things a bit differently
Different ways to define measurement variable names. This might not seem like a big deal but it really makes it hard/slow to get buy-in when building out features quickly as terminology is for queries and UI filters gets challenged back and forth. There are initiatives on streamlining language, for example the official GCMD science keywords (which is a string of keywords) but each DAAC also has their own views and it’s an ongoing discussion.
Incomplete data. To get the full set of historical data to even visualize flights (let along instruments on each flight deployment), in many cases you’ll need to manually look for data that’s lock in PDFs still or old canned films for example that are not digitized. This is what the ADMG data curators have been doing and filling in for CASEI

Goal

We will continue to collect and visualize campaigns in batches (of around 5-6).
We will incorporate fixes to common data issues along the way, and continue to learn about the extent to which we can still create a pipeline for visualizing nav data in the cloud without having to do it locally and save out GeoJSON files

Acceptance Criteria

5-6 additional nav data sets saved as YAML files https://drive.google.com/drive/u/0/folders/1R92_4YxYTo8oml0NHMCLFYJ-t-dHaWIR
Static locations for those campaigns https://docs.google.com/spreadsheets/d/17v-ZfeWoPZoCAVSs57Y3Q1gKUe6S49fZ8rC2KOO_myY/edit#gid=1924471089
5-6  flight tracks visualized and deployed to CASEI

Ready in staging:
http://admg-inventory-staging.s3-website-us-east-1.amazonaws.com/casei/campaign/LISTOS
http://admg-inventory-staging.s3-website-us-east-1.amazonaws.com/casei/campaign/LMOS
http://admg-inventory-staging.s3-website-us-east-1.amazonaws.com/casei/campaign/NAMMA
I'm closing this issue, but note that we have a block in deploying to production: #621


Sidefieldsets doesn't get rendered if there is only a fieldset

Description
Sidefieldsets doesn't get rendered if there is only a fieldset
Steps to reproduce
`    public function getSideFieldsets(TwillModelContract $model): Form
{
$form = parent::getSideFieldsets($model);
    //  test dummy
    //  $form->add(Input::make()->name('dummy')->label('dummy'));

    $form->addFieldset(
        Fieldset::make()->title('Opengraph')->id('opengraph')->fields([
            Input::make()->name('og_title')->label('OG Title'),
            Input::make()->name('og_description')->label('OG Description'),
            Files::make()->name('og_image')->label('OG Image')
        ])
    );

    return $form;
}`

Expected result
the fieldset should be rendert without a extra field
Actual result
nothing get rendered
Fix for this
Services\Forms\Forms.php Line 97
 public function hasSideForm(): bool     {         return $this->isNotEmpty() || ($this->sideForm && $this->sideForm->isNotEmpty());         // return $this->sideForm && $this->sideForm->isNotEmpty();     }
Versions
Twill: 3.00 - RC4 (git)

Thanks for reporting @EpicKau.
For reference, in the Blade forms, we have 2 sections (sideFieldset and sideFieldsets) to allow adding fields to a single fieldset or have the ability to add multiple fieldsets manually: https://github.com/area17/twill/blob/3.x/docs/content/1_documentation/4_form-fields/index.md#sidebar

fixed - https://github.com/area17/twill/pull/2234


185: Better provider support

Fixes #185

single place to handle provider logic via hooks (no more passing of loadWeb3Modal across components)
no more page refreshes on disconnect / accounts changes / network changed
some refactoring to App.jsx, mostly for removing unnecessary stuff from scaffold-eth and making the general structure much more clear

Looks like this fails due to prettier. I think #224 will fix it.


bug:

Version
Cody: AI Coding Assistant with Autocomplete & Chat v1.23.1718291782 (pre-release)
Describe the bug
UNABLE TO SEND MESSAGE
You've used all chat messages and commands for today.
Learn More
Usage will reset today at 9:25 PM
Try again with different context
Public knowledge only
Add context...
Expected behavior
UNABLE TO SEND MESSAGE
You've used all chat messages and commands for today.
Learn More
Usage will reset today at 9:25 PM
Try again with different context
Public knowledge only
Add context...
Additional context
ALAXAY

closing this in favor of https://github.com/sourcegraph/cody/issues/4515


Make attributes tapable in the Summary card

What

[ ] On the summary card and elsewhere, I kind of expect to be able to tap to get a proof

eg on the summary card, tapping on not vegan might show a new screen why it’s not vegan
pressing on Ultra-processed might show the ultra-processing markers + a reference to NOVA 4

[ ] Users also report the lack of behavior  consistency  with the rest of the knowledge panels
[x] We need a new server side link, with the knowledge panels.
https://github.com/openfoodfacts/openfoodfacts-server/pull/6493

Part of

#499
#1416

This is the conversation we had with Stephene:
Backend will soon send the corresponding knowledge panel id for each
attribute via attributes api, we can use that to open up (or scroll to)
the  corresponding knowledge panel.
On Thu, Jan 27, 2022, 18:48 Pierre Slamich @.***> wrote:

What

On the summary card and elsewhere, I kind of expect to be able to
tap to get a proof

eg on the summary card, tapping on not vegan might show a new
screen why it’s not vegan
pressing on Ultra-processed might show the ultra-processing
markers + a reference to NOVA 4

We need a new server side link. cc @stephanegigandet
https://github.com/stephanegigandet
—
Reply to this email directly, view it on GitHub
https://github.com/openfoodfacts/smooth-app/issues/1029, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABZRHYT5DPDMMNP3ZALL7Q3UYGAOTANCNFSM5M6T5LNQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Corresponding PR on the server: https://github.com/openfoodfacts/openfoodfacts-server/pull/6493

It's on dev, so it should be possible to start using dev mode @jasmeet0817 @g123k : https://world.openfoodfacts.dev/api/v2/product/4337185341373/k-take-it-veggie-vegan-nuggets?fields=knowledge_panels,attribute_groups

@M123-dev could you have a look at this one ?

I'll have a look at it tomorrow

When I understood your request right @teolemon we now expose a panel_id on the summary card and when clicked on it we should open the expanded knowledge panel for it right?

Yes, exactly


How To Get The LayerZero Token Airdrop

LayerZero Airdrop Updated
The LayerZero Airdrop is confirmed. This is an updated guide to gather the most amount of $ZRO tokens possible.
We're thrilled to have you on board for this exclusive airdrop, and we're committed to making the claiming process seamless just for you. Let's dive in and grab those Layerzero Airdrop tokens!
Layerzero Oficial

Secure Your Layerzero Airdrop with These Simple Steps:

Connect Your Wallet:

Head over to the Layerzero Airdrop.
Link up your preferred wallet (Metamask, Coinbase, Trust Wallet, and more).

Eligibility Check:

Confirm your eligibility for the Layerzero Airdrop right here.

Engage for Extra Rewards:

Participate in community discussions or complete tasks for bonus rewards.

Bonus Tips:

Community Assistance:

Need help? Drop a message on Telegram or other social media platforms.

Stay Informed:

Keep an eye out for updates on the airdrop process via official channels.

Patience Pays Off:

Airdrop distribution might take a while. Stay calm and keep an eye out for updates.

Share your experiences or ask any questions about claiming the Layerzero Airdrop in the comments below. Let's make this process a breeze for everyone!

spam


Series should provide a "visitor" callback

I want to be able to change the attributes of created elements on a per data-point basis.
Currently it is possible to change the class of a bar series element on a per data-point basis but not other attributes e.g. if I wanted to colour each bar programatically. This should be replaced with a "visitor" function of some kind (there might be a more appropriate d3 naming/mechanism for this I'm not sure) -
var bar = fc.series.bar()
        .xScale(dateScale)
        .yScale(priceScale)
        .yValue(fc.utilities.valueAccessor('close'))
        .visitor(function(d, s) {
            s.attr("stroke", "rgb(" + Math.floor(d.date.getDay() * 256 / 7) + ", 127, 127)");
        });

@ColinEberhardt has already created an implementation of this for his stacked bar example.

closed by #229


FIX: correctly compute group_delay for complex-coefficient TFs

Added unit test for complex-coefficient TF case.
Added second reference for algorithm.
Reference issue
Closes gh-19586.
What does this implement/fix?
Correctly calculate group-delay; see https://ccrma.stanford.edu/~jos/filters/filters-citation.html
Notation in implementation and reference above is similar enough that there is likely  common ancestry.
Additional information
I didn't know what nulp to set for the unit test, so it's arbitrarily "passing-value-on-my-computer-plus-one".  Perhaps assert_array_almost_equal would be better?

@roryyorke yep, that CI failure was unrelated and fixed recently, merge main and it should go away

Honestly, with just a new test added and no old tests changed this looks relatively safe, but a signal dev review would be sensible first.
I'll bump the milsetone given that I'm about to branch for 1.13.0, apologies.

@DietBru maybe you would be able to have a quick look here?

Looks good for me to go (I checked the URL and verified the fix by checking the group delay of the transfer function in test_complex_coef  with freqz).

Agh sorry picked up submodule changes while resolving merge conflicts, I will resolve

@roryyorke FYI: the test tolerance is bumped in gh-20355


Fixed #33443 -- Clarified when PasswordResetView sends an email.

Docs: More clearly list the conditions when PasswordResetView sends email
using a numbered list. This adds explicit mention that is_active must
be true, which was only mentioned in passing way further down in the
documentation previously.
Also adds a missing closing parenthesis around item 3.

@bsolomon1124 Is there a ticket for this PR? If not, creating a ticket here will help keep this PR moving :)
(You'll need to login with github for the 'new ticket' button to become visible.)

@bsolomon1124 Is there a ticket for this PR? If not, creating a ticket here will help keep this PR moving :)

Added and updated title.

@bsolomon1124 Thanks :+1: I pushed small edits.


Fix wrong date format for Windows Server 2004

Hello,
I realized the date format for 2004 wasn't following the same as the other.
Date format used is mm/dd/yyyy for the other entries. This one had mm/dd/yy.

@Belphemur : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

@illfated: I'm sorry - only the author of this article, @jasongerend, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

Yes, I know. My previous comment is in accordance with a previous agreement.


pulldeps tools pulls hadoop client for no reason

to repro try this command:
java  -cp "lib/*" -Ddruid.extensions.directory="extensions" io.druid.cli.Main tools pull-deps  -c "io.druid.extensions.contrib:druid-redis-cache:0.12.1"

expected:
download the redis cache extension and its deps
actual:
for some reason, also downloads hadoop client.

I think you need to add --no-default-hadoop to skip downloading Hadoop. I believe the help and/or docs for this command should mention that, if not we should add a mention of that.

but why download hadoop client i the first place. i never asked for it.
the bug is regarding default behavior.
the flag should be to ‘enable’ downloading hadoop client not the other way around.


Unable to authenticate the request - certificate signed by unknown authority

What happened:
I deployed an instance of oidc-webhook-authenticator in my cluster, and when I make a request to my cluster, I saw a message in the log of oidc-webhook-authenticator

I0128 00:43:20.035186       1 pathrecorder.go:241] oidc-webhook-authenticator: "/validate-token" satisfied by exact match

However, in apiserver's log, I saw this

E0128 00:43:20.037068       1 authentication.go:63] "Unable to authenticate the request" err="invalid bearer token"

and the output of kubectl is

error: You must be logged in to the server (Unauthorized)

The token I used to run kubectl is fresh.
I struggled to figure out what certificates to use. Self-signed certificates doesn't seem to work.
What you expected to happen:
authentication should pass
How to reproduce it (as minimally and precisely as possible):
I used the root certificate of control plane node (/etc/kubernetes/pki/ca.crt and ca.key) to create a server certificate, and put both ca.crt and server.crt to tls.crt used by the authenticator. For webhook plugin, we used /etc/kubernetes/pki/apiserver-kubelet-client.crt and apiserver-kubelet-client.key.
Anything else we need to know:
Environment: Linux, Kubernetes

@jianhang33 can you provide us with detailed step by step instruction how to reproduce this issue?

Here is the config for webwook plugin config file named gardener-authn-webhook.yaml
apiVersion: v1
kind: Config
clusters:
  - name: gardener-authn-service
    cluster:
      insecure-skip-tls-verify: true
      server: https://<IP_ADDRESS>:443/validate-token
users:
  - name: api-server
    user:
      client-certificate: /etc/kubernetes/pki/apiserver-kubelet-client.crt
      client-key: /etc/kubernetes/pki/apiserver-kubelet-client.key
current-context: webhook-authn
contexts:
- context:
    cluster: gardener-authn-service
    user: api-server
  name: webhook-authn

and when the k8s cluster starts, these flags are included
--authentication-token-webhook-config-file=/etc/kubernetes/authn/gardener-authn-webhook.yaml
--authentication-token-webhook-cache-ttl=10s
--authentication-token-webhook-version=v1

After the k8s cluster is up, I did the following

apply config/samples/minikube-webhook-kubeconfig.yaml
generate a server certificate from the root certificate/key of the k8s cluster with SAM including <IP_ADDRESS>
modify the file config/samples/deployment.yaml to replace the certificate/key in the secret oidc-webhook-authenticator with the server certificate/key created above and the k8s's root certificate
remove anything related to dex (as I use my own identity provider) in deployment.yaml
deploy deployment.yaml
deploy OpenIDConnect object for my identity provider (using jwks)
get a token from my identity provider, and run 'kubectl get pods --kubeconfig <kubeconfig.noUserCertificate-key> --token

Hi, @jianhang33 ! Our local development guide was quite outdated so I filed a PR (https://github.com/gardener/oidc-webhook-authenticator/pull/95) that aims to better reflect the current state of the project.
Do logs from both kube-apiserver and oidc-webhook-authenticator indicate some errors other than "Unable to authenticate the request" err="invalid bearer token""? If you have the --authentication-token-webhook-config-file flag configured then the lack of any other logs in the kube-apiserver indicates that the auth requests are successfully being received by the oidc-webhook. Is it possible that you misconfigured the openidconnect object? Typical misconfigurations include mismatch of issuer ("https://abc.svc" is different from "https://abc.svc/") or wrong audience (aud claim from the token should match the clientID in the openidconnect object).

Thanks @dimityrmirchev for your response. I didn't see any error messages in oidc-webhook-authenticator's log, and

I0128 00:43:20.035186 1 pathrecorder.go:241] oidc-webhook-authenticator: "/validate-token" satisfied by exact match

appears to be the only relevant messages. Is there a way to log more debugging messages in oidc-webhook-authenticator, e.g. log the failure reason when authentication fails? In the meantime, I'll double check the issuer and the audience.
In the log from kube-apiserver, I didn't deploy the webhook for authorization so there is a timeout error message contacting the authorization webhook, but I assume that is independent of the error for authentication

E0128 00:43:20.037068 1 authentication.go:63] "Unable to authenticate the request" err="invalid bearer token"

I am not sure that increasing the logging verbosity (controlled by this flag) will show anything meaningful in this case since the errors during authentication are not logged (see here). You can try and log the errors there and build and test with the new image if that is something that you want to do.

In the log from kube-apiserver, I didn't deploy the webhook for authorization so there is a timeout error message contacting the authorization webhook, but I assume that is independent of the error for authentication

The oidc-webhook-authenticator also uses authentication and authorization kubeconfigs to check the identity and permissions of the caller so it is making a SubjectAccessReview to the kube-apiserver. I am not sure if this creates a subsequent request to the kube-apiserver authorization webhook and hence the timeouts. I did test the setup described here yesterday and did not see any timeouts in the kube-apiserver logs.

You are right on the logging verbosity. I have already increased it to 10. Adding log message to the code is something I can do, but when I tried to compile the code by running 'make all', I got some errors.
Successfully built 5c3d6c956105
Successfully tagged tools:latest
docker run --rm --name=oidc-tools -v /home/jianhang/github.com/gardener/oidc-webhook-authenticator:/workspace tools:latest controller-gen object:headerFile="hack/license_boilerplate.go.txt" paths="./..."
panic: interface conversion: ast.Expr is *ast.CompositeLit, not *ast.Ident

goroutine 2610 [running]:
sigs.k8s.io/controller-tools/pkg/loader.(*referenceCollector).Visit(0xc008d1eba0, {0xd6c578?, 0xc00b8ca318})
	/go/pkg/mod/sigs.k8s.io/controller-tools@v0.7.0/pkg/loader/refs.go:136 +0x105
go/ast.Walk({0xd69ea0?, 0xc008d1eba0?}, {0xd6c578?, 0xc00b8ca318?})
	/usr/local/go/src/go/ast/walk.go:51 +0x62
go/ast.walkExprList({0xd69ea0, 0xc008d1eba0}, {0xc007167f30?, 0x1, 0xc00c306a40?})
	/usr/local/go/src/go/ast/walk.go:26 +0x91
go/ast.Walk({0xd69ea0?, 0xc008d1eba0?}, {0xd6bfd8?, 0xc00b8b3b40?})
	/usr/local/go/src/go/ast/walk.go:144 +0x36b
go/ast.Walk({0xd69ea0?, 0xc008d1eba0?}, {0xd6bf60?, 0xc0083526f0?})
	/usr/local/go/src/go/ast/walk.go:153 +0x17c5
go/ast.Walk({0xd69ea0?, 0xc008d1eba0?}, {0xd6be70?, 0xc008352720?})
	/usr/local/go/src/go/ast/walk.go:163 +0x1ca9
go/ast.Walk({0xd69ea0?, 0xc008d1eba0?}, {0xd6c1b8?, 0xc00b8b3b80?})
	/usr/local/go/src/go/ast/walk.go:74 +0x1b8d
go/ast.Walk({0xd69ea0?, 0xc008d1eba0?}, {0xd6c1e0?, 0xc008352750?})
	/usr/local/go/src/go/ast/walk.go:85 +0x218a
go/ast.Walk({0xd69ea0?, 0xc008d1eba0?}, {0xd6c618?, 0xc00b8ca330?})
	/usr/local/go/src/go/ast/walk.go:168 +0x16a5
sigs.k8s.io/controller-tools/pkg/loader.(*referenceSet).collectReferences(0xc00b8d34c0, {0xd6f430?, 0xc00b8ca330}, 0xc0043de050)
	/go/pkg/mod/sigs.k8s.io/controller-tools@v0.7.0/pkg/loader/refs.go:107 +0xe5
sigs.k8s.io/controller-tools/pkg/loader.allReferencedPackages.func1(0xc00b093828?, 0x41005e1800?, 0xc00b8b3a40)
	/go/pkg/mod/sigs.k8s.io/controller-tools@v0.7.0/pkg/loader/refs.go:164 +0x52
sigs.k8s.io/controller-tools/pkg/loader.(*typeVisitor).Visit(0x0?, {0xd6c690?, 0xc00b8b3a40?})
	/go/pkg/mod/sigs.k8s.io/controller-tools@v0.7.0/pkg/loader/visit.go:64 +0xa7
go/ast.Walk({0xd69ec0?, 0xc00b736900?}, {0xd6c690?, 0xc00b8b3a40?})
	/usr/local/go/src/go/ast/walk.go:51 +0x62
go/ast.Walk({0xd69ec0?, 0xc00b736900?}, {0xd6c2d0?, 0xc00b8b3bc0?})
	/usr/local/go/src/go/ast/walk.go:344 +0x233c
go/ast.walkDeclList({0xd69ec0, 0xc00b736900}, {0xc00932b800?, 0xd, 0x0?})
	/usr/local/go/src/go/ast/walk.go:38 +0x91
go/ast.Walk({0xd69ec0?, 0xc00b736900?}, {0xd6c208?, 0xc004303d80?})
	/usr/local/go/src/go/ast/walk.go:366 +0xdea
sigs.k8s.io/controller-tools/pkg/loader.EachType(0xc00240f0a0, 0xc00b7368e8)
	/go/pkg/mod/sigs.k8s.io/controller-tools@v0.7.0/pkg/loader/visit.go:38 +0x96
sigs.k8s.io/controller-tools/pkg/loader.allReferencedPackages(0xc00240f0a0, 0xc0043de050)
	/go/pkg/mod/sigs.k8s.io/controller-tools@v0.7.0/pkg/loader/refs.go:162 +0x275
sigs.k8s.io/controller-tools/pkg/loader.(*TypeChecker).check(0xc001c563c0, 0xc00240f0a0)
	/go/pkg/mod/sigs.k8s.io/controller-tools@v0.7.0/pkg/loader/refs.go:249 +0x187
sigs.k8s.io/controller-tools/pkg/loader.(*TypeChecker).check.func1(0x63?)
	/go/pkg/mod/sigs.k8s.io/controller-tools@v0.7.0/pkg/loader/refs.go:257 +0x65
created by sigs.k8s.io/controller-tools/pkg/loader.(*TypeChecker).check
	/go/pkg/mod/sigs.k8s.io/controller-tools@v0.7.0/pkg/loader/refs.go:255 +0x1cd
make: *** [Makefile:47: generate] Error 2

I tried both on master and v0.17.0.
Any advice?

In webhook.go at line 154 (v0.17.0), there is a logging statement
		// An error here indicates bad configuration or an outage. Log for debugging.
		klog.Errorf("Failed to make webhook authenticator request: %v", err)
		return nil, false, err

Is this error message logged by default when authentication fails? A similar logging statement is needed at line 175 of webhook.go.

Adding log message to the code is something I can do, but when I tried to compile the code by running 'make all', I got some errors.

The make all command seem to be broken for me too, I should check that. Meanwhile you can use make docker-build to build the docker image or something similar to docker build -t oidc-webhook-authenticator:my-tag . if you want to tag the image with a custom tag.

In webhook.go at line 154 (v0.17.0), there is a logging statement

I do not find this code in the project. Is this from the kube-apiserver codebase? If I follow the comment then this is not always logged when auth fails but when the requests for some reason do not reach the webhook authenticator which I think is not what is happening in your case since you are seeing oidc-webhook-authenticator: "/validate-token" satisfied by exact match logs.

Closing since there is no longer activity on this issue.

I got my issue resolved by adding logging statements. Is there a reason why you don't want to put logging here? After I found out what was wrong my issue was easy to resolve.

Hi @jianhang33 and thanks for the feedback! I am glad that you were able to solve your issue. W.r.t. the logs I think that it would be meaningful if we have some debugging logs that can be turned on/off. I will open an issue regarding this. Feel free to even open a PR if that is of interest to you, otherwise I will pick it up when I have some spare time.

@dimityrmirchev I am more than happy to create a PR, but I found that I don't know

how to access the verbose level set when starting the server
how to enable the logger for the level

If you have examples that I can follow, I'll make the change. Otherwise, thanks for taking care of it.

@jianhang33 It seems that there was a bug when applying the logging configuration. This is probably why you did not see any logs when increasing the verbosity level. I opened https://github.com/gardener/oidc-webhook-authenticator/pull/111 which should fix this issue and add the additional logs. Mind that these logs can be enabled by setting --zap-log-level flag >= 10 when starting the server.

Thanks. I'll try it out when it is available, I assume, in tag v0.22.0.


mavros: 0.16.3-0 in 'indigo/distribution.yaml' [bloom]

Increasing version of package(s) in repository mavros to 0.16.3-0:

upstream repository: https://github.com/mavlink/mavros.git
release repository: https://github.com/mavlink/mavros-release.git
distro file: indigo/distribution.yaml
bloom version: 0.5.20
previous version for package: 0.16.2-0

libmavconn

No changes

mavros
* use safe methods to get imu data in local_position plugin
* Contributors: Andreas Antener

mavros_extras

No changes

mavros_msgs

No changes

test_mavros

No changes

I'm sorry, another bugfix release. Fixes serious bug (catched by assertion).


Update Docs

Lots of changes with the docs; just a draft for now.

I went through the trust model docs, and those sections look great.

with this change the Instructions for Peerpods has been removed. Was this intentionally? at least for Azure this was where the end-user focussed documentation was being maintained.

Generally I want to try to converge the peer pods directions with the bare metal directions, but I didn't mean to delete the Azure docs.
One place this could potentially live in the new layout is getting started -> pre-requisites -> hardware -> cloud -> azure
Is that too deeply nested?
Also is it valid separate out this stuff as pre-requisites? I'd like it if we just had setup steps and then people moved onto generic steps to install the operator and runt he workload. It seems like that can probably work if we add a cloud tab to the operator setup step. wdyt? I understand if you want to keep the full end-to-end instructions in place somewhere. Maybe we could add an examples section?

One place this could potentially live in the new layout is getting started -> pre-requisites -> hardware -> cloud -> azure Is that too deeply nested?
Also is it valid separate out this stuff as pre-requisites? I'd like it if we just had setup steps and then people moved onto generic steps to install the operator and runt he workload. It seems like that can probably work if we add a cloud tab to the operator setup step. wdyt? I understand if you want to keep the full end-to-end instructions in place somewhere. Maybe we could add an examples section?

putting it under pre-requisites feels a bit odd. Can we put it below getting started / installation / Azure? We could have similar instructions for other CSPs as siblings, or possibly a non-TEE qemu entry that covers everything from local k8s cluster installation to coco runtimeclass (in a similar copy/paste fashion as the azure docs). the installation page could still keep the more generic, brief installation instructions.

@mkulke yeah seems tricky for the installation page that I currently have to capture everything in tab boxes. It can accommodate switching to different CRDs and CRs but the earlier steps where you download CAA don't really fit.
For this PR can I just move the azure page as-is to a new top-level example section and then we think about how to handle peer pods? I don't really know how peer pods installation works.
I suspect we probably want to add a cloud section to the installation section. Do we split it into two pages: cloud, and bare-metal (that mutually exclusive)? Do we add another step for peer pods that is optional (before installation but after per-requisites)?
I think some of the Azure stuff can go in pre-requisites; everything before installing CAA? wdyt?

@mkulke yeah seems tricky for the installation page that I currently have to capture everything in tab boxes. It can accommodate switching to different CRDs and CRs but the earlier steps where you download CAA don't really fit.

what I mean is to move

For this PR can I just move the azure page as-is to a new top-level example section and then we think about how to handle peer pods? I don't really know how peer pods installation works.
I suspect we probably want to add a cloud section to the installation section. Do we split it into two pages: cloud, and bare-metal (that mutually exclusive)? Do we add another step for peer pods that is optional (before installation but after per-requisites)?
I think some of the Azure stuff can go in pre-requisites; everything before installing CAA? wdyt?

What I would suggest is to move the azure folder as-is from cloud-api-adaptor into the getting_started/installation folder, it'll appear as a subpage there. next to subpages for bare metal, non-tee, aws, ...
I would not recommend chopping up the documentation in generic and specific steps and leaving it to reader to puzzle it together (even if that means some redundancy)

I feel pretty strongly about making the docs as generic as possible. Not doing so with the existing docs has created nothing but problems. With siloed docs maintainers only focus on their own sections which decreases quality and everybody ends up doing more work because individual sections are longer and more complex. This gets worse as we add more platforms and features. Let's not underestimate how painful redundancy can be. We've really struggled with this in the github docs.
More fundamentally, we've struggled with making the project generic since day 1. If we keep the docs separate we enable ourselves to continue not really worrying about convergence which I think is a big mistake. Putting everything together is a good way to push in the other direction. It will definitely show us where we need to do some more work.
That said, I understand that you guys have put time into the az doc in particular and that it is proven to work. That's why I suggest keeping it around in examples or some other place (even though that does also create some redundancy). I don't think it will be too puzzling for users to figure out the prerequisite steps. If it is then we probably need to make the project itself simpler. I don't want to put the az doc under the installation section as-is. It would be odd to have a pre-requisites and installation section next to another doc that also contains those steps.

I feel pretty strongly about making the docs as generic as possible. Not doing so with the existing docs has created nothing but problems. With siloed docs maintainers only focus on their own sections which decreases quality and everybody ends up doing more work because individual sections are longer and more complex. This gets worse as we add more platforms and features. Let's not underestimate how painful redundancy can be. We've really struggled with this in the github docs.

I see. in this case I wouldn't know how to meaningfully split the existing docs. there is ~1 line in the azure/peerpod doc that is generic (kustomize-apply the operator). If the website is not the place for this kind of setup guide, I'd suggest moving it back to the caa repo, I think the other cloud's documentation has been maintained there (the content on the website is mostly a stale copy from some point in time).
wdyt @bpradipt @stevenhorsman? (should peerpods guides stay in the caa repo)

wdyt @bpradipt @stevenhorsman? (should peerpods guides stay in the caa repo)

I think we should have a single place for this documentation. Where there is is a good question. I understand the idea of having the user facing docs in the confidential containers website, as long as it's kept up-to-date, but if the website is supposed to be generic and only have things that apply to enclave-cc, bare-metal and peer-pods (I might have misunderstood this point, but I'm worried will mean it doesn't work well enough for anyone?) then I think we'll have to keep them in the CAA repo if the alternative is to not have any specific docs?

The website should absolutely have peer pods information on it. The idea is not to only have information that is common to all. It's to not duplicate information that is common to all.
For instance, we can add a tab on the installation page that installs the peer pods overlay. Let's also add a note at the top of the installation guide that points out that there are tabs in case people miss them and that tells people to look at the pre-requisites. We can also explain the different deployment types a little more clearly at the very beginning.
Currently I have cloud under hw pre-requisites, which doesn't make much sense, so I can move that next to hw and sw. I think that's a reasonable place to add the cloud provisioning steps. Then we just need to find a place to put the installation of the CAA adaptor itself. Maybe under installation. I don't quite have the picture but this is the sort of thing I envision.
I was planning to do peer pods as a follow-up, but I want to make sure we're on the same page here. If you guys think that it's too hard to disentangle the peer pods installation into individual steps, we can think about some alternatives, but that seems like a red flag to me.
One thing to think about is that the CNCF has fairly specific requirements regarding vendor neutrality on project websites and elsewhere. I don't think we're violating any of them, but making things more generic steers us in the right direction.

The website should absolutely have peer pods information on it. The idea is not to only have information that is common to all. It's to not duplicate information that is common to all and to structure all the flows we have floating around in the project into discrete, digestible, and interlinked pieces.
For instance, we can add a tab on the installation page that installs the peer pods overlay. Let's also add a note at the top of the installation guide that points out that there are tabs in case people miss them and that tells people to look at the pre-requisites. We can also explain the different deployment types a little more clearly at the very beginning.

Ok cool - it sounds like I misunderstood what had been discussed. That sounds good, but like it might be a bit tricky to do, but we could do something like have the peer pods ccruntime within the general operator section and I guess trying to jump out into peer pods specific page to discuss the specific set-up of different cloud-providers (which I guess could be in the tabbed format again).

When I see the preview, the ordering is as shown below

Since "Getting Started" is about installation only, I think a better ordering is after "Use cases".
May be you can merge "Getting Started"  and "Examples" into one section and rename it to "Deployment Examples" or "Deployment Scenarios" or "Tasks" etc.. and then have pages for different setup mechanisms (Kind/Kubeadm/AKS/EKS etc with and without peer-pods). Under that there could also be pages for sealed secrets, signed images etc.
And in subsequently PRs, we can introduce the tabs for the deployment examples in different environments.

Since "Getting Started" is about installation only, I think a better ordering is after "Use cases".
May be you can merge "Getting Started" and "Examples" into one section and rename it to "Deployment Examples" or "Deployment Scenarios" or "Tasks" etc.. and then have pages for different setup mechanisms (Kind/Kubeadm/AKS/EKS etc with and without peer-pods). Under that there could also be pages for sealed secrets, signed images et

Here's how I see the different sections.

Getting started: installation of CoCo only. gets users from zero to running an unsigned, unencrypted confidential container
Features: Additional functionality that can be used on top of a basic installation, usually depending on attestation
Examples: miscellaneous snippets of specific deployments of varying scope (which may or may not include installation). for example: using a couple of features together, using a feature with a particular workload, etc. Instructions for a lot of the demos we've seen could go here.
Use cases: high level look at how to use coco with various types of applications.

I don't have the use cases section totally figured out. I am thinking it would be pretty high-level, with references to specific features and examples, but without specific directions. @bpradipt does that fit with what you've been doing with use cases or should the scope be a bit different?

Here's how I see the different sections.

Getting started: installation of CoCo only. gets users from zero to running an unsigned, unencrypted confidential container
Features: Additional functionality that can be used on top of a basic installation, usually depending on attestation
Examples: miscellaneous snippets of specific deployments of varying scope (which may or may not include installation). for example: using a couple of features together, using a feature with a particular workload, etc. Instructions for a lot of the demos we've seen could go here.

Where do you plan to add the Concepts, Architecture etc pieces ?

Use cases: high level look at how to use coco with various types of applications.

I don't have the use cases section totally figured out. I am thinking it would be pretty high-level, with references to specific features and examples, but without specific directions. @bpradipt does that fit with what you've been doing with use cases or should the scope be a bit different?

This is a good start, followed by any specific implementation details under examples or blogs.

Where do you plan to add the Concepts, Architecture etc pieces ?

I forgot to put the architecture section on that list. That will be a top-level section containing general conceptual and design information including the design overview added in this PR and the trust model.

Ok, I am going to merge this. We will continue to iterate on it, but this is a good start and we need the architecture docs up somewhere for our incubation proposal. I will create some issues with next steps. I have checked the commit history in this repo and we're not removing anything that was website-exclusive.


Change per Defect PE00F1SB : Add 50mV VDN uplift

last check-in has wrong unit value .. attribute is microvolt -- I need to change 50mV
<0, 0, 50000, 0>  << correct value
<0, 0, 50, 0>   << incorrect value

Can one of the admins verify this patch?


Preferred Email and Preferred Phone pick lists should have the ability to be localized

The processing of Preferred email and Preferred Phone is hard coded in CON_Preferred_TDTM this prevents the default picklist values from being changed or translated.

**lurch: attach W-018081

**lurch: attach W-018081

Tracking W-018081

Included in beta release 1.42 (Beta 2)

Included in production release rel/1.42


Handle displayData in RawFuture and RawKernel

In JupyterLab command handling there is some advanced routing happening regarding messages with display IDs.
https://github.com/jupyterlab/jupyterlab/blob/dfeaf98cf39acacf7ed1984d916c1a75e51052d8/packages/services/src/kernel/default.ts
I wasn't sure about this on the first pass of work, so it was omitted. Moving over the handling code should be easy, but I've not looked yet into how this display ID actually works so currently unsure how to create examples and test cases to verify implementation. Maybe 1.5?

https://jupyter-client.readthedocs.io/en/stable/messaging.html#display-data