text:
:eyes: comment out reset layout

Fixes #223

Codecov Report

Merging #228 (78461a5) into main (c905478) will increase coverage by 0.04%.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main     #228      +/-   ##
==========================================
+ Coverage   97.06%   97.11%   +0.04%
==========================================
  Files          13       13
  Lines         988     1005      +17
==========================================
+ Hits          959      976      +17
  Misses         29       29

Impacted Files
Coverage Δ

...ler/figure_resampler/figure_resampler_interface.py
99.74% <ø> (+<0.01%)
:arrow_up:

... and 5 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@jonasvdd any reason why we had the reset layout (autorange & range) for x and y axes in the constructor?

I'm fine with commenting this out!

authors: codecov-commenter jonasvdd jvdd

repo: predict-idlab/plotly-resampler


text:
docs: Add readthedocs examples

references

starts #1356
supersedes #1408

changes

[x] update examples/README.md
[x] add two examples/readthedocs-*

Thank you @bollwyvl sorry for the slow response, I missed it for some reason. I added some more platforms which makes the examples runable from all platforms.
What is the reason for using mamba to install pixi. Instead of using a pixi-docker image?

What is the reason for using mamba to install pixi. Instead of using a pixi-docker image?

At a guess: as a startup providing basically free building and hosting, and encouraging "golden path" builds based on relatively simple toolchains, RTD doesn't want to provide support for when an unlimited number of docker images of indeterminate size and security posture break, or otherwise screw up their infrastructure.

At a guess: as a startup providing basically free building and hosting, and encouraging "golden path" builds based on relatively simple toolchains, RTD doesn't want to provide support for when an unlimited number of docker images of indeterminate size and security posture break, or otherwise screw up their infrastructure.

I see, my assumption from looking at the configuration was that it could run any docker image. But if it is just a selected set, this makes total sense.

could run any docker image

Yep, here's the infra repo for their images available to open source projects, and the last discussion about it:
https://github.com/readthedocs/readthedocs.org/issues/6162

source: gharchive/pull-request

authors: bollwyvl ruben-arts

repo: prefix-dev/pixi

license_type: permissive

license_source: github-api


text:
Execute posy built-frontend to build the wheel.

When we have access to venv's from #78 we can then use the posy build-frontend to actually build the wheel from an Sdist.
To do this:
During resolution:

[x] Use the information from the Sdist pyproject to get the build backend and requirements
[x] Resolve an environment and install this into a #78 venv.
[x] Run the posy frontend to get metadata using the prepare_metadata_for_build_wheel hook and associate this metadata with the artifact. Probably need to modify the frontend to suit our use-case.

During installation

[x] Run the posy frontend to build the wheel using the build_wheel function to actually build and save it in the wheel cache #79

Important note is that the prepare_metadata_for_build_wheel need not exist so we need to differentiate between this in some way, if it was build or if it has just created the metadata.

Intial PR is here: https://github.com/prefix-dev/rip/pull/84

Closed by #84

Closed by #84

source: gharchive/issue

repo: prefix-dev/rip


text:
Tests fails to build on clang 3.5/6/7 on Ubuntu

On ubuntu 14.04-2 LTS
OK with gcc 4.8.2 - links and runs
Changing to clang++-3.5 /3.6 or recent 3.7 fails link due to a change in source in benaphore.h based on __llvm__ (gcc not supporting atomic_init)

recursivebenaphoretester.cpp.o: In function 'testRecursiveBenaphore()':
undefined reference to void std::atomic_init<std::thread_id>(std::atomic<std::thread::id>*,std::thread::id)

Having clang use gcc's path through constructor by commenting out ifdefs etc - now compiles OK and runs - downside - probably on OSX/clang?
Not sure what fix to propose? I see you have different problems with clang on OSX which caused this problem in the first place.
Maybe instead of __llvm__ combine with some OSX only define to tweak the logic?
(Also looks like atomic_init() only got implemented in gcc's libstdc++ in Jan 2015 so will take a while to propagate)

I ran some experiments using the latest Clang 3.7 (build from sources) on Debian. I was able to reproduce your link error when compiling with libstdc++. When compiling with libc++ (by specifying -stdlib=libc++ in BuildSettings.cmake), the error goes away. In fact, either method of initializing m_owner works with libc++ on Debian.
I haven't gone back to check Apple LLVM 6.0 yet, but I'm pretty sure it's also using libc++. That raises the question of why Apple LLVM 6.0 doesn't like to initialize m_owner via the constructor. I don't know if it's because it's using an older version of libc++, or because there's something peculiar about the implementation of std::thread::id on MacOS X.
For now, I'll work around the problem as you suggested: prefer atomic_init only when (defined(llvm) && defined(APPLE).

authors: mintyc preshing

license: Zlib


text:
🛑 Beta is down

In 1eff2ae, Beta (https://beta.presquelabs.com) was down:

HTTP code: 400
Response time: 633 ms

Resolved: Beta is back up in 768319e.

repo: presquelabs/upptime

license: MIT


text:
Implement getCatalogSessionProperties

What: Add support for setting default catalog session properties in FileSessionPropertyManager & DbSessionPropertyManager
How: Use the convention that the first dot in a property name is a separator between a catalog name and a the catalog specific property name
This PR is a replacement for https://github.com/prestosql/presto/pull/5188

I tried to rebase but still face ci errors that are unrelated with the PR, don't know how to go about that.
This time it's:
tests               | 2020-10-06 13:19:24 INFO: Testing with bucketingType=BUCKETED_V1, value='prestosql rocks', insertWithPresto=false, expectedFileNamePossibilites=[000001_0] tests               | 2020-10-06 13:19:25 INFO: FAILURE     /    io.prestosql.tests.hive.TestHiveBucketedTables.testBucketingVersion (Groups: ) took 49.2 seconds tests               | 2020-10-06 13:19:25 SEVERE: Failure cause: tests               | io.prestosql.tempto.query.QueryExecutionException: java.sql.SQLException: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask. Error caching map.xml: java.nio.channels.ClosedByInterruptException tests               | 	at io.prestosql.tempto.query.JdbcQueryExecutor.execute(JdbcQueryExecutor.java:114) tests               | 	at io.prestosql.tempto.query.JdbcQueryExecutor.executeQuery(JdbcQueryExecutor.java:82) tests               | 	at io.prestosql.tests.hive.TestHiveBucketedTables.testBucketingVersion(TestHiveBucketedTables.java:304) tests               | 	at io.prestosql.tests.hive.TestHiveBucketedTables.testBucketingVersion(TestHiveBucketedTables.java:280) tests               | 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) tests               | 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) tests               | 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) tests               | 	at java.base/java.lang.reflect.Method.invoke(Method.java:566) tests               | 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:104) tests               | 	at org.testng.internal.Invoker.invokeMethod(Invoker.java:645) tests               | 	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:851) tests               | 	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1177) tests               | 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) tests               | 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) tests               | 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) tests               | 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) tests               | 	at java.base/java.lang.Thread.run(Thread.java:834) tests               | Caused by: java.sql.SQLException: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask. Error caching map.xml: java.nio.channels.ClosedByInterruptException tests               | 	at org.apache.hive.jdbc.HiveStatement.execute(HiveStatement.java:275) tests               | 	at io.prestosql.tempto.query.JdbcQueryExecutor.executeQueryNoParams(JdbcQueryExecutor.java:122) tests               | 	at io.prestosql.tempto.query.JdbcQueryExecutor.execute(JdbcQueryExecutor.java:107) tests               | 	... 16 more

Please rebase and apply last comments. It looks like you hit #5427, hopefully after the rebase the issue won't appear again.

Got a green CI !

Merged, thanks!

authors: kokosing rclaude

repo: prestosql/presto


text:
TypeError: locStart is not a function

I tried playing with this but got the following stack trace. Reduced repro steps below:
$ mkdir pr; cd pr
$ yarn add --dev --exact prettier @prettier/plugin-python
$ echo '#!/usr/bin/env python' > foo.py
$ yarn run prettier --write foo.py

yarn run v1.5.1
warning package.json: No license field
$ /home/adys/pr/node_modules/.bin/prettier --write foo.py
foo.py
[error] foo.py: TypeError: locStart is not a function
[error]     at comments.forEach (/home/adys/pr/node_modules/prettier/bin-prettier.js:8108:33)
[error]     at Array.forEach (<anonymous>)
[error]     at Object.attach (/home/adys/pr/node_modules/prettier/bin-prettier.js:8094:12)
[error]     at attachComments (/home/adys/pr/node_modules/prettier/bin-prettier.js:32467:14)
[error]     at formatWithCursor (/home/adys/pr/node_modules/prettier/bin-prettier.js:32553:23)
[error]     at Object.formatWithCursor (/home/adys/pr/node_modules/prettier/bin-prettier.js:32835:12)
[error]     at format$1 (/home/adys/pr/node_modules/prettier/bin-prettier.js:38985:21)
[error]     at eachFilename (/home/adys/pr/node_modules/prettier/bin-prettier.js:39208:16)
[error]     at filePaths.forEach.filePath (/home/adys/pr/node_modules/prettier/bin-prettier.js:39150:7)
[error]     at Array.forEach (<anonymous>)
[error]     at eachFilename (/home/adys/pr/node_modules/prettier/bin-prettier.js:39149:15)
[error]     at Object.formatFiles (/home/adys/pr/node_modules/prettier/bin-prettier.js:39166:3)
[error]     at Object.run (/home/adys/pr/node_modules/prettier/bin-prettier.js:39789:14)
[error]     at Object.<anonymous> (/home/adys/pr/node_modules/prettier/bin-prettier.js:39804:5)
[error]     at Module._compile (module.js:649:30)
[error]     at Object.Module._extensions..js (module.js:660:10)
[error]     at Module.load (module.js:561:32)
[error]     at tryModuleLoad (module.js:501:12)
[error]     at Function.Module._load (module.js:493:3)
[error]     at Function.Module.runMain (module.js:690:10)
[error]     at startup (bootstrap_node.js:194:16)
[error]     at bootstrap_node.js:666:3
error An unexpected error occurred: "Command failed.
Exit code: 2
Command: sh
Arguments: -c /home/adys/pr/node_modules/.bin/prettier --write foo.py
Directory: /home/adys/pr
Output:
".
info If you think this is a bug, please open a bug report with the information provided in "/home/adys/pr/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

yarn-error.log

