windows,  border or line is blurry on some size.

1.Change the window size, see bellow:

2.sample code:
void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        // This is the theme of your application.
        //
        // Try running your application with "flutter run". You'll see the
        // application has a blue toolbar. Then, without quitting the app, try
        // changing the primarySwatch below to Colors.green and then invoke
        // "hot reload" (press "r" in the console where you ran "flutter run",
        // or simply save your changes to "hot reload" in a Flutter IDE).
        // Notice that the counter didn't reset back to zero; the application
        // is not restarted.
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);

  // This widget is the home page of your application. It is stateful, meaning
  // that it has a State object (defined below) that contains fields that affect
  // how it looks.

  // This class is the configuration for the state. It holds the values (in this
  // case the title) provided by the parent (in this case the App widget) and
  // used by the build method of the State. Fields in a Widget subclass are
  // always marked "final".

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      // This call to setState tells the Flutter framework that something has
      // changed in this State, which causes it to rerun the build method below
      // so that the display can reflect the updated values. If we changed
      // _counter without calling setState(), then the build method would not be
      // called again, and so nothing would appear to happen.
      _counter++;
    });
  }

  @override
  Widget build(BuildContext context) {
    // This method is rerun every time setState is called, for instance as done
    // by the _incrementCounter method above.
    //
    // The Flutter framework has been optimized to make rerunning build methods
    // fast, so that you can just rebuild anything that needs updating rather
    // than having to individually change instances of widgets.
    return Scaffold(
      appBar: AppBar(
        // Here we take the value from the MyHomePage object that was created by
        // the App.build method, and use it to set our appbar title.
        title: Text(widget.title),
      ),
      body: Row(children: [
        Expanded(
            flex: 1,
            child: Container(
              margin: const EdgeInsets.all(17),
              decoration: BoxDecoration(
                  border: Border.all(color: Colors.red)
              ),
              child: Column(
                crossAxisAlignment: CrossAxisAlignment.stretch,
                children: [
                  Expanded(flex: 2,child: Container(
                    margin: const EdgeInsets.all(10),
                    decoration: BoxDecoration(
                        border: Border.all(color: Colors.green)
                    ),
                  )),
                  Expanded(flex: 3,child: Container(
                    margin: const EdgeInsets.all(10),
                    decoration: BoxDecoration(
                        border: Border.all(color: Colors.green)
                    ),
                  ))
                ],
              ),
            )),
        Expanded(
            flex: 2,
            child: Container(
              margin: const EdgeInsets.all(20),
              decoration: BoxDecoration(
                  border: Border.all(color: Colors.red)
              ),
              child: Column(
                crossAxisAlignment: CrossAxisAlignment.stretch,
                children: [
                  Expanded(flex: 2,child: Container(
                    margin: const EdgeInsets.all(10),
                    decoration: BoxDecoration(
                        border: Border.all(color: Colors.green)
                    ),
                  )),
                  Expanded(flex: 3,child: Container(
                    margin: const EdgeInsets.all(10),
                    decoration: BoxDecoration(
                        border: Border.all(color: Colors.green)
                    ),
                  ))
                ],
              ),
            ))
      ],),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ), // This trailing comma makes auto-formatting nicer for build methods.
    );
  }
}

4.flutter doctor -v
Flutter assets will be downloaded from https://storage.flutter-io.cn. Make sure you trust this source!
[√] Flutter (Channel stable, 3.0.5, on Microsoft Windows [版本 10.0.19043.1889], locale zh-CN)
    • Flutter version 3.0.5 at D:\fluter
    • Upstream repository https://github.com/flutter/flutter.git
    • FLUTTER_GIT_URL = https://github.com/flutter/flutter.git
    • Framework revision f1875d570e (6 weeks ago), 2022-07-13 11:24:16 -0700
    • Engine revision e85ea0e79c
    • Dart version 2.17.6
    • DevTools version 2.12.2
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

[√] Android toolchain - develop for Android devices (Android SDK version 32.0.0)
    • Android SDK at C:\Users\liping\AppData\Local\Android\sdk
    • Platform android-32, build-tools 32.0.0
    • Java binary at: D:\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.12+7-b1504.28-7817840)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.10.3)
    • Visual Studio at D:\Microsoft Visual Studio\2019\Community
    • Visual Studio Community 2019 version 16.10.31424.327
    • Windows 10 SDK version 10.0.19041.0

[√] Android Studio (version 2021.2)
    • Android Studio at D:\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.12+7-b1504.28-7817840)

[√] Connected device (4 available)
    • Android SDK built for x86 (mobile) • emulator-5554 • android-x86    • Android 5.1.1 (API 22) (emulator)
    • Windows (desktop)                  • windows       • windows-x64    • Microsoft Windows [版本 10.0.19043.1889]
    • Chrome (web)                       • chrome        • web-javascript • Google Chrome 104.0.5112.81
    • Edge (web)                         • edge          • web-javascript • Microsoft Edge 104.0.1293.63
    ! Device 483d50e0 is offline.

[√] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

Hi @liqping, thanks for filing the issue.
I see there's an open issue addressing the case you described #100184. Although that issue is about changing the border width, take a look at the demos the borders are blurred as yours. Do you find them similar?

@huycozy I see. That is the same issue.

Hi @liqping, thanks for your confirmation. Closing this issue as a duplicate, so please follow up on https://github.com/flutter/flutter/issues/100184 for further updates.
You can leave there your comment and react an upvote to the original comment will help to raise the issue.


add 'onActiveChange' callback to DatePicker

this makes external management of the 'active' property much simpler
for example - the onFocus event was cancelling the onClick event for the text box
the onFocus handler did not trigger the 'onClick' property and so there was no way to properly manage the 'active' property externally.
this commit adds a callback for whenever the 'active' state changes internally so the external state (e.g. in redux can be updated also)
the result should be:

whenever the internal state changes - the external callback triggers updating external state to the internal value
if the external state changes - the new value should be passed in as the 'active' property and this.componentWillReceiveProps will call this.setState

these changes should be backwards compatable with existing code as they don't change existing callback handlers or the internal triggers just adds an extra callback

What happened to this PR?


Hydrogen needs to know about production URLs

Sometimes we need this for meta/SEO tags, like full canonical URLs.
We also need to reference sitemap URLs: #533
We should investigate a way for a developer to provide an intended production URL. Maybe start with a default assumption and allow it to be overridden? Perhaps a new optional config in shopify.config.js?

A few places that we can get url from

From SF API
using field shop: primaryDomain: url
the demo shop will return https://hydrogen-preview.myshopify.com

**Con: **

does not change with the environment, local or staging...etc
we only have domain and not the rest of url

From windows object
using window.location.href

**Con: **

only works in browser and not with SSR (ie. using ?_bot and inspect page)

From server object
using useServerRequest().url

**Con: **

only works in server component
useServerRequest is not publicly expose for merchant to use
navigation ( ie. from home page to product page) means this url becomes the RSC server call url and not the current url

@blittle do you have an immediate requirement for url need in i18n? Or should the production / current env url covers it.

I don't know, it depends on what the priorities are for i18n and RC 1. cc @benjaminsehl @morganmccunn


Loosened S3BucketPublisherContext's coupling with its corresponding plugin config

This is a small change to fix a bug where you cannot use the S3 bucket publisher plugin with the DSL.
Basically the DSL enforces that you set the region in caps with underscores, like AP_SOUTHEAST_2, whereas the S3 bucket publisher plugin's configuration expects a region in lower case with hyphens, like ap-southeast-2.  To work around this we had to use a configure block, which is a bit ugly.
This fix loosens the checking that occurs on the DSL's parameters, so that in future if the S3 bucket publisher changes the nature of its region configuration, the Job DSL should not need to also change.  It simply enforces that the region parameter is necessary.

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

The value are checked to detect typos in DSL scripts as early as possible, so it should not be removed. The problem is that the S3 plugin changed it's config format for no obvious reason and thus breaking not only the Job DSL but also every job config created manually with versions < 0.7. This has already been discussed in #346. I would rather deprecate DSL support for the S3 plugin than fixing random compatibility issues.

So the alternative is to use configure blocks and hack the XML? This is far
less user friendly than just not checking typos, and if a typo does occur
the build itself will fail anyway. Detecting errors early is just a "nice
to have". I'm speaking on behalf of your users when I say I think you're
making the wrong decision here.
On Wed, 28 Jan 2015 11:07 pm Daniel Spilker<EMAIL_ADDRESS>wrote:

Closed #363 https://github.com/jenkinsci/job-dsl-plugin/pull/363.
—
Reply to this email directly or view it on GitHub
https://github.com/jenkinsci/job-dsl-plugin/pull/363#event-226028434.

I submitted a pull request for the fix in the s3 plugin -- still waiting on feedback.
https://github.com/jenkinsci/s3-plugin/pull/46

@luke-tsekouras-sirca I think it's a great decision. It's not a goal to have DSL support for all 1000+ plugins. Poorly maintained plugins which cause careless compatibility problems are not good candidates for DSL support. So DSL support will be deprecated and removed when a plugin causes issues. Your fix will not restore compatibility. Instead it would force all DSL users to change their scripts to use lower case region names. And they will recognize the problem only after a job has failed and subsequent debugging. Users will not be happy to see that a job has failed after hours or during the night only due to a typo in the S3 publisher configuration that could have been detected while generating the job config.

@daspilker hope I didn't come across too harshly earlier, I was quite tired from debugging this issue the evening before.  I'm not sure if you'll waver here but I urge you to reconsider.
Contrary to what you said, this change will not force users to change their scripts to use lower case region names.  It allows users to use whatever region names their particular version of the plugin supports; no changes required for anyone, and no late night debugging.  In any case, any job that you write, be it through the UI or the DSL, requires manual testing at the end of the day, so I see no benefit in enforcing any rules on the parameters here.
Additionally this PR is actually bringing this plugin's DSL closer to the way that existing plugins work with magic String values:

https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/common/DownstreamContext.groovy#L32
https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/publisher/PublisherContext.groovy#L516
https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/publisher/PublisherContext.groovy#L516
https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/BuildParametersContext.groovy#L62
https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/wrapper/WrapperContext.groovy#L297

Other things that are checked are either coupled with global standards that are expected to be unwavering:

https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/scm/RemoteContext.groovy#L36

or are coupled to Jenkins itself:

