text:
Mull Browser - Privacy hardened fork of Firefox for Android

Mull browser is a privacy hardened fork of Firefox for Android. From the README:

Mull is kinda sorta Tor Browser Android, but without routing over Tor network and upstream Firefox. It enables many features upstreamed by the Tor Uplift project through @arkenfox and @pyllyukko's user.js projects.

It's built with open source scripts, stripping all the proprietary blobs from Firefox for Android. It's kept up to date with upstream releases, and is distributed through an F-Droid repository.
I think this would be a good inclusion on PrivacyTools.io

Do you have a link to the project? (It would alos be nice if you could use the templates provided when opening an issue 👍🏼 )

Sorry! Here's the project.
https://github.com/Divested-Mobile/mull-fenix

It enables many features upstreamed by the Tor Uplift project through @ arkenfox and @ pyllyukko's user.js projects

That's a bit misleading. Tor Uplift does not go "through" arkenfox etc. And Mull does not use pyllyukko which is at least 3 years out of date

I didn't mean to misrepresent the project. The information I shared must not be current. I didn't realize pyllyukko was no longer current.

I just came across this now.
This is my project.
It has been around since end of 2017.
It is not a hard fork by any means.
Fenix repo is here: https://github.com/Divested-Mobile/Mull-Fenix
Old Fennec repo is here: https://github.com/Divested-Mobile/Mull
Mull pulls in the user.js files from my other project Brace: https://github.com/divestedcg/Brace/tree/master/brace/usr/lib/firefox/browser/defaults/preferences
@pyllyukko's user.js file was removed many months ago: https://github.com/divestedcg/Brace/commit/27bee0bf9dcbe1a45b4c69f3cbaf7cc7ad37ce28
And even then it was a husk a year before that: https://github.com/divestedcg/Brace/commit/4d6dd6a665a4080448461bb3276795576d5ff775
The description was refined at some point: "It enables many features upstreamed by the Tor Uplift project using preferences from the arkenfox-user.js project."
I am sure it could be improved, but I haven't bothered.
As an aside, @Thorin-Oakenpants thank you for maintaining your user.js all of these years.
And related: https://github.com/privacytools/privacytools.io/issues/2041

@SkewedZeppelin thanks for clarifying 👍🏼

I ran this app through classyshark, it still includes many trackers such as google admob. Not sure if this is intentional @SkewedZeppelin?

@ph00lt0
those are blank stubs.
I think classyshark lets you long click to see the whole class.

Thanks for quick response @SkewedZeppelin, I didn't look much further yet.

Mull has recently been added to the official F-Droid repository :rocket: , you should see it in a few days.
https://gitlab.com/fdroid/fdroiddata/-/commit/31f408eef9411ceb6fa59e4393b35c86950232be

+1 mull is great for privacy by default and after being added to f droid it doesn't have any trackers unlike fennec in f droid

source: gharchive/issue

authors: Dastardly-Entrench SkewedZeppelin Thorin-Oakenpants freddy-m ph00lt0 wrkerr

license_type: permissive

license_source: github-api


text:
"Unexpected character encountered while parsing value: C. Path '', line 0, position 0" after install on 7.12.1

Happens on fresh install of Umbraco 7.12.1 (from the package catalogue via backoffice). Error below. Looking at the Metadata field, looks like this, I assume the tags aren't meant to split like this.

_Unexpected character encountered while parsing value: C. Path '', line 0, position 0.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: C. Path '', line 0, position 0._
Line 3:  @using Umbraco.Web.Models
Line 4:
Line 5:  <title>@Umbraco.Field("metaName", altFieldAlias: "pageName")</title>

Thanks John
It looks like some recent changes to Umbraco have broken it. I’ll have to get on to giving it.

If i get time today, I'll see if it works on 7.12.2

This was due to a change submitted by Jan which stores the tags data as json by default. I’ve fixed the package now and it works again.

authors: johnseto prjseal

repo: prjseal/CodeShareUmbracoStarterKit

license: MIT


text:
remove all np.random

Following @zzhaozhe-profolio comment, this blog post, and pytorch issue 5059. I removed all np.random calls in the galaxy datasets I've been using. This is a pretty subtle bug, so I think it's probably best to resolve it now rather than later.
I don't think np.random is used elsewhere in the codebase (only in some unittests to generate synthetic test data), but please let me know @jeff-regier or @zzhaozhe-profolio if I missed any other places.

Thanks, merging now

source: gharchive/pull-request

repo: prob-ml/bliss


text:
Remove BLISS_HOME dependency and improve path configuration

Closes #361. This will greatly simplify the pathing issue, since the need to set BLISS_HOME is delegated out to the specific folder directory. Along with the recent improvements to the Hydra configs, this will make setting different data directories outside the BLISS codebase trivial. (e.g. set "paths.sdss" to "/data/sdss").
To figure out where testing data files are, tests will use their own "file" absolute path.

I should note that #361 is likely already not an issue since we removed the forced changedir to the bliss root directory. However, this will make sure the bliss library (located in bliss/) does not need to be any particular working directory. It is the responsibility of the application (located in case_studies/sdss_galaxies) to provide valid paths for data files, checkpoints, etc.


text:
Adding support for lots of Holtek chips

I only tested HT32F523xx chips myself, all others are untested and
should be considered a source of trouble when working with these chips.

LGTM, Thanks :)

authors: Yatekii hargoniX

repo: probe-rs/probe-rs


text:
[WIP] - Update the STM32_WB series file

Generated via
target-gen arm --filter STM32WBxx_DFP

Using
https://www.keil.arm.com/devices/stmicroelectronics-stm32wb15ccyx/features/

is draft to see what GHA says + I still need to build and test that I can flash my device

After some conversation in the matrix chat around some misleading InvalidFlashAlgorithmStackSize errors when trying to flash new targets:

Not worth trying to track down the erroneous value of stack_size for the various  flash_algorithms; that value isn't needed by probe-rs when doing the flash operations
At least for the STM32WB15CCY series of chips, this updated STM32WB_Series.yaml works.

Thanks for this, I think the [WIP] in the title made everyone gloss over the PR.

Understandable. I'll fix that!

Is this ready? Also, have you by chance go through the memory regions to double check them? It's not rare to have errors in the packs.

I believe so, yes.
I only have the B-WB1M-WPAN1 handy to test with.
General guidance was to mark this ready so the branch can be pulled / tested by others w/ more devices on hand.


text:
Feature: Remember Process properties window user layout customizations

Is your feature request related to a problem? Please describe.
All the columns in Threads tab are reset to default, in the same session even. The Process Properties dialog is also reset to it's default size, this severely affects practical usage when performance analyzing, etc.
Describe the solution you'd like
PH to remember column choices and layout in Process/Threads dialog as well as the Process dialog window size, preferrably in real-time, not only on clean exit. Threads tab columns should also remember their custom width as well, important too because this is usually finely tuned to fit in limited space as it is overlaid over other programs and full-screen applications.
Describe alternatives you've considered
None.
Additional context
No.

Are you using the nightly builds or v2.39?

Are you using the nightly builds or v2.39?

Yes nightly, installed about 20 minutes ago.

Yes nightly, installed about 20 minutes ago.

The threads tab and properties window already save/restore their settings in the nightly?

The threads tab and properties window already save/restore their settings in the nightly?

Main Window remembers columns, but not their width. Process properties dialgo (threads tab, etc) doesn't remember anything. For me at least.

Main Window remembers columns, but not their width. Process properties dialgo (threads tab, etc) doesn't remember anything. For me at least.

There must be something in your settings file preventing the layouts from saving. Can you attach a copy here on Github so I can debug it or alternatively reset your settings to default?

There must be something in your settings file preventing the layouts from saving. Can you attach a copy here on Github so I can debug it or alternatively reset your settings to default?

It happens to also be a fresh Windows 10 (2004) install, oh and it's a ZIP binary, not setup.
ProcessHacker.exe.settings.xml._altimumdelta_columnwidth.txt

It happens to also be a fresh Windows 10 (2004) install, oh and it's a ZIP binary, not setup.
ProcessHacker.exe.settings.xml._altimumdelta_columnwidth.txt

it's a ZIP binary, not setup.

Are you running the binary from the zip without extracting it or did you extract the files from the zip then run it?
I tested your settings file and the customizations are correctly saved/restored so there must be something else preventing those settings from being saved. Do you have any antivirus products or other security software installed or running PH from a removable drive or something?
The only issue with your settings were the "Shareable WS" and "Shared WS" columns which have terrible performance. I've made some small changes that improve the performance slightly but I recommend using the "Shareable WS" and "Shared WS" counters on the properties window.

it's a ZIP binary, not setup.

Are you running the binary from the zip without extracting it or did you extract the files from the zip then run it?
I tested your settings file and the customizations are correctly saved/restored so there must be something else preventing those settings from being saved. Do you have any antivirus products or other security software installed or running PH from a removable drive or something?
The only issue with your settings were the "Shareable WS" and "Shared WS" columns which have terrible performance. I've made some small changes that improve the performance slightly but I recommend using the "Shareable WS" and "Shared WS" counters on the properties window.

Oh I have definitely extracted it, I have things well organized and everything that I manually install I create my own "program files" folders and stuff so yeah, definitely. I'm aware of that.
Yeah, I realized performance monitoring can be quite taxing on DPC latency and it would affect things, indeed it has come to my attention the amount of columns matter, but I never followed deep enough to figure out which of them is costly, so thanks for sharing that. This as initial setup and I haven't really finely tuned it if I really need Shared and Shareable WS at all, most likely not, at least in the main window.

Oh I have definitely extracted it, I have things well organized and everything that I manually install I create my own "program files" folders and stuff so yeah, definitely. I'm aware of that.
Yeah, I realized performance monitoring can be quite taxing on DPC latency and it would affect things, indeed it has come to my attention the amount of columns matter, but I never followed deep enough to figure out which of them is costly, so thanks for sharing that. This as initial setup and I haven't really finely tuned it if I really need Shared and Shareable WS at all, most likely not, at least in the main window.

Yeah, I realized performance monitoring can be quite taxing on DPC latency and it would affect the analysis,

process hacker is not the right tool for this. Use ETW (WPR/xperf/WPA) for it.

Yeah, I realized performance monitoring can be quite taxing on DPC latency and it would affect the analysis,

