Update the govuk frontend toolkit to 4.10.0

Use the latest version of the govuk frontend toolkit.
This won't affect any govuk components, e.g. the phase banner or breadcrumb, updating these will require alphagov/static to be updated.
--
https://github.com/alphagov/govuk_frontend_toolkit/blob/master/CHANGELOG.md
4.10.0

Allow New Transport font stack to be overridden by apps using
$toolkit-font-stack
and $toolkit-font-stack-tabular (PR #230)

4.9.1

Fix phase banner alignment (PR #266)

4.9.0

Add websafe organisation colours
Split colours into two files with backwards-compatible colours.scss
replacement

4.8.2

Add GOV.UK lint to lint scss files (PR #260)
Remove reference to old colour palette (PR #256)
Fix link to GOV.UK elements - tabular data

4.8.1

Update DEFRA brand colour to new green (PR #249)

4.8.0

Pass cohort name to analytics when using multivariate test (PR #251)

4.7.0

Add 'mailto' tracking to GOV.UK Analytics (PR #244)

4.6.1

Use the Sass variable $light-blue for link active and hover colours
(PR #242)

4.6.0

Add breadcrumb styles, separator images and documentation (PR #236)
Add fallback image for the back link (PR #235)

4.5.0

Find and auto-start JavaScript modules from markup:
data-module="module-name"(PR #227)

4.4.0

Add helpers partial for functions
Add px to em function and documentation

4.3.0

Allow javascript error tracking to be filtered to avoid noise from
plugins

4.2.1

Track download links using events not pageviews

4.2.0

Add two analytics plugins for download and external link tracking
Update typography mixins to be mobile first (PR #157)

4.1.1

Update Accessible Media Player to remove dependency on $.browser (PR
#206)

4.1.0

Add support for sending the page option to
GOVUK.analytics.trackEvent (PR #203)

4.0.1

Fix: stop multiline text from dropping below phase tag.

4.0.0

Remove Google Analytics classic
https://github.com/alphagov/govuk_frontend_toolkit/pull/194

References to google-analytics-classic-tracker.js should be removed

Rename GOVUK.Tracker to GOVUK.Analytics

References to GOVUK.Tracker should be updated

3.5.1

Changes Analytics API library to accept one, both or neither of the
analytics tracking codes. This means we can start removing classic
tracking codes from apps.

#3.5.0

Adds cross domain tracking to Analytics API library:
https://github.com/alphagov/govuk_frontend_toolkit/pull/185
Adds sass variables for discovery and live phases

#3.4.2

Fix: Before this fix, when a user fell into variant 0 of a
multivariate test,
the data wouldn't be reported to Google correctly because of a broken
null check in the code block that opts the user into the Google Content
Experiment.

3.4.1

Fix: Make the error colour a darker red for greater contrast and to
meet WCAG 2.0 AAAA
(this was meant to go into 3.3.1 but was lost from history)
Add $focus-colour variable (#180)

3.4.0

multivariate-test.js: add support for using Google Content
Experiments as the reporting
backend for multivariate tests

3.3.1

Fix: Make the error colour a darker red for greater contrast and to
meet WCAG 2.0 AAAA

3.3.0

Add: Analytics - pageview tracking for a print attempt

3.2.1

Fix: Analytics - don't run error and print plugins on load

3.2.0

Add: Analytics API
https://github.com/alphagov/govuk_frontend_toolkit/pull/162
https://github.com/alphagov/govuk_frontend_toolkit/blob/master/docs/anal
ytics.md

3.1.0

Fix: outdent to add right margin rather than only left
Fix: add missing semi-colons in JavaScript files
Fix: use box-sizing mixin in column mixin to support more browsers
Add: ability to specify float direction on column mixin
Add: Sass-lint tests

3.0.1

Fix a bug with the npm publishing. npm requires a version change to
publish a package.

3.0.0

Change publishing method to not use git submodules in
govuk_frontend_toolkit_npm.
This is a major version bump because it will move the toolkit from
./node_modules/govuk_frontend_toolkit/govuk_frontend_toolkit/
to ./node_modules/govuk_frontend_toolkit/, which will break
relative imports in Sass.
Fix typo in Sass comment

:+1:


Ability to query what process(es) hold open fds/handles on a given program/map/link

The netsh helper has had the following TODO in it since the beginning:

// TODO: see if the program is still loaded, in which case some other process holds
// a reference. Get the PID of that process and display it.

However, this needs an API to query that information, which is required by bpftool (and netsh).

@Alan-Jowett can you help track down what the right public APIs are to acquire this information?

I think you can get this using the process snapshot APIs.
// PSS_WALK_SNAPSHOT information classes.
typedef enum
{
PSS_WALK_AUXILIARY_PAGES = 0,
PSS_WALK_VA_SPACE = 1,
PSS_WALK_HANDLES = 2,
PSS_WALK_THREADS = 3
} PSS_WALK_INFORMATION_CLASS;
The sequence would be:

Take snapshot of process list.
Take snapshot of each process.
For each handle, query eBPF for its type info.

Still researching to see if there is a simpler way to do this via public APIs.

I verified a year ago that the APIs Alan mentions above do work.  I have a private branch somewhere with a prototype.

bpftool pids.c has build_obj_refs_table() which returns a mapping from object (program/map/link) ID to set of PIDs.

We now have a way to enumerate processes that have references to ebpf itself, but not at the granularity of individual eBPF programs, maps, or links.


Improve consistency of tests used on L1s.

Overview
This pull request:

Fixes inconsistent behavior between L1s.
Adds tests.

Summary
This PR is the first step in https://github.com/lcache/lcache/issues/70 and is a precursor to a test refactoring in https://github.com/lcache/lcache/pull/72
Description
The test suite currently uses a convention of helper methods (performL1HitMissTest(), performL1AntirollbackTest() etc) along with test* methods per implementation (testStaticL1Antirollback(), testSQLiteL1Antirollback()). I would like to switch to using inheritance or traits to share these tests among implementations (https://github.com/lcache/lcache/pull/72). Before considering that pull request, I'd like to first validate that all of these tests are appropriate to run on all L1s (with the exception of NullL1).
This pull request also makes a change to resolve inconsistent handling of hit/miss counting between the L1 implementations. Right now only the APCuL1 resets its hit/miss count as a result of a cache clear. This PR makes it so that StaticL1 and SQLiteL1 also reset their counts as the result of a cache clear.
The PR also fixes a bug in APCuL1::setWithExpiration() where the $created variable was not used.
Todo

[] Validate with David that the added tests are appropriate to run on all L1s.
[] Determine why testEmptyCleanUpDatabaseL2() makes no assertions. (I suppose this is not a hard blocker but I'd like to get this answered before refactoring tests further)

Coverage remained the same at 100.0% when pulling 35736ea15c74b50eb4144abb54a4cdad93480870 on L1-test-parity into 7adddaa78bf022c6b4a20cb34b0b049bf9146766 on master.

Coverage remained the same at 100.0% when pulling da2f5c3515f52c2f1c3b14bf1b1f971d114e5953 on L1-test-parity into 7adddaa78bf022c6b4a20cb34b0b049bf9146766 on master.

I just had a verbal conversation with Greg and David. They consider this PR ready to merge and would like https://github.com/lcache/lcache/pull/72 broken apart so that L1s and L2s can be addressed in separate PRs.
@davidstrauss Can you now "Squash and merge" this PR? I don't know why Coveralls hasn't reported back. The most recent commit was just a comment removal.

Coverage remained the same at 100.0% when pulling f4404165b6717ddaa04b835c95d018cb27427f5f on L1-test-parity into 7adddaa78bf022c6b4a20cb34b0b049bf9146766 on master.


APIv2 endpoints with /libpod prefix

/kind bug
In the list of APIv2 endpoints is an inconsistency concerning the use of the /libpod prefix. It's logical to use the '/libpod' prefix for services like pods, generate/play kube and the swagger (e.g. VersionedPath("/libpod/pods/json")).
But I don't understand this for volumes, networks and manifests (I'm not sure about container health checks). Are they intentionally prefixed?
I stumbled over this while trying so set up the Drone CI Docker Runner with Podman and the logging output told me: Failed Request: (404:Not Found) for POST:'/v1.33/volumes/create'. Aren't those three endpoints compatible to their Docker equivalents?

All our API endpoints are duplicated (containers, pods, volumes, images, exec sessions), and most offer the additional functionality we've added that Docker does not support (the list containers endpoint, for example - /v1.0/libpod/containers/json - supports displaying pod information - the compatibility endpoint, /v1.40/containers/json, does not).
Can I ask what Podman version you tried with? The remote API is presently marked alpha, and while I believe we have every endpoint we intend on implementing done on master (we have no plans to implement the swarm endpoints), earlier versions were definitely missing some. I don't recall if volumes were one of them, though. We're planning a v2.0.0 release in the near future that will include the latest work on the remote API and will promote it out of alpha status, so it may be wise to wait for that.

We have not implemented compatibility endpoints for volumes as of yet.

I use v1.9.2.
Yes, I see that the r.HandleFunc(...) calls without libpod are missing for volumes and networks which they do not for e.g. containers. I've spent ~an hour looking through the code and to me it seems as though the services work exactly like the docker spec requires them to do.
There are some parameters which aren't handled yet and the network/connect and network/disconnect endpoints are missing. Are they possible at all? I clicked through the container creation code and didn't find out how it would be possible. I thought I could try to implement those two endpoints but I probably lack the depth of knowledge of the container runtime interfaces and the libpod code.
Anyway, I am happily awaiting v2.0.0, thanks for this awesome software 👍  .

Network stuff is difficult because of our CNI network stack, but I think I have some ideas about it. The inspect endpoint should already be ready.

Given this is mostly a request about network endpoints now, I'm going to rename and change to kind/feature

we have network endpoints for compat and libpod.


[Question] How can I use my own certificate for bot deployed as an Azure App Service?

SDK Platform: .NET
SDK Version: 3.11.0
Active Channels: Webchat, cortana
Deployment Environment: Azure App Service

Hello
I am interested in using my own certificate for my azure app service for bot. Once do I need to make any changes in bot registration or anywhere else so the seamless communication is not impacted.

Hi @neetgupta7 - You don't need to add any extra configuration from the bot registration side of things. As long as your bots messaging endpoint is accessable over HTTPS with valid certificate you are good to go.
For more info on configuring your SSL certificate in Azure App Service, see:
https://docs.microsoft.com/en-us/azure/app-service/web-sites-purchase-ssl-web-site

please open a new issue if you are still experiencing problems


Event 1 feedback issue 🎧

This is the issue where you can leave your feedback about the first event, that we did @ Innovation Lab, Red Hat office in London.
What's something that you liked?
What's something that you would like to see changed?
Let us know below!

Loved the event. 🧡
What I liked was the range of conversations we had around open source. Found out about Postgraphile because of it which is awesome.
Only thing I can think of in terms feedback would perhaps to allow the separate teams to join in on conversations or perhaps mix up the people in the different topics for short while.

I really enjoyed meeting you all and am looking forward to learning even more at the next one!
On the subject of learning; I’d love for us to have a short section at the end where we can each quickly share something with the group that has had an impact on us, a bit like I did when talking about octobox.io. I’d love to hear about the awesome tools, new functionality, chat servers, podcasts, books, techniques or awesome feedback that you all have found/received. I’m thinking less than a minute each on average, entirely optional (no pressure).
One more thing is that I have very poor memory for faces (and names), even the faces of people I was chatting with just a few minutes ago I’m not sure it’s the same person (I believe this is a mild form of “face blindness”). Name badges (with twitter handle and affiliation optional) would be hugely helpful for me. 🙏

Loved how the first event went and it was great meeting everyone! 🙌
I’d second the idea of name tags, which could be optional but encouraged.
They’d really help to keep track of the amount of people, especially in case the next event attracts more attendees than this time!
I feel like exchanging ideas between the groups is important as well. I realise it’s probably impractical to swap groups rather often to avoid mixing things up too much, but this time the topics overlapped quite a bit, so this will maybe have to depend on the next event’s topics?

What's something that you liked?

Good mix of people, in particular, I thought it was amazing that there was someone who was just about to become an open-source maintainer

What's something that you would like to see changed?

When the number of attendees is lower I wonder if having just two breakout sessions is enough. Not all of the breakouts had critical-mass.

Other bits
So I really enjoyed the event, in no particular order:

I know for future events we will get topics picked in advance, getting people to think about the challenges they are facing, or how they've overcome them, before the session may help keep the discussion going
+1 to optional name badges with GitHub/Twitter handles on.
+1 to a quick show and tell on different areas.

👋 everyone!
Thank you so much for the feedback and sorry for my late reply 😅
We will try to integrate as much as possible of what you proposed in the next event, in the meantime:

we have opened a dedicated issue for proposing topics for the next event (more details around it will be announced soon here #8), please leave a comment here #9 about the subjects you want to talk about

some comments on feedback:

Only thing I can think of in terms feedback would perhaps to allow the separate teams to join in on conversations or perhaps mix up the people in the different topics for short while.

When the number of attendees is lower I wonder if having just two breakout sessions is enough. Not all of the breakouts had critical-mass.

yes, we should try and fix how the groups are created and probably if we end up with similar numbers as last time, we should probably do an average of 1 group per each 10 participants. Also, maybe mixing the groups is a bit unpractical but I liked how we sort of all collapsed at the end of event one before going back to the main room.

Name badges (with twitter handle and affiliation optional) would be hugely helpful for me. 🙏

They would be helpful, I just wonder if anyone knows of a way we could do it in a "sustainable fashion". I'd love for those not to be in recyclable materials and/or long lasting (like, you get one and you bring it with you next event).

I’d love for us to have a short section at the end where we can each quickly share something with the group that has had an impact on us, a bit like I did when talking about octobox.io. I’d love to hear about the awesome tools, new functionality, chat servers, podcasts, books, techniques or awesome feedback that you all have found/received. I’m thinking less than a minute each on average, entirely optional (no pressure).

sounds like a lovely idea! My concern is that if we grow massively it would be less doable - but if we have similar numbers to last time (and up to 40-ish) I think it's doable!

I just wonder if anyone knows of a way we could do it in a "sustainable fashion".

We made some badges for our last GraphQL Training workshop, whiteboard marker erasable and held on with magnets. They worked out pretty well, but a couple magnets and one badge went missing and TBH I think less energy would have been wasted on traditional name stickers.
Does anyone else collect event lanyards? An event lanyard with your name on would both serve to include your name, and be a talking point about the event you attended.

sounds like a lovely idea! My concern is that if we grow massively it would be less doable - but if we have similar numbers to last time (and up to 40-ish) I think it's doable!

I thought on this some more; we could put our name and a project on a slip of paper in a hat, and then pull out a few at the end of the evening depending on how much time we have left.

👋 folks!
We are finalising the details for the event next week, and just as a follow up to this conversation:

we will have name badges (more like, name stickers but hey that's a start!)
there will be a "show and tell" timeslot at the end of the event (you can let us know what you want to show/tell via an email to provided-as-is[at]formidable[dot]com

Thanks everyone for your feedback, let's see how things turn out tomorrow ;)


Incorporate NHDPlus HR catchment datasets into get_catchment_characteristics()

A nice feature enhancement would be to enable the reference_fabric argument to accept a change from "nhdplusv2" to the "nhdplusHR", which would then switch to alternative dataset(s) produced for NHDPlusHR.
A new dataset has been released by Gressler et al. 2024 for catchment characteristics attributed and accumulated at the NHDPlus High Res for the Chesapeake Bay watershed (HUCs 0205, 0206, 0207 and 0208).
These datasets are analogous to the NHDPlus Medium Res datasets produced by Mike Wieczorek, which are currently used as the data backbone for the existing get_catchment_characteristics() function. They are also cloud-hosted on S3 within sciencebase, in parquet file format, and have some existing data dictionary tables for use in variable querying and retrievals. The tables would need minor modification by joining them into a single master lookup table for joining and have s3 urls added, but that would be pretty straightforward.
There are a few potential bigger conceptual limitations to implementation at this time, that I'll document below. But this is a good time to document this feature enhancement regardless.

These HR data are only available within the Chesapeake Bay watershed, not for CONUS. Therefore, even if this enhancement were implemented, it might be a bit of a mismatch for medium-res to have data available for CONUS, while high-res only providing data for one region. This might be less incongruous if/when more regional datasets are available at the HR (although I do not know of existing plans for more regional high-res datasets at this point).
There is no current functionality in nhdplusTools or NLDI to navigate the NHDPlusHR, so there's no native discovery method for the NHDPlusHR identifiers. This wouldn't be an issue for retrieving data if the end-user already had their locations of interest, but that could be a mismatch with the "full-service" set of tools nhdplusTools currently provides.

Thanks for writing this up @mjcashman -- The plan has always been that we would eventually have NHDPlusHR and possibly other catchment sets that would work with this.
I'm excited that we might be there. I'd like to start chipping away at this functionality starting with #415 and with that, would be happy to add support for some attributes that link to NHDPlusHR. Regional datasets are fine -- I think we'll just want to indicate that certain variables are only available regionally in the index / metadata about them.
An open question is where we want to assemble the index of variables in this case where we will have many sources of characteristics rather than the one big one that we have for NHDPlusV2. I could see the index being checked in to the nhdplusTools repository or managed separately... doing it separately may be wise since hyRiver would logically also track with this work.

An initial goal here could be just getting the base NHDPlusHR attributes populated.
> names(hr$NHDFlowline)
 [1] "Permanent_Identifier"        "fdate"                       "resolution"
 [4] "gnis_id"                     "gnis_name"                   "LENGTHKM"
 [7] "REACHCODE"                   "flowdir"                     "wbarea_permanent_identifier"
[10] "FTYPE"                       "FCODE"                       "mainpath"
[13] "innetwork"                   "visibilityfilter"            "COMID"
[16] "VPUID"                       "Shape_Length"                "Enabled"
[19] "Shape"                       "streamleve"                  "StreamOrde"
[22] "StreamCalc"                  "FromNode"                    "ToNode"
[25] "Hydroseq"                    "LevelPathI"                  "Pathlength"
[28] "TerminalPa"                  "ArbolateSu"                  "Divergence"
[31] "StartFlag"                   "TerminalFl"                  "UpLevelPat"
[34] "UpHydroseq"                  "DnLevel"                     "DnLevelPat"
[37] "DnHydroseq"                  "DnMinorHyd"                  "dndraincou"
[40] "FromMeas"                    "ToMeas"                      "rtndiv"
[43] "thinner"                     "vpuin"                       "vpuout"
[46] "AreaSqKM"                    "TotDASqKM"                   "divdasqkm"
[49] "maxelevraw"                  "minelevraw"                  "maxelevsmo"
[52] "minelevsmo"                  "slope"                       "slopelenkm"
[55] "elevfixed"                   "hwtype"                      "hwnodesqkm"
[58] "statusflag"
> names(hr$NHDPlusCatchment)
[1] "COMID"        "sourcefc"     "gridcode"     "AreaSqKM"     "VPUID"        "SHAPE_Length"
[7] "SHAPE_Area"   "SHAPE"

If we started with a parquet containing:

nhdplusid / COMID
Permanent_Identifier
reachcode
fdate
gnis_id, gnis_name
lengthkm
wbarea_permanent_identifier
ftype / fcode
vpuid
areasqkm / totdasqkm
minelev / maxelev
slope / slopelenkm

I could see doing a second file with a couple other things from MainstemsV3 such as:

mainstemid (where known)
outlet NHDPlusV2 COMID
inlet NHDPlusV2 COMID
id3dhp / id3dhp match type

Then, perhaps a "nice" NHDPlusHR network to facilitate network navigation could be added on -- but that's pretty far afield from the initial functionality of get_catchment_characteristics. Thoughts @mjcashman or others watching?


use python flock firstly

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?

see linuxbrew/brew's PR

Thanks so much for your first contribution!  You rock, @okhowang!


Table style consistency check

It would be nice to be able to enforce table style consistency:
| foo | bar |
|-----|-----|
| 123 | 456 |

vs
| foo | bar
|-----|----
| 123 | 456

vs
foo | bar
----|----
123 | 456

Style could be detected as being inconsistent from first occurence, or globally enforced as a setting.

Something like https://github.com/remarkjs/remark-lint/tree/master/packages/remark-lint-table-cell-padding would indeed be nice


Git Extension: "Open Changes" shows incorrect difference for renamed, staged files

I admit that it's a niche scenario, but I think that what "Open Changes" shows for not-yet-staged changes to files that have been detected as renamed in the index is incorrect, at least inconsistent with how changes to files in the index are shown that have not been renamed.
Steps to Reproduce:

Create an empty directory and initialize a git repository in it.

In that directory create two files file1.txtand file2.txt with identical content:

abc defg hijkl mnop qrst uvwxyz
defg hijkl mnop qrst uvwxyz abc
hijkl mnop qrst uvwxyz abc defg
mnop qrst uvwxyz abc defg hijkl
qrst uvwxy zabc defg hijkl mnop
uvwxyz abc defg hijkl mnop qrst

This exact content is somewhat important, as I've confirmed that it triggers git's "rename detection" (checked with git v2.14.1).

Stage and commit both files.
Duplicate the first line in both files.
Rename file2.txt to file2-renamed.txt.
"Stage All Changes":

Now Open Changes does the right thing for both files, that is, it shows the changes between HEAD and the staged version:

file1.txt:

file2-renamed.txt:

Duplicate the first line in both files once more, but don't stage these changes.

Now Open Changes still shows the right thing for file1.txt (in this case the changes between the staged version and the file in the working tree):

As the content of both files is identical both in the index and the working tree, I would have expected the exact same result for file2-renamed.txt, but now the left side is just empty instead of showing the staged version:

VSCode Version: Code 1.16.1 (27492b6bf3acb0775d82d2f87b25a93490673c6d, 2017-09-14T16:26:20.018Z)
OS Version: Linux x64 4.12.13-1-ARCH

Hehe great catch! Would you like to attempt to fix it?

So is this issue still open and up for grabs? If so I would like to try to help 👍

@petercr Just look above your comment, there's a PR for it already: https://github.com/Microsoft/vscode/pull/34690


Release cycles not being performed correctly.

Hi guys,
I love this project but I cannot help but notice the release cycles / what's on the master branch, what's on the releases page and what's on npmjs are all different/inconsistent.
Is there a reason for this? can I help to fix this up?
Thanks,
Karl.

Further to this, NPM's current version (0.5.0) is greatly behind the master branch and npm installing from npm install --save https://github.com/FiguredLimited/vue-mc.git\#master does not give a correct installation and becomes unusable.

Not sure this is active/maintained anymore :/

Hey everyone, we've had to focus on a lot of other priorities but we've expanded our maintenance pool now so should see more response going forward. This project needs a lot of attention with many open issues to work through, but we're here and will continue to do what we can.
First things first, the last release with a changelog was 0.4.0 but there is no proper tag release for that. The version currently on NPM is 0.5.0 which was tagged on Nov 15, 2018. There have been 35 commits to master since that tag, so we need to consolidate those into a 0.6.0, and establish some scope for a 1.0.0 release that reworks all the big issues that break BC.
We also need to upgrade some dependencies that have security issues - I think this is a good place to start. My plan for this for the week is:

[ ] Update the tags and changelog to 0.5.0 so that everything is on the same level (except master).
[ ] Consolidate the commits since then into a new version, also upgrading dependencies.
[ ] Prioritize some bigger issues and work them into a milestone for 1.0.0

Good morning @rtheunissen, thanks for your input and I really appreciate it.
Is it within the realm of possibility to allow others onto this project not involved in Figured?
If so, maybe people like myself and others can jump onboard and help push this project forward.
Thanks again for your update.

Absolutely, we'll have an internal discussion about that and get back to you all. 👍

Hey everyone, we've had to focus on a lot of other priorities but we've expanded our maintenance pool now so should see more response going forward. This project needs a lot of attention with many open issues to work through, but we're here and will continue to do what we can.
First things first, the last release with a changelog was 0.4.0 but there is no proper tag release for that. The version currently on NPM is 0.5.0 which was tagged on Nov 15, 2018. There have been 35 commits to master since that tag, so we need to consolidate those into a 0.6.0, and establish some scope for a 1.0.0 release that reworks all the big issues that break BC.
We also need to upgrade some dependencies that have security issues - I think this is a good place to start. My plan for this for the week is:

[ ]  Update the tags and changelog to 0.5.0 so that everything is on the same level (except master).
[ ]  Consolidate the commits since then into a new version, also upgrading dependencies.
[ ]  Prioritize some bigger issues and work them into a milestone for 1.0.0

Hi @rtheunissen,
Are there any updates on that?

@thisninja I will be releasing 1.0.0 tonight that will consist of all the changes on master since 0.5.0, including a fix for the Vue version being locked. I'm also updating all the severely outdated package dependencies so this is technically a breaking change (some of the date formatting symbols have changed in validation).
The milestone and roadmap for the next version will be for 2.0.0 then.

Hey everyone, I have released 0.6.0 instead, which includes a lot of changes that does technically break semver. ✋ There are some bigger changes incoming to warrant a 1.0.0 from which point on we'll be following semver properly.
On that note, would anyone be interested in becoming a maintainer on this package? We're looking for some community support to assist.

@rtheunissen yea would be keen

@rtheunissen we might be keen as well.

@sifex and @inventionlabsSydney thanks for the interest. Will get back to you asap. 👍

Hi, @rtheunissen
Are there any updates when will 1.0.0. be released?

Bring the community in with this. It could be so much more popular. It is a great package and I for one find it really useful.
Allow PR's in the project that are looked at regularly.


v0.10.2 updates

Thanks for revisiting the typings

@mainnet-pat I've pushed the latest pull request to haveno-ts to upgrade to monero-ts v0.10.1, which configures jest to use the correct cors url and transform pattern for Axios.
With this change, you'll be able to observe the error when running any of the tests: 401 Unauthorized: <title>Unauthorized Access</title>
401 Unauthorized

Suspecting it's an issue with the digest authentication, but hoping we can get this figured out. :)


[Bug]: You may need an additional plugin to handle "node:" URIs.

Version
System:
    OS: macOS 14.5
    CPU: (10) arm64 Apple M1 Pro
    Memory: 1.29 GB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Browsers:
    Safari: 17.5
  npmPackages:
    @rsbuild/core: 1.0.1 => 1.0.1
    @rsbuild/plugin-less: 1.0.1 => 1.0.1
    @rsbuild/plugin-react: 1.0.1 => 1.0.1
    @rsbuild/plugin-svgr: 1.0.1 => 1.0.1

Details
// rsbuild.config.ts

import { defineConfig } from '@rsbuild/core';
import { pluginLess } from '@rsbuild/plugin-less';
import { pluginReact } from '@rsbuild/plugin-react';
import { pluginSvgr } from '@rsbuild/plugin-svgr';

export default defineConfig({
  plugins: [pluginReact(), pluginSvgr(), pluginLess()],
  tools: {
    rspack: {
      node: {
        global: true,
      },
    },
  },
});

// App.tsx

import process from 'node:process';

console.log(process.env.DEV);

I get error:

Reproduce link
See codes above
Reproduce Steps
See codes above

API from node cannot be used in the browser environment

@SoonIter
If so, what's the point of turning on polyfills for Node?

Try this plugin: https://github.com/rspack-contrib/rsbuild-plugin-node-polyfill


fix(core-chevron-link): changed tag from div to span

This PR should fix the nesting of a <ChevronLink /> inside a <Notification />. Currently if you nest the <ChevronLink /> in the <Notification /> you will receive a React propType warning that says validateDOMNesting(...): <div> cannot appear as a descendant of <p>..

Thanks @Jeffrey-Chang :) One request. Please run yarn prepr and follow the on screen directions.
Check out the "Make a pull request" section of our contributing guide for full info: https://tds.telus.com/contributing/developer-guide.html


TypeScript type definitions for reselect-tools

It would be really nice if you provide these definitions since reselect already does this

Wow, my first issue! Thanks! I haven't used typescript too much before, so can you tell me how this would help you? Is this because createSelectorWithDependencies is uninferable?

Yes and all the other APIs should have types to be inferable.
if you wrap most of the methods from reselect maybe you can reuse a lot from this file
Great Job BTW 👍

Realistically I'm not going to do this since I don't use typescript myself. I'd be happy to accept a PR though. Until then, I'm going to close this down.


Output sufrdata_* files are inconsistent with CTSM checks

Ryan Knox alerted me to this really great tool and I have been looking into using it to generate site-level runs to use with CTSM/CLM5-FATES. However, I recently ran into and then debugged an issue (or potential issue) with the scripts to create sparse grid domain and surfdata files to use with the recently released CTSM/CLM5.  I was able to use the tool to successfully create the files using different grid resolutions however when I attempted to run a case using these generated files, at this point just for the Panama BCI site, I hit an error in the startup model checks:
from the cesm log
 clmfates_interfaceMod.F90:: reading fates_hydr_kmax_node
 NetCDF: Variable not found
 NetCDF: Invalid dimension ID or name
 NetCDF: Invalid dimension ID or name
 NetCDF: Invalid dimension ID or name
 NetCDF: Invalid dimension ID or name
 NetCDF: Invalid dimension ID or name
 NetCDF: Invalid dimension ID or name
 ERROR: Unknown error submitted to shr_abort_abort.
--------------------------------------------------------------------------
A process has executed an operation involving a call to the
"fork()" system call to create a child process.  Open MPI is currently
operating in a condition that could result in memory corruption or
other system errors; your job may hang, crash, or produce silent
data corruption.  The use of fork() (or system() or other calls that
create child processes) is strongly discouraged.

The process that invoked fork was:

  Local host:          [[45798,1],0] (PID 138243)

If you are *absolutely sure* that your application will successfully
and correctly survive a call to fork(), you may disable this warning
by setting the mpi_warn_on_fork MCA parameter to 0.
--------------------------------------------------------------------------
#0  0x7F8D2C2ECB97
#1  0x970F45 in __shr_abort_mod_MOD_shr_abort_backtrace
#2  0x971160 in __shr_abort_mod_MOD_shr_abort_abort
#3  0x4A4026 in __abortutils_MOD_endrun_vanilla
#4  0x57586A in __surfrdutilsmod_MOD_check_sums_equal_1
#5  0x571955 in __surfrdmod_MOD_surfrd_get_data
#6  0x4ADB51 in __clm_initializemod_MOD_initialize1
#7  0x4A0078 in __lnd_comp_mct_MOD_lnd_init_mct
#8  0x41FD94 in __component_mod_MOD_component_init_cc
#9  0x411FBC in __cime_comp_mod_MOD_cime_init
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1001.

You may or may not see output from other processes, depending on
exactly when Open MPI kills them.

from the lnd.log
 Attempting to read surface boundary data .....
 (GETFIL): attempting to find local file surfdata_bci_sparse_grid_c180226.nc
 (GETFIL): using /data/Model_Data/sites/PA-Bar/bci_0.1x0.1_v4.0i/surfdata_bci_sparse_grid_c180226.nc
 Opened existing file /data/Model_Data/sites/PA-Bar/bci_0.1x0.1_v4.0i/surfdata_bci_sparse_grid_c180226.nc      262144
 check_var: variable xc is not on dataset
 surfrd_get_data lon_var = LONGXY lat_var =LATIXY
 surfrd_special ERROR: sum of wt_glc_mec not 1.0 at nl=           1
 sum is:    0.0000000000000000
 ENDRUN:ERROR in /data/software/CTSM/ctsm/src/main/surfrdUtilsMod.F90 at line 70

I tracked it down to here
    wt_glc_mec(:,:) = wt_glc_mec(:,:) / 100._r8
    call check_sums_equal_1(wt_glc_mec, begg, 'wt_glc_mec', subname)

in the subroutine:
!-----------------------------------------------------------------------
  subroutine surfrd_special(begg, endg, ncid, ns)
    !
    ! !DESCRIPTION:
    ! Determine weight with respect to gridcell of all special "patches" as well
    ! as soil color and percent sand and clay
    !
    ! !USES:
    use clm_varpar      , only : maxpatch_glcmec, nlevurb
    use landunit_varcon , only : isturb_MIN, isturb_MAX, istdlak, istwet, istice_mec
    use clm_instur      , only : wt_lunit, urban_valid, wt_glc_mec, topo_glc_mec
    use UrbanParamsType , only : CheckUrban
    !

where it is expecting that 100/100 = 1 (i think)
    call check_dim(ncid, 'nglcec',   maxpatch_glcmec   )
    call check_dim(ncid, 'nglcecp1', maxpatch_glcmec+1 )

    call ncd_io(ncid=ncid, varname='PCT_GLC_MEC', flag='read', data=wt_glc_mec, &
         dim1name=grlnd, readvar=readvar)
    if (.not. readvar) call endrun( msg=' ERROR: PCT_GLC_MEC NOT on surfdata file'//errMsg(sourcefile, __LINE__))

    wt_glc_mec(:,:) = wt_glc_mec(:,:) / 100._r8
    call check_sums_equal_1(wt_glc_mec, begg, 'wt_glc_mec', subname)

    call ncd_io(ncid=ncid, varname='TOPO_GLC_MEC',  flag='read', data=topo_glc_mec, &
         dim1name=grlnd, readvar=readvar)
    if (.not. readvar) call endrun( msg=' ERROR: TOPO_GLC_MEC NOT on surfdata file'//errMsg(sourcefile, __LINE__))

    topo_glc_mec(:,:) = max(topo_glc_mec(:,:), 0._r8)

    pctspec = pctwet + pctlak + pcturb_tot + pctgla

    ! Error check: glacier, lake, wetland, urban sum must be less than 100

    found = .false.
    do nl = begg,endg
       if (pctspec(nl) > 100._r8+1.e-04_r8) then
          found = .true.
          nindx = nl
          exit
       end if
       if (found) exit
    end do
    if ( found ) then
       write(iulog,*)'surfrd error: patch cover>100 for nl=',nindx
       call endrun(msg=errMsg(sourcefile, __LINE__))
    end if

I originally thought the issue was in the GLC_MEC entries into the surfdata_* file as there was a difference between the original
data:

 GLC_MEC = 0, 200, 400, 700, 1000, 1300, 1600, 2000, 2500, 3000, 10000 ;
}

and generated versions
// global attributes:
        :Created_by = "sserbin" ;
        :Created_on = "Mon Feb 26 18:31:18 2018 " ;
data:

 GLC_MEC = 0, _, _, _, _, _, _, _, _, _, _ ;
}

But changing that variable to match didnt fix it.
But then I realized there seemed to be a mismatch in PCT_GLC_MEC
 PCT_GLC_MEC =
  100,
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  0 ;

 PCT_GLC_MEC =
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  0 ;

I changed that var to match and it then worked fine.
Attempting to read surface boundary data .....
 (GETFIL): attempting to find local file surfdata_bci_sparse_grid_c180226.nc
 (GETFIL): using /data/Model_Data/sites/PA-Bar/bci_0.1x0.1_v4.0i/surfdata_bci_sparse_grid_c180226.nc
 Opened existing file /data/Model_Data/sites/PA-Bar/bci_0.1x0.1_v4.0i/surfdata_bci_sparse_grid_c180226.nc      262144
 check_var: variable xc is not on dataset
 surfrd_get_data lon_var = LONGXY lat_var =LATIXY
 WARNING: New CFT-based format surface datasets should be run with create_crop_landunit=T
 WARNING: When fates is on we allow new CFT based surface datasets to be used with create_crop_land FALSE
 Successfully read surface boundary data

I think the fix may be to update CreateCLMUgridSurfdatForCLM45.m
            switch varname
                case {'PCT_URBAN','PCT_CROP','PCT_WETLAND','PCT_LAKE','PCT_GLACIER',...
                        'PCT_GLC_MEC'}
                    data = data*0;
                case {'PCT_NATVEG'}
                    data = data*0 + 100;
            end

to
            switch varname
                case {'PCT_URBAN','PCT_CROP','PCT_WETLAND','PCT_LAKE','PCT_GLACIER'}
                    data = data*0;
                case { 'PCT_GLC_MEC', 'PCT_NATVEG'}
                    data = data*0 + 100;
            end

Thoughts?   Thanks!

@serbinsh, Can you share the .cfg you used to create a 1x1 surface dataset for Panama BCI? I would like to reproduce the error on my end.

Yes, no problem.  I had to change the .cfg extension to .txt to upload here.
bci_sparse_grid.cfg.txt
bci_sparse_grid_latlon.txt

@serbinsh, Could you check out bishtgautam/pct-frac-check branch, recreate the dataset, and run CTSM/CLM-FATES? Additionally, you will now have to add set_natural_veg_frac_to_one = 1 in your CFG if you want a surface dataset that is 100% naturally vegetated.

@bishtgautam Yes sure, thanks.  I will give it a try as soon as I have a free moment.

@bishtgautam OK, so I pulled the branch, re-generated the surfdata_ and domain_ files, and tested by running an BCI run with CLM5-FATES with inventory and everything seems to be working! Thanks!


Implement refresh specific version of tool/workflow/service endpoint

Feature Request
Desired behaviour
Refresh a specific version (used by either a curator on a user's behalf or by the user themselves in the future)
┆Issue is synchronized with this Jira Story
┆Issue Type: Story
┆Issue Number: DOCK-687

No, but for Phase 1, this should require the workflow to already exist.
This is for webhook hand-off (i.e. someone has created the workflow and associated by webhook)

Cleared some stuff up after talking to Denis. This is meant to be an endpoint called by a webhook that has the following information (repository name, organisation name, tag/release name).
What the endpoint must do is for all GitHub workflows that are associated with that repository/organisation, create a new version for those workflows (or update if the version already exists). This should only be for tags and releases, and not regular branches.

This has been done for workflows only so far.

This existed enough in staging.dockstore.org beta test.
Open more specific issues for bugs


Explore object-based routing

See also: #307

We just need need to decide if this belongs in the core framework or would be better as an add-on package.

I think I actually tried to post my implementation on the mailing list but I don't know if it made it through.  We have it working in Mailman 3.1 and it's wonderful!

For reference: Mailman's implementation is also mentioned by @maxking in a discussion comment.


chore: 🤖 add coderabbit config file

JIRA Link
N/A
Changelog / Description
Adds coderabbit config file
Checklist -

[ ] New Feature ?
[ ] Updated swagger annotation (if API structure is changed) ?
[ ] Unit Test (if possible) ?
[ ] Updated the Readme.md (if required) ?

Summary by CodeRabbit

New Features

Introduced automated code reviews with configurable settings.
Enabled language-specific reviews and high-level summaries.
Automated replies in chat for review interactions.

:tada: This PR is included in version 5.0.0-alpha.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Support Tern

Support Tern
Tern is a stand-alone code-analysis engine for JavaScript. It is intended to be used with a code editor plugin to enhance the editor's support for intelligent JavaScript editing.
I should create a pull request if welcome.

I use
{
  "plugins": {
    "node": {},
    "node_resolve": {},
    "modules": {},
    "es_modules": {}
  }
}

simple default config in my project and it works fine, but the problem's with root import path eg import Header from 'components/Header'. Auto complete doesn't work if I don't use relative path.
Do you have any solution? What's your current config that works for you?

@sourcesoft
My setting is
{
  "libs": [
    "browser",
    "ecmascript",
    "react"
  ],
  "plugins": {
    "doc_comment": {},
    "node": {},
    "webpack": {
      "configPath": "./internals/webpack/webpack.dev.babel.js"
    }
  }
}

And change process.cwd() to absolute path APP_ROOT in internals/webpack/webpack.*.babel.js
It works nice.

Tern doesn't support VS code and Atom? :(

Atom has a plugin but I'm not sure about vscode. I'm using Vim at it works
just fine.
On Sun, Jul 9, 2017 at 11:35 AM Mihir Karandikar<EMAIL_ADDRESS>wrote:

Tern doesn't support VS code and Atom? :(
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/react-boilerplate/react-boilerplate/issues/1828#issuecomment-313903288,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAlKirwGMFkQyF5VfLUAVRXKwVd7MrZ4ks5sMHuogaJpZM4OGEzq
.

--
--
Twitter http://twitter.com/sanooei - Website http://sanooei.com/ -
Linkedin http://www.linkedin.com/in/sanooei
Tell: +98-915-5224328
Developer, Designer

Closing due to inactivity


release<EMAIL_ADDRESS>

This sets publishConfig.access=public, required to publish a
scoped package -- scoped packages default to private.

The attempted npm publish of 0.4.0 failed with:
npm notice Publishing to https://registry.npmjs.org/ with tag latest and default access
npm error code E402
npm error 402 Payment Required - PUT https://registry.npmjs.org/@elastic%2fmockotlpserver - You must sign up for private packages
npm error A complete log of this run can be found in: /home/runner/.npm/_logs/2024-09-06T16_54_26_602Z-debug-0.log
Error: Process completed with exit code 1.

Release workflow run: https://github.com/elastic/elastic-otel-node/actions/runs/10742279480/job/29794579127

The release worked. The release is here: https://github.com/elastic/elastic-otel-node/releases/tag/mockotlpserver-v0.4.1
However, the CLI, at least, doesn't work:
[10:05:24 trentm@peach:~/tmp/asdf]
% npm install @elastic/mockotlpserver

added 41 packages, and audited 42 packages in 3s

3 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
[10:05:32 trentm@peach:~/tmp/asdf]
% npx mockotlpserver
/Users/trentm/tmp/asdf.20240906T100522/node_modules/.bin/mockotlpserver: line 1: /Applications: is a directory
/Users/trentm/tmp/asdf.20240906T100522/node_modules/.bin/mockotlpserver: line 2: node_modules: command not found
/Users/trentm/tmp/asdf.20240906T100522/node_modules/.bin/mockotlpserver: line 3: node_modules: command not found
/Users/trentm/tmp/asdf.20240906T100522/node_modules/.bin/mockotlpserver: line 4: node_modules: command not found
/Users/trentm/tmp/asdf.20240906T100522/node_modules/.bin/mockotlpserver: line 5: node_modules: command not found
/Users/trentm/tmp/asdf.20240906T100522/node_modules/.bin/mockotlpserver: line 6: syntax error near unexpected token `('
/Users/trentm/tmp/asdf.20240906T100522/node_modules/.bin/mockotlpserver: line 6: ` * the Apache License, Version 2.0 (the "License"); you may'

So more work required.


Connect pollers to actual database

We have pollers that know how to write data to the database, but they're not hooked up to anything yet, so we need to add logic to the main script (greenpithumb.py) to connect each sensor to its appropriate poller and the pollers to the real sqlite database.

Fixed in #89


Add minute() function

What did you do?
Tried to add an alert that triggers at a specified time, e.g.:
hour() % 8 == 0 and minute() > 30 and minute() < 40

The idea is to trigger an alert at the start of each on-call shift to test the escalation path, i.e. are the on-call people's phones working, do we have the correct phone numbers, is the rota configured correctly.
What did you expect to see?
The current UTC minutes returned.
What did you see instead? Under which circumstances?

Error executing query: parse error at char 8: unknown function with name "minutes"

Environment

Prometheus version:
matt➜github.com/prometheus/prometheus(master✗)» ./prometheus -version
prometheus, version 1.1.2 (branch: master, revision: 3fd992d2d1450e9153f27e0061bd92743499286a)
build user:       matt@matt
build date:       20160912-17:09:55
go version:       go1.7
matt➜github.com/prometheus/prometheus(master✗)»

@mattbostock Makes sense. Do you want to give this a try? It should be pretty straightforward. Here is the commit which introduced hour()/month()/etc. https://github.com/prometheus/prometheus/commit/4680daf2370391a4fd22d92eec4c043b949d7679

Sure, will do.


add persistent volume tab using mock-json

Created a mock server using go
Added README.md with instructions for running the mock-server
Using server to server mock-JSON that brings up PERSISTENT VOLUME tab

Fixes: #21
Signed-off-by: Shivesh<EMAIL_ADDRESS>

Nice job @shiveshabhishek & @chandankumar4


investigate molten leading

neater approach than fixed media-query-based breakpoints: https://css-tricks.com/molten-leading-css/

After some testing, I'm thinking of using on this:
html { font-size: 1rem; }
@media (min-width: 100rem) { html { font-size: calc(0.4vw + .85rem) } }

or the equivalent in pixels:
html { font-size: 16px; }
@media (min-width: 600px) { html { font-size: calc(0.4vw + 13.6px) } }

i.e. a constant line of 16px minimum font size for all viewports up to 600px, and from then on a linear progression based on the window width. For a smooth transition at the 600px mark, 0.4vw+13.6px should equal 16px. Since 1vw at 600px = 6, and 0.4*6 = 2.4, we need to sum 13.6 to get the 16px we started with as a minimum.
Perhaps I could set a smaller minimum, say 0.9rem.
And I wonder if we could get a smooth transition rather than a hard break. But using only elementary arithmetic operations it may become excessively convoluted.

For future reference, cross-linking to another issue related to text sizing: #30


mpv output

added dirty hack on linux, cpu dropped from 10-15% to consistent 10-11%

mpv tries to cache as much video as possible. which is a dealbreaker.


add_message is failing

This is great tool and great work. Thank you.
I have a code which was working with 23.0.0 but is failing after that to add_message to database. I do not see any change in add_message function in database.py. What could be causing the problem? Basically what I am doing is iterating though messages and adding specific messages to new database. I am getting a message with its name but failing to add it to new database. It was working fine before and generating new database.

add_message() was renamed to _add_message(), and is hence private (as leading underscore indicates).
Now, instead of adding a message with add_message(), append the message to messages, and once done, call the refresh() function to update the internal dictionaries used for encoding and decoding lookup.
Before:
import cantools
db = cantools.database.Database()
message = cantools.database.Message(...)
db.add_message(message)
... add more messages ...

After:
import cantools
db = cantools.database.Database()
message = cantools.database.Message(...)
db.messages.append(message)
... add more messages ...
db.refresh()

@eerimoq Thanks. It is working now.


short circuit self.data access

self.data only exists after calling all_datatypes_prepare, so when looking it up on self, check for it before doing so.
This should deal with the recent failures in the copy tests on CassCI:
http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_null_as_null_indicator/
http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_undefined_as_null_indicator/
I wasn't able to reproduce the original failures locally, but this change should be safe. @nutbunnies You touched this last, right? Could you review?

Oh, and this is for CASSANDRA-10454.

LGTM

Thanks, merging.


Log cause chain for exceptions

Thoughts?
cc @chef/client-maintainers

We still ship and support ruby 2.0 don't we so you'd need to respond_to?(:cause) check this or something?

I think Lamont is correct. :+1: once that's fixed up

:(
but i wanted it for windows. I'm guessing there's no way for ruby 2.0?

@jdmundrawala it's way harder, so depends on how motivated you are. Anyway, you can roll your own nested exceptions with something like:

class SomeException
  attr_reader :cause
  def initialize(*args)
    @cause = $!
    super
  end
end

You could extract that into a module and then use module prepending to add it to all of our exceptions.
But even then we can only do this for Chef's own exceptions, so stuff from inside libraries won't have this.

@jdmundrawala are we still building chef with Ruby 2.0 for Windows?  We use 2.1.5 for the ChefDK

still 2.0

:cry:

:+1: LGTM

yeah now that we're off of 2.0 everywhere we should :shipit:


Probable typo in Security hardening article

What article on docs.github.com is affected?
https://docs.github.com/en/free-pro-team@latest/actions/learn-github-actions/security-hardening-for-github-actions#using-secrets
What part(s) of the article would you like to see updated?
The text under bullet point Never use structured data as a secret starts out "Unstructured data can cause secret redaction within logs to fail, because redaction largely relies on finding an exact match for the specific secret value."  I think this should read "Structured data can cause ...".
Additional information

Thanks for letting us know @gsrohde!


binutils: 2.38 -> 2.39

Changes: https://sourceware.org/pipermail/binutils/2022-August/122246.html
Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This should be available more widely now. 🤞
@ofborg eval

Will need a libbfd fix as well. Will look in detail tomorrow. Switching to draft meanwhile.
       > patching file bfd/Makefile.am
       > Reversed (or previously applied) patch detected!  Assume -R? [n]
       > Apply anyway? [n]
       > Skipping patch.
       > 1 out of 1 hunk ignored -- saving rejects to file bfd/Makefile.am.rej
       > patching file bfd/Makefile.in
       > Reversed (or previously applied) patch detected!  Assume -R? [n]
       > Apply anyway? [n]
       > Skipping patch.
       > 1 out of 1 hunk ignored -- saving rejects to file bfd/Makefile.in.rej
       For full logs, run 'nix log /nix/store/8h4mfxwgsh0sh0wyg79yghw1bkakxg08-libbfd-2.39.drv'.

More failures:

[ ] systemd

Fails to build EFI images (due to gnu-efi deficiency). Not sure yet if the failure is intended or it's a warning-as-error bug:
FAILED: src/boot/efi/linuxx64.elf.stub
/nix/store/vq7x24g13zpqglpazlx3k574l74cnhl5-gcc-wrapper-13.0.0/bin/gcc -o src/boot/efi/linuxx64.elf.stub -Wno-format-signedness -Wno-missing-field-initializers -Wno-unused-parameter -Wdate-time -Wendif-labels -Werror=format=2 -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -Werror=int-conversion -Werror=overflow -Werror=override-init -Werror=return-type -Werror=shift-count-overflow -Werror=shift-overflow=2 -Werror=undef -Wfloat-equal -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-include-dirs -Wmissing-noreturn -Wnested-externs -Wold-style-definition -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-aliasing=2 -Wstrict-prototypes -Wsuggest-attribute=noreturn -Wunused-function -Wwrite-strings -Wno-unused-result -fno-stack-protector -fno-strict-aliasing -fpic -fwide-exec-charset=UCS2 -Wall -Wextra -Wsign-compare -nostdlib -std=gnu11 -ffreestanding -fshort-wchar -fvisibility=hidden -isystem /nix/store/0am9hs6bvh3id3g3n3fhyynznfcqnfwd-gnu-efi-3.0.14/include/efi -isystem /nix/store/0am9hs6bvh3id3g3n3fhyynznfcqnfwd-gnu-efi-3.0.14/include/efi/x86_64 -I /build/source/src/fundamental -DSD_BOOT -DGNU_EFI_USE_MS_ABI -include src/boot/efi/efi_config.h -include version.h -mno-red-zone -mno-sse -mno-mmx -fuse-ld=bfd -L /nix/store/0am9hs6bvh3id3g3n3fhyynznfcqnfwd-gnu-efi-3.0.14/lib -nostdlib -T /nix/store/0am9hs6bvh3id3g3n3fhyynznfcqnfwd-gnu-efi-3.0.14/lib/elf_x86_64_efi.lds -Wl,--build-id=sha1 -Wl,--fatal-warnings -Wl,--no-undefined -Wl,--warn-common -Wl,-Bsymbolic -z nocombreloc /nix/store/0am9hs6bvh3id3g3n3fhyynznfcqnfwd-gnu-efi-3.0.14/lib/crt0-efi-x86_64.o -pie -Wl,--no-dynamic-linker src/boot/efi/bootspec-fundamental.c.o src/boot/efi/efivars-fundamental.c.o src/boot/efi/sha256.c.o src/boot/efi/string-util-fundamental.c.o src/boot/efi/assert.c.o src/boot/efi/devicetree.c.o src/boot/efi/disk.c.o src/boot/efi/graphics.c.o src/boot/efi/measure.c.o src/boot/efi/pe.c.o src/boot/efi/secure-boot.c.o src/boot/efi/ticks.c.o src/boot/efi/util.c.o src/boot/efi/cpio.c.o src/boot/efi/initrd.c.o src/boot/efi/splash.c.o src/boot/efi/stub.c.o src/boot/efi/linux_x86.c.o -lefi -lgnuefi -lgcc
/nix/store/s2lxn7xgyf7crhny8afl4chq7111n9kv-binutils-2.39/bin/ld.bfd: warning: /nix/store/0am9hs6bvh3id3g3n3fhyynznfcqnfwd-gnu-efi-3.0.14/lib/crt0-efi-x86_64.o: missing .note.GNU-stack section implies executable stack
/nix/store/s2lxn7xgyf7crhny8afl4chq7111n9kv-binutils-2.39/bin/ld.bfd: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
collect2: error: ld returned 1 exit status

[ ] elfutils

Fails build with a failure that looks like a printf arguments problem and an address range problem:
FAIL: run-low_high_pc.sh
========================

[b] main.c
[2d] main

[b] ../sysdeps/i386/start.S
[26] _start
[40] ../sysdeps/x86/abi-note.c
[b52] init.c
[b8e] static-reloc.c
[2dba] _dl_relocate_static_pie
[2dd8] ../sysdeps/i386/crti.S
[2def] _init
lowpc: 8049000, highpc: 8049000lx
../sysdeps/i386/crti.S: [2def] '_init' highpc <= lowpc
FAIL run-low_high_pc.sh (exit status: 255)

Bumping binutils is always a huge pain :(

[ ] perf:

init_disassemble_info changed API slightly to emit coloured output: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=60a3da00bd5407f07d64dff82a4dae98230dfaac
util/annotate.c: In function 'symbol__disassemble_bpf':
util/annotate.c:1765:9: error: too few arguments to function 'init_disassemble_info'
 1765 |         init_disassemble_info(&info, s,
      |         ^~~~~~~~~~~~~~~~~~~~~

[ ] pkgsMusl.binutils:

gprofng fails to build on musl:
/nix/store/4k23hc0n15afv1nk951vh1c4c3f0yacz-bootstrap-tools/include-libc/sys/signal.h:1:2: warning: #warning redirecting incorrect #include <sys/signal.h> to <signal.h> [-Wcpp]
 #warning redirecting incorrect #include <sys/signal.h> to <signal.h>
  ^~~~~~~
In file included from dispatcher.c:30:0:
./../src/collector_module.h:78:13: error: duplicate member ‘pwrite’
   ssize_t (*pwrite64)();
             ^

[ ] bpftool:

Same failure as perf, se will need to apply patch to the kernel itself, not the individual tools.
error: builder for '/nix/store/gy683d4gdhz6ids9y3ig3a8yqf6m64xn-bpftools-5.19.drv' failed with exit code 2;
       last 10 log lines:
       >   472 | extern void init_disassemble_info (struct disassemble_info *dinfo, void *stream,
       >       |             ^~~~~~~~~~~~~~~~~~~~~
       > jit_disasm.c:105:17: error: too few arguments to function 'init_disassemble_info'
       >   105 |                 init_disassemble_info(&info, stdout,
       >       |                 ^~~~~~~~~~~~~~~~~~~~~
       > /nix/store/gziacflg8p7xd3p65rafwqvfni9j03n3-libopcodes-2.39-dev/include/dis-asm.h:472:13: note: declared here
       >   472 | extern void init_disassemble_info (struct disassemble_info *dinfo, void *stream,
       >       |             ^~~~~~~~~~~~~~~~~~~~~
       > make[1]: *** [Makefile:222: jit_disasm.o] Error 1 shuffle=1660469830
       > make: *** [Makefile:110: bpftool] Error 2 shuffle=1660469830
       For full logs, run 'nix log /nix/store/gy683d4gdhz6ids9y3ig3a8yqf6m64xn-bpftools-5.19.drv'.

Hrm, pkgs/top-level/linux-kernels.nix still has linux_default = packages.linux_5_15;, so packages like cargo-flamegraph which depend on perf don't build after this.
I don't know what the right solution is.  It's unfortunate that libopcode changed the API when they added pretty-printing instead of exposing a new function and having the old one invoke it with a sensible default.
In the meantime maybe we should throw, since if the patch is neither applied nor included (kernel>=5.20) there is no hope of compilation succeeding?  i.e.:
https://github.com/NixOS/nixpkgs/pull/186318/files#r947293455

Hrm, pkgs/top-level/linux-kernels.nix still has linux_default = packages.linux_5_15;, so packages like cargo-flamegraph which depend on perf don't build after this.
I don't know what the right solution is. It's unfortunate that libopcode changed the API when they added pretty-printing instead of exposing a new function and having the old one invoke it with a sensible default.
In the meantime maybe we should throw, since if the patch is neither applied nor included (kernel>=5.20) there is no hope of compilation succeeding? i.e.:
https://github.com/NixOS/nixpkgs/pull/186318/files#r947293455

Note that this PR is a draft. It will require a bit of porting for older kernels (or pulling in older libbfd version for older kernels).
PR you linked is already merged into master, does it cause build failures for you on master as well? Can you specify which attributes?

PR you linked is already merged into master, does it cause build failures for you on master as well? Can you specify which attributes?

Just to clarify: there is nothing wrong with #186318.  But due to github limitations I have to put the ```suggestion line in that PR.  Github won't let me put it here because this PR doesn't touch that line of code.

@ofborg build gpgme

With override { linux_default = packages.linux_5_19; } this PR successfully builds:

powerpc64le-linux

[x] full workstation except ghc and its referrers
[ ] ghc and its referrers (still building)

mips64el-linux-gnuabi64

cross from powerpc64le-linux

[x] bootstrap-files
[x] full router environment

native

[ ] stdenv (still building, almost finished with gcc)
[ ] full router environment (still building)

mips64el-linux-gnuabin32

cross from powerpc64le-linux

[x] bootstrap-files

native

[ ] stdenv (queued)
[ ] full router environment (queued)

LGTM if we can figure out what to do about the linux_default situation.

Added 2.38 release for libbfd and libopcodes to allow pinning individual tools to it.

[ ] Also proposed 2.38 holdback release against master as: https://github.com/NixOS/nixpkgs/pull/187972.

That way we can pin tools to it regardless of status of this PR. The changes should be a no-op as derivation of libbfd / libbfd_2_38 will be identical in master.

More failures:

[ ] eztrace:

Rebased against current master to include all the master fixes (mostly ping to held back binutils-2.38). Piled on a few more fixes for a small number of leaf packages. Should be good enough shape to request a new jobset to weed out the rest of failures.

@vcunat Usually helps me get a jobset for these kinds of bumps

Also asked to create a jobset on infra matrix channel: https://app.element.io/#/room/#infra:nixos.org/$Glu5NtSnZGrc_3TdGbA89SAslq4tJGiGVnFgiaglGHw

For reference, now created as https://hydra.nixos.org/jobset/nixpkgs/pr-185297-binutils-2.39

New failures:

[ ] dmd:

fails tests: https://hydra.nixos.org/build/188843476 (2 test failures)

Jobset finished with: success: 53091, failures: 812. Inspecting failures against trunk jobset I found no new failures(!).
Rebased current branch past all the fixes above. Ready for review.

You're a superstar trofi :)
Happy to see this land!

Heh, you are too kind :)

Since this merge, on macos 10.15 (and reportedly also darwin aarch64):
  CCLD     libctf-nobfd.la
./libtool: eval: line 1115: syntax error near unexpected token `|'
./libtool: eval: line 1115: `/nix/store/2z3fkfy273yqg2ylxyybvly0dks1nlby-bootstrap-stage0-clang-wrapper-11.1.0/bin/nm -B  .libs/libctf_nobfd_la-ctf-archive.o .libs/libctf_nobfd_la-ctf-dump.o .libs/libctf_nobfd_la-ctf-create.o .libs/libctf_nobfd_la-ctf-decl.o .libs/libctf_nobfd_la-ctf-error.o .libs/libctf_nobfd_la-ctf-hash.o .libs/libctf_nobfd_la-ctf-labels.o .libs/libctf_nobfd_la-ctf-dedup.o .libs/libctf_nobfd_la-ctf-link.o .libs/libctf_nobfd_la-ctf-lookup.o .libs/libctf_nobfd_la-ctf-open.o .libs/libctf_nobfd_la-ctf-serialize.o .libs/libctf_nobfd_la-ctf-sha1.o .libs/libctf_nobfd_la-ctf-string.o .libs/libctf_nobfd_la-ctf-subr.o .libs/libctf_nobfd_la-ctf-types.o .libs/libctf_nobfd_la-ctf-util.o   |  | /nix/store/8ysd696cpacbvhy61z57w4vg7jn2gncz-bootstrap-stage0-clang/bin/sed 's/.* //' | sort | uniq > .libs/libctf-nobfd.exp'

./libtool: eval: line 1115: syntax error near unexpected token `|'

This usually happens when a command is completely missing between pipes: ./a | $foo | $bar when $foo is undefined. binutils might have taken on some new dependency normally present on linux. Do you have a full build long handy by chance?
Trying to reproduce locally meanwhile.

https://gist.github.com/risicle/dda04fc876a118f494e41a66d26f7eea

Aha, checking the name lister (/nix/store/2z3fkfy273yqg2ylxyybvly0dks1nlby-bootstrap-stage0-clang-wrapper-11.1.0/bin/nm -B) interface... yes, but that nm does not support -B option. That's a binutils's configure bug. I'll stare at it a bit more to see where -B slips in.
Do you know where nm comes from in bootstrap-stage0 on darwin? At least on Linux llvmPackages_11.llvm does have nm -B flag support. In my environment ld -v from bootstrap tools says it's something called ld64-530.  ttps://opensource.apple.com/source/ld64/ld64-530/src/ld/ld.cpp.auto.html says it's from 2011.
Could it be that it's an ancient llvm version?

Oh, it's something called dawin.cctools (found in pkgs/stdenv/darwin/make-bootstrap-tools.nix). https://opensource.apple.com/source/cctools/. Has no support for -B option in latest version either. No easy workaround it seems. binutils will need to adapt.

Filed upstream bug as https://sourceware.org/PR29547

Proposed nixpkgs-specific fix as https://github.com/NixOS/nixpkgs/pull/189894 by reverting nm-specific binutils patches again until it gets fixed upstream.

Seems to have broken cross-compilation of libbfd.

Ah, because this PR enabled the libbfd documentation and it isn't cross friendly.

Let's try to sort it with https://github.com/NixOS/nixpkgs/pull/190897


AMQP: ReactorExecutor stops due to IllegalStateException after application runs for multiple days

We have an application that consumes Events from an Iot Hub. The application works fine for some days and then stops consuming incoming events. The application enters a state where it simply does nothing anymore, because it doesn't fetch events from the IotHub.
The moment the application stops to work can be tracked down to an IllegalStateException that is catched in com.azure.core.amqp.implementation.ReactorExecutor. We are not able to identify the cause of this though.
Question: What are reasons this exception may occur and how can I battle them or at least continue to fetch Events from Iot Hub?
Setup :

OS: Windows 10
IDE : IntelliJ
azure-core-amqp-1.3.0

We consume the events like the following:

EventHubConsumerAsyncClient
.receive(false)
.subscribe(
partitionEvent -> {
// execute logic
},
ex -> log.error("Error during receiving events: " + ex.getMessage()),
() -> log.info(INFO_COMPLETED_RECEIVING_EVENTS));

The following exception appears after the application runs for multiple days:
scheduleCompletePendingTasks - exception occurred while processing events. java.lang.IllegalStateException org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:112) org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324) org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:291) com.azure.core.amqp.implementation.ReactorExecutor.lambda$scheduleCompletePendingTasks$0(ReactorExecutor.java:156) reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:50) reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:27) java.base/java.util.concurrent.FutureTask.run(Unknown Source) java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) java.base/java.lang.Thread.run(Unknown Source)Cause: null org.apache.qpid.proton.engine.impl.EndpointImpl.decref(EndpointImpl.java:54) org.apache.qpid.proton.engine.impl.TransportImpl.unbind(TransportImpl.java:315) com.azure.core.amqp.implementation.handler.ConnectionHandler.onTransportError(ConnectionHandler.java:159) org.apache.qpid.proton.engine.BaseHandler.handle(BaseHandler.java:191) org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:108) org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324) org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:291) com.azure.core.amqp.implementation.ReactorExecutor.lambda$scheduleCompletePendingTasks$0(ReactorExecutor.java:156) reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:50) reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:27) java.base/java.util.concurrent.FutureTask.run(Unknown Source) java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) java.base/java.lang.Thread.run(Unknown Source)]
Followed by:
Stopping the reactor because thread was interrupted or the reactor has no more events to process.

Thanks for reporting this reliability issue in Event Hubs AMQP layer.  @conniey can you please investigate?

Do you have the full output logs from the library?

I'm trying to understand what the contents of that IllegalStateException are.
It shows that there is a transport error in the underlying library: com.azure.core.amqp.implementation.handler.ConnectionHandler.onTransportError(ConnectionHandler.java:159), so it would be nice to understand what that error is.

Does it ever recover? We have logic that when the connection closes, we will try to re-instantiate it.

Stopping the reactor because thread was interrupted or the reactor has no more events to process.

Is a normal part of closing a proton-j reactor connection. I'll make note to not change that to informational.

Thanks for the fast replies!
The application does not recover from this exception. It seems to do a retry but it doesn't work somehow.
We are also using EventHubConsumerAsyncClient 's subscribe() method which says that it shouldn't be used for production systems so probably we should switch to EventProcessorClient like the documentation suggests.
More log:

onLinkRemoteClose connectionId[MF_f6aa5b_1601880891022], linkName[mgmt:sender], errorCondition[amqp:connection:forced], errorDescription[The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05]","logger_name":"com.azure.core.amqp.implementation.handler.SendLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
processOnClose connectionId[MF_f6aa5b_1601880891022], linkName[mgmt:sender], errorCondition[amqp:connection:forced], errorDescription[The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5,Timestamp:2020-10-05T13:44:05]","logger_name":"com.azure.core.amqp.implementation.handler.SendLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
Retry #1. Transient error occurred. Retrying after 4511 ms.\nThe connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05, errorContext[NAMESPACE: iothub-ns-ssf-iothub-3802138-ca4b082f0a.servicebus.windows.net, PATH: $management, REFERENCE_ID: mgmt:sender, LINK_CREDIT: 99]","logger_name":"class com.azure.core.amqp.implementation.RequestResponseChannel","thread_name":"single-1","level":"WARN","level_value":30000}
Exception occurred:\nThe connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05, errorContext[NAMESPACE: iothub-ns-ssf-iothub-3802138-ca4b082f0a.servicebus.windows.net, PATH: $management, REFERENCE_ID: mgmt:sender, LINK_CREDIT: 99]","logger_name":"com.azure.messaging.eventhubs.implementation.ManagementChannel","thread_name":"single-1","level":"ERROR","level_value":40000}
Upstream connection publisher was completed. Terminating processor.","logger_name":"class com.azure.core.amqp.implementation.RequestResponseChannel","thread_name":"single-1","level":"INFO","level_value":20000}
namespace[MF_f6aa5b_1601880891022] entityPath[$management]: AMQP channel processor completed. Notifying 0 subscribers.","logger_name":"class com.azure.core.amqp.implementation.RequestResponseChannel","thread_name":"single-1","level":"INFO","level_value":20000}
Exception in RequestResponse links. Disposing and clearing unconfirmed sends.\nThe connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05, errorContext[NAMESPACE:iothub-ns-ssf-iothub-3802138-ca4b082f0a.servicebus.windows.net, PATH: $management, REFERENCE_ID: mgmt:sender, LINK_CREDIT: 99]","logger_name":"class com.azure.core.amqp.implementation.RequestResponseChannel","thread_name":"single-1","level":"ERROR","level_value":40000}
onLinkLocalClose connectionId[MF_f6aa5b_1601880891022], linkName[mgmt:sender], errorCondition[amqp:connection:forced], errorDescription[The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05]","logger_name":"com.azure.core.amqp.implementation.handler.SendLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkLocalClose connectionId[MF_f6aa5b_1601880891022], linkName[mgmt:receiver], errorCondition[null], errorDescription[null]","logger_name":"com.azure.core.amqp.implementation.handler.ReceiveLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkRemoteClose connectionId[MF_f6aa5b_1601880891022], linkName[mgmt:receiver], errorCondition[amqp:connection:forced], errorDescription[The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05]","logger_name":"com.azure.core.amqp.implementation.handler.ReceiveLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
processOnClose connectionId[MF_f6aa5b_1601880891022], linkName[mgmt:receiver], errorCondition[amqp:connection:forced], errorDescription[The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05]","logger_name":"com.azure.core.amqp.implementation.handler.ReceiveLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionRemoteClose connectionId[mgmt-session], entityName[MF_f6aa5b_1601880891022], condition[Error{condition=null, description='null', info=null}]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionRemoteClose closing a local session for connectionId[MF_f6aa5b_1601880891022], entityName[mgmt-session], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
connectionId[MF_f6aa5b_1601880891022] sessionName[mgmt-session]: Complete. Removing and disposing session.","logger_name":"com.azure.core.amqp.implementation.ReactorConnection","thread_name":"single-1","level":"INFO","level_value":20000}
sessionId[mgmt-session]: Disposing of session.","logger_name":"com.azure.core.amqp.implementation.ReactorSession","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionRemoteClose connectionId[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/0], entityName[MF_f6aa5b_1601880891022], condition[Error{condition=null, description='null', info=null}]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionRemoteClose closing a local session for connectionId[MF_f6aa5b_1601880891022], entityName[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/0], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
connectionId[MF_f6aa5b_1601880891022] sessionName[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/0]: Complete. Removing and disposing session.","logger_name":"com.azure.core.amqp.implementation.ReactorConnection","thread_name":"single-1","level":"INFO","level_value":20000}
sessionId[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/0]: Disposing of session.","logger_name":"com.azure.core.amqp.implementation.ReactorSession","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkRemoteClose connectionId[MF_f6aa5b_1601880891022], linkName[cbs:sender], errorCondition[amqp:connection:forced], errorDescription[The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05]","logger_name":"com.azure.core.amqp.implementation.handler.SendLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
processOnClose connectionId[MF_f6aa5b_1601880891022], linkName[cbs:sender], errorCondition[amqp:connection:forced], errorDescription[The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05]","logger_name":"com.azure.core.amqp.implementation.handler.SendLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
Retry #1. Transient error occurred. Retrying after 4511 ms.\nThe connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05, errorContext[NAMESPACE: iothub-ns-ssf-iothub-3802138-ca4b082f0a.servicebus.windows.net, PATH: $cbs, REFERENCE_ID: cbs:sender, LINK_CREDIT: 66]","logger_name":"class com.azure.core.amqp.implementation.RequestResponseChannel","thread_name":"single-1","level":"WARN","level_value":30000}
Exception in RequestResponse links. Disposing and clearing unconfirmed sends.\nThe connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05, errorContext[NAMESPACE:iothub-ns-ssf-iothub-3802138-ca4b082f0a.servicebus.windows.net, PATH: $cbs, REFERENCE_ID: cbs:sender, LINK_CREDIT: 66]","logger_name":"class com.azure.core.amqp.implementation.RequestResponseChannel","thread_name":"single-1","level":"ERROR","level_value":40000}
onLinkRemoteClose connectionId[MF_f6aa5b_1601880891022], linkName[cbs:receiver], errorCondition[amqp:connection:forced], errorDescription[The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05]","logger_name":"com.azure.core.amqp.implementation.handler.ReceiveLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
processOnClose connectionId[MF_f6aa5b_1601880891022], linkName[cbs:receiver], errorCondition[amqp:connection:forced], errorDescription[The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05]","logger_name":"com.azure.core.amqp.implementation.handler.ReceiveLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionRemoteClose connectionId[cbs-session], entityName[MF_f6aa5b_1601880891022], condition[Error{condition=null, description='null', info=null}]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionRemoteClose closing a local session for connectionId[MF_f6aa5b_1601880891022], entityName[cbs-session], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
connectionId[MF_f6aa5b_1601880891022] sessionName[cbs-session]: Complete. Removing and disposing session.","logger_name":"com.azure.core.amqp.implementation.ReactorConnection","thread_name":"single-1","level":"INFO","level_value":20000}
sessionId[cbs-session]: Disposing of session.","logger_name":"com.azure.core.amqp.implementation.ReactorSession","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionRemoteClose connectionId[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/1], entityName[MF_f6aa5b_1601880891022], condition[Error{condition=null, description='null', info=null}]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionRemoteClose closing a local session for connectionId[MF_f6aa5b_1601880891022], entityName[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/1], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
connectionId[MF_f6aa5b_1601880891022] sessionName[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/1]: Complete. Removing and disposing session.","logger_name":"com.azure.core.amqp.implementation.ReactorConnection","thread_name":"single-1","level":"INFO","level_value":20000}
sessionId[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/1]: Disposing of session.","logger_name":"com.azure.core.amqp.implementation.ReactorSession","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionRemoteClose connectionId[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/2], entityName[MF_f6aa5b_1601880891022], condition[Error{condition=null, description='null', info=null}]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionRemoteClose closing a local session for connectionId[MF_f6aa5b_1601880891022], entityName[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/2], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
connectionId[MF_f6aa5b_1601880891022] sessionName[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/2]: Complete. Removing and disposing session.","logger_name":"com.azure.core.amqp.implementation.ReactorConnection","thread_name":"single-1","level":"INFO","level_value":20000}
sessionId[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/2]: Disposing of session.","logger_name":"com.azure.core.amqp.implementation.ReactorSession","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionRemoteClose connectionId[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/3], entityName[MF_f6aa5b_1601880891022], condition[Error{condition=null, description='null', info=null}]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionRemoteClose closing a local session for connectionId[MF_f6aa5b_1601880891022], entityName[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/3], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
connectionId[MF_f6aa5b_1601880891022] sessionName[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/3]: Complete. Removing and disposing session.","logger_name":"com.azure.core.amqp.implementation.ReactorConnection","thread_name":"single-1","level":"INFO","level_value":20000}
sessionId[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/3]: Disposing of session.","logger_name":"com.azure.core.amqp.implementation.ReactorSession","thread_name":"single-1","level":"INFO","level_value":20000}
onConnectionRemoteClose hostname[iothub-ns-ssf-iothub-3802138-ca4b082f0a.servicebus.windows.net:443], connectionId[MF_f6aa5b_1601880891022], errorCondition[amqp:connection:forced], errorDescription[The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05]","logger_name":"com.azure.core.amqp.implementation.handler.ConnectionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
namespace[iothub-ns-ssf-iothub-3802138-ca4b082f0a.servicebus.windows.net] entityPath[ssf-iothub-dev]: Channel is closed.","logger_name":"com.azure.messaging.eventhubs.implementation.EventHubConnectionProcessor","thread_name":"single-1","level":"INFO","level_value":20000}
connectionId[MF_f6aa5b_1601880891022]: Disposing of connection.","logger_name":"com.azure.messaging.eventhubs.implementation.EventHubReactorAmqpConnection","thread_name":"single-1","level":"INFO","level_value":20000}
connectionId[MF_f6aa5b_1601880891022]: Disposing of ReactorConnection.","logger_name":"com.azure.core.amqp.implementation.ReactorConnection","thread_name":"single-1","level":"INFO","level_value":20000}
Shutdown received: ReactorExecutor.close() was called., isTransient[false], initiatedByClient[true]","logger_name":"com.azure.core.amqp.implementation.AmqpExceptionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
Retry #1. Requesting from upstream.","logger_name":"class com.azure.core.amqp.implementation.RequestResponseChannel","thread_name":"parallel-1","level":"INFO","level_value":20000}
namespace[MF_f6aa5b_1601880891022] entityPath[$cbs]: Connection not requested, yet. Requesting one.","logger_name":"class com.azure.core.amqp.implementation.RequestResponseChannel","thread_name":"parallel-1","level":"INFO","level_value":20000}
connectionId[MF_f6aa5b_1601880891022]: Connection is disposed. Cannot get CBS node.","logger_name":"com.azure.core.amqp.implementation.ReactorConnection","thread_name":"parallel-1","level":"ERROR","level_value":40000}
Emitting new response channel. connectionId: MF_f6aa5b_1601880891022. entityPath: $cbs. linkName: cbs.","logger_name":"com.azure.core.amqp.implementation.ReactorConnection","thread_name":"parallel-1","level":"INFO","level_value":20000}
namespace[MF_f6aa5b_1601880891022] entityPath[$cbs]: Setting next AMQP channel.","logger_name":"class com.azure.core.amqp.implementation.RequestResponseChannel","thread_name":"parallel-1","level":"INFO","level_value":20000}
namespace[MF_f6aa5b_1601880891022] entityPath[$cbs]: Next AMQP channel received, updating 0 current subscribers","logger_name":"class com.azure.core.amqp.implementation.RequestResponseChannel","thread_name":"parallel-1","level":"INFO","level_value":20000}
Unable to acquire dispose reactor semaphore within timeout.","logger_name":"com.azure.core.amqp.implementation.ReactorExecutor","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkLocalClose connectionId[MF_f6aa5b_1601880891022], linkName[cbs:sender], errorCondition[amqp:connection:forced], errorDescription[The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:549ad803b097405ba863949c809695bd_G20, SystemTracker:gateway5, Timestamp:2020-10-05T13:44:05]","logger_name":"com.azure.core.amqp.implementation.handler.SendLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkLocalClose connectionId[MF_f6aa5b_1601880891022], linkName[cbs:receiver], errorCondition[null], errorDescription[null]","logger_name":"com.azure.core.amqp.implementation.handler.ReceiveLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onConnectionLocalClose hostname[iothub-ns-ssf-iothub-3802138-ca4b082f0a.servicebus.windows.net:443], connectionId[MF_f6aa5b_1601880891022], errorCondition[null], errorDescription[null]","logger_name":"com.azure.core.amqp.implementation.handler.ConnectionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onConnectionUnbound hostname[iothub-ns-ssf-iothub-3802138-ca4b082f0a.servicebus.windows.net:443], connectionId[MF_f6aa5b_1601880891022], state[CLOSED], remoteState[CLOSED]","logger_name":"com.azure.core.amqp.implementation.handler.ConnectionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkFinal connectionId[MF_f6aa5b_1601880891022],  linkName[mgmt:sender]","logger_name":"com.azure.core.amqp.implementation.handler.SendLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkFinal connectionId[MF_f6aa5b_1601880891022],  linkName[mgmt:receiver]","logger_name":"com.azure.core.amqp.implementation.handler.ReceiveLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionFinal connectionId[MF_f6aa5b_1601880891022], entityName[mgmt-session], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionFinal connectionId[MF_f6aa5b_1601880891022], entityName[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/0], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkFinal connectionId[MF_f6aa5b_1601880891022],  linkName[cbs:sender]","logger_name":"com.azure.core.amqp.implementation.handler.SendLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkFinal connectionId[MF_f6aa5b_1601880891022],  linkName[cbs:receiver]","logger_name":"com.azure.core.amqp.implementation.handler.ReceiveLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionFinal connectionId[MF_f6aa5b_1601880891022], entityName[cbs-session], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionFinal connectionId[MF_f6aa5b_1601880891022], entityName[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/1], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionFinal connectionId[MF_f6aa5b_1601880891022], entityName[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/2], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionFinal connectionId[MF_f6aa5b_1601880891022], entityName[ssf-iothub-dev/ConsumerGroups/$Default/Partitions/3], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkFinal connectionId[MF_f6aa5b_1601880891022],  linkName[cbs:sender]","logger_name":"com.azure.core.amqp.implementation.handler.SendLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkFinal connectionId[MF_f6aa5b_1601880891022],  linkName[cbs:receiver]","logger_name":"com.azure.core.amqp.implementation.handler.ReceiveLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onSessionFinal connectionId[MF_f6aa5b_1601880891022], entityName[cbs-session], condition[null], description[null]","logger_name":"com.azure.core.amqp.implementation.handler.SessionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
connectionId[MF_f6aa5b_1601880891022] sessionName[cbs-session]: Complete. Removing and disposing session.","logger_name":"com.azure.core.amqp.implementation.ReactorConnection","thread_name":"single-1","level":"INFO","level_value":20000}
sessionId[cbs-session]: Disposing of session.","logger_name":"com.azure.core.amqp.implementation.ReactorSession","thread_name":"single-1","level":"INFO","level_value":20000}
onConnectionFinal hostname[iothub-ns-ssf-iothub-3802138-ca4b082f0a.servicebus.windows.net:443], connectionId[MF_f6aa5b_1601880891022], errorCondition[null], errorDescription[null]","logger_name":"com.azure.core.amqp.implementation.handler.ConnectionHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkLocalClose connectionId[MF_f6aa5b_1601880891022], linkName[cbs:sender], errorCondition[null], errorDescription[null]","logger_name":"com.azure.core.amqp.implementation.handler.SendLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
onLinkLocalClose connectionId[MF_f6aa5b_1601880891022], linkName[cbs:receiver], errorCondition[null], errorDescription[null]","logger_name":"com.azure.core.amqp.implementation.handler.ReceiveLinkHandler","thread_name":"single-1","level":"INFO","level_value":20000}
connectionId[MF_f6aa5b_1601880891022], message[Processing all pending tasks and closing old reactor.]","logger_name":"com.azure.core.amqp.implementation.ReactorExecutor","thread_name":"single-1","level":"INFO","level_value":20000}
onTransportError hostname[iothub-ns-ssf-iothub-3802138-ca4b082f0a.servicebus.windows.net:443], connectionId[MF_f6aa5b_1601880891022], error[Broken pipe]","logger_name":"com.azure.core.amqp.implementation.handler.ConnectionHandler","thread_name":"single-1","level":"WARN","level_value":30000}
connectionId[MF_f6aa5b_1601880891022], message[scheduleCompletePendingTasks - exception occurred while processing events.\njava.lang.IllegalStateException\norg.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:112)\norg.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324)\norg.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:291)\ncom.azure.core.amqp.implementation.ReactorExecutor.lambda$scheduleCompletePendingTasks$0(ReactorExecutor.java:156)\nreactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:68)\nreactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:28)\njava.base/java.util.concurrent.FutureTask.run(Unknown Source)\njava.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)\njava.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)\njava.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)\njava.base/java.lang.Thread.run(Unknown Source)Cause: null\norg.apache.qpid.proton.engine.impl.EndpointImpl.decref(EndpointImpl.java:54)\norg.apache.qpid.proton.engine.impl.TransportImpl.unbind(TransportImpl.java:315)\ncom.azure.core.amqp.implementation.handler.ConnectionHandler.onTransportError(ConnectionHandler.java:162)\norg.apache.qpid.proton.engine.BaseHandler.handle(BaseHandler.java:191)\norg.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:108)\norg.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324)\norg.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:291)\ncom.azure.core.amqp.implementation.ReactorExecutor.lambda$scheduleCompletePendingTasks$0(ReactorExecutor.java:156)\nreactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:68)\nreactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:28)\njava.base/java.util.concurrent.FutureTask.run(Unknown Source)\njava.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)\njava.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)\njava.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)\njava.base/java.lang.Thread.run(Unknown Source)]","logger_name":"com.azure.core.amqp.implementation.ReactorExecutor","thread_name":"single-1","level":"WARN","level_value":30000}
connectionId[MF_f6aa5b_1601880891022], message[Stopping the reactor because thread was interrupted or the reactor has no more events to process.]","logger_name":"com.azure.core.amqp.implementation.ReactorExecutor","thread_name":"single-1","level":"INFO","level_value":20000}

This looks like an issue that @srnagar and @YijunXieMS have resolved which should be fixed in our October release. Can you confirm @YijunXieMS ?

Never mind, it seems like a difference in root causes. I'll look into this. Are you using EventConsumerAsyncClient.receiveAllPartitions() ?
Yes. EventProcessorClient is the production level one you should be using. It offers connection recovery and load balancing.

We are using EventHubConsumerAsyncClient.receive(false).subscribe()
I switched to EventProcessorClient and the application runs without issues for now. It recovers from issues.
The logic for each event runs between 700ms and 1100ms

Looks like switching to EventProcessorClient resolved the issue. Closing this issue.

Usage of EventProcessorClient, you can refer to the following links:

create EventProcessorClient
SampleCheckpointStore.java