https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/publisher/PublisherContext.groovy#L560


Patch for Lost SymLinks & CodeSigning Issues

I think the issues with Code Signing
Stem for the Zip process losing symlinks. I saw that kingfisher has a similar issue documented here:
Conversation
Their Fix
I tested this locally and this is working for us now 🤓

Would love to get this in, if it fixes things @akaffenberger?

+1


Dev brokenlinks

Some of the broken links that were identified during the developer workshop are replaced by non-broken equivalents. For others there might be some need for discussion, i.e. the situation isn't clear as to whether to delete certain broken links entirely or if there even is a working alternative. Therefore not all of the possible changes are encompassed by the pull request.
Also some older http addresses were changed to https.

@doerners do you want to make further changes, or should I merge this?

@rettinghaus well there are still some unresolved questions regarding the broken links in issue #189
I'm not sure what's the best course of action now...any suggestions?

@doerners I would say that broken links should always be fixed as soon as possible. And #189 will most likely take some time before being fully resolved.

@rettinghaus I second your point(s), so I would suggest that you do the merge now since there are no immediated changes planned on my side. That is of course if there are no objections from the community.


Cordova ignores (android) for 3.4

Not much else to say: Here's what i ignore on a cordova/android project.

Superseded by #1758


Fail to install keystone package on ubuntu14.04

It fails to install keystone and throw this error:
E: Failed to fetch https://packagecloud.io/blueboxcloud/giftwrap/ubuntu/pool/trusty/main/o/openstack-keystone-10.0-bbc72/openstack-keystone-10.0-bbc72_10.0-bbc72_amd64.deb
But i can download this file through wget tool
############################################################
Log:
TASK: [openstack-package | install keystone package] **************************
Wednesday 22 July 2015  04:48:36 -0500 (0:00:00.504)       0:01:37.453 ********
failed: [<IP_ADDRESS>] => {"failed": true}
stderr: E: Failed to fetch https://packagecloud.io/blueboxcloud/giftwrap/ubuntu/pool/trusty/main/o/openstack-keystone-10.0-bbc72/openstack-keystone-10.0-bbc72_10.0-bbc72_amd64.deb
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
stdout: Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
openstack-keystone-10.0-bbc72
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
8 not fully installed or removed.
Need to get 19.6 MB of archives.
After this operation, 65.3 MB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
openstack-keystone-10.0-bbc72
Err https://packagecloud.io/blueboxcloud/giftwrap/ubuntu/ trusty/main openstack-keystone-10.0-bbc72 amd64 10.0-bbc72
msg: '/usr/bin/apt-get -y -o "Dpkg::Options::=--force-confdef" -o "Dpkg::Options::=--force-confold" --force-yes  install 'openstack-keystone-10.0-bbc72'' failed: E: Failed to fetch https://packagecloud.io/blueboxcloud/giftwrap/ubuntu/pool/trusty/main/o/openstack-keystone-10.0-bbc72/openstack-keystone-10.0-bbc72_10.0-bbc72_amd64.deb
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
FATAL: all hosts have already failed -- aborting
PLAY RECAP ******************************************************************
##############################################################
root@hkg02kvm003ccz023:/cloud/dev/ursula# wget https://packagecloud.io/blueboxcloud/giftwrap/ubuntu/pool/trusty/main/o/openstack-keystone-10.0-bbc72/openstack-keystone-10.0-bbc72_10.0-bbc72_amd64.deb
--2015-07-22 04:51:47--  https://packagecloud.io/blueboxcloud/giftwrap/ubuntu/pool/trusty/main/o/openstack-keystone-10.0-bbc72/openstack-keystone-10.0-bbc72_10.0-bbc72_amd64.deb
Resolving packagecloud.io (packagecloud.io)... <IP_ADDRESS>
Connecting to packagecloud.io (packagecloud.io)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://packagecloud-repositories.s3.amazonaws.com/1211/1535/ubuntu/package_files/26924.deb?AWSAccessKeyId=AKIAI44QGWC7C5WEV4XA&Signature=8D1iwBT6q5RP4aGv6Gt1VkWHcsA%3D&Expires=1437559009 [following]
--2015-07-22 04:51:48--  https://packagecloud-repositories.s3.amazonaws.com/1211/1535/ubuntu/package_files/26924.deb?AWSAccessKeyId=AKIAI44QGWC7C5WEV4XA&Signature=8D1iwBT6q5RP4aGv6Gt1VkWHcsA%3D&Expires=1437559009
Resolving packagecloud-repositories.s3.amazonaws.com (packagecloud-repositories.s3.amazonaws.com)... <IP_ADDRESS>
Connecting to packagecloud-repositories.s3.amazonaws.com (packagecloud-repositories.s3.amazonaws.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 19608868 (19M) [application/x-debian-package]
Saving to: 'openstack-keystone-10.0-bbc72_10.0-bbc72_amd64.deb'
100%[==============================================================================================>] 19,608,868  5.58MB/s   in 5.6s
2015-07-22 04:52:04 (3.35 MB/s) - 'openstack-keystone-10.0-bbc72_10.0-bbc72_amd64.deb' saved [19608868/19608868]

We've updated the packages and this should be resolved.


Multiple OR and AND security requirements and side effects

Just asked a question on http://stackoverflow.com/questions/42679595/swagger-openapi-multiple-security-requirements-and-side-effects but then thought this might be a better place.
When implementing the specification I am not sure how to handle multiple security requirements that are OR and AND. Generally, a failed security requirement has side effects, for example OAuth2 needs to redirect and basic authentication need to set a header and result code.
However, which one of the security requirements to pick?

The concern will be managed in this more recent ticket
https://github.com/OAI/OpenAPI-Specification/issues/4119


create a image, the image should be in the first of image list

In GitLab by @wknet123 on Jun 6, 2018, 15:13

In GitLab by @yhua123 on Nov 8, 2019, 07:51
image list sort by time

In GitLab by @sokril on Nov 8, 2019, 07:51
fix with #2066

In GitLab by @wknet123 on Nov 8, 2019, 07:51
Closing it as fixed.

In GitLab by @sokril on Nov 8, 2019, 08:22
closed

In GitLab by @sokril on Nov 8, 2019, 08:22
assigned to @wknet123


feat/event-metadata

This PR comes to enhance event management by providing an additional metadata parameter to publish method.
For now, metadata carries 2 properties : initiator and timestamp.
metadata is always provided thanks to redux eventBus middleware but its use is optional in reducers.

Codecov Report

Merging #191 (692d082) into main (9ac4ae3) will increase coverage by 0.05%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #191      +/-   ##
==========================================
+ Coverage   96.04%   96.10%   +0.05%
==========================================
  Files          38       38
  Lines         354      359       +5
  Branches       42       44       +2
==========================================
+ Hits          340      345       +5
  Misses         12       12
  Partials        2        2

Impacted Files
Coverage Δ

src/domain/common/actionCreators.ts
100.00% <ø> (ø)

src/domain/error/entity/error.ts
100.00% <ø> (ø)

src/domain/error/store/store.ts
100.00% <ø> (ø)

src/domain/faucet/store/store.ts
100.00% <ø> (ø)

src/domain/wallet/store/store.ts
100.00% <ø> (ø)

src/adapters/error/primary/eventListeners.ts
100.00% <100.00%> (ø)

src/domain/common/store.helper.ts
100.00% <100.00%> (ø)

src/domain/error/builder/error.builder.ts
100.00% <100.00%> (ø)

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

:tada: This PR is included in version 1.6.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


add check of lengthscales shape to Stationary kernel

Stationary kernels didn't check shape of lengthscales. If you have a non-ARD kernel, you should only be able to pass a single lengthscale. Shot myself in the foot because of this twice now. This PR adds checks (and tests for the checks).

Could we also have a cast to float so that lengthscales=1 doesn't break it?

Codecov Report

Merging #694 into master will decrease coverage by 0.5%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #694      +/-   ##
==========================================
- Coverage   98.09%   97.59%   -0.51%
==========================================
  Files          48       48
  Lines        4105     4109       +4
==========================================
- Hits         4027     4010      -17
- Misses         78       99      +21

Impacted Files
Coverage Δ

gpflow/kernels.py
99.43% <100%> (ø)
:arrow_up:

gpflow/features.py
68.65% <0%> (-31.35%)
:arrow_down:

Continue to review full report at Codecov.

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


dbt seed does not handle blanks as NULLS (for int fields)

Describe the bug
A clear and concise description of what the bug is. What command did you run? What happened?
Running dbt seed -s mycsv leads to this error:
('22018', "[22018] [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Conversion failed when converting the varchar value 'None' to data type int. (245) (SQLExecDirectW)")
Steps To Reproduce
In as much detail as possible, please provide steps to reproduce the issue. Sample data that triggers the issue, example model code, etc is all very helpful here.
Below .csv fails with Errror
Id, col
1,1
2,NULL
3,3
Below .csv fails with Errror
Id, col
1,1
2,
3,3
Below .csv passes
Id, col
1,1
2,2
3,3
Expected behavior
A clear and concise description of what you expected to happen.
Blank columns that Python inteprets as Nones are interpreted as NULLS by DB
Screenshots and log output
If applicable, add screenshots or log output to help explain your problem.
System information
Which database are you using dbt with?
dbt-synapse adapter
The output of dbt --version:
installed version: 0.18.0
   latest version: 0.18.1

The operating system you're using:
Windows
The output of python --version:
Python 3.8.6
Additional context
Add any other context about the problem here.

Hey @alittlesliceoftom, have you tried setting the column_types config in dbt_project.yml?
seeds:
  my_project:
    my_seed:
      +column_types:
        col: int

If that doesn't work, you could work around this issue by setting the type to varchar and then nullif and casting in a staging model.
In general, I believe this issue is specific to Synapse and the dbt-synapse adapter. I don't think there's a code change we can make in this repository, and as such I'm going to close the issue. I'd recommend re-opening in that plugin's repository to investigate enhancements to type inference in the synapse implementation of the seed materialization.


🐛 Bug Report: HTTP 500 when clicking on send button of chatbot

📜 Description
HTTP 500 when clicking on send button of chatbot
👟 Reproduction steps
Go to chatbot -> Type any prompt -> Click on send
👍 Expected behavior
No error
👎 Actual Behavior with Screenshots

💻 Operating system
Windows
What browsers are you seeing the problem on?
Chrome
📃 Provide any additional context for the Bug.
No response
📷 Relevant Screenshots (Links)
No response
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🔗 Are you willing to submit PR?
Yes, I am willing to submit a PR!
🧑⚖ Code of Conduct

[X] I agree to follow this project's Code of Conduct

Ok fix it


fix the regular expression for function clean in utils.js

Description of the Change
Fix the regular expression for function clean in utils.js to avoid potential Regular Expression Denial of Service (ReDoS) vulnerabilities.
Alternate Designs

The ReDoS vulnerabilities of the regex  /^function(?:\s*|\s+[^(]*)\([^)]*\)\s*\{((?:.|\n)*?)\s*\}$|^\([^)]*\)\s*=>\s*(?:\{((?:.|\n)*?)\s*\}|((?:.|\n)*))$/ are mainly due to the overlapped sub-patterns \s+[^(]*  and ((?:.|\n)*?)\s*.
We can ignore \s first, because in the end, we can also deal with \s using the trim function (see the code below）https://github.com/mochajs/mocha/blob/8421974e8d252e2ef11602d15bed178e4f5f4534/lib/utils.js#L92
So I am willing to suggest that you replace the ReDoS-vulnerable regex  /^function(?:\s*|\s+[^(]*)\([^)]*\)\s*\{((?:.|\n)*?)\s*\}$|^\([^)]*\)\s*=>\s*(?:\{((?:.|\n)*?)\s*\}|((?:.|\n)*))$/ with the safe regex /^function(?:\s*|\s[^(]*)\([^)]*\)\s*\{((?:.|\n)*?)\}$|^\([^)]*\)\s*=>\s*(?:\{((?:.|\n)*?)\}|((?:.|\n)*))$/
Benefits
It achieves functional equivalence and is not subject to ReDoS attacks.
Applicable issues
See the link https://www.huntr.dev/bounties/1d8a3d95-d199-4129-a6ad-8eafe5e77b9e/

