Can't install native-base

Description
ERESOLVE unable to resolve dependency tree
CodeSandbox/Snack link
no
Steps to reproduce
Latest expo sdk 47

NativeBase Version
3.4.21
Platform

[X] Android
[ ] CRA
[X] Expo
[X] iOS
[ ] Next

Other Platform
No response
Additional Information
No response

Hi,
I have the same problem, on the iphone emulator it works but using the android emulator it doesn't
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/react
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer react@"16 || 17" from<EMAIL_ADDRESS>npm ERR! node_modules/@react-native-community/cameraroll
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!   peer @react-native-community/cameraroll@">= 1.5.2" from<EMAIL_ADDRESS>npm ERR!   node_modules/@ant-design/react-native
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR!
npm ERR! For a full report see:
npm ERR! /Users/cleytonchagas/.npm/_logs/2022-11-10T12_31_52_405Z-eresolve-report.txt
"dependencies": {
"@ant-design/react-native": "^5.0.2",
"@expo/webpack-config": "^0.17.0",
"@react-native-community/cameraroll": "^4.1.2",
"@react-native-community/segmented-control": "^2.2.2",
"@react-native-community/slider": "^4.3.2",
"@react-native-picker/picker": "^2.4.8",
"@react-navigation/bottom-tabs": "^6.4.0",
"@react-navigation/native": "^6.0.13",
"@react-navigation/native-stack": "^6.9.1",
"@types/styled-components-react-native": "^5.1.3",
"expo": "~46.0.16",
"expo-splash-screen": "~0.16.2",
"expo-status-bar": "~1.4.0",
"lottie-react-native": "^5.1.4",
"native-base": "^3.4.21",
"react": "18.0.0",
"react-devtools": "^4.26.1",
"react-dom": "18.0.0",
"react-hook-form": "^7.39.1",
"react-native": "0.69.6",
"react-native-circular-progress-indicator": "^4.4.0",
"react-native-gesture-handler": "^2.8.0",
"react-native-iphone-x-helper": "^1.3.1",
"react-native-reanimated": "^2.12.0",
"react-native-responsive-fontsize": "^0.5.1",
"react-native-safe-area-context": "4.3.1",
"react-native-screens": "~3.15.0",
"react-native-svg": "12.3.0",
"react-native-svg-charts": "^5.4.0",
"react-native-vector-icons": "^9.2.0",
"react-native-web": "~0.18.7",
"styled-components": "^5.3.6"
},
"devDependencies": {
"@babel/core": "^7.12.9",
"@types/react": "~18.0.14",
"@types/react-native": "~0.69.1",
"@types/react-native-svg-charts": "^5.0.12",
"@types/react-native-vector-icons": "^6.4.12",
"@types/styled-components": "^5.1.26",
"@typescript-eslint/eslint-plugin": "^5.40.1",
"@typescript-eslint/parser": "^5.40.1",
"babel-eslint": "^10.1.0",
"eslint": "^8.25.0",
"eslint-config-universe": "^11.1.0",
"prettier": "^2.7.1",
"react-native-svg-transformer": "^1.0.0",
"typescript": "^4.8.4",
"typescript-styled-plugin": "^0.18.2"
},

The ideal would be to remove react and react native from package.json ? I just followed expo.docs and created a project with expo and then installed native-base

I don't see how that would work - the versions conflict within native-base itself. Minimal reproduction steps (valid until the next react-native update probably, but would break again in the future):
mkdir only_native_base
cd only_native_base
npm init
npm i<EMAIL_ADDRESS>
It breaks with the following err:
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/react
npm ERR!   peer react@"*" from<EMAIL_ADDRESS>npm ERR!   node_modules/native-base
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/react-dom
npm ERR!     peer react-dom@"*" from<EMAIL_ADDRESS>npm ERR!     node_modules/native-base
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/react-native
npm ERR!   peer react-native@"*" from<EMAIL_ADDRESS>npm ERR!   node_modules/native-base
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /home/dekondra/.npm/eresolve-report.txt for a full report.

Hi, i'm facing the same issue

The issue of the standalone install still persist, but I am now able to install native-base in expo without errors (albeit with many warnings). And hey, I've learnt a bit about peer dependencies along the way.
What I did was:

Explicitly expo install the dependencies mentioned when attempting to install native-base, going back to this step if native-base throws more errors of the same kind. In this case, only:

expo install react-dom

Install native-base

expo install native-base

Every time I run expo install - on its own or with some packages, it spews out a conflicting peer dependency error, but seems to work alright.

It happens to me as well.
While @LinasKo suggestion might work, I don't feel safe about upgrading my app to sdk 47 at this stage.

To those creating a NEW project, I was able to bypass this by downgrading the native-base Typescript template to v6.12.7 using the following command:
npx react-native init MyApp --template<EMAIL_ADDRESS>

Created the app with
npx create-expo-app my-app --template blank@45
and will upgrade as soon as native-base is compatible

Hi everyone, It's not a native-base Issue. Node version v16.13.0 have npm v8.1.0. Node 17 and above have npm v8.11 and above. for some reason it is mandatory to use --legacy-peer-deps or --force to install peerDependancies which are not an exact match from npm v8.5 and above. For more details, you can check the issue on npm CLI here.
As you can see in the error itself native-base has a * as a dependency so having react@18 shouldn't cause any error.

Hi everyone, It's not a native-base Issue. Node version v16.13.0 have npm v8.1.0. Node 17 and above have npm v8.11 and above. for some reason it is mandatory to use --legacy-peer-deps or --force to install peerDependancies which are not an exact match from npm v8.5 and above. For more details, you can check the issue on npm CLI here. As you can see in the error itself native-base has a * as a dependency so having react@18 shouldn't cause any error.
Let me know if this works for you.

Although it works to install native-base like that, the expo install<EMAIL_ADDRESS>still fails afterward.

Seems to work if you install react-dom first:
npx expo install react-dom
npx expo install native-base
I get lots of these warnings:
npm WARN ERESOLVE overriding peer dependency
npm WARN ERESOLVE overriding peer dependency
npm WARN ERESOLVE overriding peer dependency

Just a clue but I think there is a way to force everything to use a specific dep in package.json:
For npm:
"overrides": {
"react": "18.1.0"
}
For yarn:
"resolutions": {
"react": "18.1.0"
}

Just a clue but I think there is a way to force everything to use a specific dep in package.json:
For npm:
"overrides": { "react": "18.1.0" }
For yarn:
"resolutions": { "react": "18.1.0" }

@jpschw did you install NativeBase for an existing project?

I have upgrade Expo from SDK46 to SDK47 two days ago.
Today i've decided to Migrate my app view component to native-base.
npx expo install native-base fails. This seems to ignore my .npmrc file where i set legacy-peer-deps=true.
On the other hand expo install native-base i assume this does not ignore my .npmrc file.

let me clear some doubts. when you do expo install <some-package> it goes into your directory and searches for lock file and depending upon which lock file you have it just runs that package manager.
Example:- if you run expo install native-base and you have package-lock.json it executes npm install native-base
Now as mentioned by @ankit-tailor from the npm version v8.11 if you don't have exact matching peerDependancy. you have to add legacy-peer-deps flag.

Guys, time is passing and the solution doesn't appear, issues and more repeated issues without a definitive solution, it complicates to continue using the library in production.

Is that fixed?

Hi everyone, It's not a native-base Issue. Node version v16.13.0 have npm v8.1.0. Node 17 and above have npm v8.11 and above. for some reason it is mandatory to use --legacy-peer-deps or --force to install peerDependancies which are not an exact match from npm v8.5 and above. For more details, you can check the issue on npm CLI here. As you can see in the error itself native-base has a * as a dependency so having react@18 shouldn't cause any error.
Let me know if this works for you.