Ah, the error goes away when using git, nvm.
However, if the file only contains #!/usr/bin/env python, I get another error which looks legitimate:
$ /home/adys/pr/node_modules/.bin/prettier --write foo.py
foo.py
[error] foo.py: Error: Comment "#!/usr/bin/env python" was not printed. Please report this error!
[error]     at astComments.forEach.comment (/home/adys/pr/node_modules/prettier/bin-prettier.js:32494:13)
[error]     at Array.forEach (<anonymous>)
[error]     at ensureAllCommentsPrinted (/home/adys/pr/node_modules/prettier/bin-prettier.js:32492:15)
[error]     at formatWithCursor (/home/adys/pr/node_modules/prettier/bin-prettier.js:32562:3)
[error]     at Object.formatWithCursor (/home/adys/pr/node_modules/prettier/bin-prettier.js:32835:12)
[error]     at format$1 (/home/adys/pr/node_modules/prettier/bin-prettier.js:38985:21)
[error]     at eachFilename (/home/adys/pr/node_modules/prettier/bin-prettier.js:39208:16)
[error]     at filePaths.forEach.filePath (/home/adys/pr/node_modules/prettier/bin-prettier.js:39150:7)
[error]     at Array.forEach (<anonymous>)
[error]     at eachFilename (/home/adys/pr/node_modules/prettier/bin-prettier.js:39149:15)
[error]     at Object.formatFiles (/home/adys/pr/node_modules/prettier/bin-prettier.js:39166:3)
[error]     at Object.run (/home/adys/pr/node_modules/prettier/bin-prettier.js:39789:14)
[error]     at Object.<anonymous> (/home/adys/pr/node_modules/prettier/bin-prettier.js:39804:5)
[error]     at Module._compile (module.js:649:30)
[error]     at Object.Module._extensions..js (module.js:660:10)
[error]     at Module.load (module.js:561:32)
[error]     at tryModuleLoad (module.js:501:12)
[error]     at Function.Module._load (module.js:493:3)
[error]     at Function.Module.runMain (module.js:690:10)
[error]     at startup (bootstrap_node.js:194:16)
[error]     at bootstrap_node.js:666:3
error An unexpected error occurred: "Command failed.

And that's #69. Closing.

I think we should still look into your original issue — as useful as it is, we shouldn’t be requiring our users to use Git.

I just assumed it was an issue fixed in master and a release isn't out yet. Feel free to reopen though.

I think it's fair to change the README to use git while this is still in early dev.

I see the same error, even with a fresh git clone.
> ../plugin-python/node_modules/.bin/prettier "**/*.py"
[error] api/.tox/py27/bin/activate_this.py: TypeError: locStart is not a function
[error]     at getSortedChildNodes (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/main/comments.js:32:11)
[error]     at childNodes.forEach.childNode (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/main/comments.js:72:5)
[error]     at Array.forEach (<anonymous>)
[error]     at getSortedChildNodes (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/main/comments.js:71:14)
[error]     at childNodes.forEach.childNode (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/main/comments.js:72:5)
[error]     at Array.forEach (<anonymous>)
[error]     at getSortedChildNodes (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/main/comments.js:71:14)
[error]     at decorateComment (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/main/comments.js:84:22)
[error]     at comments.forEach (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/main/comments.js:182:5)
[error]     at Array.forEach (<anonymous>)
[error]     at Object.attach (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/main/comments.js:176:12)
[error]     at attachComments (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/index.js:34:14)
[error]     at formatWithCursor (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/index.js:120:23)
[error]     at Object.formatWithCursor (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/index.js:402:12)
[error]     at format (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/cli/util.js:157:19)
[error]     at eachFilename (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/cli/util.js:380:16)
[error]     at filePaths.forEach.filePath (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/cli/util.js:322:7)
[error]     at Array.forEach (<anonymous>)
[error]     at eachFilename (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/cli/util.js:321:15)
[error]     at Object.formatFiles (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/cli/util.js:338:3)
[error]     at Object.run (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/src/cli/index.js:60:12)
[error]     at Object.<anonymous> (/usr/local/google/home/melchang/plugin-python/node_modules/prettier/bin/prettier.js:5:23)

authors: j-f1 jleclanche melissachang

repo: prettier/plugin-python


text:
Fix inconsistency in merge terminology

This brings it in-line with the GitHub terminology
Fixes #109

LGTM!

authors: TimvdLippe txsmith

repo: preview-code/rite-evaluation

license_source: bigquery


text:
PrimeNG 17.17.0 Stepper Component Support

Hello,
I just cloned the template and tried the Stepper component and the functionality works but feels like it's missing some styling.
I am quite new to the libraries wanted to make sure if i am missing something or this component is not supported yet.
Link to the component documentation:
https://primeng.org/stepper
Here is my code:
https://github.com/ericaskari/sakai-ng-primeng-stepper
And the commit:
https://github.com/ericaskari/sakai-ng-primeng-stepper/commit/704755cb945a92c28fb7dbd8bd1ff85b1d391215
Few pictures of how it looks like:

And how it should look like:

Thank you.

Was about to raise the same issue. Need to raise a PR. If someone has already got this then good. otherwise I will try to work on this.

Anyone who got a solution to this issue ?

Anyone who got a solution to this issue ?

Go to node_modules> PrimeNg>resources>thems  Based on the requirement, let say for example i am taking eg as lara-light-indigo in ngSakai. open same theme in node_modules and copy the below css and paste it in your assets> theme> lara-light-indigo>theme.css. Same method for rest of themes ..
.p-stepper .p-stepper-nav {
    position: relative;
    display: flex;
    justify-content: space-between;
    align-items: center;
    margin: 0;
    padding: 0;
    list-style-type: none;
    overflow-x: auto;
  }

  .p-stepper-vertical .p-stepper-nav {
    flex-direction: column;
  }

  .p-stepper-header {
    position: relative;
    display: flex;
    flex: 1 1 auto;
    align-items: center;
  }
  .p-stepper-header:last-of-type {
    flex: initial;
  }

  .p-stepper-header .p-stepper-action {
    border: 0 none;
    display: inline-flex;
    align-items: center;
    text-decoration: none;
    cursor: pointer;
  }
  .p-stepper-header .p-stepper-action:focus-visible {
    outline: 0 none;
    outline-offset: 0;
    box-shadow: 0 0 0 0.2rem #C7D2FE;
  }

  .p-stepper.p-stepper-readonly .p-stepper-header {
    cursor: auto;
  }

  .p-stepper-header.p-highlight .p-stepper-action {
    cursor: default;
  }

  .p-stepper-title {
    display: block;
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;
    max-width: 100%;
  }

  .p-stepper-number {
    display: flex;
    align-items: center;
    justify-content: center;
  }

  .p-stepper-separator {
    flex: 1 1 0;
  }

  .p-stepper .p-stepper-nav {
    display: flex;
    justify-content: space-between;
    margin: 0;
    padding: 0;
    list-style-type: none;
  }
  .p-stepper .p-stepper-header {
    padding: 0.5rem;
  }
  .p-stepper .p-stepper-header .p-stepper-action {
    transition: box-shadow 0.2s;
    border-radius: 6px;
    background: #ffffff;
    outline-color: transparent;
  }
  .p-stepper .p-stepper-header .p-stepper-action .p-stepper-number {
    color: #4b5563;
    border: 1px solid #f3f4f6;
    border-width: 2px;
    background: #ffffff;
    min-width: 2rem;
    height: 2rem;
    line-height: 2rem;
    font-size: 1.143rem;
    border-radius: 50%;
    transition: background-color 0.2s, color 0.2s, box-shadow 0.2s;
  }
  .p-stepper .p-stepper-header .p-stepper-action .p-stepper-title {
    margin-left: 0.5rem;
    color: #6b7280;
    font-weight: 700;
    transition: background-color 0.2s, color 0.2s, box-shadow 0.2s;
  }
  .p-stepper .p-stepper-header .p-stepper-action:not(.p-disabled):focus-visible {
    outline: 0 none;
    outline-offset: 0;
    box-shadow: 0 0 0 0.2rem #C7D2FE;
  }
  .p-stepper .p-stepper-header.p-highlight .p-stepper-number {
    background: #EEF2FF;
    color: #4338CA;
  }
  .p-stepper .p-stepper-header.p-highlight .p-stepper-title {
    color: #4b5563;
  }
  .p-stepper .p-stepper-header:not(.p-disabled):focus-visible {
    outline: 0 none;
    outline-offset: 0;
    box-shadow: 0 0 0 0.2rem #C7D2FE;
  }
  .p-stepper .p-stepper-header:has(~ .p-highlight) .p-stepper-separator {
    background-color: #6366F1;
  }
  .p-stepper .p-stepper-panels {
    background: #ffffff;
    padding: 1.25rem;
    color: #4b5563;
  }
  .p-stepper .p-stepper-separator {
    background-color: #e5e7eb;
    width: 100%;
    height: 2px;
    margin-inline-start: 1rem;
    transition: box-shadow 0.2s;
  }
  .p-stepper.p-stepper-vertical {
    display: flex;
    flex-direction: column;
  }
  .p-stepper.p-stepper-vertical .p-stepper-toggleable-content {
    display: flex;
    flex: 1 1 auto;
    background: #ffffff;
    color: #4b5563;
  }
  .p-stepper.p-stepper-vertical .p-stepper-panel {
    display: flex;
    flex-direction: column;
    flex: initial;
  }
  .p-stepper.p-stepper-vertical .p-stepper-panel.p-stepper-panel-active {
    flex: 1 1 auto;
  }
  .p-stepper.p-stepper-vertical .p-stepper-panel .p-stepper-header {
    flex: initial;
  }
  .p-stepper.p-stepper-vertical .p-stepper-panel .p-stepper-content {
    width: 100%;
    padding-left: 1rem;
  }
  .p-stepper.p-stepper-vertical .p-stepper-panel .p-stepper-separator {
    flex: 0 0 auto;
    width: 2px;
    height: auto;
    margin-inline-start: calc(1.75rem + 2px);
  }
  .p-stepper.p-stepper-vertical .p-stepper-panel:has(~ .p-stepper-panel-active) .p-stepper-separator {
    background-color: #6366F1;
  }
  .p-stepper.p-stepper-vertical .p-stepper-panel:last-of-type .p-stepper-content {
    padding-left: 3rem;
  }

Another solution is Copy all the lastest themes from  node_modules>Primeng>resources>thems  and replace it in your assets  themes folder   assets>layout>styles>themes

authors: Mashudu ericaskari siva-geddada swapnil0545

repo: primefaces/sakai-ng


text:
TextInput - Accessibility review recommended updates

Describe your changes here.
Here, I've made a few recommended updates as suggested by the accessibility review in https://github.com/github/primer/issues/538

Removed inline validation from the stories. It's not a feature of textinput. But its not recommended for accessibility. Page level validation is preferred as my understanding
Deprecate loading related props. Also remove aria-live and aria-busy values.
Remove examples of placeholder usage. I don't think we should block it though. It's a feature of <input /> html element.

Merge checklist

[x] Added/updated tests
[x] Added/updated documentation
[x] Tested in Chrome
[x] Tested in Firefox
[x] Tested in Safari
[ ] Tested in Edge

Take a look at the What we look for in reviews section of the contributing guidelines for more information on how we review PRs.

I'm working on adding a validation example that aligns with what we defined in the interface guidelines: https://github.com/primer/react/pull/2315

@mperrotti what are your thoughts on next steps on this PR - do we need Allie's input to unblock? I'd hate to let this work go stale while @pksjce is on leave.

Based on feedback during a11y office hours, I think we to remove aria-live and aria-busy.

the react input has aria-live and aria-busy and this was reported a long time ago. It means that a screenreader will read out the input as you type into it which as you can imagine is really annoying.
— Slack message (only available to Hubbers)

Before moving forward, I'd like to get feedback from @alliethu or somebody else from the a11y team about my review comment.

@mperrotti @lesliecdubs apologies for missing all these pings!

Removed inline validation from the stories. It's not a feature of textinput. But its not recommended for accessibility. Page level validation is preferred as my understanding

@alliethu - can we really not have an error message at the text input level? I thought this was ok as long as we followed the guidelines defined here: https://primer.style/design/ui-patterns/forms#validation

I just had a chance to review the very thorough forms validation guidelines and agree that it would be ok assuming guidelines are followed. I'm cc/ing @primer/accessibility-design to keep me honest.

Deprecate loading related props. Also remove aria-live and aria-busy values.