hey @boneskull someone from the team asked @yetingli to open a PR with a security fix; do you guys plan on merging it sometime soon?

I am voting for this to be merged ASAP.

Reported in huntr https://www.huntr.dev/bounties/1d8a3d95-d199-4129-a6ad-8eafe5e77b9e/
Please Confirm the fix once it's merged.
@ewrayjohnson please mark as valid and confirm fix in huntr once it's merged, so that I will get rewarded for their efforts!
Thanks! cc @psmoros

Coverage decreased (-0.1%) to 94.326% when pulling 2a3005c67df109db0eb9ec5934f0b50469e89621 on yetingli:master into 111467fa6fbcea153074d57442f15055c4cd592a on mochajs:master.

@yetingli We missed it. Can you sign the CLA?
I confirmed this ReDos vulnerability and addressed it with this fix.
@mochajs/core I will merge this in a few days after CLA
Because mocha is a test framework, ReDoS is not very likely in a production environment, but it needs to be fixed.

https://github.com/mochajs/mocha/issues/4909

Hi @outsideris, thank you for your response! And I have signed the CLA.
Please mark as valid and confirm fix in huntr (https://www.huntr.dev/bounties/1d8a3d95-d199-4129-a6ad-8eafe5e77b9e/) once it's merged, so that I will get rewarded for their efforts!
Thanks! cc @psmoros

@yetingli Okay, It's my first time using Huntr. I will try it after merging this.

Which mocha version has this fix? 10.0.0 is still giving the same issue.

v10.0.0 is giving the same issue. Which version to use ?

@outsideris sorry to bother, but can a new version be published with this fix? Our security tools are complaining...

@sauravlikhar @heidemn-faro the fix is now published in version 10.1.0

is it fixed??? 10.2.0 is still giving this error

I too still see this error in 10.2.0


Remove MLJ from testing by adding local Standardizer

Replaces #22
This PR:

extends the compatibility of MLJModelInterface to include latest version 0.4
replaces use of MLJ in testing with MLJBase wherever possible
replaces use of Standardizer (and the now redundant UnivariateStandardizer) from MLJModels with a local version defined in test/_standardizer.jl This eliminates some circular dependency issues - including PartialLeastSquaures in the model registry, which currently lives in the same place as MLJModels, which contains Standardizer

@filipebraida @lalvim

Sorry for the delay to answer you (classes started last week).
I didn't understand about Standardizer. Wouldn't it be better to remove it from the package and let the user define the pipeline?

The point is that you use Standardizer, defined in MLJModels, for testing, which means it must be test dependency of
PartialLeastSquaresRegressor.jl. (Currently you have MLJ, which is one-higher up the food chain). The problem is that the model registry currently lives in MLJModels. So I have a circular dependency issue: want to update PLSR but this requires MLJModels, but I can't update MLJModels without updating the registry, which requires PLSR to be updated.
There may be other solutions, but from our end this is the easiest. I simply copied code for the Standardizer model you need for testing into your repo so you can use it independent of MLJModels (and MLJ). Your dependency for testing is then just MLJBase.
Is this clear?

@filipebraida Just a note that users of the latest MLJ 0.16.0 are now unable to use your models. The compatibility needs to be extended, eg by pulling this PR.
Note, to be clear, all this PR does is extend compatibility and add code to the testing suite to make current tests independent of MLJModels, MLJ.

@ablaom I asked to @lalvim to revise the code. As he implemented it, I think he better take a better look.

@ablaom nice work.
I didn't really understand the point of the cause of circular dependency, but I believe it. I checked your codes and it looks ok. I did the merge. One question that remains is regarding the use outside the tests. Couldn't you use the mlj standardizer more?

@lalvim @filipebraida Thanks for being accommodating.

One question that remains is regarding the use outside the tests. Couldn't you use the mlj standardizer more?

Outside of testing of this package, you can use Standardizer all you want.


tls/store/basic: introduce CertList and CertSet

Summary by CodeRabbit

New Features

Introduced CertList and CertSet types for improved management of TLS certificates.
Added a new package basic for a programmable TLS store.
Implemented a generic function join for converting two-dimensional slices to one-dimensional slices.

Bug Fixes

Enhanced error handling for nil values in certificate management methods.

superseeded by https://github.com/darvaza-proxy/x/pull/135


[BUG] kubectl drain node gets stuck forever - Cannot evict pod as it would violate the pod's disruption budget.

Just can not drain a node.  This happens almost at least half of the times I need to drain a node.
Cannot evict pod as it would violate the pod's disruption budget.
To Reproduce
Simple 4 node cluster, tried to drain one of the nodes.
I could see in the interface that all volumes had been detached and reattached and the pods started running in other nodes, but the node never finishes draining.
longhorn-system   pod/share-manager-pvc-64f91ac7-abcf-4ffa-8925-89de19818d3b            1/1     Running             0               16h     <IP_ADDRESS>     node2     <none>           <none>
longhorn-system   pod/share-manager-pvc-8325be46-d63e-4fc8-9fef-fa4f089d8490            1/1     Running             0               16h     <IP_ADDRESS>     node1     <none>           <none>
longhorn-system   pod/share-manager-pvc-93649f22-80e0-499d-bfeb-9aeb10c5ad55            1/1     Running             0               16h     <IP_ADDRESS>     node3     <none>           <none>
wp                pod/wp-mariadb-0                                                      1/1     Running             0               10m     <IP_ADDRESS>     node3     <none>           <none>
wp                pod/wp-wordpress-cfcc7fd6f-nh8fl                                      1/1     Running             0               10m     <IP_ADDRESS>     node2     <none>           <none>
wp                pod/wp-wordpress-cfcc7fd6f-nws8m                                      1/1     Running             3 (9m53s ago)   16h     <IP_ADDRESS>     node1     <none>           <none>
wp2               pod/wp-mariadb-0                                                      1/1     Running             0               16h     <IP_ADDRESS>     node3     <none>           <none>
wp2               pod/wp-wordpress-cfcc7fd6f-bdvzd                                      1/1     Running             1 (16h ago)     16h     <IP_ADDRESS>     node1     <none>           <none>
wp2               pod/wp-wordpress-cfcc7fd6f-sv8fw                                      1/1     Running             0               10m     <IP_ADDRESS>     node2     <none>           <none>
wp3               pod/wp-mariadb-0                                                      1/1     Running             0               10m     <IP_ADDRESS>     node3     <none>           <none>
wp3               pod/wp-wordpress-cfcc7fd6f-qw27r                                      1/1     Running             0               10m     <IP_ADDRESS>     node2     <none>           <none>
wp3               pod/wp-wordpress-cfcc7fd6f-wppst                                      1/1     Running             3 (9m51s ago)   16h     <IP_ADDRESS>     node1     <none>           <none>
wp          persistentvolumeclaim/data-wp-mariadb-0   Bound    pvc-efa3b148-a765-430f-a94e-a5df20757c0b   5Gi        RWO            longhorn       16h   Filesystem
wp          persistentvolumeclaim/wp-wordpress        Bound    pvc-93649f22-80e0-499d-bfeb-9aeb10c5ad55   2Gi        RWX            longhorn       16h   Filesystem
wp2         persistentvolumeclaim/data-wp-mariadb-0   Bound    pvc-d11ab7d8-6a5c-48b1-9260-4bb5b0043953   5Gi        RWO            longhorn       16h   Filesystem
wp2         persistentvolumeclaim/wp-wordpress        Bound    pvc-64f91ac7-abcf-4ffa-8925-89de19818d3b   2Gi        RWX            longhorn       16h   Filesystem
wp3         persistentvolumeclaim/data-wp-mariadb-0   Bound    pvc-51f9a96d-410f-49cd-be2d-d25ee33eac27   5Gi        RWO            longhorn       16h   Filesystem
wp3         persistentvolumeclaim/wp-wordpress        Bound    pvc-8325be46-d63e-4fc8-9fef-fa4f089d8490   2Gi        RWX            longhorn       16h   Filesystem

I used this command to drain:
kubectl drain --force --ignore-daemonsets --delete-emptydir-data --grace-period=10 node4

Expected behavior
After all pods have been removed, the controller should remove the PDB that blocks draining of the manager allowing the drain to finish.
Support bundle for troubleshooting

https://file.io/gfrW38dcRhJv
Environment

Longhorn version: 1.5.1
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): kubespray
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: Onprem vanilla kubernetes installed by kubespray

Number of management node in the cluster: 3
Number of worker node in the cluster: 4