process hacker is not the right tool for this. Use ETW (WPR/xperf/WPA) for it.

I realized performance monitoring can be quite taxing on DPC latency

performance monitoring shouldn't be "taxing" considering the spikes on this graph for DPCs (blue) were from moving the mouse: https://i.imgur.com/Edmd50n.png

process hacker is not the right tool for this

You should only need WPR/xperf/WPA when there's an actual problem with DPC latency that needs diagnosing. Most machines can handle > 5 million a second without any delays.

I realized performance monitoring can be quite taxing on DPC latency

performance monitoring shouldn't be "taxing" considering the spikes on this graph for DPCs (blue) were from moving the mouse: https://i.imgur.com/Edmd50n.png

process hacker is not the right tool for this

You should only need WPR/xperf/WPA when there's an actual problem with DPC latency that needs diagnosing. Most machines can handle > 5 million a second without any delays.

Sorry, I've kinda thrown my words out there, it's something around stuttering/DPC becuase I can see the mouse and game/app stuttering when Process Explorer / Process Hacker / Process Monitor is active in some cases, I've figured it probably has to do with the number of columns you enable. Tho I don't know if it's a program front-end or back-end (API) issue, as in, whether it would cause the same slowdown if there were no GUI, etc.
I believe some newer versions of Process Explorer introduced lag, as it seemed to me, or I wasn't using it in that manner before, I got more into digging I started experimenting, spamming a lot of columns. I've seen it affect DPC and it would cause issues.
But as I mentioned that I do turn these things off when I'm doing actual analysis with the mentioned tools, otherwise the results would just be worthless. Why I use PH/PE at all, becuase it helps out in things where WPR(ETW)/GPA/VTune can't and not meant for, there's no one tool to rule them all and that's probably good anyway for other reasons.
Process Explorer causing high DPC or otherwise latency could be a side effect of some other root cause, but I've never narrowed it down to a specific column or feature yet, I'm now on a fresh Win10 with a much higher version than last time and if there was some sort of compatability this may fix it. Why I mentioned PE, it's because I had a similar experience with PH just a few days ago, I didn't actually checked what DPC latency looked like, becuase I'm not actually testing DPC latency in general, I'm testing programs, graphics apps, games (full screen applications). The reason why I need to keep DPC in check is because for the tests to be of any use (valid) I can't have any other factors affecting the analysis and the results.
Moreover, even if it perhaps may not matter with handling (polling) a lot of diagnostic info that much, and with DPC, it would still be good if it were only possible to poll 1 process, not all the processes nobody cares about. Unfortunate that the fundamentals of Windows and Window's profiling has such an inefficient limitation, or whatever it is, at least to my knowledge reading the docs, but I've been out of the loop for a while.

Sorry, I've kinda thrown my words out there, it's something around stuttering/DPC becuase I can see the mouse and game/app stuttering when Process Explorer / Process Hacker / Process Monitor is active in some cases, I've figured it probably has to do with the number of columns you enable. Tho I don't know if it's a program front-end or back-end (API) issue, as in, whether it would cause the same slowdown if there were no GUI, etc.
I believe some newer versions of Process Explorer introduced lag, as it seemed to me, or I wasn't using it in that manner before, I got more into digging I started experimenting, spamming a lot of columns. I've seen it affect DPC and it would cause issues.
But as I mentioned that I do turn these things off when I'm doing actual analysis with the mentioned tools, otherwise the results would just be worthless. Why I use PH/PE at all, becuase it helps out in things where WPR(ETW)/GPA/VTune can't and not meant for, there's no one tool to rule them all and that's probably good anyway for other reasons.
Process Explorer causing high DPC or otherwise latency could be a side effect of some other root cause, but I've never narrowed it down to a specific column or feature yet, I'm now on a fresh Win10 with a much higher version than last time and if there was some sort of compatability this may fix it. Why I mentioned PE, it's because I had a similar experience with PH just a few days ago, I didn't actually checked what DPC latency looked like, becuase I'm not actually testing DPC latency in general, I'm testing programs, graphics apps, games (full screen applications). The reason why I need to keep DPC in check is because for the tests to be of any use (valid) I can't have any other factors affecting the analysis and the results.
Moreover, even if it perhaps may not matter with handling (polling) a lot of diagnostic info that much, and with DPC, it would still be good if it were only possible to poll 1 process, not all the processes nobody cares about. Unfortunate that the fundamentals of Windows and Window's profiling has such an inefficient limitation, or whatever it is, at least to my knowledge reading the docs, but I've been out of the loop for a while.

It does seem to be remembering things now, perhaps that was just a one off edge case, or perhaps one particular column is triggering a bug.

It does seem to be remembering things now, perhaps that was just a one off edge case, or perhaps one particular column is triggering a bug.

perhaps one particular column is triggering a bug.

Do you have issues saving settings anywhere else? The same function for saving those window settings is used throughout the application.

It does seem to be remembering things now in the Threads tab

I haven't changed anything... You probably have third party software interfering with our window or the settings file and they've  updated their code so that isn't as obvious.

perhaps one particular column is triggering a bug.

Do you have issues saving settings anywhere else? The same function for saving those window settings is used throughout the application.

It does seem to be remembering things now in the Threads tab

I haven't changed anything... You probably have third party software interfering with our window or the settings file and they've  updated their code so that isn't as obvious.

It could be a locale encoding issue. Try opening cmd and running the "systeminfo" command and post your locale settings so I can preform some tests using that same locale:

third party software interfering

If there isn't a locale encoding issue then something probably hooked WideCharToMultiByte/MultiByteToWideChar and messed with the null terminators causing the settings to get written as garbage.

It could be a locale encoding issue. Try opening cmd and running the "systeminfo" command and post your locale settings so I can preform some tests using that same locale:

third party software interfering

If there isn't a locale encoding issue then something probably hooked WideCharToMultiByte/MultiByteToWideChar and messed with the null terminators causing the settings to get written as garbage.

third party software interfering

I've disabled the native Windows string conversion support... Update to the latest nightly build and check if settings are being saved correctly.

third party software interfering

I've disabled the native Windows string conversion support... Update to the latest nightly build and check if settings are being saved correctly.

Oh, right, I was busy, I will check it soon.

Oh, right, I was busy, I will check it soon.

I tried the latest Nightly version now and everything seems to work fine, in the Process Properties and Threads tab overall. And this time around it did save the Process specific stuff in the same session without closing first on the first run. But I'll still keep an eye still if I see something off.
But I left all the options default, previously I think I was disabling plugins and extended features and changing some settings but I forgot exactly how/what.

this time around it did save the Process specific stuff in the same session without closing first on the first run

Good to hear, thanks. Feel free to report any other issues you might run into 👍

authors: MagicAndre1981 altimumdelta dmex

repo: processhacker/processhacker


text:
Add draft and final tags to docker cache sources

Example merged bake file output including additional cache-from sources:
{
    "target": {
      "default": {
        "attest": [
          "type=provenance,disabled=true"
        ],
        "context": ".",
        "dockerfile": "Dockerfile",
        "args": {
          "DOCKER_META_IMAGES": "sut,localhost:5000/sut,ghcr.io/product-os/flowzone",
          "DOCKER_META_VERSION": "0ea38579ec88bd9ef8096a361f2ea57d709c46b4"
        },
        "labels": {
          "org.opencontainers.image.created": "2023-11-10T15:00:20.963Z",
          "org.opencontainers.image.description": "Reusable, opinionated, zero-conf workflows for GitHub actions",
          "org.opencontainers.image.licenses": "Apache-2.0",
          "org.opencontainers.image.ref.name": "default",
          "org.opencontainers.image.revision": "da3329194cdb73d3bada2a215fe5a3fb76dbd9b9",
          "org.opencontainers.image.source": "https://github.com/product-os/flowzone",
          "org.opencontainers.image.title": "flowzone",
          "org.opencontainers.image.url": "https://github.com/product-os/flowzone",
          "org.opencontainers.image.version": "5.12.9"
        },
        "tags": [
          "sut:0ea38579ec88bd9ef8096a361f2ea57d709c46b4",
          "sut:build-0ea38579ec88bd9ef8096a361f2ea57d709c46b4",
          "sut:build-kyle-cache-from-latest",
          "sut:latest",
          "localhost:5000/sut:0ea38579ec88bd9ef8096a361f2ea57d709c46b4",
          "localhost:5000/sut:build-0ea38579ec88bd9ef8096a361f2ea57d709c46b4",
          "localhost:5000/sut:build-kyle-cache-from-latest",
          "localhost:5000/sut:latest",
          "ghcr.io/product-os/flowzone:0ea38579ec88bd9ef8096a361f2ea57d709c46b4",
          "ghcr.io/product-os/flowzone:build-0ea38579ec88bd9ef8096a361f2ea57d709c46b4",
          "ghcr.io/product-os/flowzone:build-kyle-cache-from-latest",
          "ghcr.io/product-os/flowzone:latest"
        ],
        "cache-from": [
          "type=gha,scope=kyle/cache-from-latest-default-linux/amd64",
          "ghcr.io/product-os/flowzone:master",
          "ghcr.io/product-os/flowzone:0ea38579ec88bd9ef8096a361f2ea57d709c46b4",
          "ghcr.io/product-os/flowzone:build-0ea38579ec88bd9ef8096a361f2ea57d709c46b4",
          "ghcr.io/product-os/flowzone:build-kyle-cache-from-latest",
          "ghcr.io/product-os/flowzone:latest"
        ],
        "cache-to": [
          "type=gha,mode=min,scope=kyle/cache-from-latest-default-linux/amd64"
        ],
        "secret": [
          "id=GITHUB_TOKEN",
          "id=GH_TOKEN"
        ],
        "platforms": [
          "linux/amd64"
        ],
        "output": [
          "type=docker"
        ]
      }
    }
  }

I self-certify!

repo: product-os/flowzone


text:
[Trivial] we are using the term 'Connection' interchangeably with 'Session Establishment'

Type
Rename
Explanation
src/app/OperationalSessionSetup.h
pidarped yesterday
It seems we are using the term 'Connection' interchangeably with 'Session Establishment'. The API is FindOrEstablishSession() but herein we are calling it a connection. This would, especially, muddy the waters when we have TCP as the underlying transport. Would have preferred if it were named as Session. Changing it everywhere would have a lot of touch points though.