I don't think we actually want to remove these.

@alliethu's review assumes that the loading indicator is only used for inline validation. This is not the case - we would use a loading state when a text input is performing a search.

I think you're right that my review was based on the assumption the loading indicator was only being used for inline validation. Again, I would default to the team to get this a second look, as it's been so long since I performed this review.

Agree that inline validation is okay per the guidelines in our form validation guidance! I think it would be good to also have examples of places this is okay outside of a failed validation re-do, like a password field checking if a username is available on sign up.

Based on feedback during a11y office hours, I think we to remove aria-live and aria-busy.
We can remove these. If we left them we'd want to add an additional element of timing; when the validation message is read off and trying to come up with just the right timing would get complex. For example, if the validation waits 5 seconds after a user stops typing to read out the validation. Too quickly and it's annoying, too slow and the user might miss it. We just want to be sure that the user has some form of reading that inline validation.

Thanks folks!

Based on feedback during a11y office hours, I think we to remove aria-live and aria-busy.

@mperrotti are you comfortable executing on this change ^ directly on the branch in this PR so we can move toward merge? Let me know if you want support to get this over the line.

authors: alliethu ichelsea lesliecdubs mperrotti pksjce

repo: primer/react


text:
The appearance of Button's trailing visual counter needs adjustment

The trailing_visual_counter Button slot does not look good on primary buttons (I haven't checked other schemes).
In light, contrast is low:

In dark dimmed, the color looks wrong:

It looks like the Counter is still using --color-btn-counter-bg instead of --color-btn-primary-counter-bg, despite the Button being scheme: :primary.
Explicitly passing scheme: :primary to trailing_visual_counter also does not seem to be taking effect.

The old .btn seems to use a separate --color-btn-primary-counter-bg variable for primary buttons:

So it probably should be fixed when using that also for the new Button.

authors: scotttesler simurai


text:
Is there a way to set up proxy?

Describe the issue
Is there a way to set up proxy? I am getting access denied because the proxy is not set up
Suggest an improvement to documentation
No response

Could you elaborate?

I am running this internally in a restricted access to websites and post get requests. I have to set up my proxy here in run.py,
def run(self, index):
# Reset environment
instance_id = self.env.data[index]["instance_id"]
os.environ['http_proxy'] = ''
os.environ['https_proxy'] = ''
print("Current HTTP_PROXY: ", os.getenv('HTTP_PROXY'))
proxies = {
'http': os.getenv('HTTP_PROXY'),
'https': os.getenv('HTTPS_PROXY'),
}
for hook in self.hooks:
hook.on_instance_start(index=index, instance=self.env.data[index])
assert isinstance(instance_id, str)  # mypy
if self.should_skip(instance_id):
for hook in self.hooks:
hook.on_instance_skipped()
raise _ContinueLoop
logger.info("▶  Beginning task " + str(index))
observation, info = self.env.reset(index)

it hasn't worked and i do get this error below

Traceback (most recent call last):
  File "/home/ebabaoglu/SWE-AGENT/SWE-agent/run.py", line 511, in <module>
    main(get_args())
  File "/home/ebabaoglu/SWE-AGENT/SWE-agent/run.py", line 507, in main
    Main(args).main()
  File "/home/ebabaoglu/SWE-AGENT/SWE-agent/run.py", line 293, in __init__
    self.env = SWEEnv(args.environment)
  File "/home/ebabaoglu/SWE-AGENT/SWE-agent/sweagent/environment/swe_env.py", line 117, in __init__
    self.data = get_instances(self.data_path, self.args.base_commit, self.args.split, token=self._github_token, repo_path=self.args.repo_path)
  File "/home/ebabaoglu/SWE-AGENT/SWE-agent/sweagent/environment/utils.py", line 597, in get_instances
    ib.set_problem_statement(file_path)
  File "/home/ebabaoglu/SWE-AGENT/SWE-agent/sweagent/environment/utils.py", line 474, in set_problem_statement
    self.set_problem_statement_from_gh_issue(data_path)
  File "/home/ebabaoglu/SWE-AGENT/SWE-agent/sweagent/environment/utils.py", line 460, in set_problem_statement_from_gh_issue
    self.args["problem_statement"] = get_problem_statement_from_github_issue(owner, repo, issue_number, token=self.token)
  File "/home/ebabaoglu/SWE-AGENT/SWE-agent/sweagent/environment/utils.py", line 441, in get_problem_statement_from_github_issue
    issue = api.issues.get(owner, repo, issue_number)
  File "/home/ebabaoglu/miniconda3/envs/swe-agent/lib/python3.9/site-packages/ghapi/core.py", line 62, in __call__
    return self.client(self.path, self.verb, headers=headers, route=route_p, query=query_p, data=data_p)
  File "/home/ebabaoglu/miniconda3/envs/swe-agent/lib/python3.9/site-packages/ghapi/core.py", line 121, in __call__
    res,self.recv_hdrs = urlsend(path, verb, headers=headers or None, debug=debug, return_headers=True,
  File "/home/ebabaoglu/miniconda3/envs/swe-agent/lib/python3.9/site-packages/fastcore/net.py", line 218, in urlsend
    return urlread(req, return_json=return_json, return_headers=return_headers)
  File "/home/ebabaoglu/miniconda3/envs/swe-agent/lib/python3.9/site-packages/fastcore/net.py", line 117, in urlread
    with urlopen(url, data=data, headers=headers, timeout=timeout, **kwargs) as u: res,hdrs = u.read(),u.headers
  File "/home/ebabaoglu/miniconda3/envs/swe-agent/lib/python3.9/site-packages/fastcore/net.py", line 108, in urlopen
    try: return urlopener().open(urlwrap(url, data=data, headers=headers), timeout=timeout)
  File "/home/ebabaoglu/miniconda3/envs/swe-agent/lib/python3.9/urllib/request.py", line 517, in open
    response = self._open(req, data)
  File "/home/ebabaoglu/miniconda3/envs/swe-agent/lib/python3.9/urllib/request.py", line 534, in _open
    result = self._call_chain(self.handle_open, protocol, protocol +
  File "/home/ebabaoglu/miniconda3/envs/swe-agent/lib/python3.9/urllib/request.py", line 494, in _call_chain
    result = func(*args)
  File "/home/ebabaoglu/miniconda3/envs/swe-agent/lib/python3.9/urllib/request.py", line 1389, in https_open
    return self.do_open(http.client.HTTPSConnection, req,
  File "/home/ebabaoglu/miniconda3/envs/swe-agent/lib/python3.9/urllib/request.py", line 1349, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error Tunnel connection failed: 407 Proxy Authentication Required>

because the call to make an http request doesn't pass in the proxy settings
from the miniconda library

Seems like this is occurring while you're pulling information from github. Can't you just run on a local repo then?
Alternatively, you could check how you can set up the gh API to use proxy settings.
Not sure if we can do much on our side (though if there's a simple thing we could do, let me know or open a PR)

authors: elifbabaoglu klieret

repo: princeton-nlp/SWE-agent


text:
Can't get correct model types string

Hi! I will try to be the most short as possible. Please could you warn me if it lacks information?
The error:

Only the initial scalars are being pulled, although there are more in my datamodel.
for example:

Does this proof I did generate correctly?

//src/index

import { GraphQLServer } from "graphql-yoga";
import { nexusPrismaPlugin } from "nexus-prisma";
import { makeSchema } from "nexus";
import * as allTypes from "./api";
import { join } from "path";
import { permissoes } from "./permissoes/index";
import { Photon } from "@generated/photon";

const photon = new Photon({ debug: true });

const nexusPrismaTypes = nexusPrismaPlugin({
  types: allTypes,
});

const schema = makeSchema({
  types: [allTypes, nexusPrismaTypes],
  typegenAutoConfig: {
    debug: true,
    sources: [
      {
        source: "@generated/photon",
        alias: "photon"
      },
      {
        source: join(__dirname, "types.ts"),
        alias: "ctx"
      }
    ],
    backingTypeMap: {
      Date: "Date",
      Upload: "Upload"
    },
    contextType: "ctx.Context"
  },
  outputs: {
    schema: join(__dirname, "./schema.graphql")
  }
});

export const server = new GraphQLServer({
  schema,
  // middlewares: [permissoes],
  context: request => ({
    ...request,
    photon
  })
});

server.start(() => console.log(`Server is running on http://localhost:4000`));

It appears to be no error when starting....
[INFO] 14:56:22 Restarting: manual restart from user
Using ts-node version 8.3.0, typescript version 3.4.5
Server is running on http://localhost:4000
  getos { platform: 'win32', libssl: undefined } +0ms
GraphQL Nexus: No match for Time in "@generated/photon" using /(?:interface|type|class|enum)\s+(Time)\W/g
GraphQL Nexus: No match for Time in "..\..\..\src\types" using /(?:interface|type|class|enum)\s+(Time)\W/g

How can I provide more info? Trying to solve this since yesterday, sorry if I missed something...

I think the reason why your output types are not appearing is because you're not calling the functions of t.crud., you're simply accessing them as properties, which does nothing.
Try the following for all t.crud/t.model:
- t.crud.estados
+ t.crud.estados()

You're right, I missed that...
But still I can't make it work. It seems to miss the "type" argument.

Error:
- Missing type CategoriaDeComodidade, did you forget to import a type to the root query or mean CategoriaDeComodidadeOrderByInput?
    at assertNoMissingTypes (C:\projetob\yugi\backend\node_modules\nexus\src\builder.ts:1663:11)
    at Object.makeSchema (C:\projetob\yugi\backend\node_modules\nexus\src\builder.ts:1589:3)
    at Object.<anonymous> (C:\projetob\yugi\backend\src\index.ts:11:16)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Module._compile (C:\projetob\yugi\backend\node_modules\source-map-support\source-map-support.js:521:25)
    at Module.m._compile (C:\Users\RAFFAE~2\AppData\Local\Temp\ts-node-dev-hook-5697630631774853.js:57:25)
    at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at require.extensions.(anonymous function) (C:\Users\RAFFAE~2\AppData\Local\Temp\ts-node-dev-hook-5697630631774853.js:59:14)
    at Object.nodeDevHook [as .ts] (C:\projetob\yugi\backend\node_modules\ts-node-dev\lib\hook.js:61:7)
    at Module.load (internal/modules/cjs/loader.js:599:32)

When I look through @generated/photon files, it seems to be correctly generated, with all models I have on datamodel file.
I will try to reproduce the example on examples folder here.

Hi! I realized something I was missing.
Now I must first declare what models will be available on my api declaring it with t.model.MODEL, right? Sorry I didn't realize that before.  I do have many models. Is there any easy way like t.prismaModels(['*']) or something to declare all at once?

following #299

authors: Weakky outerlook

repo: prisma-labs/nexus-prisma


text:
Prisma Migrate: Support for configuring the shadow DB URL

Problem
The migrate dev or migrate reset commands in Prisma Migrate require a shadow database. Prisma Migrate assumes the same credentials used for the development database can be used to create it. When using a local DBMS, this can be achieved by granting the user privileges to create new databases.
Some of our users develop on the cloud and don't run their DBMS locally. This prevents these users from using Prisma Migrate in development unless they switch to using a local DBMS.
Solutions
We could allow users to provide a URL to a shadow database that can be used as the shadow database. Example: a user could provision two Postgres databases on Heroku, one for the development another the shadow database.
In order to do this, we'd need to enable a way to supply this configuration, i.e., config file, env variable, etc.

Update: after carefully considering multiple options, we have decided that this configuration would be made via the Prisma schema file, by adding one more field to the datasource block.
We don't think it's very elegant but it works and is consistent with the way the main database URL is configured. We hope we are able to revisit at some point the entire configuration topic at a high level, this would be one more configuration bit that would be taken into account.

Update: after carefully considering multiple options, we have decided that this configuration would be made via the Prisma schema file, by adding one more field to the datasource block.
We don't think it's very elegant but it works and is consistent with the way the main database URL is configured. We hope we are able to revisit at some point the entire configuration topic at a high level, this would be one more configuration bit that would be taken into account.

@albertoperdomo will v2.15 have it set up that way and ready to use? I really need to update and have groupBy abilities!

@albertoperdomo will v2.15 have it set up that way and ready to use? I really need to update and have groupBy abilities!

@perryraskin Unfortunately not, but hopefully we can release it in 2.16.0. Thanks for your patience while we figure out the best solution.

@perryraskin Unfortunately not, but hopefully we can release it in 2.16.0. Thanks for your patience while we figure out the best solution.

@tomhoule Looks like it would be a good thing to add a check at runtime to verify that the db url and shadow db url database are different.

@tomhoule Looks like it would be a good thing to add a check at runtime to verify that the db url and shadow db url database are different.

👋 Thanks for working on this! I wanted to clarify something, and ask a question about alternatives.

Some of our users develop on the cloud and don't run their DBMS locally.

This implies that the prisma migrate command is intended for development-only; if that's the case, what's the correct way to update a production database? In other words, once I've run prisma migrate locally and generated the migration.sql files, what's the correct way to run that migration? Is it through prisma db push?

Hi @JasonEtco , indeed it is deploy. Thanks for the feedback!

@JasonEtco I just created https://github.com/prisma/prisma/issues/5531 to mention it, great idea! Thanks!

This feature is now live in 2.17.0 - https://github.com/prisma/prisma/releases/tag/2.17.0
For feedback, please post on https://github.com/prisma/prisma/issues/4531.

authors: JasonEtco Jolg42 albertoperdomo perryraskin tomhoule

repo: prisma/prisma


text:
Update tutorial.md

Update to use prisma2 instead of prisma in cli example.

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

Someone already submitted this. Closing.

authors: CLAassistant jebrial


text:
[CompactGate] Generate state transitions of dynamic steps

Goal
Generate state transitions of dynamic steps. (i.e., BitOpStep)
Context
There are steps that are dynamically generated based on the number of bits, rows, etc., usually using repeat64str macro. Fortunately, these steps have finite number of states, so we can generate the state transitions either in steps file generation or in compile time. We need to take into consideration about the case where there are child steps branching off from the dynamic step.
Currently we do this in collect_steps.py. In the future, we want to do this in compile time with a proc macro, but that requires #704 to be solved first.

fixed with #771

repo: private-attribution/ipa


text:
Implement BQL syntax for multiple/joint imputation

Currently
INFER EXPLICIT PREDICT x, PREDICT y FROM p

imputes x and y from their marginals. We need BQL syntax for imputing from the joint distribution
INFER EXPLICIT PREDICT (x,y), PREDICT y FROM p

There are non-trivial UI and implementation questions here -- i.e. how does the result look in a tabular form, since the first PREDICT is bivariate input-output which is not standard SQL.
I recall @riastradh-probcomp did some enormous hack to get PREDICT ... CONFIDENCE working.

Of course a user can always manually impute using SIMULATE x, y GIVEN z FROM p which returns results from the specified distribution {x,y}|z, and then post-process in their favorite way. But BayesDB (or as it stands now IBayesDBMetamodel) should also have some default imputation strategy based on the stattypes.

repo: probcomp/bayeslite


text:
Don't assume libselinux.so.1 to be present in the target systems

https://github.com/The-Compiler/qutebrowser/issues/1912#issuecomment-244534556

In kdenlive-16.12-alpha1-x86_64, the issue is
kdenlive-16.12-alpha1-x86_64/usr/lib/qt5/plugins/platforms/libqxcb.so
loads
kdenlive-16.12-alpha1-x86_64/usr/lib/libEGL.so.1 and/or
kdenlive-16.12-alpha1-x86_64/usr/lib/libglapi.so.0
Since the latter two are bundled from a CentOS system, they depend on libselinux.

But not all users appreciate that:
https://github.com/The-Compiler/qutebrowser/issues/1912#issuecomment-244534556
https://kdenlive.org/2016/10/kdenlive-packages-available-for-testing/
For example, on Manjaro Linux:
Getting the following error in Manjaro KDE:

This application failed to start because it could not find or load the Qt platform plugin “xcb”
in “”.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, xcb.

Reinstalling the application may fix this problem.
/tmp/.mount_NBF2EU/AppRun: line 49: 2322 Aborted (core dumped) kdenlive $@

So the question is, can these libraries be rebuilt without the need for libselinux, or could we have some dummy selinux replacement library that does nothing.
Please comment here if you have an idea how to solve this.

https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds says "preload a dummy libselinux that makes all child processes think that SELinux is disabled" - where can we get this?

@darealshinji can you do a dummy libselinux.so.1 similar to what you did on https://github.com/probonopd/AppImages/issues/127? Thanks :-)

Try to build this as a shared library:
gcc -s -shared -o libselinux.so.1 -Wl,-soname,libselinux.so.1 selinux-mock.c
But I'd say if selinux is not available in all distros the AppImage should not include anything depending on it in the first place. The current AppImage release is 16.12.2. Maybe it's no longer an issue there?

It's an issue in the Subsurface AppImage and other ones built on Travis CI and it's been bothering me, so a thousand thanks for your hint. :+1:

What happens if the libselinux.so.1 file from the build system will be bundled with the AppImage?

That would also be an option, but adding to the size of the AppImage.

Well, it's only about 120k uncompressed...

What is the current state of this problem? i have a Qt application for what I wanted to create an AppImage using linuxdeployqt. I am using a centos7 based docker image to build the application and the AppImage. Unfortunately I ran in the same issue with libselinux on ArchLinux. Should I switch to a different build system (for example debian or ubuntu)?

When you compile on Ubuntu, your binaries won't have a dependency on libselinux. Although I am almost sure there must be an easier way to achieve the same without switching the entire build operating system.

Possibly removing libselinux-devel using yum before compiling could do the trick. May be worth a try.

Try to figure out with libraries have a dependency on libselinux and install them as non-selinux builds from another repository. That might help.

@probonopd  I wasn't able to remove selinux without breaking the system. As this build system was docker based it wasn't that difficult to move to ubuntu:trusty. LinuxDeployQt works perfectly there and the generated AppImage seems to work on most distributions (have only checked a few myself). Thanks for bringing AppImage and linuxdeployqt to us!

@crapp glad it is working for you; feel free to add your software to https://github.com/probonopd/AppImageKit/wiki/AppImages.

Hey, facing this in Archlinux, with an AppImage generated in a local docker, derived from ubuntu:xenial.
First, trying to run the appimage doesn't work with the message:
execv error: No such file or directory

If I extract it with ./MyApp --appimage-extract
cd ./squashfs-root/usr/bin
QT_DEBUG_PLUGINS=1 ./MyApp

I got:
...
Got keys from plugin meta data ("xcb")
QFactoryLoader::QFactoryLoader() checking directory path "/home/phc/tmp/squashfs-root/usr/bin/platforms" ...
loaded library "/home/phc/tmp/squashfs-root/usr/plugins/platforms/libqxcb.so"
QLibraryPrivate::loadPlugin failed on "/home/phc/tmp/squashfs-root/usr/plugins/platforms/libqxcb.so" : "Cannot load library /home/phc/tmp/squashfs-root/usr/plugins/platforms/libqxcb.so: (libselinux.so.1: cannot open shared object file: No such file or directory)"
This application failed to start because it could not find or load the Qt platform plugin "xcb".
Available platform plugins are: xcb.

Reinstalling the application may fix this problem.

My work in progress Dockerfile is here: https://github.com/phcerdan/FFT-from-image-compute-radial-intensity/blob/master/extra/Docker/xenial_linuxdeployqt/Dockerfile

What's the problem of bundling a libselinux.so, as @darealshinji suggested?

@phcerdan Good question. I don't know how much of an security issue it may be or if bundling it works at all (I don't know much about SELinux and what it's actually used for).
One option could be: use dlopen() to find out if libselinux.so.1 is available. If it's not, add the fake selinux library[1][2] to LD_LIBRARY_PATH

What's the problem of bundling a libselinux.so, as @darealshinji suggested?

Nothing, apart from it making the AppImage unneccessarily larger

Added it as an annoyance to the list of Desktop Linux Platform Issues https://github.com/AppImage/AppImageKit/wiki/Desktop-Linux-Platform-Issues#selinux

The reason why libselinux.so.1 was blacklisted:

# sed: error while loading shared libraries: libpcre.so.3: cannot open shared object file: No such file or directory

So it depends on libpcre.so.3 which was blacklisted, but isn't anymore. I'd say libselinux.so.1 shouldn't be blacklisted anymore. Uncompressed filesize on Ubuntu is less than 200k.

Hi @probonopd,

Nothing, apart from it making the AppImage unnecessarily larger

How is this unnecessary? Isnt' the aim of AppImage to generate binaries for all distros? For 200k increase, solving this issue sounds worthy, IMHO.
Not working on Arch and derivatives distros at the moment. I will try the workaround. Thanks.

Hey this workaround work in Arch:
create a fake library from this selinux_mock.c
extern int is_selinux_enabled(void)
{
  /* always return 0; this way we don't trigger any SELINUX calls */
  return 0;
}

And compile it in the folder /path with: gcc -s -shared -o libselinux.so.1 -Wl,-soname,libselinux.so.1 selinux-mock.c
Then execute your AppImage with:
LD_LIBRARY_PATH=/path:${LD_LIBRARY_PATH} ./MyApp.AppImage

For bundling the fake libselinux.so in docker, so Arch users can run it:
RUN echo "extern int is_selinux_enabled(void){return 0;}" >> selinux-mock.c && \
    gcc -s -shared -o libselinux.so.1 -Wl,-soname,libselinux.so.1 selinux-mock.c && \
    rm selinux-mock.c && \
    mv libselinux.so.1 \
    ${APP_DIR}/usr/lib/

Where ${APP_DIR}/usr/lib might change depending on the project structure.

That's awesome indeed.
Maybe we could make appimagetool do something like this:
echo 'H4sICGC8jlkAA2xpYnNlbGludXguc28uMQDtWF1sFFUUPrPdny7Q3dUoLi2RiQEtRieIYCpYQWph
QDBY2uiDdZx2p901+4Mzs9ASEhsRhRCSSuIDDySExESNMX0TwYfWmoLxwfqXEF8kKklRolUDKS+M
986c0525dAIPJiamZzP7zTn3fPeee+/cmXPva+3bN0ckCUjq4Eng2kjM0zeiPXPHrAuztUCC/TfC
Etc3BuHyUCKIALL7z3lxXm8K60/JQYx49mwkyIsgrxl5zehPOIJdIaxHdhSv82gXcTkEMYq485Kd
4/cfxj1dxKUQROI9x3hxuH3JIHZge2HjMo3xEtLMcc5dwOcPYMuzXTB07kzfV8d2jh8cOvHFtbGr
J14f/T0NWN7AroXgzZsYYwJ9+LgtYFeSXYt85bydCPokoDaPh0aXSxDdlEz4OJvav79y9udj+zs+
3X/qwqsvLP3k6J+p3779I3WrsahjNewWHio+vvIcvlKIXQ+xt4TYO9h13xz2Y8DnZjHImSDrXdd+
DzQL9iq77mS9fwcHdiHaj6O/WE/G9b+5v4tdewOcFCdI0/pLlbJm2bppaxpohXLBBq2PAWhbO3do
OcM0+guWbZidO9qKlbLRqfcUDa9s7hKtd0DnFejFwj6mbtujdaBfW1G3LMOCgqVZRrFQrg5oRpmT
clAs9PQqVkV5DDQjp9s6q6bHsrywmKnseiCJ+z0CW7Zv3dSmrVZWK2sDHYqwOQz+DkFtPVQbC0nu
c4bGC9cBreuXcXyygl0meyZoJ/1C2sM4eM8zyUWfvc5nn/LZoz77tM/un8IZn90/heqBK/XqkZix
QAb14Kgdm2pyjZ/Xj3vlzlqTFTkrbPafXraR3a1jd33DzoptLqpHY7s592hrD4MudeWMeviSemAm
tTfSPc4qjmLFf3U7Fzmf+T/u+a/2+Y/N1KmHP1PHft2gSpPq1zNVl3z3j0lO/oaR1cMTzk+cP9R6
nRmh+oB6oPUcv+tifHuReqT1B6ZNGY7jTOXZX/dEbJIZpL/HOatPSS97A/vbejrBaPb9LLi9SS+4
xi4WzylmZnU5k92Xn2cVpJcNcf/Lz7B73sZprrGo+Hjh8EhNdeuzOF+/3HCcNdyfub8I3ruPi7Sv
A6SBjNS0KFE/LHnvc/7ueI/5u89UKrM5ld2WXri3fgg2NK5/8NHl7rLnPk+z6yCrz12zT6Uyb0ba
GuKbWUUwL/MyL/MyL/Py/xbKp2Qh76R9xiFESuI/QKQ9AuWxDahT/roEdcrfmlCnb2sjIuVxS4Vy
yrlo33P1hlPh2ILJG+VeI5i0UfgDWL4A9QlEysuziLO5HuaHtF0diQbjGEVMCnyWXrjxDKO/gzqN
2zTqe7D8Our+HPO/ENo3i0J58pa2tnVy866uXe3ydp7Lr5TXKC08g1esvGWbtt4DSrliG0p/uar0
VAvF3MOFHLhaXrfyoOQGy9ZgyUPb9Er2GKZVqJQDisbKTKOoc0dQ3F2NsrtoK/0VdmMbA+zf3eQo
Rl7rM/WSoeVzZk3zKJpumvqg50n3r/Sabut6qdALvDpeLbPwTYvC9iyg9FZKJaNs/yvjyZ8r/uzQ
niLsnIEkKug8GY35+OJ+XxV44vq4l13X2LNFfFofhE+E8EmasQ/Ep/VD2IJxUIyz+yrEVeA908Sn
9UhI649EEnS+P3d88dN6IaT3BMUfEbAdvLVIOq1HQhlq8Utwc/87oXbG4cYdDeKo0L7Y/5egdibC
hd6HhBQ/iTj/ZwX+cCyIGcE/I2BO4J+MBVHki/0vCXw6ByScDmmfxBLbjwcxKfiL/R9EPo1/2Hlb
GP8tgX8+HsSc4C/2/23wvm30Xq6dv83tL+on2JX28el7lr1N/vsYP/Fl5Mu3yf8IgmcXtfNRTx/x
rV8/n+YxL7RP5yQX0lhfSPuEHwt8+p5SA7ROwvijAp++Q9lM0E/kk0ygbXb8kC+H8MX3z5doWyXY
5ZD4pTlwrm96C/K/u0X7/wDlRnoKkBcAAA==' | base64 -d - | gunzip > libselinux.so.1

This was made by
echo "extern int is_selinux_enabled(void){return 0;}" >> selinux-mock.c
gcc -s -shared -o libselinux.so.1 -Wl,-soname,libselinux.so.1 selinux-mock.c
strip libselinux.so.1
ls -l selinux-mock.c
gzip libselinux.so.1
base64 libselinux.so.1.gz

You have just delivered the proof that it is unneccessary to ship the full library, haven't you?

Well, yes, but if bundling a small library solves all these workarounds...

You have just delivered the proof that it is unneccessary to ship the full library, haven't you? Now, could the mock be made a bit more clever, and "route through" (e.g., using dlopen()) the original library if it is installed on the target system? After all, I assume it does something on systems with SELinux enabled.

Good question indeed does it do something? selinux archwiki. I have no idea about selinux, but it is a good question. How secure is it to execute a binary from a 3rd party for selinux to matter though?

The question is, will an AppImage that contains the mock library run on a system that has SELinux in "enforcing" mode at all.

I have no way to access such a SElinux system, but I would love to find out.

The easiest way to find out would probably be to run Fedora in a VM.

The easiest way to find out would probably be to run a Fedora Live ISO.
According to https://fedoraproject.org/wiki/FedoraLiveCD, it

Uses SELinux in enforcing mode and other security features by default.

(It is the first thing I always disable when running Fedora...)

Cool, will test it in a VM.

I have tested it in Fedora26 Live ( literally in a live session in a VM, without installing it to disk)
sestatus:
SELinux status: enabled
Loaded policy name: targeted
Current mode: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed

And it works when the fake selinux is bundled:
It works straight away with: ./MyApp.AppImage
Checking the guts with: ./MyApp.AppImage --appimage-extract
cd ./squashfs-root
ldd AppRun | grep -i selinux
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fdb2cc09000)
when in archlinux with the bundled libselinux.so as well:
ldd AppRun | grep -i selinux returns nothing.

Current mode: enforcing
it works when the fake selinux is bundled

That is excellent news. I really wonder why the library is needed after all, then.
Thank you very much!

Personally I think it's still better to bundle the original selinux library, in case the program wants to load other symbols from it. However if you really want to stick with the fake library you should probably add extern int is_selinux_mls_enabled(){ return 0; } too.

Can't we satisfy all symbols?

Can't we satisfy all symbols?

That's a lot: https://github.com/SELinuxProject/selinux/blob/master/libselinux/include/selinux/selinux.h
I think it's easier and safer to bundle libselinux.so.1. I don't see why bundling it would be an issue.

200k useless bloat
NSA-related code

Because it was originally made by the NSA doesn't mean it's evil. As for the bloat: if you create an AppImage of a program that uses libav to encode videos into avc/aac/mp4 format you will have a lot more bloat, probably several megabytes, because by default libav is enabled to encode and decode a lot more codecs. A 200k library as a dependency to ensure that Centos' libraries are working correctly seems fine to me.
Another alternative would be to use a Centos build that comes without selinux.

I wouldn't be so sure about this. On https://github.com/SELinuxProject/selinux it states

Please submit all bug reports and patches to selinux@tycho.nsa.gov.
Subscribe via selinux-join@tycho.nsa.gov.

Even if the code is not malicious (which I cannot judge but remember NIST and elliptical curves?), I don't want to ship anything that has anything to do with NSA whatsoever.

I don't want to ship anything that has anything to do with NSA whatsoever.

Okay, don't get me wrong, but that seems a bit paranoid. This would also mean you're never using a distro that comes with libselinux, like Ubuntu or Fedora.
SELinux is still an open source project, which makes adding backdoors much harder. And who guarantees the NSA is not involved in other software projects, under different names? Besides, as far as I understood the SELinux functionalities can't be used anyway if the kernel doesn't support it.
I found these statements quite interesting:
https://security.stackexchange.com/a/42398
https://debianforum.de/forum/viewtopic.php?f=37&t=99389#p623750
I'd leave it to AppImage distributors if they want to ship a fake-SELinux library or not.
I'd also like to hear what @TheAssassin or others have to say about it.

This would also mean you're never using a distro that comes with libselinux, like Ubuntu or Fedora.

I do try to avoid Red Hat software indeed...

I have researched this topic a few years ago, and to my best knowledge, the following points represent the situation:
SELinux have been started by the NSA, a non-trustworthy US government agency who perform mass surveillance on billions of people, without respecting other countries' jurisdictions, without anyone being able to stop them. The purpose is ridiculous, and the amount of surveillance is not justified by the results they came up with so far.
However, this does not mean that the system is compromised by default. This begins with the fact that the software is fully open source. Distros who ship it by default are aware of the source code, read it, understand it. I have strong belief that any potential backdoor would have been discovered, but there are none. I don't use it myself except for my Android phone, I use systems with AppArmor. But I believe it is secure, good software, and can be used without any problems when shipped by trustworthy distributors (to which I don't count the NSA).
I would never register with the NSA to be able to contribute. But the pure usage seems okay.
The primary maintainer of SELinux himself does not work for the NSA either, it's a Red Hat employee, who testified that there are no backdoors.
Further examples on government contributions to free security-related software involve the Tor project, GnuPG, the DoD published a few things, too. Free software has some problems, yes, but the probability for government placed security holes is nearly 0.
There's a lot more problems with hardware than with software. Ever wondered why you can run your computer virtually only with free software (there's even a few FOSS drivers), but all the hardware is proprietary? Sure, some projects like the Raspberry Pi attempt to improve this situation, but most PC hardware is proprietary, there's literally no usable free GFX drivers, etc. etc. etc. The firmware of network cards is proprietary, albeit you send all your data over it, some of it isn't even encrypted, because it's only "the local network". Many SSDs ship with hardware encryption in their controllers, but literally no one trusts them. But the least users question other hardware components.
TL;DR: I'd trust SELinux 1000 times more than any of the afore-mentioned components, as I can at any time read and compile its source code. Shipping such a library is > 99.9% okay. Even though it used to be developed primarily by the NSA, nowadays, a lot more people frequently check the source code. It's trustworthy.

Super useful insights!
Here is my attempt to bundle the original libselinux.so.1:
RUN cp /lib/x86_64-linux-gnu/libselinux.so.1 ${APP_DIR}/usr/lib/

When executing in arch:
QFactoryLoader::QFactoryLoader() checking directory path "/tmp/.mount_FFT_Fu64XhwA/usr/bin/platforms" ...
loaded library "/tmp/.mount_FFT_Fu64XhwA/usr/plugins/platforms/libqxcb.so"
QLibraryPrivate::loadPlugin failed on "/tmp/.mount_FFT_Fu64XhwA/usr/plugins/platforms/libqxcb.so" : "Cannot load library /tmp/.mount_FFT_Fu64XhwA/usr/plugins/platforms/libqxcb.so: (libpcre.so.3: cannot open shared object file: No such file or directory)"

This is weird because libpcre.so.3 is bundled already.
But it the app looks first for system libraries and find other version of libpcre.so
ldd ./squashfs-root/usr/plugins/platforms/libqxcb.so | grep -i pcre
ldd: warning: you do not have execution permission for `./squashfs-root/usr/plugins/platforms/libqxcb.so'
        libpcre16.so.3 => /home/phc/tmp/./squashfs-root/usr/plugins/platforms/../../lib/libpcre16.so.3 (0x00007f254aa4e000)
        libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f254955b000)
        libpcre.so.3 => not found

So, I wonder, if system libraries take precedence, maybe the fake libselinux.so.1 is not a problem??
If there is a system libselinux, it will take precedence and be used instead of the fake one (see the results of ldd in Fedora in my previous comment where this happen). If no libselinux present, we use the fake one that does nothing.

You could perform some research on how LD_LIBRARY_PATH is interpreted by the default linker on your distribution, and perhaps even on other ones. This is the way we use to link against the AppDir libraries. Maybe that provides some useful insights.

echo $LD_LIBRARY_PATH is empty in my arch.

Also, why does the linker consider pcre.so.1 as valid, when is needing pcre.so.3? can that be tweaked?

@phcerdan They are identical libraries. libpcre.so.3 is a historical Debian/Ubuntu screwup. Everywhere else it is libpcre.so.1.

@phcerdan It looks like libpcre16.so.3 is bundled but not libpcre.so.3. If the symbols are all the same, you could create a symlink from libpcre.so.3 to libpcre16.so.3.

Argh. What does "libpcre16.so.3" even mean? They (who?) can't decide whether it is major version 3 or 16?

@probonopd PCRE 1 provides three libraries: libpcre.so.1, libpcre16.so.1 and libpcre32.so.1. On Debian systems, this is bumped to soversion 3.

Do you know why there are three libraries? Are they different or just differently named?

Package descriptions are:
libpcre16-3
    Perl 5 Compatible Regular Expression Library - 16 bit runtime files**
libpcre16-3
    Perl 5 Compatible Regular Expression Library - 16 bit runtime files
ibpcre32-3
    Perl 5 Compatible Regular Expression Library - 32 bit runtime files

I assume they are different.

@probonopd I don't know all the details, but I think it has to do with data sizes (bitness). There was a libpcre64.so.1 at one point, I think.

Now I am totally confused. I though the architecture.e.g, x86_64, is not part of the library name at all.. and why would we still care about 16-bit?

@probonopd It's not about architectures I think, it's about preserving ABI differences through historical changes (short -> int -> long, that sort of thing).
That said, PCRE2 isn't done this way so this stupidity ends with PCRE1.

@probonopd

It looks like libpcre16.so.3 is bundled but not libpcre.so.3.

Both are bundled it seems: ls ./squashfs-root/usr/lib/ | grep -i pcre
libpcre16.so.3
libpcre.so.3

For completness, in my system I have: ls /usr/lib | grep -i pcre
libpcre16.so -> libpcre16.so.0.2.9
libpcre16.so.0 -> libpcre16.so.0.2.9
libpcre16.so.0.2.9
libpcre2-16.so -> libpcre2-16.so.0.5.0
libpcre2-16.so.0 -> libpcre2-16.so.0.5.0
libpcre2-16.so.0.5.0
libpcre2-32.so -> libpcre2-32.so.0.5.0
libpcre2-32.so.0 -> libpcre2-32.so.0.5.0
libpcre2-32.so.0.5.0
libpcre2-8.so -> libpcre2-8.so.0.5.0
libpcre2-8.so.0 -> libpcre2-8.so.0.5.0
libpcre2-8.so.0.5.0
libpcre2-posix.so -> libpcre2-posix.so.1.0.1
libpcre2-posix.so.1 -> libpcre2-posix.so.1.0.1
libpcre2-posix.so.1.0.1
libpcre32.so -> libpcre32.so.0.0.9
libpcre32.so.0 -> libpcre32.so.0.0.9
libpcre32.so.0.0.9
libpcrecpp.so -> libpcrecpp.so.0.0.1
libpcrecpp.so.0 -> libpcrecpp.so.0.0.1
libpcrecpp.so.0.0.1
libpcreposix.so -> libpcreposix.so.0.0.5
libpcreposix.so.0 -> libpcreposix.so.0.0.5
libpcreposix.so.0.0.5
libpcre.so -> libpcre.so.1.2.9
libpcre.so.1 -> libpcre.so.1.2.9
libpcre.so.1.2.9

I can solve in my system creating a link named .so.3 pointing either to the system library:
ln -s /usr/lib/libpcre.so ~/pcre/libpcre.so.3
or to he bundled one:
ln -s ~/.squashfs-root/usr/lib/libpcre.so.3 ~/pcre/libpcre.so.3 And then executing the image works with: LD_LIBRARY_PATH=~/pcre ./MyApp.AppImage`
But well, not really a solution. Maybe just moving libselinux.so.1 into the ${APP_DIR}/usr/lib folder wasn't enough?
The failing bit is on the bundled libselinux.so.1:
ldd ./squashfs-root/usr/lib/libselinux.so.1
linux-vdso.so.1 (0x00007ffee9df4000)
libpcre.so.3 => not found
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f4bae92f000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f4bae589000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f4baed55000)

Even though, libpcre.so.3 is bundled in the same folder.
Doing the same with libqxcb.so which is the one that triggers the error:
ldd ./squashfs-root/usr/plugins/platforms/libqxcb.so | grep -i 'selinux\|pcre'
        libpcre16.so.3 => /home/phc/tmp/./squashfs-root/usr/plugins/platforms/../../lib/libpcre16.so.3 (0x00007f515d962000)
        libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f515c46f000)
        libselinux.so.1 => /home/phc/tmp/./squashfs-root/usr/plugins/platforms/../../lib/libselinux.so.1 (0x00007f5159dae000)
        libpcre.so.3 => not found