Additional context

Thanks for the report
I can reproduce the issue in v1.5.1
The running replicas on the node should be stopped and shown as Failed. But nothing happened to my replicas.
@PhanLe1010 could you help to verify it? Thanks

Thanks for the report I can reproduce the issue in v1.5.1 The running replicas on the node should be stopped and shown as Failed. But nothing happened to my replicas.
@PhanLe1010 @roger-ryao could you help to verify it? Thanks

Hi @ChanYiLin & @PhanLe1010
I attempted to reproduce the issue on my cluster, but I wasn't able to replicate it. I also tested the scenario described in https://github.com/longhorn/longhorn-tests/blob/05b21ac771aba74f3f0b2e68e0640678f5bcbc13/docs/content/manual/pre-release/upgrade/test-node-drain-policy.md under case 1.2.1 where there are multiple healthy replicas, and I didn't encounter the reported error. I plan to retest it again tomorrow.

Sorry for the misleading, last time I just mounted the volume to the host directly so I couldn't drain the node before because the volume could not be detached from the host automatically.
By mounting the volume to the pod, I can successfully drain the node because the pod will be evicted and rescheduled and the volume will be reattached to another node where pod recreated. Longhorn can then delete the pdb for the instance-manager to unblock the drain process.

I can see there is a engine pvc-93649f22-80e0-499d-bfeb-9aeb10c5ad55-e-ce86048d still running on node4, normally engine will only run on the same node where volume mounted.
But in your support bundle the engine ran on two instance-managers at the same time
  spec:
    image: longhornio/longhorn-instance-manager:v1.5.1
    nodeID: node4
    type: aio
  status:
    currentState: running
    instanceEngines:
      pvc-93649f22-80e0-499d-bfeb-9aeb10c5ad55-e-ce86048d:
        spec:
          backendStoreDriver: v1
          name: pvc-93649f22-80e0-499d-bfeb-9aeb10c5ad55-e-ce86048d
        status:
          state: running
          type: engine

  spec:
    image: longhornio/longhorn-instance-manager:v1.5.1
    nodeID: node3
    type: aio
  status:
    currentState: running
    instanceEngines:
      pvc-93649f22-80e0-499d-bfeb-9aeb10c5ad55-e-ce86048d:
        spec:
          backendStoreDriver: v1
          name: pvc-93649f22-80e0-499d-bfeb-9aeb10c5ad55-e-ce86048d
        status:
          state: running
          type: engine

I can see there is a engine pvc-93649f22-80e0-499d-bfeb-9aeb10c5ad55-e-ce86048d still running on node4, normally engine will only run on the same node where volume mounted.
But in your support bundle the engine ran on two instance-managers at the same time
  spec:
    image: longhornio/longhorn-instance-manager:v1.5.1
    nodeID: node4
    type: aio
  status:
    currentState: running
    instanceEngines:
      pvc-93649f22-80e0-499d-bfeb-9aeb10c5ad55-e-ce86048d:
        spec:
          backendStoreDriver: v1
          name: pvc-93649f22-80e0-499d-bfeb-9aeb10c5ad55-e-ce86048d
        status:
          state: running
          type: engine

  spec:
    image: longhornio/longhorn-instance-manager:v1.5.1
    nodeID: node3
    type: aio
  status:
    currentState: running
    instanceEngines:
      pvc-93649f22-80e0-499d-bfeb-9aeb10c5ad55-e-ce86048d:
        spec:
          backendStoreDriver: v1
          name: pvc-93649f22-80e0-499d-bfeb-9aeb10c5ad55-e-ce86048d
        status:
          state: running
          type: engine

And what could have caused that?

I can't find the root cause from the log
But base on your current situation, you can

uncorden node4
delete instance-manager pod on the node4 (instance-manager-a88277b22f49670de0dada3c3706a2d1)
wait until instance-manager pod is recreated, and check the instance-manager to see if there are still engine running in it.

kubectl get lhim/instance-manager-a88277b22f49670de0dada3c3706a2d1 -n longhorn-system -oyaml

if there is no engine running on it, you can try to drain the node again.

I am having pretty much the same problem. Just sent you a support bundle from my setup - maybe that has some useful information.

I keep having the same problem. The workaround of killing the node engine works, but it would be nice to have that fixed.

One thing I've noticed: I have volumes showing as healthy (not Detached) even though I shutdown the pods using them today. And at least in one case, it's been the engines for those volumes that were kept running.

I briefly checked @docbobo's support bundle. His cluster has a similar symptom to @jsalatiel's. There are two engines with the following behavior. Each:

Is only represented by one Engine CR.
Appears as running in two different InstanceManager CRs.

(fd2f99b620d3-e and 2a600e0d3b7a-e are good search strings to find them if you are looking through the bundle or have access to the cluster).

It seems pretty clear how an engine in the above scenario would prevent draining:
We check if we can delete the PodDisruptionBudget for the InstanceManager here:
https://github.com/longhorn/longhorn-manager/blob/8ce69c8f280a5a2715c528034e0274391ad761c0/controller/instance_manager_controller.go#L575-L582
Early on in that check, we try to determine whether all volumes are detached:
https://github.com/longhorn/longhorn-manager/blob/8ce69c8f280a5a2715c528034e0274391ad761c0/controller/instance_manager_controller.go#L697-L706
We do this by verifying that all instances are removed from the InstanceManager:
https://github.com/longhorn/longhorn-manager/blob/8ce69c8f280a5a2715c528034e0274391ad761c0/controller/instance_manager_controller.go#L826-L830
If there are any instanceManager.status.instanceEngines, we return false all the way up the chain:
https://github.com/longhorn/longhorn-manager/blob/8ce69c8f280a5a2715c528034e0274391ad761c0/controller/instance_manager_controller.go#L842-L846
The logic is sound, assuming there is not a "rogue" instance running within the InstanceManager. Unfortunately, we have two environments in which there is one.

To anyone experiencing the kubectl drain issue this ticket was opened with, the following command is helpful in determining if you also have an extra engine process. In my test cluster, it shows I only have on engine running with name pvc-d1d108a1-2cb9-42ca-b1e1-5eb8b3d49cbd-e-f8bb0399, but all of the unique engine names any instance manager knows about with the number that are running.
-> kubectl get -n longhorn-system -o yaml lhim | grep 'name:.*-e-' | sort | uniq -c
      1           name: pvc-d1d108a1-2cb9-42ca-b1e1-5eb8b3d49cbd-e-f8bb0399

Right now, the output shows 1 for every single volume. However, the list also contains volumes that definitely do not have a pod attached.
I did a small experiment today and believe that if there would be an actual pod, the eviction of that pod would trigger the correct behavior. Just a guess though.

Can you either send the names of those volumes to us via e-mail or post them here? There are some things I'd like to check, but I want to make sure I'm looking at the right volumes.

Right now, the output shows 1 for every single volume. However, the list also contains volumes that definitely do not have a pod attached.

Interesting, this bears further investigation.
I did manage to reproduce the inability to drain a node AFTER it is running a duplicate engine in its instance manager.

Install Longhorn v1.5.1.
Deploy a pod backed by a Longhorn volume (I actually created the volume through the UI and then deployed the workload later, but it should be the same).
Check instance manager logs for the engine process creation command/args.

-> kl logs --tail=-1 -l longhorn.io/component=instance-manager
[longhorn-instance-manager] time="2023-09-07T16:28:46Z" level=info msg="Creating instance" backendStoreDriver=v1 name=test-e-126ceb25 type=engine
[longhorn-instance-manager] time="2023-09-07T16:28:46Z" level=info msg="Creating process" args="[controller test --frontend tgt-blockdev --size<PHONE_NUMBER> --current-size 0 --engine-replica-timeout 8 --file-sync-http-client-timeout 30 --replica tcp://<IP_ADDRESS>:10000 --replica tcp://<IP_ADDRESS>:10000 --replica tcp://<IP_ADDRESS>:10000]" binary=/engine-binaries/longhornio-longhorn-engine-v1.5.1/longhorn name=test-e-126ceb25 portArgs="[--listen,<IP_ADDRESS>:]" portCount=1
[longhorn-instance-manager] time="2023-09-07T16:28:46Z" level=info msg="Process Manager: prepare to create process test-e-126ceb25"
[longhorn-instance-manager] time="2023-09-07T16:28:46Z" level=debug msg="Process Manager: validate process path: /engine-binaries/longhornio-longhorn-engine-v1.5.1/longhorn dir: /engine-binaries/ image: longhornio-longhorn-engine-v1.5.1 binary: longhorn"
[longhorn-instance-manager] time="2023-09-07T16:28:46Z" level=info msg="Process Manager: created process test-e-126ceb25"

Exec into a different instance manager and use the longhorn-instance-manager CLI to create a duplicate process. (This is certainly not how the duplicate processes are appearing, but its an easy recreate.)

instance-manager-0331339a5c09fb77fce790a98880c871:/ # longhorn-instance-manager process create --binary /host/var/lib/longhorn/engine-binaries/longhornio-longhorn-engine-v1.5.1/longhorn --name test-e-126ceb25 --port-args "--listen,<IP_ADDRESS>:" --port-count 1 controller test --frontend tgt-blockdev --size<PHONE_NUMBER> --current-size 0 --engine-replica-timeout 8 --file-sync-http-client-timeout 30

instance-manager-0331339a5c09fb77fce790a98880c871:/ # longhorn-instance-manager process ls
INFO[0000] Falling back to non tls client                error="failed to load tls key pair from file: open /tls-files/tls.crt: no such file or directory"
{
        "test-e-126ceb25": {
                "spec": {
                        "name": "test-e-126ceb25",
                        "binary": "/host/var/lib/longhorn/engine-binaries/longhornio-longhorn-engine-v1.5.1/longhorn",
                        "args": [
                                "controller",
                                "test",
                                "--frontend",
                                "tgt-blockdev",
                                "--size",
                                "5368709120",
                                "--current-size",
                                "0",
                                "--engine-replica-timeout",
                                "8",
                                "--file-sync-http-client-timeout",
                                "30",
                                "--listen",
                                "<IP_ADDRESS>:10010"
                        ],
                        "port_count": 1,
                        "port_args": [
                                "--listen,<IP_ADDRESS>:"
                        ]
                },
                "status": {
                        "state": "running",
                        "port_start": 10010,
                        "port_end": 10010
                }
        },
        ...
}