Connecting,       // CASE handshake in progress.

SessionEstablishing,       // CASE handshake in progress.

SecureConnected,  // CASE session established.

SessionEstablished,  // CASE session established.

Platform
all
Platform Version(s)
No response
Testing
CI tested
(Optional) If manually tested please explain why this is only manually tested
No response
Anything else?
No response

Renaming the state enums is not a big deal as log as we do it before we ship those as public (i.e. before we ship https://github.com/project-chip/connectedhomeip/pull/29305).  Renaming a bunch of the other things would be a change to a public API that is probably quite difficult to do; the best we can do is aliases and deprecating the old names....

authors: bzbarsky-apple yufengwangca

repo: project-chip/connectedhomeip


text:
[Ameba] Update dockerfile for the support of OTA header

Problem

Support OTA header in Ameba SDK

Change overview

Update chip-build-ameba/Dockerfile
Update version

Testing
Tested docker build

/rebase

Hi @andy31415 , @woody-apple ,
Please help to review this PR when you are available, many thanks!

/rebase


text:
Stop calling the attribute change callback on the wrong thread in bridge-app.

A few changes here:

Stop trying to pass values to the attribute change callback, since those get
ignored anyway.
Run the attribute change callback off a task on the Matter thread, instead of
calling it directly from a different thread.
Change initial bridge setup to set state before setting change callbacks, so
we won't try to notify changes at startup before the Matter stack is actually
initialized.

Fixes https://github.com/project-chip/connectedhomeip/issues/21212
Problem
See above.
Change overview
See above.
Testing
Ran bridge-app locally.  Tried triggering things by typing b and c followed by return in the bridge app, and with these changes no longer fail the threading asserts.

Fast tracking platform changes.

authors: bzbarsky-apple woody-apple


text:
Not in anchor workspace

Hi I copied an anchor github repo https://github.com/Henry-E/dog-money
then pasted it into the downloaded anchor repo/examples/
then opened the terminal to issue this command "anchor test" in that dog-money folder,
then it gave me "Not in anchor workspace."
What did I miss? Please help.

The Anchor.toml for that example is invalid (it's now out of date). It needs to be updated to
[provider]
cluster = "localnet"
wallet = "/root/.config/solana/id.json"

I works!! Thank you! I added [provider] so mine looks this way:
[provider]
cluster = "localnet"
wallet = "~/.config/solana/id.json"

authors: AuroraLantean armaniferrante

repo: project-serum/anchor


text:
Issue #SC-0000 fix: code changes to update dialcodes to live hierarch…

…y for reserve dialcode api

Codecov Report

Merging #440 into release-2.1.0 will decrease coverage by <.01%.
The diff coverage is 0%.

@@                 Coverage Diff                 @@
##             release-2.1.0     #440      +/-   ##
===================================================
- Coverage            32.09%   32.09%   -0.01%
  Complexity            1211     1211
===================================================
  Files                  172      172
  Lines                15048    15056       +8
  Branches              2387     2391       +4
===================================================
+ Hits                  4830     4832       +2
- Misses                9501     9507       +6
  Partials               717      717

Impacted Files
Coverage Δ
Complexity Δ

...operation/dialcodes/ReserveDialcodesOperation.java
1.2% <0%> (-0.19%)
1 <0> (ø)

...p/searchindex/elasticsearch/ElasticSearchUtil.java
48.61% <0%> (+0.55%)
51% <0%> (ø)
:arrow_down:

...mpl/operation/hierarchy/GetHierarchyOperation.java
51.97% <0%> (+0.86%)
21% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

Closing this pull request as it is not required for now. It may be required in future.

authors: codecov-io krgauraw


text:
Added upward navigation for CityMapsActivity

Upwards Navigation
I have added up navigation to the CityMapsActivity

Ooh sorry its because I have not updated to 3.5 on my side yet
Sent from Mail for Windows 10
From: Swati Garg
Sent: Sunday, October 6, 2019 8:38 AM
To: project-travel-mate/Travel-Mate
Cc: Florence Njeri; Author
Subject: Re: [project-travel-mate/Travel-Mate] Added upward navigation forCityMapsActivity (#721)
@Swati4star requested changes on this pull request.
In Android/build.gradle:

@@ -9,7 +9,7 @@ buildscript {
google()
}
dependencies {

   classpath 'com.android.tools.build:gradle:3.5.0'

   classpath 'com.android.tools.build:gradle:3.4.0'

why this change?
Is there any reason for downgrading the version?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@Florence-Njeri Can you update to the project's version and update your PR?

@Florence-Njeri Closing this PR because of inactivity. Feel free to reopen it if you continue to workn on it

repo: project-travel-mate/Travel-Mate


text:
Health Log showing tabs while in the flow (should not)

From Antoine: Health Log showing tabs while in the flow. They should not.

I can confirm that this was fixed in build 13 on iOS.

repo: project-vagabond/covid-green-app


text:
Added clustering github workflow

Signed-off-by: Petu Eusebiu peusebiu@cisco.com

What type of PR is this?

Which issue does this PR fix:
What does this PR do / Why do we need it:
If an issue # is not available please add repro steps and logs from IPAMD/CNI showing the issue:
Testing done on this change:

Automation added to e2e:

Will this break upgrades or downgrades. Has updating a running cluster been tested?:
Does this change require updates to the CNI daemonset config files to work?:

Does this PR introduce any user-facing change?:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

need to change localstack with minio, as localstack seems to be very slow.

Also,
Complete requests:    0
Failed requests:      100

@peusebiu, disable logs ("output": "/dev/null") so that the output is clean and readable.

authors: peusebiu rchincha

repo: project-zot/zot


text:
Write processing for ORGS pop-ups

We don't seem to have processing for organizations that are listed in ORGS1. We do point to organizations using the org: prefix (e.g., in running text and in respStmts). We'd like pop-ups that work like the pers: entity pop-ups.

I can go in and add info for all of the orgs. I've added it to my to-do list for this week.

I assume the original issue is fixed, so I'm closing this.

authors: JanelleJenstad martindholmes

repo: projectLEMDO/lemdoIssues


text:
feat: recipe page responsive design

What does this PR do?
Make the recipe page responsive. The Recipe/Application details will be placed on top on the README.md when the window size will reach a size of 1024px. (Ref https://tailwindcss.com/docs/responsive-design).

The models tabs is a bit weird looking when the size is very small, the table itself is responsible of that behaviour, so we probably want later to improve the table component.

Screenshot / video of UI
https://github.com/projectatomic/ai-studio/assets/42176370/1402004d-50c5-4222-80fb-8477fc200ad6
What issues does this PR fix or reference?
Fixes https://github.com/projectatomic/ai-studio/issues/258
How to test this PR?

(1) Open any recipe
(2) Make the window size vary

We might want to have @mairin opinion on the subject

@lstocchi  thanks for the tests! It was complicated to find, but the small horizontal bar was appearing because the text in the links in markdown where overflowing.

@lstocchi I fixed the position of the toggle button. However, for the scrollbar, the issue is a bit complexe, the table has some hardcoded pixel values for the headers, and they are overflowing on the right, the scrollbar is hidden because of that.
The ideal fix would be to define optional column, that could be hidden when the size of the screen get too small.
For now, I cannot improve further the design nor fix the scroll bar without changing a lot the table component.

repo: projectatomic/ai-studio


text:
remove an image by force also remove the container which is using the image

It remove all containers silently.
# buildah from busybox
busybox-working-container-1
# buildah from busybox
busybox-working-container-2
# buildah rmi -f busybox
untagged: docker.io/library/busybox:latest
5b0d59026729b68570d99bc4f3f7c31a2e4f2a5736435641565d93e7c25bd2c3
# buildah containers
#

docker is unable to remove the image if it's in use.
# docker rmi 84581e99d807
Error response from daemon: conflict: unable to delete 84581e99d807 (cannot be forced) - image is being used by running container d6cdb7497c31

Hi @gouyang,
Thanks for the report, but this is working as designed, when you use -f with 'buildah rmi' it removes the associated containers to and there's a warning in the man page.
--force, -f

This option will cause Buildah to remove all containers that are using the image before removing the image from the system.

I just checked buildah rmi -h, not the man page. Please close the issue if no action need.

Thanks @gouyang!  I'll see if I can update the usage to make the help be clearer.

Yes lets make a one line change to the help to fix this.

Closed with #441, thanks for the issue report @gouyang

authors: TomSweeneyRedHat gouyang rhatdan

repo: projectatomic/buildah

license_source: bigquery


text:
TCP connection blocks after peer process is terminated (conntrack issue?)

Client gets blocked writing/reading on connected TCP socket when server pod is deleted abruptly. Client resumes only after TCP retransmit timeout, which is 15 minutes by default.
The following conditions need to be met to reproduce the issue:

Client and server pods are running in different nodes of the cluster.
The server pod is exposed to the client pod using a service of type ClusterIP, but NOT headless.
The server pod is force-deleted.

Expected Behavior

When writing/reading data to a socket with no peer alive anymore, the client should receive error, e.g. via TCP RST message or when deleting the server pod it should result in TCP FIN message to the client.
Current Behavior

The client application gets blocked until TCP retransmission timeout is reached.  The deletion of the server pod and process will not be visible in any way and there is conntrack entry left on the worker where client pod is running.
Possible Solution

Steps to Reproduce (for bugs)

https://github.com/tsaarni/kubernetes-tcp-retransmit-retry-timeout/
Context

Your Environment

Calico version: v3.26.1 (reproduced with other versions too)
Orchestrator version: kubernetes v1.27.3 (reproduced with other versions too)
Operating System and version: Ubuntu 22.04.3 LTS (reproduced with other operating systems too)
Link to your project (optional):

I have not defined policies.
In my reproduction environment (link) I used the default config by deploying https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml which I believe is using iptables. I tested also EBPF but the result seemed to be the same.

We have the same Problem. Calico is configured to advertise serviceLoadBalancerIPs with BGP. If we change something in our BGP configuration on our network Equipment, remote client gets blocked writing/reading on connected TCP until the TCP retransmit timeout.
Setting net.ipv4.tcp_retries2 to a lower value helps to decrease the time, but this does not really fix the problem.
We have no policies and using the iptables dataplane.

when deleting the server pod it should result in TCP FIN message to the client.

It can hardly result in FIN if you force delete the pod.

the client should receive error, e.g. via TCP RST

That is a fair expectation assuming the packet reaches the node. Is that expectation correct? Are you able to track where your retransmitted packets end up?

It can hardly result in FIN if you force delete the pod.

Also to my surprise, it can. It depends on following condition  (link): TCP implementation in Linux kernel will send (1) FIN when the socket has no unread data when socket is closed or (2) RST when socket has unread data. It did not matter if I explicitly called close() or just terminated the process by sending SIGKILL. When process is terminated the sockets are automatically closed. The TCP implementation does not seem to make difference between explicit or implicit close.

Are you able to track where your retransmitted packets end up?

I've now observed following sequence when capturing traffic on both worker nodes (client, server) on any interface:

The client attempts to (periodically) send data to the server. In the capture from both worker nodes, I can observe the packets twice (as expected): once with IPIP tunnel link layer type and once with Ethernet.
The server pod is force deleted but the server process is still running (grace period).
Packets from the client are still received by worker node where server is running but only with IPIP tunnel link layer type, not with Ethernet link layer type anymore.
The client starts retransmitting the unacknowledged packet. Also, the retransmits can be seen at server worker, but they never reach the server pod.
The server process is terminated.
The server sends TCP FIN to the client (the kernel implicitly closing sockets). The capture only contains the packet with Ethernet link layer type and the TCP FIN packet is not seen at IPIP tunnel. Expectedly, it also does not reach the other worker.
Server re-transmits the TCP FIN packet. Also, that is never seen at IPIP tunnel.

One more observation after trying to troubleshoot the problem by enabling debug on Felix:
When I compare debug logs between normal pod delete and forced pod delete, the latter was missing debug message Pod is being deleted and IPs have been removed by Calico CNI. I tracked it down to this function. It seems the pod spec will not have the required annotation when force deleting and the fallback logic does not get triggered either since the pod status was Pending. Not sure what this was about. Maybe it is related to how sometimes in deletes the object is being replaced by a "tombstone" when the final state is not known?
I made an experiment by applying following workaround, but it did not seem to fix my problem
diff --git a/libcalico-go/lib/backend/k8s/conversion/conversion.go b/libcalico-go/lib/backend/k8s/conversion/conversion.go
index 4f30f6687..5581254a3 100644
--- a/libcalico-go/lib/backend/k8s/conversion/conversion.go
+++ b/libcalico-go/lib/backend/k8s/conversion/conversion.go
@@ -176,6 +176,10 @@ func IsFinished(pod *kapiv1.Pod) bool {
                        return true
                }
        }
+       if pod.DeletionTimestamp != nil && pod.DeletionGracePeriodSeconds != nil && *pod.DeletionGracePeriodSeconds == 0 {
+               log.Debug("Pod is being deleted and has no grace period.")
+               return true
+       }
        switch pod.Status.Phase {
        case kapiv1.PodFailed, kapiv1.PodSucceeded, podCompleted:
                log.Debug("Pod phase is failed/succeeded/completed.")

Wanted to add:

The server sends TCP FIN to the client (the kernel implicitly closing sockets). The capture only contains the packet with Ethernet link layer type and the TCP FIN packet is not seen at IPIP tunnel. Expectedly, it also does not reach the other worker.

The conntrack entry I saw being left in the worker with client is explained by the above. The worker node will have wrong connection status since it never sees the connection being terminated.

One more observation:
When the server pod is force deleted, Kubernetes removes the endpoint from EndpointSlice immediately. This seems to trigger Calico to remove route entry for the pod's calico interface. The pod interface remains there as long as the process is running but there is no route entry.
Just for testing if this is a problem, I created the route entry back manually quickly after pod force delete, but this did not help. The FIN packet still did not find its way to the tunnel interface.  In addition to adding route entry back, I also tried to comment out this call which also seems to get executed immediately at pod force delete, but no visible change from that either.

It can hardly result in FIN if you force delete the pod.

Also to my surprise, it can.

ACK :heavy_check_mark:

The client attempts to (periodically) send data to the server. In the capture from both worker nodes, I can observe the packets twice (as expected): once with IPIP tunnel link layer type and once with Ethernet.
The server pod is force deleted but the server process is still running.>
Packets from the client are still received by worker node where server is running but only with IPIP tunnel link layer type, not with Ethernet link layer type anymore.

By Ethernet you mean the main interface of the node? Are those packets forwarded via IPIP from another node or are they suppose to arrive as IPIP to the node in any case - both client and server pods are in IPIP-always ippools. If so, i'd expect to see the packet on the eth device as an ipip encap and then on the tunl0 device and then forwarded to the server pod device. So if you listen to any, i'd expect to see the packet 3x (once as ipip).
Once the route to the server pod is removed, i'd expect to see the packet on the eth and tunl0 only. I'd also expect and icmp error sent back to the client by the node saying the the destination is unreachable. Do you see any such icmp packets?

The client starts retransmitting the unacknowledged packet. Also, the retransmits can be seen at server worker, but they never reach the server pod.

That would be expected as there is no route anymore.

The server sends TCP FIN to the client (the kernel is implicitly closing the socket). The capture only contains the packet with Ethernet link layer type and the TCP FIN packet is not seen at IPIP tunnel. Therefore, it also does not reach the client worker.
Server re-transmits the TCP FIN packet. Also, that is never seen at IPIP tunnel.

That may be because a route that would steer it towards tunl0 is also gone. And you probably see it on eth as a plain paclet (not ipip) because that is the default route. And if that route is missing, any icmp error is probably sent via the default route instead of the ipip way as well :thinking:

I am still not sure if this is an unexpected behaviour. Is a graceful shutdown an option for you? On the calico side, it is hard to clean up only after your apps connections shut down. It would probably behave more as expected if there was no overlay, but kernel may drop drop packets due to rpf from server if there is no reverse route to it etc.

By Ethernet you mean the main interface of the node? Are those packets forwarded via IPIP from another node or are they suppose to arrive as IPIP to the node in any case - both client and server pods are in IPIP-always ippools. If so, i'd expect to see the packet on the eth device as an ipip encap and then on the tunl0 device and then forwarded to the server pod device.

When capturing on any I lose the exact interface info, but libpcap attaches the "Linux cooked capture" pseudo-header showing "Ethernet" or "IPIP". The packets are forwarded from another node via IPIP (client pod in one node, server pod in another).

So if you listen to any, i'd expect to see the packet 3x (once as ipip).

Aha, you are correct! Sorry, I missed it is really 3x.

Packets from the client are still received by worker node where server is running but only with IPIP tunnel link layer type, not with Ethernet link layer type anymore.

Once the route to the server pod is removed, i'd expect to see the packet on the eth and tunl0 only. I'd also expect and icmp error sent back to the client by the node saying the the destination is unreachable. Do you see any such icmp packets?

Yes, I see the retransmit packets from client to server only on eth and tunl0.  It is clear why, since the route to server pod's calico i/f is removed.
But I do not see ICMP packets :thinking:

Server re-transmits the TCP FIN packet. Also, that is never seen at IPIP tunnel.

That may be because a route that would steer it towards tunl0 is also gone. And you probably see it on eth as a plain paclet (not ipip) because that is the default route.

I have now captured traffic individually from server pod's calico i/f, server node's eth0 and server node's tunl0.
The FIN packet can be seen ONLY in pod's calico i/f.
I'm puzzled what can prevent the FIN packet being forwarded from the (now deleted) server -> client. The destination address for the packet is the client podIP (for example 192.168.136.5) and there of course still is route in server node towards client node 192.168.136.0/26 via 172.20.0.3 dev tunl0 proto bird onlink. But the packet is not seen in tunl0.

I am still not sure if this is an unexpected behaviour. Is a graceful shutdown an option for you?

It has been unexpected behavior to me since Calico has been the only CNI implementation where I'm observing the behavior. I've tested also with Kindnet, Flannel and Cilium.
Due to the complexity of the software of today, it causes quite tricky issues to troubleshoot: we started from failures in Vault (client), we investigated why it was not re-connecting to etcd database (server) in timely manner. The database client library was waiting for 15 min TCP retransmit timeouts (in kernel) to expire, which finally led me to study more about Calico :smile: But it took quite some effort to go through the layers of software to finally arrive to the root cause.
Pod force delete is often used for disturbance and resiliency testing, or during development and troubleshooting. In our case this time it was the resiliency testing.
According to what I found, it is not well known that pod force delete could cause problems for Calico (or for CNI implementations in general).

It has been unexpected behavior to me since Calico has been the only CNI implementation where I'm observing the behavior. I've tested also with Kindnet, Flannel and Cilium.

Are you using the same kind of overlay with the other CNIs? Different CNIs may have different security requirements beyond just networking.

The FIN packet can be seen ONLY in pod's calico i/f.
I'm puzzled what can prevent the FIN packet being forwarded from the (now deleted) server -> client. The destination address for the packet is the client podIP (for example 192.168.136.5) and there of course still is route in server node towards client node 192.168.136.0/26 via 172.20.0.3 dev tunl0 proto bird onlink. But the packet is not seen in tunl0.

If you do dmesg would you see those packets reported as "martian" ? If so then that would be strict RPF setting on the cali interfaces and/or enforcing the same in iptables. You may see packets dropped by rpfilter rules. That would be because of the missing (reverse) route back to the server pod. If so, that has a security reason.

If you do dmesg would you see those packets reported as "martian" ?

Nothing visible in dmesg. I tried enabling martian logging on all interfaces, and also disabled rp_filter by writing 0 for all interfaces, but no change unfortunately...

Are you using the same kind of overlay with the other CNIs? Different CNIs may have different security requirements beyond just networking.

They all of course have their differences. I tried Flannel with VXLAN and IPIP and Cilium with default config which uses VXLAN.
I had a second look at Cilium now with Wireshark and realized that after pod force delete, there is TCP RST response, while the server process was still running so it is NOT generated by the server itself.  I do not know what generates it, but it will solve the problem from client perspective just fine.  And Cilium does not need to wait for the process to terminate for cleanups. I wonder could this be achievable in Calico as well?

Hi @tomastigera, I know the issue is closed as not planned, but I wanted to re-test the scenario on v3.28.1 release, since it had backport #8970 for issue #8882, which you marked as related to this issue.
To my surprise, I found that already beginning from v3.27.0, the client connection is not anymore hanging, but only if using BPF mode. In iptables mode the client still hangs for the whole TCP retransmission period.
I wonder, do you happen to know if some change in v3.27.0 allows connection to be terminated successfully when the peer process dies?

Fuuuu hard to say what could have done it. My guess would be that we fixed some icmp csum issue. 3.27 was about adding ipv6 and there was a lot of refactoring and bug fixing. But I am glad that it works for you now!

Ok, thank you @tomastigera!  I was pondering if I could figure out something I could try to contribute for making iptables mode as well :)

I thought tcp keep-alive would save the day, but is isn't. Please see the blog referred by Antonio (it's really good). I tried to set terminationGracePeriodSeconds: 0 in the server, to improve the probability for the race to <100%, but it doesn't seem to work. I added an initContainer in the client to set sysctl net.ipv4.tcp_retries2 (https://github.com/projectcalico/calico/issues/7983#issuecomment-1746262777), and got the time down to ~10s.
apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  nodeSelector:
    kubernetes.io/hostname: vm-002
  initContainers:
  - name: sysctl
    image: quay.io/tsaarni/echo:latest
    imagePullPolicy: IfNotPresent
    securityContext:
      privileged: true
    command: ["sysctl", "-w", "net.ipv4.tcp_retries2=3"]
  containers:
  - name: echo
    image: quay.io/tsaarni/echo:latest
    imagePullPolicy: IfNotPresent
    command: ["/app/echo", "client"]
    ports:
    - containerPort: 8000

But IMHO this really is a problem in Calico.

authors: freym tomastigera tsaarni uablrek

repo: projectcalico/calico


text:
Move 'Resource definitions' out of calicoctl directly under References

Description
Currently, Resource definitions are listed under calicoctl hierarchy on References page. This PR proposes to list it under References to allow independent references to resources from other sections in the documentation. I have also arranged resources in alphabetical order on overview page and as menu items.
Todos

[x] Tests

[x] CI

Release-Note
Adjust References menu moving 'Resource definitions' from under calicoctl to directly under References.

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

Deploy preview for calico ready!
Built with commit 8e129f7239a6fac5b6327a8ffabc61468c71f28c
https://deploy-preview-2606--calico.netlify.com

@realgaurav I think it might make sense to simultaneously simplify the calicoctl section - right now it is two layers deep, and I don't think we need that any more: https://deploy-preview-2606--calico.netlify.com/master/reference/calicoctl/
wdyt?

authors: CLAassistant caseydavenport realgaurav


text:
Refactor backend API to WatchOptions struct

Description

In preparation for supporting watch bookmarks, replace the inflexible "revision" argument to backend.Watch() with a struct.  This mimics the k8s client approach so it should map on nicely.
Related issues/PRs

Todos

[ ] Tests
[ ] Documentation
[ ] Release note

Release Note

TBD

Reminder for the reviewer
Make sure that this PR has the correct labels and milestone set.
Every PR needs one docs-* label.

docs-pr-required: This change requires a change to the documentation that has not been completed yet.
docs-completed: This change has all necessary documentation completed.
docs-not-required: This change has no user-facing impact and requires no docs.

Every PR needs one release-note-* label.

release-note-required: This PR has user-facing changes. Most PRs should have this label.
release-note-not-required: This PR has no user-facing changes.

Other optional labels:

cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.
needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.

/merge-when-ready squash-commits

OK, I will merge the pull request when it's ready, squash the commits when I merge it, and leave the branch after I've merged it.

authors: fasaxc marvin-tigera


text:
ignore default paths if -scp is provided

close #970

Thanks so much for your contribution @zrquan , we appreciate it!
We also have a Discord server, which you’re more than welcome to join. It's a great place to connect with fellow contributors and stay updated with the latest developments!

I accidentally deleted the head repository. Can someone teach me how to recover it, or do I have to submit a new PR :smiling_face_with_tear:

@zrquan  Can you create a new branch with the same name and commits?

create a new branch with the same name and commits

Then I created a new PR(#979) 😂

authors: GeorginaReeder dogancanbakir zrquan

repo: projectdiscovery/katana


text:
logstream timeout to 120 mins

logstream timeout to 120 mins

Please share reasoning behind of 2 hrs.

When it comes to building, deploying and testing apps, 30 minutes is too small and disruptive.
@selvasingh do you have anything to add?

repo: projectkudu/kudu


text:
Update to Kyverno 1.8 to support OpenShift 4.11

Kyverno 1.7 is officially not supported on Kubernetes 1.24 and OpenShift 4.11.
Alternatives
Replace Kyverno with something else.

The component now supports kyverno 1.8 with release v2.0

authors: glrf megian

repo: projectsyn/component-kyverno


text:
Replacing hard-coded email address with configuration value equivalent

This work was lost when we fixed/replaced the bonnie-prior branch earlier

The build is failing because of an unrelated security vulnerability. We will address that in a separate release.

repo: projecttacoma/bonnie


text:
CardValidationResult { } characters in description

Currently there is no way to get plain text error messages from a CardValidationResult. The results are put into a JSON like structure, as seen in the following image.

Would it be possible to have a function or property that returns an array of strings, or update description to remove the { \t and } characters, and the initial new line character?

Please see #9 for a fix.

works well, thanks for the fix

authors: Haud MichaelCampbell

repo: prolificinteractive/Caishen

license: mit


text:
Please switch to fsnotify.v1 API

Hello,
alertmanager still uses the fsnotify.v0 API which has been deprecated. It would be nice if it could be ported to fsnotify.v1.
See https://github.com/go-fsnotify/fsnotify for the status of both API and https://godoc.org/gopkg.in/fsnotify.v1 for the doc of the new API.
Thank you!

@rhertzog Thanks for pointing this out! However, we'll likely not adjust this in the existing Alertmanager anymore, and the rewrite which is currently being planned will not have file listeners anymore (only reload by SIGHUP). So I'll close this issue in the expectation that the problem will go away by itself...

authors: juliusv rhertzog

repo: prometheus/alertmanager


text:
Duplicated timeseries in CollectorRegistry

Hello, when i tried to write a custom exporter, i met some error:
Duplicated timeseries in CollectorRegistry

Here is my code.
def Aliyun_MongoDB_monitor(DBInstanceId):

    StartTime = (datetime.utcnow() - timedelta(minutes=1)).strftime('%Y-%m-%dT%H:%MZ')
    EndTime = datetime.utcnow().strftime('%Y-%m-%dT%H:%MZ')

    request.set_StartTime(StartTime)
    request.set_EndTime(EndTime)
    request.set_DBInstanceId(DBInstanceId)

    response = json.loads(client.do_action_with_exception(request))

    for item in response['PerformanceKeys']['PerformanceKey']:
        if '&' in item['ValueFormat']:
            n = 0
            for name in item['ValueFormat'].split('&'):
                monitor_item_name = item['Key'] + '_' + name
                monitor_item_volume = item['PerformanceValues']['PerformanceValue'][0]['Value'].split('&')[n]
                print(monitor_item_name,monitor_item_volume)
                Gauge(monitor_item_name, 'Description of gauge').set(monitor_item_volume)
                n = n + 1
        else:
            monitor_item_name = item['Key']
            monitor_item_volume = item['PerformanceValues']['PerformanceValue'][0]['Value']
            Gauge(monitor_item_name, 'Description of gauge').set(monitor_item_volume)
            print(monitor_item_name,monitor_item_volume)

if __name__ == '__main__':
    # Start up the server to expose the metrics.
    start_http_server(8000)
    # Generate some requests.
    while True:
        Aliyun_MongoDB_monitor('dds-xxxxxxxxxxxxx')
        time.sleep(60)

I found out that i can't run Gauge(monitor_item_name, 'Description of gauge').set(monitor_item_volume) multiple times.

It makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.

authors: brian-brazil robinwangrubin


text:
Having to sign the DCO discourages contributions

Background:

I'm a technical writer, and love to contribute to open source projects on GitHub, given its easy to use interface for editing Markdown and submitting a PR.
At the same time, I don't have the inclination to fork, clone, edit etc. a project just to fix a typo.
Prometheus is the first project I've seen in years that automatically rejects all such contributions because of a thing called DCO (remember, I'm just a technical writer, and I'm unfamiliar with the reasons why this DCO is necessary here, but nowhere else I've been contributing).
I'm not the only one whose commits have been rejected for not signing the DCO. https://github.com/prometheus/docs/search?q=dco&type=issues shows 116 issues that have the word "DCO" in them. Just look at the first page of results.

I assume this DCO thing is worth rejecting contributions from the community, but there's got to be a better way.
The PR template is super cryptic for drive-by contributors: "Please sign CNCF's Developer Certificate of Origin". What's CNCF? Developer Certificate of Origin? Yeah, you can Google those, but the whole line made me gloss over it several times, and the vast majority won't take the time to Google these things. Also, this line suggests that the contributor would have to "sign" something like a CLA, which can be done after submitting the commit, and is far more likely to be done than someone forking the repo, clonig, and amending their commit.
Also, the PR template is displayed too late for GitHub users. At that point, the commit was already made. Again, look at the hundreds of issues created by the DCO.
If you want to accept contributions from the community, please try to make it as easy as possible for the community to do so.

Thank you. How could we improve the PR template to make DCO easier to grasp?
DCO is mandated to us by CNCF, it is not a choice of Prometheus itself: https://github.com/cncf/foundation/blob/main/charter.md#11-ip-policy so we can not remove this requirement, but I am happy to see how we can make it easier.

I don't think updating the PR template would help contributions via GitHub, because it's displayed too late, after the commit is created.
What would help would be a comment block at the top of each source .md file, advising to sign off the DCO. Something like:
<!--
Please sign off your commits so that we can legally accept your contribution.

You can do this with `git commit -s` or, from the GitHub interface,
by adding the following line to the "extended description" of each commit:

    Signed-off-by: Your Name <youremail@example.com>

There is also a browser extension to do this automatically:
https://github.com/scottrigby/dco-gh-ui
-->

BTW, the This documentation is [open-source](https://github.com/prometheus/docs#contributing-changes). note in the footer of docs pages could be even more helpful by directing the user to the precise Markdown file in the repo. Several notable OSS projects do this.

We've updated the document in prometheus/docs will be making some additional changes in the other repos.

authors: hdost roidelapluie tredondo

repo: prometheus/docs


text:
Add GCE SD docs

This PR adds documentation for the GCE SD, including the change from https://github.com/prometheus/prometheus/pull/2063

Thanks!
Technically the status should go into next-release, but given we were lacking docs it's better to get the rest in.

Sorry, got that messed up.

This does not actually document the gce_sd_config section fields itself?
See https://prometheus.io/docs/operating/configuration/#gce_sd_config

Indeed, let me fix that.

authors: brian-brazil dominikschulz juliusv


text:
Created Timestamp: Prometheus progates CT in Remote-Write 2.0

Proposal
Part of https://github.com/prometheus/prometheus/issues/14217
Is blocked by: https://github.com/prometheus/prometheus/issues/14218
With https://github.com/prometheus/prometheus/issues/14218 we could use this information to put into Remote-Write 2.0 created_timestamp proto field for specific series.
Acceptance Criteria

Prometheus adds CT to Remote-Write 2.0 requests when it can.

As I read https://prometheus.io/docs/specs/remote_write_spec_2_0/, it is in the protocol.
But I don't see any handling inside Prometheus.
I expect Prometheus to be able to use created_timestamp to add the initial 0 on counters received via remote-write v2.

authors: bboreham bwplotka

repo: prometheus/prometheus


text:
Intermediate rule evaluation results

Proposal
I commonly find teams having to do multiple recording rules in order to arrive at the final result they need, for example due to needing to do range queries on the result in the next step. Contrieved example:
groups:
- name: example
  rules:
  - record: step1
    expr: histogram_quantile(0.9, sum by (le) (rate(duration_seconds_bucket[5m])))
  - record: step2
    expr: max(step1)
  - record: step3
    expr: step2 > bool 5
  - record: step4
    expr: avg_over_time(step3[7d])

In this case, we don't really care about saving steps 1-2 (step 3 would need to be kept since we do a range on it). This both leads to unnecessary storage and "worthless" metrics floating around.
Could we add a new directive, maybe discard: true, to instruct Prometheus not to persist the result but instead drop it after the group has finished?

That's not how Prometheus storage works internally, once it's added it's added from a performance standpoint.

Ah, ok. So then it would merely be the cluttering aspect then (typically they are now named things like "temp_result_xyz").
But should I interpret this as it not being even possible?

I'm not saying it's not possible, but there's not much point.

We are currently running a bug scrub with the team.
You could actually write this whole thing as one expression thanks to sub-queries.
If you still want to write it as separate expressions for better readability, that boils down to templating or macro expansion or whatever you want to call it, which is something we currently deliberately want to avoid inside Prometheus.
So we decided to close this as "won't fix".

authors: beorn7 brian-brazil carlpett


text:
Prometheus calls https when http is configured

With the config below the Targets page of my main prometheus instance shows:
Get "https://prometheus-swarm:80/federate?match%5B%5D=%7B__name__%3D~%22..%2A%22%7D": http: server gave HTTP response to HTTPS client
It's configured as http so I don't get why it tries to open https. When I open a shell inside the prometheus container and ise wget (there is no curl in the container) to load that URL it works fine and I get back the metrics I need.
I had a config error in HaProxy before where it did try to redirect to https but that's long gone now. I have restarted and recreated the container but it keeps trying to open https. Even if I add the internal domain name to the target so it thinks it has a new target to load it tries to load over https.
global:
  scrape_interval:     15s # By default, scrape targets every 15 seconds.

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
    monitor: 'monitor'

rule_files:
  - 'alerts.yml'

alerting:
  alertmanagers:
    - scheme: http
      static_configs:
        - targets: ['alert-manager:9093']

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.

# FEDERATION FROM SWARM
  - job_name: 'federate_swarm'
    scrape_interval: 5s

    honor_labels: true
    metrics_path: '/federate'
    scheme: http

    params:
      'match[]':
        - '{__name__=~"..*"}'
    static_configs:
      - targets:
        - 'prometheus-swarm'

Can you share a tcpdump? There's probably a redirect.

'{name=~"..*"}'

See https://www.robustperception.io/federation-what-is-it-good-for

I'll have a look. Although wget inside the container and curl on the host don't show any redirects.

We have looked at it during our bug scrub and determined that it is more than probably due to a redirect or a proxy.
Please reopen if that's not the case.

authors: Fossil01 brian-brazil roidelapluie


text:
docker_sd: Deduplicate containers attached to multiple networks

Proposal
I have several containers attached to multiple Docker networks (e.g. frontend, backend). At the moment docker_sd creates a scraping target for each container on all networks. As some services are only attached to one network, it's not feasible to use relabelling to drop all containers in a certain network (or only keep those).
It would be nice if docker_sd could be configured to only use the first network, for example or find some other way to avoid duplicate targets.

This is interesting. Can you workaround the issue by taking multiple labels in input_labels and use regexes ? e.g. can you find which container is attached to which network based on the container name?
Are you using docker swarm?

Can you workaround the issue by taking multiple labels in input_labels and use regexes ? e.g. can you find which container is attached to which network based on the container name?

The container network name is stored in __meta_docker_network_name, so I tried setting a label prometheus.network on the container, but AFAIK there's no way to compare __meta_docker_network_name and the resulting __meta_docker_container_label_prometheus_network during relabeling, as the RE2 engine doesn't support back references.

Are you using docker swarm?

No I'm using docker_sd, but I guess this is also the case for docker_swarm_sd.

Indeed, you would need to hardcode them:
- source_labels: [__meta_docker_network_name,__meta_docker_container_label_prometheus_network]
  regex: frontend;frontend
  target_label: __tmp_docker_keep
  replacement: keep
- source_labels: [__meta_docker_network_name,__meta_docker_container_label_prometheus_network]
  regex: backend_backend
  target_label: __tmp_docker_keep
  replacement: keep
- source_labels: [__tmp_docker_keep]
  regex: keep
  action: keep

or, shorter
- source_labels: [__meta_docker_network_name,__meta_docker_container_label_prometheus_network]
  regex: `frontend;frontend|backend;backend`
  target_label: __tmp_docker_keep
  replacement: keep

The issue with the approach you are proposing is that I do not know what are the guarantees from Docker that the networks are ordered in fixed order between API calls, and how it behaves when you attach/detach to networks, then restarts the daemon, etc.

I'm not sure about the behavior of the Docker API either, it would just be nice to have some built-in way to avoid duplicate targets.

okay. I think we could have a networks array where we take a list of networks. For each container, we add its target on that network. If not network is matched, we dismiss the target. Does it sound like a solution?

Ok, I'm not sure I understand you correctly. Given the following container setup (and assuming all containers have Prometheus metric endpoints), how can we make sure the "api" container doesn't end up twice in the target list?

container: frontend
networks: frontend

container: api
networks: frontend, backend

container: database
networks: backend

We could implement/explore with an alternative mode, like we do for kubernetes, where one target has the addresses over all the networks.
I have tagged this issue as P3.

Currently, for each container we retrieve we loop through each of its networks and furthermore each of its ports, adding a target for each network+port combination.
https://github.com/prometheus/prometheus/blob/9e88c3bb4dd7b01456639df06df07053d5626445/discovery/moby/docker.go#L186-L205
I think we could just provide a configuration setting to break after the first network iteration, allowing target(s) to be added for only one network per container (there could be multiple ports).

If we break, we should order them. We should also have one label for each other network address.

If we break, we should order them.

Using what method?

We should also have one label for each network address (without port).

So when we break and only add a target for the first network, we should add extra labels to that target with the other network addresses (like __meta_docker_network_other_frontend=127.0.0.1)

I think Docker, Docker Swarm and Kubernetes SD should ideally behave the same way, as it boils down to "software running containers attached to (multiple) networks". Not saying, that the current Kubernetes implementation is the way to go, but if we come to a decision, it should apply to all three SD methods.

Kubernetes implementation is the way to go, but should be behind a flag if possible.

If we break, we should order them.

Using what method?

We should also have one label for each network address (without port).

So when we break and only add a target for the first network, we should add extra labels to that target with the other network addresses (like __meta_docker_network_other_frontend=127.0.0.1)

I think it's no need order multiple networks by default, just get the first network will be ok.
People can order the networks in docker-compose config file.
Kubernetes meet the same promblem when pod has multiple networks and it just shows the first network as default network.
The command look as below:
nsenter -n -t19032 -F -- ip -o -4 addr show dev eth0 scope global

For anyone curios, I solved the network deduplication using the keepequal action in the relabel configs. I also use an extra couple relabel configs to deduplicate the port (if you have a container that publishes multiple ports). I am also able to override the port when the default 80 is not the port I want. With these relabel configs I am able to monitor 13 containers using just a few simple labels on each docker swarm service and double checking the prometheus UI it is truly only picking up one target on the port and network I expect.
relabel configs with comments:
    relabel_configs:
      # Only keep containers that should be running.
      - source_labels: [__meta_dockerswarm_task_desired_state]
        regex: running
        action: keep
      # Only keep containers that have a `prometheus-port` label.
      - source_labels: [__meta_dockerswarm_service_label_prometheus_port]
        regex: .+
        action: keep
      # get the port from this target
      - source_labels: [__address__]
        regex: '[^\s]+:(\d+)'
        target_label: __tmp_found_port
      # keep only if this is the port we're looking for
      - source_labels: [__meta_dockerswarm_service_label_prometheus_port]
        target_label: __tmp_found_port
        action: keepequal
      # limit to one network
      - source_labels: [__meta_dockerswarm_service_label_prometheus_network]
        target_label: __meta_dockerswarm_network_name
        action: keepequal
      # replace address with prometheus-replacement-port if available
      - source_labels: [__address__, __meta_dockerswarm_service_label_prometheus_replace_port]
        separator: ':'
        regex: '([^:]+):[^:]+:(\d+)'
        replacement: "${1}:${2}"
        target_label: __address__
      # override address if an override is provided
      - source_labels: [__meta_dockerswarm_service_label_prometheus_address]
        regex: '([^\s]+)'
        target_label: __address__
      # override scheme if an override is provided
      - source_labels: [__meta_dockerswarm_service_label_prometheus_scheme]
        regex: '([^\s]+)'
        target_label: __scheme__

Hello from the bug scrub: please see the #10490 for latest status.

authors: DrAuYueng LeviHarrison fhemberger gnomed krajorama roidelapluie


text:
Fix spacing in linode_sd_config

Fix spacing in linode_sd_config causing "credentials not found in type linode.plain"
Signed-off-by: Ryan Lonergan rlonergan@linode.com

Thanks!


text:
Add stddev_over_time and stdvar_over_time.

Fixes #1792

:+1:


text:
Fully Adopt Prometheus/common HTTPClient in Consul SD

This PR fully adopts common's HTTPClient into the Consul SD.
Fixes #8924

Can you rebase this? Thanks!

I have tested this against consul.
Thanks!

authors: LeviHarrison roidelapluie


text:
unwrap paren expr with stepinvariant expr

ref - https://github.com/prometheus/prometheus/pull/9591#discussion_r746650891
Signed-off-by: darshanime deathbullet@gmail.com

Closing as it's been in draft state for a long time.
If you come back to it please re-open.

Hello from the bug-scrub!
As a previous reviewer, the status remains that the code changes behaviour and the PR comments do not acknowledge this change, so I cannot accept the PR.
Personally, I would advocate for a different approach entirely: have one pass where the AST is walked to remove redundant steps, etc., and then during evaluation the AST would not be modified at all.

authors: bboreham darshanime


text:
duplicate key in schema.sql

When generating a many 2 many table Propel generates an extra key which isn't nccessary in schema.sql.
PRIMARY: site_id, user_id <- which is what we want
sites_users_FI_2: 	user_id <- loop continues but not necessary (already in PRIMARY)
Hope it's clear enough

schema.xml example:

    <foreign-key foreignTable="sites" skipSql="true">
        <reference local="site_id" foreign="id" />
    </foreign-key>
    <foreign-key foreignTable="users" skipSql="true">
        <reference local="user_id" foreign="id" />
    </foreign-key>
</table>

I believe you're using MySQL? We create indices for every foreign key in MySQL.

If that's true it's missing a key (site_id).

Here is a nice blog post for this issue: http://propel.posterous.com/dont-do-this-at-home-4-add-indices-on-foreign

authors: fzaninotto jlammertink willdurand

repo: propelorm/Propel


text:
Conflict between timestampable and i18n behaviors

On rows that has both timestampable and i18n behaviors, if you only change i18n columns, the updated_at columns isn't updated.
Here is the PoC: http://sandbox.propelorm.org/2a9bcb5

Is someone able to make a PR here with suggested changes?

authors: dereuromark lovenunu


text:
setQueryKey() is not compatible with terminators that execute several queries - such as Paginate()

UPDATE: Previously I thought it was propel's caching system in general that was causing this error, but I've found it's just paginate() (or potentially any terminator that uses more than one Query to run).
When using a caching system (I tested both APC & Memcache) the system does actually store successfully (on both the official APC & memcache methods) but it only stores the first SELECT COUNT(*) query. This behavior has occurred on both a Windows & Linux machine.
In other words, look at this behavior, with Memcache disabled (but setQueryCache still live in the code):
Without Cache
[2014-12-29 01:58:40] defaultLogger.INFO: SELECT COUNT(*) FROM (SELECT article.id, article.title, article.body, article.tags, article.positive_votes, article.negative_votes, article.theme_id, article.created_at, article.updated_at, article.slug FROM article) propelmatch4cnt [] []
[2014-12-29 01:58:40] defaultLogger.INFO: SELECT article.id, article.title, article.body, article.tags, article.positive_votes, article.negative_votes, article.theme_id, article.created_at, article.updated_at, article.slug FROM article ORDER BY article.id DESC [] []
First, Propel counts the number of objects, THEN executes the query to actually receive rows - which paginate() needs to do before receiving these rows so it can get the right number of results.
This chain of events is the same if the cache is enabled, except that the first COUNT SQL statement is stored. When Propel follows through to get a paginated list of rows it suddenly finds that a key has been created already, so it just uses the cache. So, in result, Propel executes a COUNT statement twice.
With Cache
[2014-12-29 01:57:12] defaultLogger.INFO: SELECT COUNT(*) FROM (SELECT article.id, article.title, article.body, article.tags, article.positive_votes, article.negative_votes, article.theme_id, article.created_at, article.updated_at, article.slug FROM article) propelmatch4cnt
[2014-12-29 01:57:12] defaultLogger.INFO: SELECT COUNT(*) FROM (SELECT article.id, article.title, article.body, article.tags, article.positive_votes, article.negative_votes, article.theme_id, article.created_at, article.updated_at, article.slug FROM article) propelmatch4cnt [] []
Maybe I am doing something incredibly wrong, but I don't think so, because I followed the documentation, even using the example on paper, and the same problem occurs.
Here is one example of the code that fails with this:
	$posts = ArticleQuery::create()
		->setQueryKey("all_posts")
		->orderById('DESC')
		->paginate($page, $perPage);

Whilst you might say that caching such a general query is unnecessary, it is a test, and a test that is failing. I have ensured that spaces in memcache key names are converted to underscores, etc, so it is definitely a propel issue.
Tested with both
	$posts = new ArticleQuery();
	$posts = $posts
		->setQueryKey("homepage")
		->paginate($page, $perPage);

And the $posts = ArticleQuery::create() way. Adding filler parameters like orderById() has no affect on the result.
Which should have done the same thing anyway.
My suggestion is to either:

Add an optional parameter (defaulting to true) called "cacheable" that is checked before executing the cache behavior.
When using termination methods that require additional queries, append "_paginate" to the initial count query key so that both are cached separately.

@SacredSkull  Why did you close this ? does the referenced PR fix your issue?

authors: SacredSkull nibsirahsieu


text:
Why does Prose.io ask for access to my private repos?

I don't want to give unknown third-parties access to my company's private repos, but this cannot be deselected during the authentication process.
Until this is changed, I cannot try out this tool.

Dupe of https://github.com/prose/prose/issues/126

authors: letsgetrandy mikemorris

repo: prose/prose


text:
Prose cannot handle slash branches e.g f/newfeature

This doesn't look to be a url encoding issue.
Repro steps:

Using Prose navigate to a repo that has branches with slashes in the name.
Select a branch with a slash in the name e.g f/branch

Results:
Page 404s when it tries to load the branch.

Unfortunately, a known issue. Duplicate of #841.
I'd love to review a PR to fix this. Diagnosis in the ticket I linked to.

authors: dereklieu richardofortune


text:
Category: Charities

A list of places y'all can donate all over the world. Many of the places we link to already have donate options but lets make a specific category for this.
New Links

GivePower
MyCliamte Offset Projects

We need to get all the ucsusa.org greenpeace everyone fighting the climate crisis that are having to do double the work on a much reduced budget now that COVID-19 is distracting people from shit like EPA rollbacks on industry pollution levels and vehicle standards.
https://thehill.com/policy/energy-environment/489753-epa-suspends-enforcement-of-environmental-laws-amid-coronavirus

The Trump administration has finalized new fuel efficiency standards, lowering expectations from 54 miles per gallon by 2025 to 40 miles a gallon by 2030.

https://blog.ucsusa.org/dave-cooke/trump-administration-finalizes-car-rule-which-will-worsen-economy-public-health
https://www.nytimes.com/2020/03/30/climate/trump-fuel-economy.html


text:
🛑 dnslink.org is down

In 654ac85, dnslink.org (https://dnslink.org) was down:

HTTP code: 502
Response time: 413 ms

Resolved: dnslink.org is back up in 6346a3a after 6 minutes.

repo: protocol/upptime-pln


text:
Add 24/7 CFE

Insert URLs to the project here:
https://github.com/PyPSA/247-cfe

[x] The projects is active, documented, open source licensed, shows usage from external parties and is directly targeting environmental sustainability. Find more details in the Contribution Guide.

All issues labeled as 'Good First Issue' of the project listed on OpenSustain.tech will be visible on ClimateTriage.com. This is a great way to welcome new community members to your project.

@Irieo

repo: protontypes/open-sustainable-technology


text:
CRITICAL ISSUE: Account cannot connect to agents

Describe the bug
Multiple accounts in Origin Asia that I have created and tested became unable to connect to their agents. As a result, these accounts are locked out completely.
I believe this is related to the update on 4th October to clear the databases in Origin Asia since I had never seen this kind of error before the update.
I could not figure out the cause of these errors as they seem to appear at random. @dhh1128 hypothesized that this error occurs when too many browser windows (6 windows) are opened simultaneously. It turns out not to be the case since the same error still occurs to more of my newly created accounts even though I wasn't using them.
Here are the list of affected accounts:

qar1@enauthn.id ZsYWGPeTxgPOlcxX1Esx5
qar2@enauthn.id ORBGa4ADp4zn5oBGognhB
qar1@enauthn.dev CF0KaynOunMGuBdk6kD0s
qar2@enauthn.dev EbT6PB116pNq1n73xhdkp
qar3@enauthn.dev RwtabKxBioqQAcc6WwS3h
qar4@enauthn.dev cL40hoY5XcVvwkOr5gLut
qar5@enauthn.dev o09l0tIuzLHjt4vaTuToc
qar6@enauthn.dev 0NN3refPqEn0VnZhz67Vb
qar4@enauthn.io AYycZexAceKQ90UFU8ai0
qar5@enauthn.io jr0lHTNEvbTR568vhFHCA
qar6@enauthn.io eYjEzr1gS8m2DKmPEbxHm

To Reproduce
Unknown
Expected behavior
The accounts should be able to connect to KERIA agents
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

OS: MacOS Sequoia 15.0.1
Browser: Brave, Chrome, Edge

Error messages from Chrome Dev Tool
CognitoUserPool.js:1 [zustand devtools middleware] Please install/enable Redux devtools extension
(anonymous) @ CognitoUserPool.js:1
Show 1 more frame
Show less
CognitoUserPool.js:1 Processing auto-todo of type notification.auto-todo-user-onboarding-complete  {"id":"e83507db-1d00-49f5-8eef-fbdd47ada67e","description":"notification.auto-todo-user-onboarding-complete","title":"","createdAt":1730509599526,"userId":"7dc2d5f6-aa81-4cb5-8e37-6a02a934d301","channel":"AUTO_TODO","read":false}
CognitoUserPool.js:1 AUTO_TODO_HANDLER_ERROR ::  TypeError: Cannot read properties of null (reading 'identifiers')
    at d (CognitoUserPool.js:1:1)
    at P (CognitoUserPool.js:1:1)
    at Q.handleAutoTodoNotification (CognitoUserPool.js:1:1)
(anonymous) @ CognitoUserPool.js:1
Show 1 more frame
Show less
identifiers:1 [DOM] Found 2 elements with non-unique id #alias: (More info: https://goo.gl/9p2vKq) <input class="block w-full h-[44px] border px-3 py-2.5 rounded-md font-light text-sm hover:border-neutralsAdditional800 visited:border-neutralsAdditional800 focus-visible:outline-none focus-visible:border-royalBlue disabled:text-neutralsAdditional500 disabled:border-neutralsAdditional400 disabled:bg-grey200 border-neutralsAdditional400 rounded-lg p-2.5 text-sm" id="alias" name="alias"> <input class="block w-full h-[44px] border px-3 py-2.5 rounded-md font-light text-sm hover:border-neutralsAdditional800 visited:border-neutralsAdditional800 focus-visible:outline-none focus-visible:border-royalBlue disabled:text-neutralsAdditional500 disabled:border-neutralsAdditional400 disabled:bg-grey200 border-neutralsAdditional400 rounded-lg p-2.5 text-sm" id="alias" name="alias">
CognitoUserPool.js:1

       GET https://dev.asia.origincloud.net/v1/keria/admin/agent/EL7c23esz-u6ARvfUlhbQXWYcTFJKlaFUDq9cebKuMFr 500 (Internal Server Error)
(anonymous) @ CognitoUserPool.js:1
state @ index.mjs:38
connect @ index.mjs:38
f @ CognitoUserPool.js:1
await in f
connectToAgent @ CognitoUserPool.js:1
v @ CognitoUserPool.js:1
await in v
onClick @ CognitoUserPool.js:1
eV @ react-dom.production.min.js:54
eW @ react-dom.production.min.js:54
(anonymous) @ react-dom.production.min.js:55
rn @ react-dom.production.min.js:55
rt @ react-dom.production.min.js:106
(anonymous) @ react-dom.production.min.js:117
oN @ react-dom.production.min.js:274
eF @ react-dom.production.min.js:52
ri @ react-dom.production.min.js:109
nV @ react-dom.production.min.js:74
nI @ react-dom.production.min.js:73
a @ CognitoUserPool.js:1
Show 19 more frames
Show less
CognitoUserPool.js:1 INIT_CLIENT_ERROR::: TypeError: Cannot read properties of undefined (reading 's')
(anonymous) @ CognitoUserPool.js:1
f @ CognitoUserPool.js:1
await in f
connectToAgent @ CognitoUserPool.js:1
v @ CognitoUserPool.js:1
await in v
onClick @ CognitoUserPool.js:1
eV @ react-dom.production.min.js:54
eW @ react-dom.production.min.js:54
(anonymous) @ react-dom.production.min.js:55
rn @ react-dom.production.min.js:55
rt @ react-dom.production.min.js:106
(anonymous) @ react-dom.production.min.js:117
oN @ react-dom.production.min.js:274
eF @ react-dom.production.min.js:52
ri @ react-dom.production.min.js:109
nV @ react-dom.production.min.js:74
nI @ react-dom.production.min.js:73
a @ CognitoUserPool.js:1
Show 17 more frames
Show less
connections:1 [DOM] Found 3 elements with non-unique id #alias: (More info: https://goo.gl/9p2vKq) <input class="block w-full h-[44px] border px-3 py-2.5 rounded-md font-light text-sm hover:border-neutralsAdditional800 visited:border-neutralsAdditional800 focus-visible:outline-none focus-visible:border-royalBlue disabled:text-neutralsAdditional500 disabled:border-neutralsAdditional400 disabled:bg-grey200 border-neutralsAdditional400 rounded-lg p-2.5 text-sm" id="alias" name="alias"> <select class="block w-full border disabled:cursor-not-allowed disabled:opacity-50 bg-gray-50 border-gray-300 text-gray-900 focus:border-blue-500 focus:ring-blue-500 dark:border-gray-600 dark:bg-gray-700 dark:text-white dark:placeholder-gray-400 dark:focus:border-blue-500 dark:focus:ring-blue-500 rounded-lg p-2.5 text-sm" id="alias" name="alias">…</select> <select class="block w-full border disabled:cursor-not-allowed disabled:opacity-50 bg-gray-50 border-gray-300 text-gray-900 focus:border-blue-500 focus:ring-blue-500 dark:border-gray-600 dark:bg-gray-700 dark:text-white dark:placeholder-gray-400 dark:focus:border-blue-500 dark:focus:ring-blue-500 rounded-lg p-2.5 text-sm" id="alias" name="alias">…</select>
identifiers:1 [DOM] Found 2 elements with non-unique id #alias: (More info: https://goo.gl/9p2vKq) <input class="block w-full h-[44px] border px-3 py-2.5 rounded-md font-light text-sm hover:border-neutralsAdditional800 visited:border-neutralsAdditional800 focus-visible:outline-none focus-visible:border-royalBlue disabled:text-neutralsAdditional500 disabled:border-neutralsAdditional400 disabled:bg-grey200 border-neutralsAdditional400 rounded-lg p-2.5 text-sm" id="alias" name="alias"> <input class="block w-full h-[44px] border px-3 py-2.5 rounded-md font-light text-sm hover:border-neutralsAdditional800 visited:border-neutralsAdditional800 focus-visible:outline-none focus-visible:border-royalBlue disabled:text-neutralsAdditional500 disabled:border-neutralsAdditional400 disabled:bg-grey200 border-neutralsAdditional400 rounded-lg p-2.5 text-sm" id="alias" name="alias">
connections:1 [DOM] Found 3 elements with non-unique id #alias: (More info: https://goo.gl/9p2vKq) <input class="block w-full h-[44px] border px-3 py-2.5 rounded-md font-light text-sm hover:border-neutralsAdditional800 visited:border-neutralsAdditional800 focus-visible:outline-none focus-visible:border-royalBlue disabled:text-neutralsAdditional500 disabled:border-neutralsAdditional400 disabled:bg-grey200 border-neutralsAdditional400 rounded-lg p-2.5 text-sm" id="alias" name="alias"> <select class="block w-full border disabled:cursor-not-allowed disabled:opacity-50 bg-gray-50 border-gray-300 text-gray-900 focus:border-blue-500 focus:ring-blue-500 dark:border-gray-600 dark:bg-gray-700 dark:text-white dark:placeholder-gray-400 dark:focus:border-blue-500 dark:focus:ring-blue-500 rounded-lg p-2.5 text-sm" id="alias" name="alias"><option value>Identifier</option>slot</select> <select class="block w-full border disabled:cursor-not-allowed disabled:opacity-50 bg-gray-50 border-gray-300 text-gray-900 focus:border-blue-500 focus:ring-blue-500 dark:border-gray-600 dark:bg-gray-700 dark:text-white dark:placeholder-gray-400 dark:focus:border-blue-500 dark:focus:ring-blue-500 rounded-lg p-2.5 text-sm" id="alias" name="alias">…</select><option value>Identifier</option>slot</select>

I noticed another issue that may be related. When I created a new account, generate a passcode, and paste it on the "Confirm your passcode" box, I encounter An error has occurred, please try again later.

The error of the Chrome dev tool is below.
CognitoUserPool.js:1 [zustand devtools middleware] Please install/enable Redux devtools extension
(anonymous) @ CognitoUserPool.js:1
Show 1 more frame
Show less
/v1/user-mgmt/auth/onboard:1

       Failed to load resource: the server responded with a status of 400 ()
/v1/keria/admin/identifiers:1

       Failed to load resource: the server responded with a status of 400 ()
CognitoUserPool.js:1 INIT_CLIENT_ERROR::: Error: HTTP POST /identifiers - 400  - {"title": "400 Bad Request", "description": "unknown witness BG6aVhGdmp-XtyvWE566MxTwAca3877ru0ni1TgBTv7c"}
(anonymous) @ CognitoUserPool.js:1
Show 1 more frame
Show less
/v1/keria/admin/identifiers/-as-user-at-origin:1

       Failed to load resource: the server responded with a status of 404 ()
/v1/keria/admin/identifiers/-as-user-at-origin/oobis?role=agent:1

       Failed to load resource: the server responded with a status of 404 ()

[from twin in jira]
This issue is being tracked in jira at https://eipi.atlassian.net/browse/DF-2566.
To send new comments there, start them with 'Tell jira:'.
The issue is assigned in jira to Cal Warshaw.
As of 2024-11-04T07:23Z, the status of the issue in jira is 'to do'.

[from twin in jira]
The issue is assigned in jira to Arshdeep Singh.
At 2024-11-05T09:02Z, Daniel Hardman said: Arsh has observed an interesting event in the logs that is almost certainly related to the root cause. He is investigating.

[from twin in jira]
As of 2024-11-05T16:51Z, the status of the issue in jira is 'doing'.
At 2024-11-05T16:51Z, Arshdeep Singh said: This issue is occurring for these accounts because there is a {{dot}} in the org name, for example, {{enauthn.id}},  {{enauthn.dev}}  The reason is that registry records stored in the {{regs}} table are keyed by the Registry Name like for the first account, one of the keys is {{enauthn.id-as-qvi-reg}}. The {{regs}} table is of type {{Komer}}, and in this type, the {{dot}} is used as a separator for combining a tuple of string keys into key bytes. When retrieving values from the database, the keys tuple is separated by splitting at this separator. Therefore, the db key for {{enauthn.id-as-qvi-reg}} becomes {{('enauthn', 'id-as-qvi-reg')}}. This causes an exception with the error {{ValueError: too many values to unpack (expected 1)}}.
We should avoid using {{dot}} in the org name or in the user’s first and last names. We will also add a validation check during onboarding to prevent the use of {{dot}} in names.

Tell Jira:
@Arsh-Sandhu the error also occurs if either name or surname has a {{dot}}.

repo: provenant-dev/origin-community


text:
Support py3.12

New feature motivation
Support py3.12
Solution Proposed
Relax constraint
Describe alternatives you've considered

none

Additional context
No response

https://github.com/prowler-cloud/prowler/pull/3271

repo: prowler-cloud/prowler