Just putting libraries into AppDir subdirectories will not magically make ldd look for them there. For ldd to pick them up, you need to either export LD_LIBRARY_PATH=<path to the libraries it needs>, or use patchelf  on the library like patchelf --set-rpath '$ORIGIN'.

Just putting libraries into AppDir subdirectories will not magically make ldd look for them there.

I was suspecting that, thanks for the confirmation.

patchelf --set-rpath '$ORIGIN'.

That's the missing part. Now it works.
RUN apt-get install -y patchelf
RUN cp /lib/x86_64-linux-gnu/libselinux.so.1 ${APP_DIR}/usr/lib/ && \
    patchelf --set-rpath '$ORIGIN' ${APP_DIR}/usr/lib/libselinux.so.1

RUN ./squashfs-root/AppRun .${APP_DIR}/usr/share/applications/*.desktop -bundle-non-qt-libs
RUN ./squashfs-root/AppRun .${APP_DIR}/usr/share/applications/*.desktop -appimage
RUN rm -rf ./squashfs-root/

Tested in 'arch' (no selinux at all) and Fedora (selinux enforced). It works.

I assume we should somehow bring this workaround into the tools (at least into linuxdeployqt and functions.sh).

Why not simply using a distro to bundle, which comes without SELinux?

@ShalokShalom In my case, because ci platforms use SElinux distros, i.e travis, circle-ci.

You can disable it, is it enough?
I think we should make a list of all the distros, who are free from SELinux. KaOS and Slackware are what I know, I guess hard that PCLinuxOS and most of the systemd free distros count to that as well.

This is completely idiotic. Both major LSMs (AppArmor and SELinux) have userspace libraries that applications link into. If your library chain includes libselinux.so.1 or libapparmor.so.1, then just pull it in. It does literally nothing if there's no SELinux/AppArmor available, and will provide security enhancements if there is.

/tmp/.mount_OfyqhO/usr/bin/subsurface: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory

Sorry for being ignorant here, but in order for the security to work, AppArmor and SELinux require the "suspect" application to "cooperate" by linking to these libraries? Don't think this provides any real security then, since the AppImage could ship some random fake "AppArmor" or "SELinux" library. If that is true, then the best advice would be to disable AppArmor and SELinux when building, and if this is not possible (e.g., because the source code is not available), then ship a dummy library.
I might be wrong though. If so, please correct me.

@probonopd The AppArmor and SELinux libraries are basically programmer's interfaces to kernel ioctls and common utils functions. They don't do much and the real meat is still in the kernel itself. That's why the soversion of the libraries hasn't changed in almost a decade.

Which means that the security of AppArmor and SELinux works regardless of wheter the application links the corresponding libraries, am I understand you right @Conan-Kudo?

@probonopd Yep. Lots of things are confined without application level integration. The application integration just lets the app itself do cool things and be smarter.

And how to get it working on distros without those libs?

Just bundle the libraries and leave it be. They don't hurt anything.

Yes, please! Otherwise AppImages are likely to not run on distros like Arch.
--- a/excludelist
+++ b/excludelist
@@ -79,16 +79,6 @@
 # Workaround for:
 # Application stalls when loading fonts during application launch; e.g., KiCad on ubuntu-mate

-libselinux.so.1
-# Workaround for:
-# sed: error while loading shared libraries: libpcre.so.3: cannot open shared object file: No such file or directory
-# Some distributions, such as Arch Linux, do not come with libselinux.so.1 by default.
-# The solution is to bundle a dummy mock library:
-# echo "extern int is_selinux_enabled(void){return 0;}" >> selinux-mock.c
-# gcc -s -shared -o libselinux.so.1 -Wl,-soname,libselinux.so.1 selinux-mock.c
-# strip libselinux.so.1
-# More information: https://github.com/AppImage/AppImages/issues/83
-
 # The following are assumed to be part of the base system
 # Removing these has worked e.g., for Krita. Feel free to report if
 # you think that some of these should go into AppImages and why.

@darealshinji with this workaround, they will work

@probonopd
The problem is that "not by default" doesn't mean it might not be there and useful. The Arch/Gentoo Hardened projects offers SELinux enablement.
Debian and SUSE both offers SELinux and AppArmor support and policies.
Red Hat/Fedora, of course, offers SELinux and Ubuntu offers AppArmor.
The dummy libraries means that applications can't detect when such things are active and automatically use them properly, which defeats the point of making applications that can secure themselves.

# Workaround for:
# sed: error while loading shared libraries: libpcre.so.3: cannot open shared object file: No such file or directory

This "workaround" is obsolete, since libpcre.so.3 is now bundled by default, as not all distros provide it themselves.

Please bundle the proper libselinux and solve all this for 200K. Hijacking the name of a library with a mock seems... not good.

Can you explain to me what that library does for your application @phcerdan?

@probonopd it is beyond the scope of my application. It is a dependency imposed by bundling my app in a SElinux system. But in short, it allows my application to run on all linux distros.
It does nothing in systems without SELinux, as people that know way more than I have stated in this conversation but allow people in SELinux systems to use their SELinux policy with the app. I think is super important to worry about privacy, and NSA, as you do, but libselinux is opensource and already present in a lot of systems for appimage to "guard/watch" about it.

Again the question, do you think your application will run less secure when this library is replaced with a stub? My point is, we don't even know what it does...

Some people do know and choose to use it. I think it is beyond the scope of appimage to impose that decision.
And we should define secure, I guess you can package a super vital app with appimage and then use SELinux to enforce a policy for its usage, or whatever it does.

Please bundle it by default. AppImage distributors should decide whether they want to replace any of their libs with stubs or not. libselinux.so.1 is not available on all distros, small and portable between distros (unlike i.e. glibc). So there's no point to exclude it by default.

AppImage distributors should decide whether they want to replace any of their libs with stubs or not.

I agree with that.
But for the AppImages that I make, I don't want to include NSA-originated software that I do not understand and that has no apparent use to me.

But for the AppImages that I make, I don't want to include NSA-originated software that I do not understand and that has no apparent use to me. This is not to say that AppImages that others make should necessarily follow the same logic.

That's fine. But in this case I think you should still remove libselinux.so.1 from the excludelist as most people who build AppImages will use the same list and usually "blindly" accept it (i.e. resulting in Subsurface being incompatible with Arch).

True! Doing it now.

@TheAssassin

there's literally no usable free GFX drivers

While there are mostly no open source alternatives available for some devices, which counts especially for the UEFI/CPU, is GFX very well supported by AMD these days.

为了在docker中捆绑伪libselinux.so，Arch用户可以在没有任何解决方法的情况下运行它：
# Generate a fake libselinux.so and bundle it in your app.
RUN echo "extern int is_selinux_enabled(void){return 0;}" >> selinux-mock.c && \
    gcc -s -shared -o libselinux.so.1 -Wl,-soname,libselinux.so.1 selinux-mock.c && \
    rm selinux-mock.c && \
    mv libselinux.so.1 \
    ${APP_DIR}/usr/lib/

# Then run linuxdeployqt as usual:
RUN ./squashfs-root/AppRun .${APP_DIR}/usr/share/applications/*.desktop -bundle-non-qt-libs
RUN ./squashfs-root/AppRun .${APP_DIR}/usr/share/applications/*.desktop -appimage

哪里${APP_DIR}/usr/lib可能会根据项目结构而改变。

Thanks for solved the problem of install seafile😃

authors: Conan-Kudo ShalokShalom TheAssassin YuSetsuna crapp darealshinji phcerdan probonopd

repo: probonopd/AppImages

license: mit


text:
"probot: secretOrPrivateKey must have a value" error with 10.0.0-beta.4

Bug Report
Current Behavior
After upgrading from 9.13.0 to 10.0.0-beta.4 our bot is throwing the following error on incoming hooks:
18:46:54.745Z ERROR probot: secretOrPrivateKey must have a value
  Error: secretOrPrivateKey must have a value
      at Object.module.exports [as sign] (/srv/packages/release-candidate-notes/node_modules/jsonwebtoken/sign.js:107:20)
      at getToken (/srv/packages/release-candidate-notes/node_modules/universal-github-app-jwt/dist-node/index.js:13:23)
      at Object.githubAppJwt (/srv/packages/release-candidate-notes/node_modules/universal-github-app-jwt/dist-node/index.js:34:23)
      at getAppAuthentication (/srv/packages/release-candidate-notes/node_modules/@octokit/auth-app/dist-node/index.js:14:57)
      at getInstallationAuthentication (/srv/packages/release-candidate-notes/node_modules/@octokit/auth-app/dist-node/index.js:138:35)
      at async hook (/srv/packages/release-candidate-notes/node_modules/@octokit/auth-app/dist-node/index.js:283:7)
      at async Job.doExecute (/srv/packages/release-candidate-notes/node_modules/bottleneck/light.js:405:18)

This error goes away after downgrading to 9.13.0 (without any code changes).
I suspect this is happening somewhere in the private key processing. We pass a base64 encoded key as the PRIVATE_KEY env var value. But it works fine in 9.13.0 so not sure what's going on. The error stack doesn't seem to start in any probot code (first line is from bottleneck) which is weird.
Expected behavior/code
No errors and successful processing of webhooks.
Environment

Probot version(s): 10.0.0-beta.4
Node/npm version: node 14
OS: Linux

is the code of your app open source?
If not, could you maybe create a minimal test case that reproduces the problem?
Could you try to replace new lines in the private key with "\n" instead of using base64 encoding?

The logic to decode a base64 encoded key is still there, I didn't touch that part of the code, so it would be great to have a minimal test case to reproduce the problem

Tried using the latest 10.8.0 build and it seems to be working fine now. 🤷

repo: probot/probot

license: ISC


text:
[WIP] Refactor

11 suits pass, 5 suits fail

There is some in progress to make tests pass again, see https://github.com/probot/probot/pull/1855

@gr2m
can we have a next branch?

Yes, sure. I'd prefer a beta branch as we expect breaking changes

Thank you. 11 suits pass now, 5 faill

14 suits passing, 2 suits failing

15 suits passing, 1 suit failing

all suits pass now
well. maybe not elegant. and maybe we have to discuss the changes. but the tests pass now.

@gr2m
How can I support you for reviewing this PR?

@gr2m
Addressed your remarks :)

@gr2m
Can you please provide feedback :)?

Thank you for the thorough pull request. I'd like some folks to test this before we release it as a breaking change. We should also try our best to list out all breaking changes, including all the changes coming from the octokit upgrades, otherwise this will be a very hard upgrade for Probot users.
@AaronDewes could you please give this a review, compare it to your probot-ng fork? I'll ask internal GitHub folks who expressed interest to test out this pull request before we merge it

I have a Probot app that I have developed for a customer, and I will attempt to test it with this new version of the code @Uzlopak

@gclhub
Thank you

I've done some testing with my customer's GitHub app, and everything is working as expected. There are some REST API endpoints that I had to call directly instead of using function-like wrappers with the previous version of Probot that used the older version of Octokit. I will also update my code to modernize those calls and retest.

@gclhub
I wanted to fix the remaining remarks tonight or on sunday. Are you willing then to test again? Please :)?

@gclhub
I wanted to fix the remaining remarks tonight or on sunday. Are you willing then to test again? Please :)?

Absolutely 👍
I just updated my app code as follows, and that worked fine:
@@ -113,14 +113,11 @@ module.exports = (app, { getRouter }) => {
     // can associate it with the source workflow information in the hashmap.
     if (context.payload.action == "update-session") {
       // Get the HTML URL for the run attempt
-      let run_attempt = await context.octokit.request('GET /repos/{owner}/{repo
}/actions/runs/{run_id}/attempts/{attempt_number}', {
+      let run_attempt = await context.octokit.actions.getWorkflowRunAttempt({
         owner: context.payload.repository.owner.login,
         repo: context.payload.repository.name,
         run_id: context.payload.client_payload.run_id,
         attempt_number: context.payload.client_payload.run_attempt,
-        headers: {
-          'X-GitHub-Api-Version': '2022-11-28'
-        }
       });

       // The workflow_run event handler doesn't support a client_payload

I would take a look through #1821 as well for things to incorporate, not necessarily in this PR, it can be done in further PRs to the beta branch

@gr2m Can octokit-auth-probot be updated for new Octokit releases

@gr2m
@wolfy1339
I think all your remarks are resolved. Just my three remarks at the beginning are left and needs feedback from you guys.
@gclhub
If you want to test this branch, than be aware, that you need probably set webhookPath accordingly to your needs ;)

@gr2m
@wolfy1339
I am quiete satisfied with this PR. I think it is ready for review/merge :)

@gr2m @wolfy1339
I think all your remarks are resolved. Just my three remarks at the beginning are left and needs feedback from you guys.
@gclhub If you want to test this branch, than be aware, that you need probably set webhookPath accordingly to your needs ;)

I'll have some time to look at this today @Uzlopak

@gclhub
Great! I am currently working on a MockAgent for nock fetch functionality. I hope that then i can finally upgrade and test our bots.


text:
Convert application tests to TypeScript

https://github.com/probot/probot/issues/582 Convert tests that test/application.test.js  to TypeScript.

Hi @bkeepers, thanks for your review comment.
I understood that run linting and type checking are not working against the tests. When #622 is merged, I’m going to submit changes to fix failed tests and lint errors.

#622 is merged

I fixed lint errors and failed tests. Please review again.

authors: bkeepers kentaro-m


text:
FFT at using lower sample rate audio input

There's project that uses Processing to analyze brain waves that I'd like to port over to use P5js but the frequency range of the brain waves I want to monitor are in the range of 8 - 30 Hz.  The current FFT function using 44 kHz audio input samples and limited to 1024 point FFT doesn't give much resolution down at that lower frequency range so I'd either need to do FFT's with significantly higher size (4096 or higher?) or filter and resample the audio input before it's sent to the FFT function so that it provides useful results at that very low range of frequencies.
My understanding is that the FFT function is limited to a max size of 1024 samples, is there a way to resample the audio input to a lower sample rate to, for example,  2.2 kHz rather than 44 kHz?

#617 is a similar question.
I dont know about resampling the audio input, but as I said in #617 I think you should be able to use values between 16 and 16384 for the p5.FFT bins.

authors: DaveSprague KevinGrajeda


text:
imageLight() sample of reference page seems not working

Most appropriate sub-area of p5.js?

[ ] Accessibility
[ ] Color
[ ] Core/Environment/Rendering
[ ] Data
[ ] DOM
[ ] Events
[ ] Image
[ ] IO
[ ] Math
[ ] Typography
[ ] Utilities
[X] WebGL
[ ] Build Process
[ ] Unit Testing
[ ] Internalization
[ ] Friendly Errors
[ ] Other (specify if possible)

p5.js version
1.9.0
Web browser and version
Chrome
Operating System
Windows11
Steps to reproduce this
Steps:

Let's take a look at the imageLight() section of the reference.
The sample does not work because the image cannot be loaded.

Snippet:
imageLight
let img;
function preload() {
  img = loadImage('assets/outdoor_image.jpg');
}
function setup() {
  createCanvas(100, 100, WEBGL);
}
function draw() {
  background(220);
  imageMode(CENTER);
  push();
  translate(0, 0, -200);
  scale(2);
  image(img, 0, 0, width, height);
  pop();
  ambientLight(50);
  imageLight(img);
  specularMaterial(20);
  noStroke();
  scale(2);
  rotateX(frameCount * 0.005);
  rotateY(frameCount * 0.005);
  box(25);
}

Shibomb pointed this out in a tweet.
I think it would be a problem for people who are interested in the behavior of imageLight(), so I think it would be better to fix it as soon as possible.

Additional assets for reference is somewhat manual at the moment. If possible do try to reuse existing assets and if needed to be added, we need to remember to also put it in the website folder.


text:
Allowing to use included views transformer from the current view

:
Fix for 225

@bhooshiek-narendiran I'm hoping to move on this fix soon, so I've opened a new PR with some changes and tests. It's based on your commits, so they aren't lost. Please comment there if you have feedback, and let me know if you were planning any additional changes we can merge together.

@bhooshiek-narendiran I'm hoping to move on this fix soon, so I've opened a new PR with some changes and tests. It's based on your commits, so they aren't lost. Please comment there if you have feedback, and let me know if you were planning any additional changes we can merge together.

Yes, we can merge this. I wrote the test. Facing some issues in local. Will try to complete it.

authors: bhooshiek-narendiran njbbaer

repo: procore-oss/blueprinter


text:
Mapeamento de Telas

Realizar o mapeamento das telas faltantes para implementação do novo design

Lista de Telas:

[ ] Tela Inicial;
[ ] Registrar;
[ ] Login;
[ ] Telas de Recuperação de senha;
[ ] Tela de "Loading";
[ ] Home;
[ ] Diário;
[ ] Conselho;
[ ] Noticias;
[ ] Relato Ruim;
[ ] Cadastro de Familiar;
[ ] Maps;
[ ] Perfil;
[ ] Ajuda;
[ ] Rumor;
[ ] Sobre;
[ ] Termos e politicas;
[ ] Tutorial.

A implementação de quase todas as telas foi concluída na branch feature/newDesign, é necessário testar e vou fazer alguns ajustes também.

Concluído, todas as telas com o novo design na branch development.

authors: alvesitalo gabrieldouurado

repo: proepidesenvolvimento/guardioes-app


text:
良いところ診断の結果に優しさを追加したい

以下の結果を追加したい
'{userName}のいいところは優しさです。あなたの優しい雰囲気や立ち振る舞いに多くの人が癒やされています。'

これから対応します 🌮


text:
dokku --help is unwieldy, collapse help into commands (topics) similar to heroku and docker

Presently dokku outputs some 60+ lines of help with no paging option built in, before you add plugins. When hunting for a command, a user may not be familiar with the naming conventions and be left to hunt for the feature.
Example of output today:
$ dokku --help
Usage: dokku [--quiet|--trace|--rm-container|--rm|--force] COMMAND <app> [command-specific-options]

Options:
    apps:create <app>                                                  Create a new app
    apps:destroy <app>                                                 Permanently destroy an app
    apps                                                               List your apps
    certs:add <app> CRT KEY                                            Add an ssl endpoint to an app. Can also import from a tarball on stdin
    certs:chain CRT [CRT ...]                                          [NOT IMPLEMENTED] Print the ordered and complete chain for the given certificate.
    certs:generate <app> DOMAIN                                        Generate a key and certificate signing request (and self-signed certificate)
    certs:info <app>                                                   Show certificate information for an ssl endpoint.
    certs:key <app> CRT KEY [KEY ...]                                  [NOT IMPLEMENTED] Print the correct key for the given certificate.
    certs:remove <app>                                                 Remove an SSL Endpoint from an app.
    certs:rollback <app>                                               [NOT IMPLEMENTED] Rollback an SSL Endpoint for an app.
    certs:update <app> CRT KEY                                         Update an SSL Endpoint on an app. Can also import from a tarball on stdin
    config (<app>|--global)                                            Display all global or app-specific config vars
    config:get (<app>|--global) KEY                                    Display a global or app-specific config value
    config:set (<app>|--global) KEY1=VALUE1 [KEY2=VALUE2 ...]          Set one or more config vars
    config:unset (<app>|--global) KEY1 [KEY2 ...]                      Unset one or more config vars
    docker-options:add <app> <phase(s)> OPTION                         Add docker option to app for phase (comma separated phase list)
    docker-options <app>                                               Display apps docker options for all phases
    docker-options <app> <phase(s)>                                    Display apps docker options for phase (comma separated phase list)
    docker-options:remove <app> <phase(s)> OPTION                      Remove docker option from app for phase (comma separated phase list)
    domains:add <app> DOMAIN                                           Add a custom domain to app
    domains <app>                                                      List custom domains for app
    domains:clear <app>                                                Clear all custom domains for app
    domains:remove <app> DOMAIN                                        Remove a custom domain from app
    enter <app>  [<container-type> || --container-id <container-id>]   Connect to a specific app container
    events:list                                                        List logged events
    events:off                                                         Disable events logger
    events:on                                                          Enable events logger
    events [-t]                                                        Show the last events (-t follows)
    help                                                               Print the list of commands
    logs <app> [-h] [-t] [-n num] [-q] [-p process]                    Show the last logs for an application
    ls                                                                 Pretty listing of deployed applications and containers
    nginx:access-logs <app> [-t]                                       Show the nginx access logs for an application (-t follows)
    nginx:build-config <app>                                           (Re)builds nginx config for given app
    nginx:disable <app>                                                disable nginx for an application (forces container binding to external interface)
    nginx:enable <app>                                                 enable nginx for an application
    nginx:error-logs <app> [-t]                                        Show the nginx error logs for an application (-t follows)
    plugin:disable <name>                                              Disable an installed plugin (third-party only)
    plugin:enable <name>                                               Enable a previously disabled plugin
    plugin:install [--core|git-url]                                    Optionally download git-url & run install trigger for active plugins (or only core ones)
    plugin:install-dependencies [--core]                               Run install-dependencies trigger for active plugins (or only core ones)
    plugin                                                             Print active plugins
    plugin:uninstall <name>                                            Uninstall a plugin (third-party only)
    plugin:update [git-url]                                            Optionally download git-url & run update trigger for active plugins
    ps <app>                                                           List processes running in app container(s)
    ps:rebuildall                                                      Rebuild all apps
    ps:rebuild <app>                                                   Rebuild an app
    ps:restartall                                                      Restart all deployed app containers
    ps:restart <app>                                                   Restart app container(s)
    ps:restore                                                         Start previously running apps e.g. after reboot
    ps:scale [<app> <proc>=<count> [<proc>=<count>]]                   Get/Set how many instances of a given process to run
    ps:start <app>                                                     Start app container(s)
    ps:stop <app>                                                      Stop app container(s)
    run <app> <cmd>                                                    Run a command in the environment of an application
    shell                                                              Spawn dokku shell
    tags <app>                                                         List all app image tags
    tags:create <app> <tag>                                            Add tag to latest running app image
    tags:deploy <app> <tag>                                            Deploy tagged app image
    tags:destroy <app> <tag>                                           Remove app image tag
    tar:from <app> <url>                                               Loads an app tarball from url.
    tar:in <app>                                                       Reads an tarball containing the app from stdin
    trace [on/off]                                                     Enable dokku tracing
    url <app>                                                          Show the first URL for an application (compatibility)
    urls <app>                                                         Show all URLs for an application
    version                                                            Print dokku's version

Proposed change:
$ dokku --help
Usage: dokku [--quiet|--trace|--rm-container|--rm|--force] COMMAND <app> [command-specific-options]

Help commands, use 'dokku [COMMAND] --help' for more details:

    apps                                                               List your apps
    certs                                                              Update an SSL Endpoint on an app. Can also import from a tarball on stdin
    config                                                             Display all global or app-specific config vars
    docker-options                                                     Display apps docker options for all phases
    domains                                                            List custom domains for app
    enter                                                              Connect to a specific app container
    events                                                             Show the last events (-t follows)
    logs                                                               Show the last logs for an application
    ls                                                                 Pretty listing of deployed applications and containers
    plugin                                                             Print active plugins
    ps                                                                  List processes running in app container(s)
    run                                                                Run a command in the environment of an application
    shell                                                              Spawn dokku shell
    tags                                                               List all app image tags
    tar                                                                Reads an tarball containing the app from stdin

Additional commands:
    help                                                               Print the list of commands
    trace [on/off]                                                     Enable dokku tracing
    url <app>                                                          Show the first URL for an application (compatibility)
    urls <app>                                                         Show all URLs for an application
    version                                                            Print dokku's version

$ dokku ps --help

Usage: dokku ps[:command-specific-options] [<app>]

    ps <app>                                                           List processes running in app container(s)
    ps:rebuildall                                                      Rebuild all apps
    ps:rebuild <app>                                                   Rebuild an app
    ps:restartall                                                      Restart all deployed app containers
    ps:restart <app>                                                   Restart app container(s)
    ps:restore                                                         Start previously running apps e.g. after reboot

Formating above is just an example and would be corrected for description and posix utility argument syntax conventions. This is obviously a plugn issue, but since dokku is the main consumer of that project, I figured I would start the conversation here before I submitted a PR there.

What sort of changes do you expect to submit to make to plugn to make this available, if any?

It's been a while since I looked at that code but I would do something like this:
plugn trigger commands descriptions
Which could read the plugin.toml description field. Plugins that don't have a description field would then get their normal plugn trigger commands help output  appended to the "Additional commands:". This allows for single line commands and backwards compatibility with old plugins. For Dokku's remaining built in commands, they could either be moved to plugins or a empty "builtins" plugins created to output their help.
Thoughts?

Could we do this without any changes to plugn?

Also, would there be a way to get the current output as is?

Could we do this without any changes to plugn?

I know that feel, what do you think about forking it to the Dokku org?

Also, would there be a way to get the current output as is?

Totally, we can have a wildcard option, anything is possible with computer programing!™

:+1:

My initial thought process was putting this functionality plugn (still could in the future), but instead, simply dropping help that includes a : seems to work well in my branch:
root@dokku:~/dokku# dokku
Usage: dokku [--quiet|--trace|--rm-container|--rm|--force] COMMAND <app> [command-specific-options]

Primary help options, type "dokku COMMAND:help" for more details:
Commands:
    apps                                                              List your apps
    checks <app>                                                      Show zero-downtime status
    config (<app>|--global)                                           Display all global or app-specific config vars
    docker-options <app>                                              Display app's Docker options for all phases
    docker-options <app> <phase(s)>                                   Display app's Docker options for phase (comma separated phase list)
    domains [<app>]                                                   List domains
    enter <app> [<container-type> || --container-id <container-id>]   Connect to a specific app container
    events [-t]                                                       Show the last events (-t follows)
    logs <app> [-h] [-t] [-n num] [-q] [-p process]                   Show the last logs for an application
    ls                                                                Pretty listing of deployed applications and containers
    plugin                                                            Print active plugins
    proxy <app>                                                       Show proxy for app
    ps <app>                                                          List processes running in app container(s)
    run <app> <cmd>                                                   Run a command in the environment of an application
    shell                                                             Spawn dokku shell
    tags <app>                                                        List all app image tags
    trace [on/off]                                                    Enable dokku tracing
    url <app>                                                         Show the first URL for an application (compatibility)
    urls <app>                                                        Show all URLs for an application
    version                                                           Print dokku's version

root@dokku:~/dokku# dokku domains:help
    domains [<app>], List domains
    domains:add <app> DOMAIN, Add a domain to app
    domains:clear <app>, Clear all domains for app
    domains:disable <app>, Disable VHOST support
    domains:enable <app>, Enable VHOST support
    domains:remove <app> DOMAIN, Remove a domain from app
    domains:set-global <domain>, Set global domain name

I would touch each core plugin and make sure it supports COMMAND:help and we might want to make it a convention to recommend using column in all plugin's help outputs instead just the top level help command:
root@dokku:~/dokku# dokku domains:help
    domains [<app>]               List domains
    domains:add <app> DOMAIN      Add a domain to app
    domains:clear <app>           Clear all domains for app
    domains:disable <app>         Disable VHOST support
    domains:enable <app>          Enable VHOST support
    domains:remove <app> DOMAIN   Remove a domain from app
    domains:set-global <domain>   Set global domain name

@josegonzalez how does that sound, think we can squeeze into 0.5.0? Once MH is done with https://github.com/dokku/dokku/pull/1953 I can shoot over a PR.

Sounds good to me :)

authors: christiangenco josegonzalez u2mejc

repo: progrium/dokku


text:
A list of list is not supported yet. Otherwise this should be a list of SemanticTags

item name="SemanticTags" type="SemanticTag" array="true" optional="false"/> -->

https://github.com/project-chip/connectedhomeip/blob/f0f5de0d79ae1c51d7fddbf70900ebac0acd899a/src/app/zap-templates/zcl/data-model/chip/mode-select-cluster.xml#L30-L35

This issue was generated by todo-issue based on a TODO comment in f0f5de0d79ae1c51d7fddbf70900ebac0acd899a.

This should be supported fine.
@du48s03 could you please take a look into fixing this?

authors: bzbarsky-apple woody-apple

repo: project-chip/connectedhomeip


text:
[GC-2.4] Device should response with error for invalid regulatory config value.

Problem
Step ./chip-tool generalcommissioning set-regulatory-config 4 12 0 15 0 shall fail
with ifeld ErrorCode as 'ValueOutsideRange'(1) and DebugText as a 'string' value.
GC_2_4.log

@doublemis1 What SHA is this being tested on?  This was fixed in #18067 on May 5, as far as I can tell....

The issue was revealed on TE9 SHA (https://github.com/project-chip/connectedhomeip/tree/TE9)

Ah, yes, that predates that fix.
This works correctly on tip.