Getting almost the same error, just have the most recent native-base version (3.4.28). This is also explained here in another similar issue. I tried using node 16.13.0 and had no luck though (I'm not using expo). It's strange because one day it will happen and the next day it won't, when I haven't changed anything.


SSL Check and Kind 3 Management

Also some other stuff you might wanna check out
Resolves #216
Resolves #189

Woah! Amazing!

@Cameri Read to ship?

@Cameri Ready to ship? Made some updates

Looks solid to me!

Polished, ready for staging

Can't merge into production until I've dealt with #215


Selenoid throws Unauthorized access when running chromedriver.exe  v2.41 with whitelisted-ips option

It helped to replace --whitelisted-ips='' to --whitelisted-ips

Event the ChromeDriver.exe 2.45 is having same issue when i am trying to access using white listed IP i am getting error as Unauthorized access

For build 2.45.615291 (ec3682e3c9061c10f26ea9e5cdcf3c53f3f74387)"
when i manually tried added both machines in --whitelisted-ips=''XX.XXX.XXX.XX","XXX.XX.XXX.XX"
it worked for me .
also it works with chromedriver.exe --whitelisted-ips


Sometimes no QA values are received by mros1_reasoner

Context:

all metacontrol monitoring input is sent via /diagnostics (probably not the best idea I ever had). This input is mainly messages about QA values for energy and safety
in our system, /ekf_localization is also publishing in /diagnostics
a callback in mros1_reasoner process these messages to update the KB (runtime ontology in memory)

Problem
Sometimes no QA values at all are received by mros1_reasoner
See TEST 1 below
This is tricky because it only happens sometimes, especially for energy (maybe because they are published less frequently)
See TEST 2
I have checked that sometimes energy and safety messages are published see TEST 3
Maybe this is related to the messages published in topic /diagnostics
Could it be that the diagnostic messages from /ekf_localization are "jamming" the topic?
@marioney @gavanderhoorn advice from ROS experts is needed here.
Tests
TEST 1: no QA value messages in /diagnostics at all? At least not received by mros1_reasoner
Terminal 1: simulation + navigation + rosgraph_monitor+ rosgraph_manipulator
roslaunch metacontrol_sim MVP_metacontrol_world.launch

OUTPUT analysis: All seems to work as expected
Terminal 2: rostopic echo /diagnostics
header:
  seq: 20
  stamp:
    secs: 19
    nsecs:  60000000
  frame_id: ''
status:
  -
    level: 0
    name: "ekf_localization: Filter diagnostic updater"
    message: "The robot_localization state estimation node appears to be functioning properly."
    hardware_id: "none"
    values: []
  -
    level: 0
    name: "ekf_localization: odometry/filtered topic status"
    message: ''
    hardware_id: "none"
    values:
      -
        key: "Events in window"
        value: "502"
      -
        key: "Events since startup"
        value: "952"
      -
        key: "Duration of window (s)"
        value: "10.040000"
      -
        key: "Actual frequency (Hz)"
        value: "50.000000"
      -
        key: "Minimum acceptable frequency (Hz)"
        value: "43.200000"
      -
        key: "Maximum acceptable frequency (Hz)"
        value: "57.200000"
... __AND ONLY MESSAGES LIKE THE ONE ABOVE__

OUTPUT analysis: All seems to work as expected
Terminal 3: mros1_reasoner
roslaunch mros1_reasoner run.launch onto:=mvp.owl
 ...
RELEVANT OUTPUT
----------------------------
FG Statuses:
fg_standard      None    []

OUTPUT analysis: The callback for message reception does not seem to be triggered, since there is no output like this:
[INFO] [1590055021.497386, 38.601000]: received QA observation
TEST in which only QA values on safety are received
Terminal 1: simulation + navigation + rosgraph_monitor+ rosgraph_manipulator
roslaunch metacontrol_sim MVP_metacontrol_world.launch

OUTPUT analysis: All seems to work as expected
Terminal 2: rostopic echo /diagnostics
Unfortunately not recorded, trying to reproduce
Terminal 3: mros1_reasoner
roslaunch mros1_reasoner run.launch onto:=mvp.owl
 ...
RELEVANT OUTPUT
----------------------------
[INFO] [1590055014.832565, 36.205000]: received QA observation
received QA about:  mvp.fg_standard     TYPE:  safety
              __5-6 LIKE THE ONE ABOVE on each reasoning period__
...
FG Statuses:
fg_standard      None    [('obs_mvp.safety_10', 1.0), ('obs_mvp.safety_14', 1.0), ('obs_mvp.safety_24', 1.0), ('obs_mvp.safety_33', 1.0), ('obs_mvp.safety_41', 1.0), ('obs_mvp.safety_52', 1.0), ('obs_mvp.safety_61', 1.0)]

OUTPUT analysis: The callback for message reception is triggered by the received messages with QA safety values
TEST 3
Terminal 1: simulation + navigation + rosgraph_monitor+ rosgraph_manipulator
roslaunch metacontrol_sim MVP_metacontrol_world.launch

OUTPUT analysis: All seems to work as expected
Terminal 2: rostopic echo /diagnostics
...
---
header:
  seq: 4
  stamp:
    secs: 3
    nsecs:         0
  frame_id: ''
status:
  -
    level: 0
    name: "ekf_localization: Filter diagnostic updater"
    message: "The robot_localization state estimation node appears to be functioning properly."
    hardware_id: "none"
    values: []
  -
    level: 0
    name: "ekf_localization: odometry/filtered topic status"
    message: ''
    hardware_id: "none"
    values:
      -
        key: "Events in window"
        value: "147"
      -
        key: "Events since startup"
        value: "147"
      -
        key: "Duration of window (s)"
        value: "3.000000"
      -
        key: "Actual frequency (Hz)"
        value: "49.000000"
      -
        key: "Minimum acceptable frequency (Hz)"
        value: "43.200000"
      -
        key: "Maximum acceptable frequency (Hz)"
        value: "57.200000"
---
header:
  seq: 16
  stamp:
    secs: 2
    nsecs: 802000000
  frame_id: ''
status:
  -
    level: 0
    name: ''
    message: "QA status"
    hardware_id: ''
    values:
      -
        key: "safety"
        value: "1.0"
---
header:
  seq: 17
  stamp:
    secs: 2
    nsecs:   4000000
  frame_id: ''
status:
  -
    level: 0
    name: ''
    message: "QA status"
    hardware_id: ''
    values:
      -
        key: "energy"
        value: "0.233684937159"

...

Maybe this is related to the messages published in topic /diagnostics
Could it be that the diagnostic messages from /ekf_localization are "jamming" the topic?

A temporal fix could be to disable diagnostics for /ekf_localization, but is that possible?
I cannot find how, I do not see any ROS param for that in /ekf_localization
Ideas are welcome @marioney @ipa-hsd

I cannot find how, I do not see any ROS param for that in /ekf_localization

Found it! http://docs.ros.org/melodic/api/robot_localization/html/state_estimation_nodes.html?highlight=diagnostics#print-diagnostics
now I just need to find in our code where we launch /ekf_localization :smile:

Topics cannot be "jammed" actually.
What could happen is that buffers get full, but then I would expect all new messages to not make it into the queue.
Without looking into this in more detail -- and reproducing the setup -- there's not much more I can add I'm afraid.

What could happen is that buffers get full, but then I would expect all new messages to not make it into the queue (not just those from a specific publisher).

Maybe the messages from /ekf_localization are causing the buffer to get full, I guess that also affects rostopic echo ?


HDDS-6507. Spotbugs transitive dependencies may result in NoClassDefFound error

What changes were proposed in this pull request?
Remove unnecessary dependency spotbugs.  Only spotbugs-annotations are needed.
Depending on spotbugs allows using classes from commons-lang instead of commons-lang3.  Code compiles fine, but dependency is not available at runtime, resulting in NoClassDefFoundError.
\- com.github.spotbugs:spotbugs:jar:3.1.12:provided
   ...
   +- commons-lang:commons-lang:jar:2.6:provided

https://issues.apache.org/jira/browse/HDDS-6507
How was this patch tested?
Temporarily added offending import:
diff --git hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3/endpoint/ObjectEndpoint.java hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3/endpoint/ObjectEndpoint.java
index 863b1b08c..373c80f8a 100644
--- hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3/endpoint/ObjectEndpoint.java
+++ hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3/endpoint/ObjectEndpoint.java
@@ -53,6 +53,7 @@
 import java.util.Map;
 import java.util.OptionalLong;

+import org.apache.commons.lang.StringUtils;
 import org.apache.hadoop.hdds.client.ReplicationFactor;
 import org.apache.hadoop.hdds.client.ReplicationType;
 import org.apache.hadoop.hdds.conf.OzoneConfiguration;

Verified it does not compile:
hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3/endpoint/ObjectEndpoint.java:[56,31] package org.apache.commons.lang does not exist

Regular CI:
https://github.com/adoroszlai/hadoop-ozone/actions/runs/2035550297

Thanks @ayushtkn for the review.


Tell us how you use Poli?

Hey Folks,
Thanks so much for using Poli! We'd like to hear more about how you use Poli in your product/company/organization/project and how it helps to solve your problems.
Feel free to leave your product/company/organization/project information below so we can show them on our website(coming soon) and readme file!
Thanks again!

We are using it now for simple BI views in our organization. It is really nice tool for very quick previews. I would really like this project to grow bigger.

Hello, I am from Argentina and I have a software build in Delphi and Mysql, for Billing, Stocks, and Accounting.
I am trying to use Poli as a companion for my software.
I like poli, it is easy to use, and you can do much, in very little time.
An explaining video would help to guess less.


Cannot write to ostream at offset 692. (CANNOT_WRITE_TO_OSTREAM)

facing this issue when running an aggregate query through jdbc client . On jdbc client side its throwing java.sql.BatchUpdateException: Read timed out, server ClickHouseNode [uri=http://localhost:8123/cafebot, options={keepalive=true,queryTimeout=120000,dataTransferTimeout=60000,connectTimeout=120000,socketTimeout=120000}]

Good day, @easy-data !
Which timeout was triggered?
Read timeout may happen when socketTimeout is exceeded.


visible Pet names

Is your feature request related to a problem? Please describe.
when playing with 6 pets  (4 dogs) its hard to tell which dog is who's pet to buff correctly.
Describe the solution you'd like
display pet names.
Describe alternatives you've considered
sort pets in the order of the party they appear in.
Additional context
none.

Hmm, I think this can be done


Guys help

As you know, Im very new to this database thing, i experienced an error whenever i join the game
https://pastebin.com/MF2QaFiZ

That error is detailed on the wiki page here:
https://github.com/lucko/LuckPerms/wiki/Storage-system-errors#luckperms-cannot-connect-to-my-mysql-server
If you have any more troubleshooting problems, feel free to ask on the discord! You'll probably be helped faster! (https://discord.gg/luckperms)


Bake in additional dependencies

The container needs gcc and python3-devel as the dependencies for
the image build process to succeed.

Can one of the admins verify this patch?

LGTM

/retest

There seems to be some dependency issues with the travis env, merging it as the CI just runs tox/linter for the code and the change is in dockerfile.


 I have to kill and reopen it to make it work.
Internet in the same time works perfectly for other apps (browser, for example).
How can I help you for improving this ?
Environment
K-9 Mail version: 5.402 F-droid
Android version: 7.1.2 (LOS)
Account type (IMAP, POP3, WebDAV/Exchange): IMAP

@Massedil thanks for finding this workaround. I can confirm it is working even on AICP Custom ROM.

Hello,
I have investigating for this problem with debug log activated.
Here a fresh log file :
02-22 19:50:39.040 I/MessagingController(5485): Running command 'getFolderUnread:XXXXXXXXXX.YYYY:INBOX', seq = 79 (foreground priority)
02-22 19:50:39.049 I/MessagingController(5485): Command 'getFolderUnread:XXXXXXXXXX.YYYY:INBOX' completed
02-22 19:50:43.285 I/MessagingController(5485): Running command 'synchronizeMailbox', seq = 80 (background priority)
02-22 19:50:43.286 I/MessagingController(5485): Synchronizing folder XXXXXXXXXX.YYYY:INBOX
02-22 19:50:43.287 D/MessagingController(5485): SYNC: About to process pending commands for account XXXXXXXXXX.YYYY
02-22 19:50:43.292 V/MessagingController(5485): SYNC: About to get local folder INBOX
02-22 19:50:43.314 D/LocalFolder(5485): Updated last UID for folder INBOX to 6308
02-22 19:50:43.319 V/MessagingController(5485): SYNC: About to get remote folder INBOX
02-22 19:50:43.321 V/MessagingController(5485): SYNC: About to open remote folder INBOX
02-22 19:50:43.325 V/ImapConnection(5485): conn264303763>>> 127 NOOP
02-22 19:51:43.418 V/ImapConnection(5485): conn160229065>>> 124 NOOP
02-22 19:52:43.896 D/ImapConnection(5485): Connecting to imap.XXXXXXXXXX.YYYY as imap.XXXXXXXXXX.YYYY/A.B.C.D
02-22 19:52:44.124 V/ImapConnection(5485): conn171592757 <<< #null# [OK, [CAPABILITY, IMAP4rev1, LITERAL+, SASL-IR, LOGIN-REFERRALS, ID, ENABLE, IDLE, AUTH=PLAIN], Dovecot ready.]

The problem is always at this moment : V/ImapConnection(5485): connXXXXXXXXXX>>> nnn NOOP.
Here are old logs :
01-20 14:17:48.571 V/ImapConnection(15563): conn229504011>>> 33 NOOP
01-20 14:18:49.008 D/ImapConnection(15563): Connecting to imap.XXXXXXXXXX.YYYY as imap.XXXXXXXXXX.YYYY/A.B.C.D

[...]

01-21 00:52:50.103 V/ImapConnection(15563): conn206356584>>> 9 NOOP
01-21 00:53:50.504 D/ImapConnection(15563): Connecting to imap.XXXXXXXXXX.YYYY as imap.XXXXXXXXXX.YYYY/A.B.C.D

[...]

01-24 18:44:30.870 V/ImapConnection(4218): conn155697025>>> 9 NOOP
01-24 18:45:31.548 D/ImapConnection(4218): Connecting to imap.XXXXXXXXXX.YYYY as imap.XXXXXXXXXX.YYYY/A.B.C.D

So the operation seems to time out.
Sometimes, it works fine :
01-20 14:18:52.421 V/ImapConnection(15563): conn206356584>>> 7 NOOP
01-20 14:18:52.459 V/ImapResponseParser(15563): conn206356584<<<#7# [OK, NOOP completed.]

Is it possible to reduce the time out to something like 2 seconds ?

Here, I think, is the 60 seconds timeout :
https://github.com/k9mail/k-9/blob/master/k9mail-library/src/main/java/com/fsck/k9/mail/store/RemoteStore.java#L29
Here, I think, is the ImapConnection classes that uses this timeout :
https://github.com/k9mail/k-9/blob/master/k9mail-library/src/main/java/com/fsck/k9/mail/store/imap/ImapConnection.java
Here, I think, is the line where the looong NOOP call is done :
https://github.com/k9mail/k-9/blob/master/k9mail-library/src/main/java/com/fsck/k9/mail/store/imap/ImapStore.java#L327

Do you think it is possible to reduce the timeout for the NOOP operation to something more acceptable ? 2 seconds ? 5 seconds ?

A timeout of 2 or 5 seconds is not reasonable for the internet. In rare cases people have a regular network latency in that order.
I believe a better way to fix this is to close IMAP connections in the connection pool after a short timeout, say 5 -10 minutes. Most zombie connections (you can't reach the other side, but as far as your OS is concerned the connection is still established) are due to NAT gateways that kill the mapping of TCP connections after a timeout. Usually that timeout is around 30 minutes, but some providers are more aggressive and use shorter timeouts.

A timeout of 2 or 5 seconds is not reasonable for the internet.

Sure, I suggested it only in the case I described.
But, why don't we close the IMAP connection after using it ? (Except keeping special connections for PUSH, if necessary)
I mean why when 10 minutes after manually fetching my emails, there is still an open TCP connection that we try to reuse ?

It was like this when I joined the project. So I can only speculate. My guess is because of the "high" cost of establishing a connection and logging in (there's quite a bit of back and forth). Opening an unread message usually triggers a 'mark as read' operation that sends a command to the server. You don't want to create new IMAP connections for that all the time when you can reuse an existing one.

Ok, well, I understand that : it's better to do not open a new connection for each instruction to send to the server.
So, in that case, for me, a reasonable time to keep a TCP connection opened in the pool is not about minutes but seconds (still except for IMAP PUSH). Closing a TCP connection in the pool after 30 seconds of inactivity seems good, no ?
Because what we want to avoid is creating and destroying a lot of TCP connection, not keeping a TCP connection opened for minutes.

What do you think about that ?

I don't see anything wrong with keeping a connection open for a couple of minutes. I don't want to optimize for super aggressive NAT gateways that break the internet.
A timeout of 30 seconds means you have to be done reading an email in 30 seconds in order to be able to reuse the IMAP connection when you trigger a mark as read upon opening the next email. It feels like that would make the connection pool almost useless.

A timeout of 30 seconds means you have to be done reading an email in 30 seconds in order to be able to reuse the IMAP connection when you trigger a mark as read upon opening the next email. It feels like that would make the connection pool almost useless.

I agree.
So, may be close TCP connections after some seconds when the app is in the background ? And/or if the screen is off ? In this case, there is no need to keep them open, no ?

I believe a better way to fix this is to close IMAP connections in the connection pool after a short timeout, say 5 -10 minutes.

After, may be your proposition will work, but it is just that I think keeping an opened TCP connection on a mobile device for 5/10 minutes without sending nothing on it will possibly fail, like now. And be blocked by the long 60 seconds timeout in that case.
Here they speak about difficulty to keep a TCP connection opened :
https://stackoverflow.com/questions/865987/
May be there is two approach to solve the problem :

Trying to keep a TCP connection opened the maximum possible time (like now)

If the connection is opened since a long time, use a smaller time out : more the last sent command is far, less will be the timeout value. (not like now)

Close the TCP connection when it's accurate

When the user is using the app, try to reuse connections.
When the user is not using the app anymore, close the connections.

What is your opinion ?

Are you planning on implementing this? Why are you insisting on a super low timeout being the answer? Did you actually check whether the proposed idle connection timeout of 10 minutes wouldn't work in your case?

Closing TCP connections when the app is not in focus / the screen is off, completely kills background email. It's not a workable solution.
Closing TCP connections that are idle for more than say 30 seconds makes IDLE completely useless because it forces IDLE connections to spam IDLE keep alives.
The person on that StackOverflow post says it's specified in seconds. They aren't saying it's a few seconds.
From Cisco: https://supportforums.cisco.com/t5/network-infrastructure-documents/how-to-configure-a-nat-translation-timeout/ta-p/3109488

TCP translations time out after 24 hours, unless a RST or FIN is seen on the stream, in which case it times out in 1 minute.

We are defaulting to 60 minutes, way inside the standard allowance.

We're only talking about IMAP connections that aren't currently in use and are "parked" in ImapStore's connection pool. Currently we have no timeout to close those parked connections and they can be around for hours. That's also why a NOOP command is sent. It's to test if the connection is still alive before handing it to a caller of ImapStore.getConnection(). If the connection is alive from the OS's point of view but the other side never receives any packets (e.g. NAT mapping was killed), it'll take the read timeout of 60 seconds to detect a connection as dead.
So my suggestion is to close those parked connections before their NAT mapping expires. Usually the NAT timeout is around 30 minutes (so e.g. IMAP IDLE can work). We probably don't need to keep them open for that long. Around 10 minutes sounds like a reasonable value to me. But ideally, we use some mechanism that closes connections when the modem is going to send some data anyway. Otherwise we might wake up the modem just to close a connection.

It's also worth looking at #2652 here - we have a very long read timeout which affects checking for NOOP responses from dead connections.


[Bug]: Wallet balance can be persistently incorrect on restore

Describe the bug
When attempting to recreate https://github.com/synonymdev/bitkit/issues/1806, which I couldn't, I got into the state where the wallet's balance was incorrect given the current transaction history. This can be seen in the Ledger view. In this state, some things such as the transfer slider do not work at all (slider wont move).
I suspect one of the black screen fixes combined with bitkit/pull/1773 may have caused this.
I suspect that during restoration, the wallet can proceed to calculate the balance before it has all the necessary data.
Please retest https://github.com/synonymdev/bitkit/issues/1806 once fixed
Reproduce

With slow network (e.g. HSDPA on android emulator) This is now happening for two of my wallets with fast network
Restore a wallet that has onchain funds and a few historical onchain transactions
Wait for main screen to load and display some balance
Observe to see if balance is correct. Historical transactions may or may not load. I needed to set my network back to faster (LTE). The balance never corrected itself automatically. Needed to manually 'Rescan Addresses' from Advanced settings to set the balance correct.

Screenshots / Recording

Wallet 1
bad_restore.webm

Wallet 2
bad_restore_2.webm
Operating system
Android 14
Bitkit version
2336e54f2712b5025f7d3a121fee028ae69b3797
Log output
No response

Potentially due to throttling from the Electrum server given it's current bitcoind_throttle config setting of 50 20 5 . Will retest once the server's config has been updated. Thread for reference.

This is very similar and fully reproducible on v118
https://github.com/synonymdev/bitkit/assets/74595920/ad00f7f5-5134-46c6-b997-33c8c0174e85

Retest this once the mainnet server has been updated to where it won't throttle you upon restore. Again, please see thread.

once the mainnet server has been updated

Any idea when this might happen?

If the app is getting throttled by the Electrum server (its data source for everything), it will not be able to retrieve the current balance info of a given set of addresses.

When Fulcrum on Mainnet? @dzdidi

@JeanlChristophe , it was there since a year, I think. The lates config update was done on 13:20 (UTC+1), May 28th 2024

@JeanlChristophe as @coreyphillips  mentioned https://github.com/synonymdev/bitkit/issues/1841#issuecomment-2129543285

@catch-21, if you're still experiencing this issue after retesting please DM me your testing mnemonic phrase so I can attempt to reproduce it on my end.

Checked on three of my and I don't think I am seeing this anymore 🙌
Although, the main screen does display before all balances have been determined so I'd like to track that separately: https://github.com/synonymdev/bitkit/issues/1934


Automatically detect visual studio vs 2013 for iojs 2.1.0

hey @lygstate, it's been some time now. was this a placeholder? it's not clear since there's no description

I think this can be closed. Let me know if it should be reopened.

It's resolved long ago.


💭 Escape non-printable characters

Having non-printable characters in the code can be very confusing. I'd suggest automatically reformatting some characters by using their escape sequences instead. Usually, when these types of characters are added to the source code, it's a mistake, and depending on the editor it may well be invisible and therefore very hard/annoying to debug.
// There's a zero-width space between `Hello` and `World`

// Before
console.log("HelloWorld");

// After
console.log("Hello\u200bWorld");

Whitespace
I've personally had problems with U+200B zero-width space and U+00A0 non-breaking space.
But I think it's reasonable to escape all space characters except U+000A newlines (and probably carriage U+000D returns), U+0020 spaces and U+0009 tabs.
Here are other space chars: U+1680 U+2000 U+2001 U+2002 U+2003 U+2004 U+2005 U+2006 U+2007 U+2008 U+2009 U+200A U+2028 U+2029 U+202F U+205F U+3000 U+000B U+000C U+0085 U+202F U+2007 U+2060
Text direction
I've personally had problems with the U+200E left-to-right mark showing up unexpectedly. I don't think it would annoy anyone, but if you want to be conservative, it could be escaped only when the rest of the string is ASCII.
If you don't want to be conservative, we should also escape the U+200F right-to-left mark.
Soft hyphens
U+00AD Soft hyphens also usually don't render at all. Escape them too.
Other control characters
I don't think I've personally ever needed other control characters automatically escaped, but I don't see why not.
A conservative approach would be to skip these until someone has had a problem.
Here's a list: https://www.fileformat.info/info/unicode/char/200f/index.htm

I could have sworn I created an issue related to this, but I might have just added a TODO to create one...
Our current strategy for determining when to escape characters isn't very good. Right now anything that isn't ASCII gets output as a unicode escape inside of strings. It's really an awful experience for users working in different languages.
As far as I know, Prettier gets around this by using the raw values from the parser. I don't like this strategy as it requires keeping track of the original source value as code could have been transformed and the string modified. Babel has a hack where it tags on some additional properties so it can be reconciled. This sort of introspection and duplication isn't good to have in an AST.
We should definitely figure out some better heuristics here.
Related, we have a method called showInvisibles at internal/cli-diagnostics/utils.ts which we use when displaying code snippets. It shows invisible characters such as carriage returns, tabs, spaces, null characters, zero-width spaces etc. This makes it much more obvious when we're displaying diffs where you can't visually see any differences. So there's precedent in Rome for us caring about this.

I assume what you're saying is that there are situations where you don't store the original location, meaning you can't reconstruct the raw value.
I'm not sure that it's possible to have a one-solution-fits-all without keeping at least some raw string values.
Here's me thinking out loud about my needs/preferences:

I always want to escape non-printable chars
I've had a modern environment mangle non-ASCII code (Windows, Visual Studio, Prettier) - so we've had to escape letters that we wouldn't have wanted to escape
I've wanted to use Fontawesome's code points directly in code (e.g. \uf29d) - this I want escaped
I don't want to escape any letters that I can create on my keyboard (for me that's most Latin letters with most diacritic marks)
I want to escape symbols that look like common symbols (e.g. all hyphens except -)
More generally, I want to escape chars that look like "common" chars (e.g. а, which is Cyrillic)
I'm ambivalent about emoji

And here are my corresponding suggestions:
1.
1.


doc command: all links in Scaladoc are hardcoded with "https://scala-lang.org/api/3.x/" as the site root

when I use doc on my projects, such as enum-extensions docs here
it seems literally all links to are prefixed with https://scala-lang.org/api/3.x/, even when not in scala package
e.g.

Maybe this default setting is to blame?
https://github.com/VirtusLab/scala-cli/blob/310895426e322add4ab2cbad2968e8aa1cc814a7/modules/cli/src/main/scala/scala/cli/commands/doc/Doc.scala#L128

looking at the source code for scaladoc, it seems at first glance this regex examines any part of the path where the class came from, naturally this path will include .scala-build, so could this be the reason?


Fixed #31701 -- Made FileDescriptor subclass DeferredAttribute.

Ticket #31701
The model fields use, by default, the descriptor DeferredAttribute to access and process (if necessary) the data associated with them. This type of data represents the actual data in db column. I prefer to call it a “field data”.
To access the field data in instance dict, Field.attname is used as a key.
In addition to the field data, some other model fields (for example, ForeignKey) also use a "client data" of the attribute, the processing of which is performed by a particular descriptor. Such a descriptor is assigned to a model using Field.name.  Its task is to present the same field data in a different format, the result of which differs from the result of field.attname descriptor: article.author returns a User object, and article.auther_id returns a User object pk.
This feature is not used in models.FileField. Then why use FileField.name instead of FileField.attname for FileDescriptor?
I think it would be better if FileDescriptor extends the DeferredAttribute class and uses field.attname instead of field.name.

@felixxm Thank you so much for your comment.
I thought about it when I rewrote the code. By default the super class models.Field uses self.name in Field.save_form_data(). I think this is because Django assumes that form field will always send a "client data" - if it is implemented - (full Python object, e.g. User object), rather than "field data" (raw value, e.g. pk value).
Model fields, as I understand, use self.name to set a value (Field.save_form_data), and self.attname to retrieve a value (Field.value_from_object and Field.pre_save).
Maybe no need to change the base class logic here. This allows other users to extend models.FileField and use self.name to represent a more complex object than FieldFile, while maintaining a reference to the raw FieldFiel object (by using self.attname).

@alosultan Agreed. Thanks!

You’re welcome 👍🏻


UnicodeDecodeError: 'ascii' codec can't decode byte 0xe8 in position 19: ordinal not in range(128)

How did you solve it?


Missing audio format

Describe the bug
Few audio format are missing when searching all audio format
To Reproduce
Steps to reproduce the behavior:

I have an .aac file
Look for audio file on device
AAC file can not be found

Expected behavior
The filepicker should find the aac audio file.
Android info (please complete the following information):

Not relevant

Additional context
Many mime types are missing in:
AudioSelectionArgs.addAll(Arrays.asList("audio/mpeg", "audio/mp3", "audio/x-ms-wma", "audio/x-wav", "audio/amr", "audio/3gp"));
You may use https://developer.android.com/reference/android/media/MediaFormat MIMETYPE_AUDIO_*
Anyway, I think you can look for file with mime type starting with "audio/"
For testing, you may use the audio file from https://docs.espressif.com/projects/esp-adf/en/latest/design-guide/audio-samples.html

Same for image and video files

Can you try out the following release
implementation 'com.github.jaiselrahman:FilePicker:1.4.0-alpha01'

Querying media has been improved.


Arduino simulation page for the library 😀

hi There
Good day
Thank you for the wonderful library for the shift out register.
I am writing this to share with you a link for the Arduino simulation for the useful library you have shared
Permanent link:
https://wokwi.com/arduino/projects/309636841566372416

I would love to hear your feedback on the Arduino simulator can be improved so that, people who create and share libraries be benefitted.
We will be glad, if you also add the link in the ReadMe file so that future readers and visitors will know first-hand the capability of the library.
Please don't hesitate to ask questions and suggest improvements.
Thank you!
Matititam

Can this library use for many 74HC595?

That's amazing, thank you @matititam, I'm impressed by the simulator. Will check it out in greater detail :-)
Out of curiosity: does the simulator also support (fake) SD card modules for examples?

Dear @Simsso It will be awesome fi you can share some feedback.
How can the simulator be helpful t a developer like you? What else would you love to see in the simulator?
It will be fun, if you can say hi to fellow Wokwi users on Discord..at your convenience


Target buffs and debuffs

We need buffs and debuffs on the target frame. They must be filtered, yet possible to view everything.
Buffs and debuffs should be separated, and probably displayed at opposite places for friendly and unfriendly targets. Though we should be able to see what's relevant on both, like ice block on enemy Mages or bubbles on Paladins.
Long term buffs in client versions prior to Legion should be consolidated, to avoid them taking up valuable screen estate and clutter things up.

for what I've seen so far is, that some debuffs are not shown like bloodlust. Is it possible to show longer debuffs?


chore: release main

:robot: I have created a release beep boop
auto-instrumentations-node: 0.45.0
0.45.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/instrumentation-amqplib bumped from ^0.36.0 to ^0.37.0
@opentelemetry/instrumentation-aws-lambda bumped from ^0.40.0 to ^0.41.0
@opentelemetry/instrumentation-aws-sdk bumped from ^0.40.0 to ^0.41.0
@opentelemetry/instrumentation-bunyan bumped from ^0.37.0 to ^0.38.0
@opentelemetry/instrumentation-cassandra-driver bumped from ^0.37.0 to ^0.38.0
@opentelemetry/instrumentation-connect bumped from ^0.35.0 to ^0.36.0
@opentelemetry/instrumentation-cucumber bumped from ^0.5.0 to ^0.6.0
@opentelemetry/instrumentation-dataloader bumped from ^0.8.0 to ^0.9.0
@opentelemetry/instrumentation-dns bumped from ^0.35.0 to ^0.36.0
@opentelemetry/instrumentation-express bumped from ^0.37.0 to ^0.38.0
@opentelemetry/instrumentation-fastify bumped from ^0.35.0 to ^0.36.0
@opentelemetry/instrumentation-fs bumped from ^0.11.0 to ^0.12.0
@opentelemetry/instrumentation-generic-pool bumped from ^0.35.0 to ^0.36.0
@opentelemetry/instrumentation-graphql bumped from ^0.39.0 to ^0.40.0
@opentelemetry/instrumentation-hapi bumped from ^0.36.0 to ^0.37.0
@opentelemetry/instrumentation-ioredis bumped from ^0.39.0 to ^0.40.0
@opentelemetry/instrumentation-knex bumped from ^0.35.0 to ^0.36.0
@opentelemetry/instrumentation-koa bumped from ^0.39.0 to ^0.40.0
@opentelemetry/instrumentation-lru-memoizer bumped from ^0.36.0 to ^0.37.0
@opentelemetry/instrumentation-memcached bumped from ^0.35.0 to ^0.36.0
@opentelemetry/instrumentation-mongodb bumped from ^0.42.0 to ^0.43.0
@opentelemetry/instrumentation-mongoose bumped from ^0.37.0 to ^0.38.0
@opentelemetry/instrumentation-mysql bumped from ^0.37.0 to ^0.38.0
@opentelemetry/instrumentation-mysql2 bumped from ^0.37.0 to ^0.38.0
@opentelemetry/instrumentation-nestjs-core bumped from ^0.36.0 to ^0.37.0
@opentelemetry/instrumentation-net bumped from ^0.35.0 to ^0.36.0
@opentelemetry/instrumentation-pg bumped from ^0.40.0 to ^0.41.0
@opentelemetry/instrumentation-pino bumped from ^0.37.0 to ^0.38.0
@opentelemetry/instrumentation-redis bumped from ^0.38.0 to ^0.39.0
@opentelemetry/instrumentation-redis-4 bumped from ^0.38.0 to ^0.39.0
@opentelemetry/instrumentation-restify bumped from ^0.37.0 to ^0.38.0
@opentelemetry/instrumentation-router bumped from ^0.36.0 to ^0.37.0
@opentelemetry/instrumentation-socket.io bumped from ^0.38.0 to ^0.39.0
@opentelemetry/instrumentation-tedious bumped from ^0.9.0 to ^0.10.0
@opentelemetry/instrumentation-winston bumped from ^0.36.0 to ^0.37.0
@opentelemetry/resource-detector-alibaba-cloud bumped from ^0.28.8 to ^0.28.9
@opentelemetry/resource-detector-aws bumped from ^1.4.1 to ^1.4.2
@opentelemetry/resource-detector-container bumped from ^0.3.8 to ^0.3.9
@opentelemetry/resource-detector-gcp bumped from ^0.29.8 to ^0.29.9

auto-instrumentations-web: 0.39.0
0.39.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/instrumentation-document-load bumped from ^0.37.0 to ^0.38.0
@opentelemetry/instrumentation-user-interaction bumped from ^0.37.0 to ^0.38.0

contrib-test-utils: 0.39.0
0.39.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

host-metrics: 0.35.1
0.35.1 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

id-generator-aws-xray: 1.2.2
1.2.2 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-amqplib: 0.37.0
0.37.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-aws-lambda: 0.41.0
0.41.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-aws-sdk: 0.41.0
0.41.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/propagation-utils bumped from ^0.30.8 to ^0.30.9

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-bunyan: 0.38.0
0.38.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-cassandra-driver: 0.38.0
0.38.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-connect: 0.36.0
0.36.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-cucumber: 0.6.0
0.6.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-dataloader: 0.9.0
0.9.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-dns: 0.36.0
0.36.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-document-load: 0.38.0
0.38.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-express: 0.38.0
0.38.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-fastify: 0.36.0
0.36.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-fs: 0.12.0
0.12.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

instrumentation-generic-pool: 0.36.0
0.36.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-graphql: 0.40.0
0.40.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-hapi: 0.37.0
0.37.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-ioredis: 0.40.0
0.40.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

instrumentation-ioredis: drop @types/ioredis dependency (#2069) (a172f8a)
revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/redis-common bumped from ^0.36.1 to ^0.36.2

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-knex: 0.36.0
0.36.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-koa: 0.40.0
0.40.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-long-task: 0.38.0
0.38.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

instrumentation-lru-memoizer: 0.37.0
0.37.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-memcached: 0.36.0
0.36.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-mongodb: 0.43.0
0.43.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-mongoose: 0.38.0
0.38.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-mysql: 0.38.0
0.38.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-mysql2: 0.38.0
0.38.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/sql-common bumped from ^0.40.0 to ^0.40.1

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-nestjs-core: 0.37.0
0.37.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-net: 0.36.0
0.36.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-pg: 0.41.0
0.41.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/sql-common bumped from ^0.40.0 to ^0.40.1

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-pino: 0.38.0
0.38.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-redis: 0.39.0
0.39.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/redis-common bumped from ^0.36.1 to ^0.36.2

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-redis-4: 0.39.0
0.39.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/redis-common bumped from ^0.36.1 to ^0.36.2

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-restify: 0.38.0
0.38.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-router: 0.37.0
0.37.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-runtime-node: 0.4.0
0.4.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-socket.io: 0.39.0
0.39.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-tedious: 0.10.0
0.10.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

instrumentation-undici: 0.2.0
0.2.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
instr-undici: add instrumentation for undici versions >=5 <7 and global fetch API (#1951) (fe18e2f)
remove generic type from instrumentations (80cbee7)

instrumentation-user-interaction: 0.38.0
0.38.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

instrumentation-winston: 0.37.0
0.37.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
instrumentation-winston: Allow log level to be configured for log sending (#2016) (b903bce)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/winston-transport bumped from ^0.2.0 to ^0.3.0

plugin-react-load: 0.30.1
0.30.1 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

propagation-utils: 0.30.9
0.30.9 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

propagator-grpc-census-binary: 0.27.2
0.27.2 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

propagator-instana: 0.3.2
0.3.2 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

propagator-ot-trace: 0.27.2
0.27.2 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

redis-common: 0.36.2
0.36.2 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

resource-detector-alibaba-cloud: 0.28.9
0.28.9 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

resource-detector-aws: 1.4.2
1.4.2 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

resource-detector-azure: 0.2.7
0.2.7 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

resource-detector-container: 0.3.9
0.3.9 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

resource-detector-gcp: 0.29.9
0.29.9 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

resource-detector-github: 0.28.2
0.28.2 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

resource-detector-instana: 0.9.0
0.9.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.38.0 to ^0.39.0

sql-common: 0.40.1
0.40.1 (2024-04-25)
Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)

winston-transport: 0.3.0
0.3.0 (2024-04-25)
Features

deps: update otel-js to 0.51.0 (80cbee7)
instrumentation-winston: Allow log level to be configured for log sending (#2016) (b903bce)
remove generic type from instrumentations (80cbee7)

Bug Fixes

revert modifications to Apache license (#2105) (4590c8d)
winston-transport: Typescript issue with OpenTelemetryTransportV3 not assignable to TransportStream (#2079) (b006f7f), closes #2015

This PR was generated with Release Please. See documentation.

trentm approved these changes

Ah, I just noticed the browser-test (16) test failure.

Ah, I just noticed the browser-test (16) test failure.

Fixed after a re-run of the failed test, so it was transient.

Tested, thanks everyone for the hardwork.
Appreciated the efforts.

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-alibaba-cloud-v0.28.9 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-aws-v1.4.2 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-azure-v0.2.7 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-container-v0.3.9 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-github-v0.28.2 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-instana-v0.9.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/auto-instrumentations-node-v0.45.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/auto-instrumentations-web-v0.39.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/host-metrics-v0.35.1 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/id-generator-aws-xray-v1.2.2 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/propagation-utils-v0.30.9 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/redis-common-v0.36.2 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/sql-common-v0.40.1 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/contrib-test-utils-v0.39.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/winston-transport-v0.3.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-amqplib-v0.37.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-cucumber-v0.6.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-dataloader-v0.9.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-fs-v0.12.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-lru-memoizer-v0.37.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mongoose-v0.38.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-runtime-node-v0.4.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-socket.io-v0.39.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-tedious-v0.10.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-aws-lambda-v0.41.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-aws-sdk-v0.41.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-bunyan-v0.38.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-cassandra-driver-v0.38.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-connect-v0.36.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-express-v0.38.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-fastify-v0.36.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-generic-pool-v0.36.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-graphql-v0.40.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-hapi-v0.37.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-ioredis-v0.40.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-knex-v0.36.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-koa-v0.40.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mongodb-v0.43.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mysql-v0.38.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mysql2-v0.38.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-nestjs-core-v0.37.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-net-v0.36.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-pino-v0.38.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-redis-v0.39.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-redis-4-v0.39.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-restify-v0.38.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-router-v0.37.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-winston-v0.37.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-document-load-v0.38.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-long-task-v0.38.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-user-interaction-v0.38.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/plugin-react-load-v0.30.1 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/propagator-grpc-census-binary-v0.27.2 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/propagator-instana-v0.3.2 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/propagator-ot-trace-v0.27.2 :sunflower:


OpenAPI doesn't work with tracing::instrument

Expected Behavior
This code should compile:
struct Test {}

#[OpenApi]
impl Test {
    #[oai(path = "/", method = "get")]
    #[tracing::instrument(skip(self), fields(header = header.0.as_deref()))]
    async fn test_instrumenting(
        &self,

        #[oai(name = "X-Header-Name")] header: Header<Option<String>>,
    ) {
    }
}

Actual Behavior
error: expected literal
    --> crates/server/src/http/server.rs:1017:55
     |
1017 |     #[tracing::instrument(skip(self), fields(header = header.0.as_deref()))]
     |                                                       ^^^^^^

Fixed in v1.2.53 🙂


nextcloudPackages.apps don't expose licensing information

The nextcloud package set offers apps, that have licensing information attached, but not exposed as part of their meta attribute.
Also, there are some apps, like news, where the licensing information says null, which requires clarification.
This needs to be fixed. @onny

Thank you @RaitoBezarius for opening the draft PR in order to fix my mistakes and broken packages. I'm sorry for the bad communication and the inability to resolve this serious issue.
Fixing this for Wordpress packages and themes (wp4nix) and Nextcloud apps (nc4nix) in a foreseeable time exceeds my skills and competence. Therefore I would like to offer to add a broken flag to these package sets and remove them for the next release 23.11 if it's not resolved by then.


docstrings and Sphinx autodoc

Hello John,
I am Python intermediate dev looking to make open source contributions and would be glad to help out on this issue.
cheers

Hi! Sure, I'd love some help.
#. Please fork
#. Find some method you want to document in the codebase
#. Follow PEP doc guidelines https://www.python.org/dev/peps/pep-0257/
#. Create PR
Thanks!
John


Ensure kubeval runs on helm template output

I noticed in one of the CI logs a warning from kubeval mentioning an empty document:

It appears that kubeval in the current setup expects a single k8s yaml file so we can instruct helm to generate that instead of a directory which then logs the linting results as expected:

See https://github.com/ascoderu/opwen-cloudserver/issues/246

Codecov Report

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

@@           Coverage Diff           @@
##           master     #317   +/-   ##
=======================================
  Coverage   98.75%   98.75%
=======================================
  Files          14       14
  Lines        1206     1206
=======================================
  Hits         1191     1191
  Misses         15       15

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 aed1a11...a13479f. Read the comment docs.


sql: fix the asyncpg tests to hit cockroach

https://github.com/cockroachdb/cockroach/pull/72161 --- Release note (sql): fix the asyncpg tests to hit cockroach

this was a testing only change, no need for a release note


Development environment / project setup instructions?

Hey! Awesome project :) Would love to contribute a little, unfortunately it's been a while since I've setup a PHP environment. Do you have any light instructions on how to do that?
I'm working on the assumption that this is a standard LAMP stack project? Are there some other things I need to do to get the local development environment working? Thanks!

Dev environment? Just edit on the live site 🤣😂
A standard PHP7 installation should be fine. It isn't using any funky extensions.
You'll need a MySQL database - the structure can be found in the database folder.
Add the login details to config.php
Thay should be sufficient. I'm away from my main computer until Sunday - but I'll do my best to answer any questions you may have.

I've added details to the README. Shout if you need any help.

Thanks @edent . I'll look into helping out when I have a little more free time. The new logo looks great by the way!


Dev

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: nlsdfnbch:x: DevOpsBotDevOpsBot seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


0% and just closes client

It happens every time after server update on all of my computers whats wrong ? Before reintstallation helped but now nothing

Runescape is currently offline while they deal with a bug.

This was caused by OSRS being down


METRON-799: The MPack should function in a kerberized cluster

Contributor Comments
Allows the Ambari Kerberos wizard to handle Metron setup.
Changes include:

Creation of Keytabs
Running everything as the Metron user, including Storm topology workers (on a Kerberized cluster).
Setup for Metron user to actually be able to run (client_jaas setup, home Storm dir setup, etc.)
Adjusting perms to 0755.  The exception is the HDFS output folder on a non-kerb cluster is left as 0775 because we don't have Storm running workers as metron user on.  When Kerberizing, the permissions will be restricted down to 0755.
Kafka ACLs
HBase ACLs
Refactored Topic creation to use a common function so I didn't have to edit the same thing 3 times.
Automated updating of Storm configs (the AutoTGT and running workers as user)

There's still more testing I want to do, but this is definitely far enough along to submit a PR.
I've spun this up on full dev with the now modified Kerberos setup instructions, with the caveat that Ambari's Storm service check fails (it's harmless, as far as I can tell).  See below for more details.  As this does not touch the sensors, data will need to be pushed manually (same as the old instructions).  I've been able to push data from Kafka to Elasticsearch/HDFS.
The Bad News
I would love insight on a problem, if anybody has some.  I haven't edited the docs to reflect this yet, in the hopes it'll be resolved.
Storm's service check will fail during (and after) Kerberization.  Metron can immediately be started perfectly fine.  Nothing is legit wrong, but this setup means that the storm user is unable to submit to the cluster (it doesn't have it's home directory setup with some configs).  Unfortunately, Ambari runs the service check as the storm user.
This can be worked around by creating ~storm/.storm/storm.yaml
nimbus.seeds : ['node1']
java.security.auth.login.config : '/usr/hdp/current/storm-supervisor/conf/storm_jaas.conf'
storm.thrift.transport : 'org.apache.storm.security.auth.kerberos.KerberosSaslTransportPlugin

java.security.auth.login.conf can also be /etc/storm/conf/storm_jaas.conf, but the value above leads me to my next point.  All of these values already exist in storm.yaml.  The fact that they need to be specified again in the user's home is really strange. And it'll give an error that the TGT found is not renewable, not something you'd expected.
I'm unsure if there are restrictions on where Ambari chooses to run service check, so it's possible this would have to be setup on every node Storm lives on the cluster. I'm also unsure if we can actually have Ambari automate this if it turns out to be necessary, since we aren't the Storm service.
Pull Request Checklist
Thank you for submitting a contribution to Apache Metron (Incubating).
Please refer to our Development Guidelines for the complete guide to follow for contributions.
Please refer also to our Build Verification Guidelines for complete smoke testing guides.
In order to streamline the review of the contribution we ask you follow these guidelines and ask you to double check the following:
For all changes:

[x] Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
[x] Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

For code changes:

[x] Have you included steps to reproduce the behavior or problem that is being changed or addressed?

[x] Have you included steps or a guide to how the change may be verified and tested manually?

[x] Have you ensured that the full suite of tests and checks have been executed in the root incubating-metron folder via:
mvn -q clean integration-test install && build_utils/verify_licenses.sh

~Have you written or updated unit tests and or integration tests to verify your changes?~

~If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?~

[x] Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

For documentation related changes:

[x] Have you ensured that format looks appropriate for the output in which it is rendered by building and verifying the site-book? If not then run the following commands and the verify changes via site-book/target/site/index.html:
cd site-book
bin/generate-md.sh
mvn site:site

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
It is also recommened that travis-ci is set up for your personal repository such that your branches are built there before submitting a pull request.

I have a (likely wrong) idea about the service check. A couple of things to check- can you verify that Ambari runs the service check as the storm user, because that's just weird, isn't it? If it does, make sure the user identity it's using is in nimbus.admins. If that doesn't work, maybe try adding the metron user to nimbus.admins.

@dlyle65535 I'll take a look at nimbus.admins.  I'm pretty confident it's running as Storm user though,
Partial output from Ambari:
Traceback (most recent call last):
 ...
    user=params.storm_user

Yeah, reading is FUNdamental. I didn't see that it was the Storm service check that was failing. I kind of made up in my head that it was the Metron service check, because that would make sense.

So coming back to the AutoTGT discussion and making it easier to see.  There's basically two approaches we can takes that (should) work.

The current use of AutoTGT.  This requires setting up .storm/storm.yaml for the Storm nodes, and users will have to do the same.
The AutoHDFS / AutoHBase solution mentioned by @dlyle65535.  This requires symlinking some jars and configs to make them available to Storm.  Should only be necessary for Nimbuses, but it does mean that HDFS/HBase upgrades can make the symlinks stale.

Either solution requires Ambari acting on a different node (potentially) than the one running the scripts.  I don't know if Ambari has any resources for handling that sort of things.  It could potentially be a command over ssh to another node, but presumably that requires passwordless ssh setup or someone to manually create the symlinks (which may be acceptable for this pass).
I'm fairly strongly inclined towards the second one, primarily because it requires less effort on the users part.  Ambari work is fairly similar either way.

Still need to do some additional testing (I'm spiin, but this is updated to pull the topology.auto-credentials down to the topology level.
This should let Storm actually run service check (because AutoTGT isn't initializing).  At the same time, Metron should be able to set these appropriately and run them.   This involves passing the config down to the various files (the .properties files that feed Flux) and updating integration tests slightly.
Oddly enough, the use of the tickets in the client_jaas file caused issues, so it's now using the ticket cache and running a kinit before acting on topologies.  I strongly dislike having the kinits, but there's no obvious reason for the difference in behavior between ticket cache and keytab.

Full dev is able to successfully startup, be Kerberized via Ambari without errors (including Storm service check), and have new data flow through.

Updated to use builtin check for security in stack advisor.  Old versions caused problems because of typing in Python and my lack of catching what it actually does.  Params files should still be fine, because the config objects underneath the covers in Ambari explicitly convert strings to booleans if appropriate.

Update on this:
After a significant amount of pain involved in making this work, we need to have the client_jaas.conf and the metron keytab distributed to the various supervisor nodes so that they can actually be authenticated/authorized as the metron user.
The best discovered solution to this is to have a client that essentially just sets them up (so we can actually create things on the various supervisor servers).  It's not ideal, but @dlyle65535 and I are testing that it works.
To actually set this up, just install Metron clients on all Storm supervisor nodes prior to Kerberization.  Docs will be updated once we confirm that this approach works.

I've run this up on an EC2 cluster, and been able to get data from the core topologies from Kafka to ES/HDFS.  There are a couple caveats spelled out in the metron-deployment README now in a short Kerberos section mentioning that the mpack supports Ambari's Kerberization process.
The client process managed to ensure keytabs existed and that the client_jaas was created appropriately.

I've had 2 successful runs:

Full dev + kerberos.
EC2 will full stack installed prior to enabling kerberos.

Both ran without error.

I validated this on full dev.  Ran a vagrant up, followed the instructions in Kerberos-setup.md, and verified Bro data being written to the index.
+1.  Nice job.

+1 I tested it on AWS and was able to get it to work. Great job!


docs: fix incorrect doc about cluster warming in CDS

For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Description: doc update
Risk Level: low
Testing:
Docs Changes: api/XDS_PROTOCOL.md
Release Notes:
[Optional Fixes #Issue]
[Optional Deprecated:]

Sorry for the trouble :( , fixed for real this time ;p


[desktop_webview_window] listen to page finished loading

I want to listen to the page loaded in the Webiew to parse its content
I get content by
final content = await webview.evaluateJavaScript(
                                 "document.documentElement.outerHTML.toString()");

but it prints
flutter:
I know you have used Future.delay in your example but It is better to listen to the page loaded

And same for URL redirection, I want to listen to the page loaded
 ..addOnUrlRequestCallback((url) async {
                  await Future.delayed(Duration(seconds: 2));
                  final content = await webview.evaluateJavaScript(
                                      "document.documentElement.outerHTML.toString()");
                  print('$content');
                                })

I use this library for scraping HTML content
Thanks for your effort.
I tried to open the macOS folder in Xcode, but there is no project or workspace there to open, only classes
https://github.com/MixinNetwork/flutter-plugins/tree/main/packages/desktop_webview_window/macos

I tried to open the macOS folder in Xcode, but there is no project or workspace there to open, only classes.

You can go to example folder. and open macos/Runner.xcworkspace. then you can find the macos classes in development pods folder.

I want to listen to the page loaded.

Ummm. That's Sounds feasible, but maybe still need took some time to check how to combine WebView2,GtkWebKit,WKWebView all into one library.

@boyan01 a temporary workaround, while content.lenght<100 Future.dalay(1 second
  Future<String?>? getContent() async {
    await Future.delayed(Duration(seconds: 1));

    final content = await webview
        ?.evaluateJavaScript('document.documentElement.outerHTML.toString()');
    if (content!.length < 100) {
      return getContent();
    }
    return content;
  }

I have same request like you!

I found it have isNavigating
https://pub.dev/documentation/desktop_webview_window/latest/desktop_webview_window/Webview/isNavigating.html
Is it possiable add a callback for status change ?

My implementation on @dodatw workaround, just in case someone needed it:
  Future<bool> waitForCompletion() async {
    var completer = Completer<bool>();
    listener() {
      if (webview!.isNavigating.value == false) {
        webview!.isNavigating.removeListener(listener);
        completer.complete(false);
      }
    }

    webview!.isNavigating.addListener(listener);
    return completer.future;
  }


bipartition.is_trivial is True for non-trivial bipartitions in v4.0.3

In the following print() output, I would not expect line 3 to be included because AB | CD isn't a trivial bipartition:
:tree = dendropy.Tree.get_from_string('((A,B),(C,D));', 'newick', rooting=None)
:tree.encode_bipartitions()
:for bipartition in tree.bipartition_encoding:
:    if bipartition.is_trivial:
:        print(bipartition.split_as_newick_string(tree.taxon_namespace))
:
:--
((B, C, D), (A));
((B), (A, C, D));
((C, D), (A, B));
((C), (A, B, D));
((D), (A, B, C));
(A,B,C,D);

I also wouldn't expect the last line to be printed because "rooting=None" so it is partitioning an unrooted tree from nothing. Is this behaviour unexpected?

(1) There is a bug in your code: Bipartition.is_trivial is a
function, not a property or attribute. Perhaps it makes sense for it to
be the latter, but since some calculations go on behind the scenes to
determine this, keeping it as a function alerts the user (or me, at
least, when using it) that the call is not without cost.
The line:
if bipartition.is_trivial

will always return True. It should be:
if bipartition.is_trivial()

(2) As to the fact that "(A,B,C,D)" is considered a bipartition, I can
see why this might be objectionable. Bipartitions or splits correspond
to edges, and while a rooted tree might have an edge for the root, it
does not make sense for an unrooted tree, where the root is an
algorithmic artifact.
However, when dealing with trees with incomplete leafsets, it is useful
to have a bipartition available for inspection/comparison at the root,
to quickly assess which leaves are present in the tree, whether or not
the tree is rooted. So corresponding to the algorithmic convenience (or
necessity) of having a "root" in an unrooted tree, we also find it
algorithmically convenient to have a bipartition corresponding to the
initial split in an unrooted tree in the cases of dealing with trees
with incomplete leaf sets.
-- jeet
On 8/21/15 2:08 PM, daveuu wrote:

In the following print() output, I would not expect line 3 to be
included because AB | CD isn't a trivial bipartition:
|:tree = dendropy.Tree.get_from_string('((A,B),(C,D));', 'newick',
rooting=None) :tree.encode_bipartitions() :for bipartition in
tree.bipartition_encoding: : if bipartition.is_trivial: :
print(bipartition.split_as_newick_string(tree.taxon_namespace)) : :--
((B, C, D), (A)); ((B), (A, C, D)); ((C, D), (A, B)); ((C), (A, B, D));
((D), (A, B, C)); (A,B,C,D); |
I also wouldn't expect the last line to be printed because
"rooting=None" so it is partitioning an unrooted tree from nothing. Is
this behaviour unexpected?
—
Reply to this email directly or view it on GitHub
https://github.com/jeetsukumaran/DendroPy/issues/27.

--

Jeet Sukumaran
<EMAIL_ADDRESS>Blog/Personal Pages:
http://jeetworks.org/
GitHub Repositories:
http://github.com/jeetsukumaran
Photographs (as stream):
http://www.flickr.com/photos/jeetsukumaran/
Photographs (by galleries):
http://www.flickr.com/photos/jeetsukumaran/sets/

That makes sense, thanks.


Use input validators for same password check on change password component

We should do validation (comparison) of new passwords on the change password component using validators that checks if the value are equal and shows UI-hints of bad input, before the user is allowed to actually submit the form to change the password.

Thank you for the suggestion, @sondreb. We will implement input validation for password confirmation in the change password component. This will ensure that the new passwords match and provide UI hints for any discrepancies before form submission. Could you please assign this issue to me?


Migrate from AMS 0.10 to jsonapi-rb for JSON-API implementation

I've really enjoyed the comprehensiveness and configurability of jsonapi-rb. Working with relationships, sparse fieldsets, and JSON API errors feels easier than using AMS.

jsonapi-rb seems to be abandoned at this point, so closing this out


Cut/Paste tool crashes the game when cutting a running laserio setup

Figured something like that would happen
Anyway, here's the pastebin https://pastebin.com/Uq58H0mp

Can you try doing it without any rendering mods like Sodium?

I had the same Crash and disabled Rubidium, it fixed the crash when cutting an inventory with items in it.

Yea, I'll see what I can do to avoid crashes with those mods. I'll have to add them to my dev environment to figure out whats happening

I made an issue over on their repo asking to work together to resolve it - I'll close this one for now.


Request for SF Bay Area config file

Alongside the portland example, can a San Francisco Bay Area example config file be created as well?

This is a cool idea. I'm not sure how many would be practical but there's no reason we couldn't have pre-built examples for a few popular cities.

Hey @3vivekb, I'm not American and not totally 100% on what's defined as the Bay Area, assuming SF and Oakland?
If you could definitely which areas you need I can look in to creating the config file for you.

San Francisco Bay Area usually includes everything in ABAG.

I would also suggest having config files that demonstrate how to add countries & continents.

I've moved this issue from https://github.com/pelias-deprecated/dockerfiles to http://github.com/pelias/docker/, which is better set up to support many config files. As a popular area, a SF Bay area project configuration would be a great addition from someone looking to contribute.


Validate package.json repository url

Hi,
I was recently configuring conventional-github-releaser and it appeared to working, but no release messages were being written to github (but the tags were being created). After a while I realized this was because the wrong repository URL was set in package.json (Another repo i have access to was where the release messages were being written to).
If the repository URL configured in package.json is not the same as the git working directory, should/could a warning be displayed or error be thrown? Although this was a silly error on my behalf, such a simple check could save other users time if they were to make the same mistake.
Adam.

Howdy @adam-26. Thank you for filing your suggestion.
Personally, I wouldn't want to invest to much in implementing this kind of enhancement since, as you hinted at, it's an issue that can arise in pretty much any project, not just when using conventional-github-releaser.
However, I can definitely see the frustration in having this tool work, but not in the desired manner, leaving you with the burden of figuring out what happened, and why.
To help move this discussion forward, I'd like to ask you, and anyone else interested, whether we would ever expect that someone would purposefully want to have their package.json file point to a different repository than their git remote?
If not, then we would just need to see if someone already provides a validation package out there that we can just call.

@hbetts I happened to stumble across here, and yes, there are use cases for having different remotes and package.json repository fields. One of them is having a private fork (in e.g. github enterprise) of an open source project a company contributes to, thus having the private repository as your primary remote, but the open source repository configured in the package.json. I know many big companies do this, facebook is one example. They have their own private repositories and CI pipelines for open source projects, while still contributing changes to the open source version.
I personally wouldn't go presuming too much about github remotes, there's a LOT of edge cases.

Thank you @Tapppi for the detailed explanation you provided for some corporate workflows. It helps to keep me informed on how individuals, teams, and companies use, or may use, tools like conventional-github-releaser and conventional-gitlab-releaser.
@Tapppi you say that we shouldn't presume too much about github remotes (I assume that means git remotes in general). Therefore, I assume switching to just getting git remote origin and using that URL as the Git host may be problematic in many edge cases?
If @stevemao is alright with it, I'd be alright with switching to a package that checked that the URLs matched, and if not, throwed an exception. (Though, I, personally, don't have the time to develop, or maintain such a package, so I would need to rely on the community to develop such a package) As y`all said, that would at least alert users, rather than erroneously publish release information, or indicate success.

Thank you @Tapppi for the detailed explanation you provided for some corporate workflows. It helps to keep me informed on how individuals, teams, and companies use, or may use, tools like conventional-github-releaser and conventional-gitlab-releaser.
@Tapppi you say that we shouldn't presume too much about github remotes (I assume that means git remotes in general). Therefore, I assume switching to just getting git remote origin and using that URL as the Git host may be problematic in many edge cases?
If @stevemao is alright with it, I'd be alright with switching to a package that checked that the URLs matched, and if not, throwed an exception. (Though, I, personally, don't have the time to develop, or maintain such a package, so I would need to rely on the community to develop such a package) As y`all said, that would at least alert users, rather than erroneously publish release information, or indicate success.

Yeah @hbetts I meant git remotes in general. I don't think this is easily solvable, I don't really see git remote origin being much better than the package.json repo field and it would be a breaking change.
Optimally I think the package.json field should stay as the default and it should throw if the remote and repo field differ. You would need to be able to disable it though. The repo could be configurable as an argument, and that could squash the error. Just throwing in ideas. I'm swamped right now too, but maybe I can take a stab at it at some point.

Yeah @hbetts I meant git remotes in general. I don't think this is easily solvable, I don't really see git remote origin being much better than the package.json repo field and it would be a breaking change.
Optimally I think the package.json field should stay as the default and it should throw if the remote and repo field differ. You would need to be able to disable it though. The repo could be configurable as an argument, and that could squash the error. Just throwing in ideas. I'm swamped right now too, but maybe I can take a stab at it at some point.

So I just ran into this issue, and used the --verbose flag to debug and find out that I was essentially getting a 302 status from the node-github callback.
Would it make sense to just print the status out to the console? That way there's some feedback.
I would go a step further and say any non-200 status should print to stderr. Thoughts?


TypeError: Cannot set property overflow of # which has only a getter

Hello, I created a react typescript project using CRA to test out this lib, but i'm getting this error when i use @stitches/tailwind
TypeError: Cannot set property overflow of #<Object> which has only a getter

addDefaultUtils
src/utils.ts:107

  104 |
  105 | export const addDefaultUtils = (config: IConfig) => {
  106 |   config.utils = config.utils || {};
> 107 |   config.utils.overflow = (css) => (
  108 |     value: StandardProperties["overflow"],
  109 |     pseudo?: string
  110 |   ) =>

this is my code
import React from 'react';
import { createCss } from '@stitches/css';
import { tailwind } from '@stitches/tailwind';

const css = createCss(tailwind);

function App() {
  return (

Hello World

  );
}

export default App;

if i use only the css from @stitches/css it works fine, but with the tailwind version, i keep getting this error

Hi there and thanks a bunch for the issue!
I am not sure why this happens, but it led me to see an other bug so I have changed how these default utilities are added so it fixes two issues 😄
If you install latest it is fixed!