Confirm that there are now two instance managers running the same(ish) engine process. I didn't start the duplicate engine with access to the replicas, as I believe that would have failed.

-> kubectl get -n longhorn-system -o yaml lhim | grep 'name:.*-e-' | sort | uniq -c
      2           name: test-e-126ceb25

Try to kubectl drain the node with the "extra" engine process. This fails forever. Since there is a running engine process, the PDB can't be removed, but the engine object is tracking the original engine process, so longhorn-manager doesn't know to delete the "extra".
Try instead to kubectl drain the node with the original engine process. This works as expected.

Can you either send the names of those volumes to us via e-mail or post them here? There are some things I'd like to check, but I want to make sure I'm looking at the right volumes.

That would be

pvc-2ff575f6-9ec9-48a9-9464-2ae546894060
pvc-1efc9b3b-7621-47b1-a6e3-f8d99b5307f2

Okay, I thought about this a little bit further. At least in my case, there seem to be some pending backup operations (see https://github.com/longhorn/longhorn/discussions/6281#discussioncomment-6434352). However, there aren't.
So maybe the assumption about the absence if rogue instances isn't that wrong. Shall I file another ticket for the backups issue?

I just now had a similar situation. kured was draining a node for a reboot. the pods were drained but one strictly-local volume stayed attached, even though the pod (cnpg) was stopped.
the moment I detached it via the UI (without force) the instance manager stopped and the node was able to finishing draining.

Thanks @schmidp. Do you have a support bundle? For this issue, it is best to capture one while the drain is failing, as after the problem is resolved, we will not see the state of the attachmentTickets when detach was failing.
Note that if you have attached a volume via the UI, kubectl will not be able to drain it. Volumes attached via the UI must be detached via the UI.

Thanks @schmidp. Do you have a support bundle? For this issue, it is best to capture one while the drain is failing, as after the problem is resolved, we will not see the state of the attachmentTickets when detach was failing.
Note that if you have attached a volume via the UI, kubectl will not be able to drain it. Volumes attached via the UI must be detached via the UI.

On volumes attached via the UI, once detached via the UI, will it be auto reattached or will become a UI managed only volume forever? That does not look like a nice behavior. If i try to drain a node, i would expect it to be drained despite if it some volume was or not attached via the UI.

Thanks @schmidp. Do you have a support bundle? For this issue, it is best to capture one while the drain is failing, as after the problem is resolved, we will not see the state of the attachmentTickets when detach was failing.
Note that if you have attached a volume via the UI, kubectl will not be able to drain it. Volumes attached via the UI must be detached via the UI.

I have a support bundle now, would it be possible to send it via email? I feel a bit uneasy to share it here.

cc @c3y1huang

@schmidp you can send it over to<EMAIL_ADDRESS>

Looking at the support bundle, I see two cordoned nodes.
One of the nodes (...mea) has a couple of running engines, but they appear to be attached only by the CSI. It looks like they are just waiting for their corresponding workloads to be scaled down before they detach. For now, I am assuming this is not a concern.
The other node (...tvn) has a single running engine, pvc-1a5253c5-f4e5-4729-b6fb-405bb33cee6c-e-57e230d7. According to this volume's volumeattachment.longhorn.io, it has been attached via the UI.
spec:
  attachmentTickets:
    longhorn-ui:
      generation: 0
      id: longhorn-ui
      nodeID: ...tvn
      parameters:
        disableFrontend: "false"
        lastAttachedBy: "null"
      type: longhorn-api
  volume: pvc-1a5253c5-f4e5-4729-b6fb-405bb33cee6c

Assuming it was intentionally attached via UI, this is working as designed (though maybe not as expected). The fix is to detach it via the UI. @PhanLe1010, do you know if this is a behavioral change from v1.4.x (before we used attachment tickets)?

If not, please feel free to open an enhancement request for this @schmidp. I'm not sure if anyone is relying on the current behavior or not, so we may need to introduce a setting (e.g. DetachManuallyAttachedVolumesDuringDrain or some better name). If we go this route, please provide as much justification as you can to help us prioritize (e.g. why are volumes manually attached in this environment?).
If so, we probably need to treat this like a bug and figure out a mechanism for correcting it. In that case, we probably don't need the setting, as we are just reverting an undocumented behavioral change.

@ejweber thank you for looking into this. sadly the pvc is now gone from our deployment, but what I can say for sure: there was no reason for attaching this manually except, that a few months ago we had a OOM situation where I afterwards tried to manually fix some pod issues by manually de- and attaching volumes.
I will wait for @PhanLe1010 reply and in case its intended behaviour request a setting as I believe its very easy to fall into this pit.

Assuming it was intentionally attached via UI, this is working as designed (though maybe not as expected). The fix is to detach it via the UI. @PhanLe1010, do you know if this is a behavioral change from v1.4.x (before we used attachment tickets)?

Agree with @ejweber that the action to detach it via the UI. This behavior has been the same in older Longhorn versions: if user manually attach the volume using UI, the volume need to be detach from UI first before the workload on another node can attach the volume.
If user has never been using UI/Longhorn API to attach the volume, this is unexpected

Assuming many of the mentioned problems are UI attached volumes, I wonder if it should be more discoverable if a volume has been attached via the UI.
This could be solved by an icon or column in the UI, representing how it was attached.

I like the icon idea, but i still think that drain should always have higher priority and detach even volumes attached by the UI.

Personally, a setting (to not change existing behaviour) plus some kind of visualisation would also be my preference.

I have opened https://github.com/longhorn/longhorn/issues/6978 to track the feature request for automatically detaching manually attached volumes during drain.
Let's refocus this one on the original issue. Both @jsalatiel and @docbobo have clusters with multiple engine processes for a volume running on different nodes, and @docbobo has seen engine processes running for detached volumes. Another user has provided a support bundle with similar symptoms offline. We need to discover how Longhorn is "forgetting" to clean up old engine processes, as these processes prevent drains.

Haven't used attaching volumes via UI at all, but faced similar problems anyway. Most of the time, Longhorn doesn't evict instance-manager pods and thus blocking node draining. Maybe I should set bigger timeout (30m now) for draining nodes, but this is getting too time-consuming when maintaining bigger clusters. Only manually deleting such pods helps.

I discovered a pretty straightforward reproduce of this behavior today related to this code which still exists in master. Basically, if an instance-manager is in any state other than running (including unknown), longhorn-manager will not attempt to actually reach out to the instance-manager and stop an engine process before recording that it is stopped in its CR. But unknown is a state that instance-managers can come back from (e.g. if a kubelet is temporarily down, but then returns without the instance-manager pod actually stopping). When an instance-manager does, all of its processes remain running (and its CR remembers the ones that were never deleted).
Reproduce:

Deploy Longhorn master-head.
Create a volume (e.g. with the UI).
SSH to the node the volume is attached to.
Stop the kubelet.
Wait ~30s for Kubernetes to notice and for the instance-manager state to transition to unknown.
Detach the volume.
Start the kubelet.
Attach the volume to a different node.

Now the volume is in the state seen in the bundles of @docbobo and @jsalatiel. There is one engine CR tracking one engine process running on the NEW node, but the instance-manager CR on the OLD node also shows that same engine process running.
My personal preference is to never allow skipping the deletion of the engine process in an unknown state. Taking this approach would:

Prevent us from accidentally orphaning processes in this case and ensure engine processes are definitely stopped when we think they are, but
Cause the user to wait > 6min for Kubernetes to evict an instance-manager pod on an unrecoverable node for Kubernetes to evict the instance-manager pod and for its CR to transition to error. This is a state it cannot recover from without restarting, so we cannot have an orphan.

However, in a discussion with the North America team (@shuo-wu, @PhanLe1010, and @james-munson), the general direction we have decided to move in is to:
Create a PR

[ ] Create a PR to make a best-effort attempt to stop the engine process in this case to close out this issue. In the reproduce, there is actually no reason the longhorn-manager couldn't reach the instance-manager and make it happen.
[ ] Follow up with the automated cleanup in this and other cases in https://github.com/longhorn/longhorn/issues/6764.


Fix #134 #135 #136

This PR contains a:

[x] bugfix
[ ] new feature
[ ] code refactor
[ ] test update
[ ] typo fix
[ ] metadata update

Motivation / Use-Case
Fixes NoSleep not working in recent iOS versions with the solution found by @z-x
https://github.com/richtr/NoSleep.js/issues/135
https://github.com/richtr/NoSleep.js/issues/136
Also fixes NoSleep not working on Samsung Browser due to permission denied error
https://github.com/richtr/NoSleep.js/issues/134

Thanks!

I can confirm this fixed NoSleep.js on iOS 15.1 in my app.

@richtr Any way to merge it?

Hey guys, it will be perfect if it will be merged 🙌

@zamarawka it looks like @richtr has made zero contributions this year.. I wonder if this is a dead repo :(

Since the owner seems dead, I republished it as another package under @uriopass/nosleep.js with version 0.12.1

@Uriopass @alebianco-doxee @z-x @Moongazer @huppfi @CodeCommander @zamarawka @Romander @dcbarans - please, please, please will one of you kind people consider taking this on and creating an "official" fork which we can all come together around?  The functionality of nosleep is simply too important not to have a maintained solution (and @richtr definitely seems to have disappeared :( ) - otherwise we are going to end up with a 1000 forks!
If it helps, I am sure some sponsor/patreon/etc. income could be generated for an active repo.

The fix from #135 doesn't work in Firefox if the script is loaded before the body tag. Appending to body needs to be delayed with something like:
document.addEventListener("DOMContentLoaded", function() {
  document.querySelector("body").append(this.noSleepVideo);
});

Since the owner seems dead, I republished it as another package under @uriopass/nosleep.js with version 0.12.1

Awesome, thank you!
Could you please change the installation instructions in the readme to include the updated package name?

Since the owner seems dead, I republished it as another package under @uriopass/nosleep.js with version 0.12.1

Awesome, thank you! Could you please change the installation instructions in the readme to include the updated package name?

Done :)

I've checked and the Readme file still contains:
This package is published to npm as nosleep.js and can be installed with:
npm install nosleep.js

Ah sorry you're talking about the npm page! I'll fix this

@Uriopass will you update your version?

I don't see what's there to update


inkscape gone - back to 0.91

I recently installed inkscape 0.92 from this tap. Worked fine.
Did a 'brew update' just some minutes ago, this did 'brew uninstall --force inkscape' without asking and installed (from cask) inkscape 0.91. I can see some points in going to cask - but deleting files from my computer without even prompting is not ok at all !
Seriously, I had a working Inkscape 0.92 (thanks to your work and providing an brew) - and now im am left without, and (for the time being) without a way to get it.
=====
$ brew update
Updated Homebrew from c9d7bab6ca to 6f305ad3dc.
Updated 7 taps (caskroom/cask, dholm/sdr, homebrew/core, homebrew/gui, homebrew/science, homebrew/x11, pothosware/pothos).
==> New Formulae
dholm/sdr/rtl433                         todoman
homebrew/science/dl_poly_classic
==> Updated Formulae
crystal-lang                             opus
dar                                      parallel ✔
docker                                   pothosware/pothos/limesuite
docker-swarm                             qemu ✔
extract_url                              svtplay-dl
gdb                                      swift
git-tracker                              swiftformat
gitlab-ci-multi-runner                   swiftlint
homebrew/science/cantera                 unrar ✔
homebrew/science/dealii                  vim
homebrew/science/oce                     yle-dl
lean-cli                                 youtube-dl ✔
libvirt                                  zimg
==> Deleted Formulae
homebrew/gui/gtkwave                     homebrew/gui/meld ✔
homebrew/gui/hexchat                     homebrew/gui/transmission-remote-gtk
homebrew/gui/inkscape ✔
==> inkscape has been moved to Homebrew-Cask.
==> brew uninstall --force inkscape
Uninstalling inkscape... (1,015 files, 124.0M)
==> brew prune
Pruned 5 symbolic links and 28 directories from /usr/local
Unlinked 5 apps from /Users/marcel/Applications
==> brew cask install inkscape
==> Satisfying dependencies
complete
==> Downloading https://inkscape.global.ssl.fastly.net/media/resources/file/Inks
######################################################################## 100,0%
==> Verifying checksum for Cask inkscape
==> Moving App 'Inkscape.app' to '/Applications/Inkscape.app'
==> Symlinking Binary 'inkscape' to '/usr/local/bin/inkscape'
🍺  inkscape was successfully installed!

Sorry for the downgrade. I suggest opening a pull request to https://github.com/caskroom/homebrew-cask/blob/master/Casks/inkscape.rb with the newer version if you'd like to help remedy the situation.

Sorry about the double-post.
There is no point in opening a pull request to Casks/inkscape.rb, as the Inkscape project does not (not yet?) provide binaries for 0.92/osx - maybe because of library dependencies, don't know. Which forces one to MacPorts, although I do prefer Homebrew. Yes, I know I can grab the Formula from two days ago and just shove it somewhere or make a new Tap from it or plain simply recover the Cellar section from my backup.
Anyway, my main concern (not specifically about inkscape) is about 'brew update'. Doing anything on installed packages (like removing, no questions asked) does not seem to be right at all - according to the documentation it is supposed to update the "metadata" of package-build-and-dependency-information. And then 'upgrade', 'install', 'uninstall' and the like would do things on the Cellar. And that is why I asked the other question, if really 'brew update' is supposed to remove things according to tap-migrations.json ?

And that is why I asked the other question, if really 'brew update' is supposed to remove things according to tap-migrations.json ?

Yes, it is.

Given the current situation, I propose resurrecting the Inkscape formula from here in homebrew-core: https://github.com/Homebrew/homebrew-core/pull/9355

It's not going to go into homebrew-core, so I've set up a tap for providing formulae for software packaged as casks. To install Inkscape:
brew install caskformula/caskformula/inkscape


Sync: Bookmark timestamps

Task/Issue URL:
Description
Steps to test this PR
Feature 1

[ ]
[ ]

UI changes

Before
After

!(Upload before screenshot)
(Upload after screenshot)

Current dependencies on/for this PR:

develop

PR #3039   👈

This comment was auto-generated by Graphite.


where's the actual migration explanation?

The main docs say "Read the Migrations section for more information and a full list of configuration options", followed by an example file. The migrations section then doesn't even explain all the things listed in the example.
What does the tablename do? How do I load migrations from file, in sequence? There's almost no information in the migration section.

Related to #563.
A PR resolving this issue would be appreciated.

Tried to improve this a while back, in #956

super nice! If there was also an example migration and seeding, that PR would pretty much be perfect.

@harriha I had not seen this. Will review soon.

@Pomax Thanks - what comes to examples in general, it's often useful to take a look at tests of a project. For example, migration tests can be found from https://github.com/tgriesser/knex/tree/master/test/integration/migrate, might help at least a bit. But true, I guess the docs themselves could always be better.
@rhys-vdw Thanks, please don't hesitate to throw the PR back to me if there's issues with it.

@harriha, yeah having documentation in addition to the code (the test/integration code has no comments, for instance) is super useful.


Expose eth_coinbase and eth_accounts via sendSync

Context / issue
Gitcoin requires that eth_coinbase and eth_accounts can be queried synchronously. Currently we only allow this asynchronously.
Proposed solution
Add handling for these methods to the SafeProvider::sendSync method
Additional context
To test if this is working open https://gitcoin.co/funding/new and try to trigger a transaction.

Implemented here: https://github.com/gnosis/safe-browser-extension/pull/93


Update packages

Old Sinon packages had a downstream dependency on an old version of path-to-regexp, which is vulnerable: https://github.com/advisories/GHSA-9wv6-86v2-598j
Updating packages required adjustments to tsconfig and package config to be able to build and test again.

Actually, don't merge this yet, have to pull out the npm publishing stuff I added so that I could use the fixes immediately.


Environment Internal Metadata API and CLI

What is it?
This is about making a REST API that is only accessible from within an environment to get environment metadata and to have the environment push events up the stack to its peers and the Bazaar. It will have two parts:

A REST API of various endpoints hosted at the gateway (or some fixed preset IP) in each environment segment
A CLI program or script which mirror the REST API for convenience while scripting, and should be available in the base templates

No authentication is needed since the containers making the REST calls are within the
Why?
The facility is a general one. It can be used for any function. Some ideas of what we would like to use it for include:

service discovery
environment awareness
container syslog service
application alerts
enabling scripts, playbooks, and blueprints to make decisions about how to configure themselves

This was asked for before several times but it never happened.
Precedents
This is not a unique idea. AWS uses this with it's Metadata API. It even has a REST API and a CLI component just as was stated here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
Also note that this API uses a non-routable special address to expose the rest API: http://<IP_ADDRESS>/latest/meta-data/

We have an experimental endpoint that provides information about the environment.
From within a container it is possible to request the information to be put inside the containers filesystem ( it gets dumped to /root/env file).
The endpoint is GET https://<IP_ADDRESS>:8443/rest/v1/environments/{CONTAINER-IP}/info, where CONTAINER_IP is container's eth0 interface ip.

This is a good start. We just also need to support endpoints to send stuff from the container. IP can be used to key off of like this in the rest URI path. The dumping to the file system is a bad code smell but I guess we can use this info in any way. But I guess this just dumps a huge file with all env info instead of a granualar api ... not a problem for now.
We just need to be able to use this interface for applications to send events especially when building long running environment blueprint apps. Can you talk to @absidish and @tjamakeev about this to share your ideas. Thanks.

I like the idea of depositing the token, with TTL and only using the depositing to an address thing once to make sure it is secure. Can we revisit this stuff when you are around? I want to make sure we can enhance this feature to be robust and support all the things we want to do with it.

It will be nice also to document exactly how this works now and how it will work later in the future.

The idea with token based access is this (it is just design but can be implemented based on this):

Client can reside inside ANY container
Client needs to know container IP from eth0 interface
Client requests token from Console by the REST endpoint: GET https://<IP_ADDRESS>:8443/rest/v1/environments/{CONTAINER-IP}/token
Token gets deposited  into the agreed location on the container's filesystem
Token has TTL and is bound to the container's environment. Console allows to read information of and optionally perform actions only within the context of the container's parent environment


Physical Limits

Define the Physical Limits of the Battle Ground so the characters are never out of bonds.

Resolved on the following commit: https://github.com/BraisGlezArias/TheHeroNeverDies/commit/758033226d8bf72d85539230d777f6e2981d52d6


Migrate to actix-web 4

This migrates polaris to the recently released actix-web 4 and also upgrades tokio to 1.0.

Codecov Report

Merging #171 (794919b) into master (90fd6bb) will decrease coverage by 0.06%.
The diff coverage is 62.96%.

@@            Coverage Diff             @@
##           master     #171      +/-   ##
==========================================
- Coverage   72.26%   72.20%   -0.07%
==========================================
  Files          40       40
  Lines        1803     1799       -4
==========================================
- Hits         1303     1299       -4
  Misses        500      500

Impacted Files
Coverage Δ

src/app/index/mod.rs
60.00% <ø> (ø)

src/service/dto.rs
87.80% <ø> (ø)

src/service/actix/mod.rs
59.37% <14.28%> (ø)

src/service/actix/api.rs
78.40% <73.33%> (-0.17%)
:arrow_down:

src/app/config/manager.rs
70.96% <100.00%> (-0.91%)
:arrow_down:

src/app/thumbnail/manager.rs
92.59% <100.00%> (ø)

src/app/thumbnail/read.rs
84.09% <100.00%> (ø)

Continue to review full report at Codecov.

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

Nice work! (and thanks @lnicola for the extra pair of eyes)


Elapsed / Remaining Time Next to Progress Bar, closes #587

Hello!
This the pull request to go with recently raised https://github.com/chriskiehl/Gooey/issues/587.
Changes are as follows:

New pub/sub event created for application in events.py for TIME_REMAINING_UPDATE.
StaticText label added in Footer adjacent to progress bar for displaying elapsed & remaining time.
Functions added to processor.py:

_get_current_time() either use time.perf_counter() in Python 3.3+ or timeit.default_timer() for Python 2.7 compatibility to get a current time in seconds as a float
_calculate_time_remaining(progress,start_time) estimate the time remaining by calculating the current rate of progress over elapsed time and extrapolate for the remainder of progress.
format_interval() This was taken from the tqdm project https://github.com/tqdm/tqdm/blob/0cd9448b2bc08125e74538a2aea6af42ee1a7b6f/tqdm/std.py#L228 for showing the elapsed & remaining time in [H]:MM:SS format.

_forward_stdout in processor.py has been altered to show time remaining when progress is greater than 0.
Relevant tests for all functions added can be found in test_processor.py.

I absolutely love this package, thank you so much!

This does not include a dependency of tqdm, as the functionality has been 'extracted'.

Furthemore, I've created a working example to add to the examples repository as well! Which I have created a PR over at: https://github.com/chriskiehl/GooeyExamples/pull/31.

Howdy!
Your git history is all kinds of bonkers ^_^ I suspect a rebase may have gone afoul.
Could you cut a clean version from this from mainline and open the pull against the release branch?
This sounds like a neat addition (and doing it without adding a new dependency gives bonus points in my book!), but the diff is so messy I can't actually see what changes you're attempting to add.

Holy dooly, didn't see that coming!
I'll try have another crack, thought I had done it right before.

This has been redone with a pull request on the release branch to make changes more clear. Find it at: https://github.com/chriskiehl/Gooey/pull/589.


Improve descriptions Part 2

[ ] Maps
[ ] Structs
[ ] Pattern Matching
[x] Functions
[x] Enums
[x] Processes
[ ] Tasks

:+1: Nice work


Azure support with faraday

This PR based on https://github.com/alexrudall/ruby-openai/pull/238
Thank you rmachielse
Unfortunately on my environment  had only deployed gpt-3.5-turbo,
I couldn't update other spec files.

@abnokubi, thanks for your work on this - Azure support was released in v4.2!


Strange behavior when auto complete a path

Hi. When I enter a path and stroke 'tab', the path name is auto completed with more characters (including quotes) than what I need. Is this a bug?

Yeah. It's pretty strange that the paths are recognized as a variable.
Couldn't reproduce the issue. If it's possible, please provide a demo project, so i can reproduce and fix the issue.
Greetings


Pipeline: Several bugfixes to support ScholarPhi paper

Several changes were needed to make the ScholarPhi pipeline robust enough to handle the ScholarPhi paper. Namely:

A bug was found in the citation color macros where a coloring macro was calling itself recursively. That has now been fixed (03-load-color-commands.tex)

TeX logs can apparently contain non-utf-8 characters. So the logs needed to be loaded in a way that was tolerant to unexpected non-utf-8 characters (locate_entities.tex)

The bibliography entries for this paper were written idiosyncratically---often there was a newline between the \bibitem macro and the {...} curly braces in which the key for the reference was written. This was confusing our code that parsed out reference keys from the bibliography. This has since been fixed (see extractor.py and test_parse_tex.py).

The following GIF shows citation interactions working for the ScholarPhi paper in a local version of the app:

cc @aschokking

cc @aschokking


Make it possible to disable the minibuffer messages

Hi!
I've just started using history-mode and I like it a lot, thanks!
I find the messages in the minibuffer (that shows you where in the history you are) distracting however.
Would it be possible to add a defcustom to disable that?
Thanks again for a great mode!

This is my current workaround:
(with-eval-after-load 'history
  (let* ((default-bg     (face-attribute 'default :background))
         (default-height (face-attribute 'default :height))
         (faces '(history-current-history
                  history-current-temp-history
                  history-other-history
                  history-prompt
                  history-temp-history)))
    (mapcar (lambda (face)
              (set-face-attribute face
                                  nil
                                  :foreground default-bg
                                  :height default-height
                                  :inherit 'default))
            faces)))

That is: set the foreground and to whatever the default background is and then resetting the height. This makes the messages virtually invisible

Wow, thank you for the feedback. Would you be able to create a PR since I'm not actively maintaining this for years?


Adds ChildAdded

Coverage increased (+0.006%) to 97.756% when pulling 778a9c7074abcee6739a153f6c6eda141ebae552 on Kampfkarren:childadded into 86b33cdfb46fd1e736f8ee1d8861d1b58ffa987f on LPGhatguy:master.

Looks good to me!


LittleFS Display Directory Content

I was looking for a simple arduino/c++ solution to use within the NodeMCU module.
I noticed the solution provided was a little complicated for me and maybe related to modifying the LittleFS library itself (which I'm not sure, I'm just guessing).
So I have come up with a simple function for listing all the files inside a directory (recursively).
I hope it helps future noobies like myself! :D
void listAllFilesInDir(String dir_path)
{
	Dir dir = LittleFS.openDir(dir_path);
	while(dir.next()) {
		if (dir.isFile()) {
			// print file names
			Serial.print("File: ");
			Serial.println(dir_path + dir.fileName());
		}
		if (dir.isDirectory()) {
			// print directory names
			Serial.print("Dir: ");
			Serial.println(dir_path + dir.fileName() + "/");
			// recursive file listing inside new directory
			listAllFilesInDir(dir_path + dir.fileName() + "/");
		}
	}
}

Use like this:
if (LittleFS.begin()) {
	listAllFilesInDir("/");
}

The output should be something like this:
File: /asset-manifest.json
File: /favicon.ico
File: /index.html
File: /manifest.json
File: /robots.txt
Dir: /static/
Dir: /static/css/
File: /static/css/main.1635e87c.chunk.css
Dir: /static/js/
File: /static/js/2.2c405b20.chunk.js
File: /static/js/3.8cb6885c.chunk.js
File: /static/js/main.435818a8.chunk.js
File: /static/js/runtime-main.00e2c71a.js

Originally posted by @jeot in https://github.com/littlefs-project/littlefs/issues/2#issuecomment-881683790
Hello all, im using the LittleFS libary out of the Arduino ESP32 Core 2.0.15 directly. And right now i am struggling to create a Dir Object cause as it says there should be a Directory Object and then LittleFS.openDir but i just cant do that, it says : "Dir was not declared in this scope" and i dont know how to do it
My Module: ESP32 WROOM

@GitonioDev
Hi,
The snippet I originally provided was based on the LittleFS library by Arduino that probably used Littlefs-project (this repo) under the hood (although I'm not sure).
There are lots of examples and use-cases here:
https://github.com/espressif/arduino-esp32/blob/master/libraries/LittleFS/examples/LITTLEFS_test/LITTLEFS_test.ino

Hi, yeah i seen that method several times but its very slow and not good to display a lot of content the openDir variant looks more efficient and this function is more intended for my case

This may be more useful to open as an issue in https://github.com/espressif/arduino-esp32 or related forums.
It does look like the upstream listDir is allocating (three times?) and looking up each path (twice?) during directory traversal, which is a bit wasteful...
But this is the core littlefs repo, we don't really have any control over the framework-specific layers.


Filter out remote entity when generating pb

TL;DR
Skip remote entity when generating protobuf files.
cc @sonjaer
Type

[x] Bug Fix
[ ] Feature
[ ] Plugin

Are all requirements met?

[x] Code completed
[x] Smoke tested
[x] Unit tests added
[ ] Code documentation added
[ ] Any pending items have an associated Issue

Complete description
We should not generate protobuf files for remote entities.


Suppress error messages

Hey. Thanks for your work.
Could I ask for suppress error message or add such option in configuration? Sometimes I save broken code and plugin react on it.

Hey,
Yes I like this idea. Will add a toggle in the settings to supress error messages. On holiday this week so I'll have time to tackle this on the weekend.
Cheers
Mike

Thanks, adding only that I have autosave on so saving code in broken state is unavoidable, hence I have a constant cascade of red stuff on the right side of the screen, considering duct taping something over it :(

Sorry it's taken a lot of time for me to get to this. Please checkout the latest release to see options for controlling error messages.

Don't see any error opts in 0.6.0. Atom reports up-to-date.

Just this second updated it. 0.7.0 should be the version. Maybe it takes a little time for them to push it out everywhere.

Ok thanks
On Sun, Dec 9, 2018, 9:05 AM mikehoyio<EMAIL_ADDRESS>wrote:

Just this second updated it. 0.7.0 should be the version. Maybe it takes a
little time for them to push it out everywhere.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mikehoyio/atom-python-black/issues/8#issuecomment-445554027,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3RW8kkNJFuF1sx7hSBJfNPpNaBEOevks5u3ULHgaJpZM4WpWgZ
.


chore: use os and io instead of deprecated io.ioutil

In go v1.16 the io/ioutil package is deprecated.

Thanks a lot! :)


monitor: 0.12.0 -> 0.13.0

Description of changes
https://github.com/stsdc/monitor/compare/0.12.0...0.13.0
https://github.com/stsdc/monitor/releases/tag/0.13.0
Things done

Built on platform(s)

[x] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 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.

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

1 package built:

monitor


Sync executable with formal spec - DELEG STS

Closes #733

sync DELEG STS (inline predicates + consequents, use Relation class, ...)
use Relation class in AVUP STS (there were still some missed opportunities for Relation operators)

I was about to make a comment about splitting up the case distinction on cert type into actual separate rules, but it seems we are still not sure if we like the "structural" vs "throwable" predicate distinction.


Added dynamic inventory for AWS as contrib

Just thought I'd contribute this in if anyone wants to use it. It's somewhat useful for a kargo-specific inventory script.

Awesome! Thanks for sharing @rsmitty 👍

@bradbeam or @mattymo can one of you guys approve this so I can merge and close? it's just a quick python script added to contrib.


Can't verify Identity of server With Trust all hosts.

I currently have my mailer builder setup to trust all hosts (a temporary work around, or so I thought, to see if mailing was working otherwise). However, even with this setup:
MailerBuilder
            .withSMTPServer("smtp.mailgun.com", 2525, Env.smtpUsername, Env.smtpPassword)
            .withTransportStrategy(TransportStrategy.SMTP_TLS)
            .withSessionTimeout(10 * 1000)
            .withDebugLogging(Env.debug)
            .trustingAllHosts(true)
            .buildMailer()

I'm getting the exception:
Caused by: javax.mail.MessagingException: Could not convert socket to TLS;   nested exception is: 	java.io.IOException: Can't verify identity of server: smtp.mailgun.com 	at com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTransport.java:2140) 	at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:738) 	at javax.mail.Service.connect(Service.java:388) 	at javax.mail.Service.connect(Service.java:246) 	at javax.mail.Service.connect(Service.java:195) 	at org.simplejavamail.mailer.internal.mailsender.MailSender.sendMailClosure(MailSender.java:265)
I'm not entirely sure what's going on here.

Can you verify that your mailer's session has the following property set?
Mailer yourMailer = MailerBuilder
            ...
            .buildMailer()

String sslTrust = yourMailer.getSession().getProperty("mail.smtp.ssl.trust");
System.out.println(sslTrust);

Should be "*".

Have you tried the other ports?

Mailgun supports sending via SMTP. Our servers listen on ports 25, 465 (SSL/TLS), 587 (STARTTLS), and 2525. - (source pdf)

Also, have you tried it with the traditional JavaMail API and a custom session object (so without Simple Java Mail)? I'm wondering if that works (I'm expecting it doesn't if the other ports don't perform better).

May or may not be helpful: I had a somewhat similar error getting the mailer to trust my localhost mailserver with bogus certificate.
.withProperty("mail.smtp.ssl.checkserveridentity", "false") sufficed to fix it.

same issue here, fixed by adding .withProperty("mail.smtp.ssl.checkserveridentity", "false")

same issue here, fixed by adding .withProperty("mail.smtp.ssl.checkserveridentity", "false")

Again, that's not a fix, but an insecure work-around.

Ok, I finally decided to get set up with MailGun myself and test the original case.
I used the following code, like that from the first post:
Mailer mailer = MailerBuilder
	.withSMTPServer("smtp.mailgun.org", 2525, USERNAME, PASSWORD)
	.withTransportStrategy(TransportStrategy.SMTP_TLS)
	.trustingAllHosts(true)
	.buildMailer();

Email email = EmailBuilder.startingBlank()
	.from("email-I-registered-with-MailGun")
	.to("email-I-registered-with-MailGun")
	.withSubject("Mailgun test")
	.withPlainText("Mailgun body test")
	.buildEmail();

mailer.sendMail(email);

This worked fine for me, using Simple Java Mail 5.0.7. Also port 587 worked fine.
So I don't know what is going on with the other reports here. Perhaps you are using a different JavaMail dependency than Simple Java Mail is developed with (should be javax.mail:1.6.0). Otherwise I can only imagine it's a configuration issue with MailGun and how you set up your domains.
Unless there's a compelling argument that Simple Java Mail actually is bugged, I'm closing this issue for now.

Related to https://github.com/bbottema/simple-java-mail/issues/221, which might solve this issue.


Remove transformBody from lambda

@jonathan-codaio @spencer-codaio @coda/packs PTAL
Looks good? As it turns out, I don't think it's a huge deal if we run transformBody more than once (it will just do nothing), but we need to run it at least once. :D

Huge failwhale on the tests... digging in.

oh man, there are tons of test cases to update. :)

Fixed the tests.
@jonathan-codaio @spencer-codaio  - One artifact of this change is that it will/could break tests that assume that transformBody is supposed to be called by the lambda glue. Not sure if we're worried about that or not.

It seems like a good change to make, and it would be nice if we could work this into our existing breaking moment. Given this only affects the CLI we don't need to provide a toggle for it, since CLI users can choose when to upgrade SDK versions.

OK. Updated this to retain the behavior within tests and a flag for disabling it. Added changelog entry.
PTAL @jonathan-codaio @ekoleda-codaio

@jonathan-codaio Tests pass with that commit BTW.


A Typo in "Understanding GitHub Actions" Page

The code uses actions/checkout v3 as opposed to v2

Why:
Closes N/A
Found a typo in the doc

What's being changed:

The code uses actions/checkout v3 but the description is v2

Check off the following:

[x] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[ ] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

@kk-kd Thanks for opening a pull request! We've triaged this issue for technical review by a subject matter expert :eyes:

Power
Vào 21:16, T.2, 11 Th4, 2022 Ramya Parimi @.***> đã
viết:

@kk-kd https://github.com/kk-kd Thanks for opening a pull request!
We've triaged this issue for technical review by a subject matter expert
👀
—
Reply to this email directly, view it on GitHub
https://github.com/github/docs/pull/16954#issuecomment-1095105798, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AXTWXQIHRER7PEV5PRNO3DTVEQX5HANCNFSM5S532XNQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


littlefs case insensitive setting

Greetings,
Is there a way to make the littlefs file system case insensitive?
We are moving from a FATFS (espressif) file system that is prone to corruption issues that littlefs doesn't have but all of our libraries expect the file system to be case insensitive.
Thanks!
Travis

I would just create a wrapper which converted all filenames to lower case, would that help?9 mars 2023 kl. 02:26 skrev TravisRo @.***>:
Greetings,
Is there a way to make the littlefs file system case insensitive?
We are moving from a FATFS (espressif) file system that is prone to corruption issues that littlefs doesn't have but all of our libraries expect the file system to be case insensitive.
Thanks!
Travis
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>


chore: partial revert of 4e82abc

Some issues where rebuilds are stuck are seen since 4e82abc. We should change the way rebuilds communicate with the nexus/children but since we are nearing a release for now let's partially revert it.
Signed-off-by: Tiago Castro<EMAIL_ADDRESS>

What is the nature of stuck rebuilds? i.e. are they stuck with the actual copy not at all started OR stuck midway copying?

What is the nature of stuck rebuilds? i.e. are they stuck with the actual copy not at all started OR stuck midway copying?

Between terminating and completing - B2-604

bors merge


SPDX-tools

Hello,
Could you please how to run this program and also if i run i get error pyspdxtools -i or pyspdxtools -i <input_file> -o <output_file> ( In place of filename we give the filename of ours.)
Even tried with giving the path of the files its still not working
Error is CreationInfo doesnot exists
Could you please explain in details how to run this package

Hi, @virajgaonkar, thanks for your interest in the spdx-tools!
The error you encounter indicates that the parser can't find the CreationInfo in your SPDX file. The CreationInfo is mandatory, so you should check that it is present in your file. If it is, then your file probably does not conform to the syntax described by the specification.
I might be of further help if you could provide me with an example file that is failing for you, or at least which file format you are using.


auth: Support all JWT algorithms

This change adds support to etcd for all of the JWT algorithms included in the underlying JWT library.
Fixes #9696

Codecov Report

Merging #9883 into master will increase coverage by 0.29%.
The diff coverage is 82.78%.

@@            Coverage Diff             @@
##           master    #9883      +/-   ##
==========================================
+ Coverage   68.96%   69.25%   +0.29%
==========================================
  Files         385      386       +1
  Lines       35703    35731      +28
==========================================
+ Hits        24621    24744     +123
+ Misses       9263     9190      -73
+ Partials     1819     1797      -22

Impacted Files
Coverage Δ

auth/store.go
73.53% <ø> (ø)
:arrow_up:

auth/jwt.go
67.7% <64.28%> (-2.57%)
:arrow_down:

auth/options.go
92.5% <92.5%> (ø)

pkg/transport/timeout_conn.go
80% <0%> (-20%)
:arrow_down:

etcdserver/util.go
81.25% <0%> (-13.75%)
:arrow_down:

proxy/grpcproxy/watcher.go
85.71% <0%> (-8.17%)
:arrow_down:

pkg/transport/listener.go
58.67% <0%> (-4.09%)
:arrow_down:

etcdserver/v2_server.go
80.76% <0%> (-3.85%)
:arrow_down:

proxy/httpproxy/director.go
80% <0%> (-2.86%)
:arrow_down:

etcdserver/api/v3election/election.go
66.66% <0%> (-2.78%)
:arrow_down:

... and 23 more

Continue to review full report at Codecov.

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

lgtm, thanks! @joelegasse


Needs an overhaul

The code is getting hard to read.

It got one now it needs some testing but everything does seem correct.


Cannot reach api via http in kubernetes

Hi,
if I want to include the plugin into our environment i could normally reach the api via a kubernetes service hostname with http internally.
It turns out that plain http seems to be not called by your rest client. If I switch to https there is some call in the log.

Solution: I had to set Cache to NO_CACHE. On the first ever request my controller returned 401 which i missed in the logs. Any further request was not performed due to caching.


Displaying LaTex between [math] [/math]

Hello,
My browser does not render LaTex equations between [math] [/math]. Can you please help me with that? I enabled java script on my browser.
Technical details:

MathJax Version: 2.3 (latest commit: f3aaf3a2a3e964df2770dc4aaaa9c87ce5f47e2c)
Client OS: Windows 10
Browser: Chrome 29.0.1547.57

The default delimiters for in-line math are \(...\) and for display math are \[...\] or $$...$$.  You do not give any information about your configuration or the environment in which you are using MathJax, so it is not easy to tell you what you need to do to adjust this.  But the basic configuration information is in the documentation.  The first code block there gives a configuration that adds inline delimiters, so you could use that idea to add [math]...[/math] as delimiters.  That section also tells you how to load MathJax in your page, in case you aren't doing that.  If you are really using version 2.3 (as indicated in your report), then you may want to update to a more current version (at least to the highest v2 version, which is 2.7.9, if you can't move to version 3).
In general, this issue tracker is for reporting bugs in MathJax, not asking questions.  It is better to do that in the MathJax User's Forum where more people will see your question and may respond.


How to get jupyter shell to auto scroll to new output?

Applies To

[ ] Notebooks (.ipynb files)
[X] Interactive Window and/or Cell Scripts (.py files with #%% markers)

What happened?
I am running some code which outputs a lot of stuff, including figures. However, I have to continually scroll to keep up with the output. I saw some previous threads where this was an issue, but I was unable to find a good solution. Can anyone help?
VS Code Version
Version: 1.65.2 (user setup) Commit: c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1 Date: 2022-03-10T14:33:55.248Z Electron: 13.5.2 Chromium: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0.19043
Jupyter Extension Version
v2022.2.1030672458
Jupyter logs
No response
Coding Language and Runtime Version
3.7.7
Language Extension Version (if applicable)
No response
Anaconda Version (if applicable)
conda 4.11.0
Running Jupyter locally or remotely?
Local

@moonj94 quick question here. Do you have the setting Jupyter: Always Scroll On New Cell turned on? That might be what you are looking for here. I wasn't quite sure if you were looking at autoscrolling to new cells, or if you were looking at scrolling within a single cell output.
If you are looking at scrolling just in single cell output that's an issue that we are looking at resolving, https://github.com/microsoft/vscode-jupyter/issues/8426.

@IanMatthewHuff I do have that setting turned on. I guess I am looking for something that auto-scrolls just in a single cell's output.

@moonj94 I'm going to close down this issue in favor of just tracking #8426. Just follow that issue to see progress with fixing this.