downgrading ansi-regex version 4 to 3 - an arrow function was used in…

since there was an arrow function used in strip-ansi version 4, next.js was throwing errors is versions 3+.
so we should either use the old version of strip-ansi or we should compile it.
more info about the problem of version 4 of strip-ansi is found here.

Word. Experiencing the same thing! @timneutkens

Looks like this was fixed in #2860 and then reverted in 531d0a3.

If you're using Yarn you can work around this issue with:
  "resolutions": {
    "next/strip-ansi": "3.0.1"
  }

See: https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

@haydn thank you it worked really well. although it doesn't work in Development but it works like a charm in Production.

Applied a fix that didn't involve downgrading ansi-regex. It was being build into the production bundle, even though it wasn't being used (only in development). So this error is going in production mode. @iamsoorena has confirmed it works on slack 👍

In what version @timneutkens ?

@ptomasroos next@canary

@timneutkens doesn't seem to have been fixed in next@canary, still getting the ansiregex syntax error (arrow function) running with a custom server, so not sure if it's because of that?

@mattywong Did you try it on production environment?
because the problem haven't been resolved in development environment yet.

@timneutkens my bad, it's working fine now in production thanks!

So this still doesn't solve the "Fetch as Google / PageSpeed" problem. ie,
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fdeploy-preview-38--candidco.netlify.com%2F

The problem still persists.

Anyone, please help, I just migrated to next on the promise of good SEO and now everything is in the air :-(
I can't use the solution from @timneutkens as I am using  NPM.

I see that the Zeit.co website it's working properly! @rauchg what are you and your team doing in order it should work?

Next by itself doesn't need polyfills, but you're most likely using an external library does.
Example of basic Next.js:
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fcreate-next-example-app-fnevuusuhp.nextjs.org%2F&tab=mobile
The with-polyfills example shows how to configure polyfills as-needed:
https://github.com/zeit/next.js/tree/canary/examples/with-polyfills
Since you asked, this is the polyfills we add:
import fill from 'core-js/library/fn/array/virtual/fill'
import includes from 'core-js/library/fn/string/virtual/includes'
import repeat from 'core-js/library/fn/string/virtual/repeat'
import startsWith from 'core-js/library/fn/string/virtual/starts-with'
import assign from 'core-js/library/fn/object/assign'

// Some of the NPM packages we included, use following methods without polyfills.
// So, we need to include these polyfills.
// (This is only needed for IE11)
Array.prototype.fill = fill
String.prototype.includes = includes
String.prototype.repeat = repeat
String.prototype.startsWith = startsWith
Object.assign = assign

@timneutkens so basically every web app will need different polyfills in order to be supported in Chrome 41, the version that Google Bot uses?


Create a user authentication demo in nodejs fastify framework

Need to create a small user authentication demo using LoginRadius solution, Check our Demo Guidelines for how to make the authentication demo and Contributing Guidelines to know about the contribution flow.
Platform - NodeJS (latest stable  version)
Framework - Fastify (latest stable version)
Code Folder - https://github.com/LoginRadius/developer-authentication-demos/tree/master/demos/nodejs/fastify

I'll try to take it

Sure @GuyKh .  Also, do check out our hacktoberfest page to become eligible for swags from LoginRadius.

Thanks @ashish8947 -- already have


In extract aggregate, check GroupByKeys

In order for the aggregates to perform any operation, it is necessary that the GroupByKeys field be specified. However, nowhere in the code is it checked that this parameter was provided. If the field is left out, there is some anomalous behavior in the resulting output.

This is not completely correct. If we intend to use all the raw data in a prometheus histogram, then it might make sense to not group.


Update : Folder Structure

Related Issue
Issue Number #6
Proposed Changes

Change 1 : The folder structure has been reorganized based on Data Structure, Algorithm and STL (concept explanation separately)

Additional Info
Yet to confirm to include problem statement and solutions folder not, So, I have added it as ~problems~
Checklist

[ ] ✅ My code follows the code style of this project.
[ ] 📝 My change requires a change to the documentation.
[ ] 🎀 I have updated the documentation accordingly.
[X] 👀 I have read the CONTRIBUTING document.
[ ] ✨ I have added tests to cover my changes.
[ ] 🚩 All new and existing tests passed.
[ ] 🌟 ed the repo

I have reorganized the repo into proper folder structures.

It will help  learners and future contributors to access the project easily.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Output Screenshots

Screenshot #1
Screenshot #2

Title goes here
Title goes here

Image goes here
Image goes here

Looks Good , Create PR for the rest of changes 💯

@all-contributors please add @n4i9kita maintenance , ideas


Fix Pyserini compatibility issues

As discussed in #70, recent refactoring of Pyserini resulted in some module names changing.  This PR updates the compatibility issues in the BM25 reranker, relevance.py and segmentation.py.

@justinborromeo lemme know when I should review this!

@ronakice This is ready for review.  I opened a PR to fix the bm25 reranker but noticed additional issues when I was running the MSMarco document experiment.


update packages

:white_check_mark: Build TheIdServer 6.3.1-fix-dependencies1-0103 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/90b17ed4c5 by @)


Adding g4Web to g4run

Some working highlights for the entire g4web  based on collected data

Visualize the Diff and Raw Reports with appealing colours.
Apply Thresholds to cut down searching to some specific ranges.
Pre-loaded Flamegraphs
TreeMaps with suitable customizations
Scatter-Plot with suitable customizations
Spider Plot tool-tip skeliton ready over the scatter-plot dots.

I merged this as subtree to keep the commit history intact, this is why it shows the pull request as closed. Thanks for the great work!


Using local or session storage only when cookie enabled

What's the purpose of this pull request?
We were having some Sentry errors in Marin Brasil when the user disables the browser cookies. When the cookies are disabled, all the localStorage or sessionStorage features doesn't work and trigger some error logs.
How it works?
It checks the navigator.cookieEnabled property before each localStorage or sessionStorage feature.
How to test it?
Check each browser behavior in Marin Brasil. (Link WIP)
References

I did a PR in Order Manager as well.
We have this report here in Chromium.

I think all localStorage based storages could be replaced by an instance of a class we add to the window that internally makes the if cookiesEnabled check. The only place where this is impossible is on the failure recovery. All other places I think we could replace with this approach, what do you think?

I like this approach, but I'm not sure whats the better way to do it. How do you think we can name this and where?

I think all localStorage based storages could be replaced by an instance of a class we add to the window that internally makes the if cookiesEnabled check. The only place where this is impossible is on the failure recovery. All other places I think we could replace with this approach, what do you think?

@tlgimenes I like this approach, but I'm not sure whats the better way to do it. How do you think we can name this and where?
edit.: Something like window.validatedLocalStorage hahah idk really. But yeah, we don't need this for the sessionStorage since it's handled only for failure.
edit2.: I found this btw

I'm not sure how's the best way of doing this either, however I like being explicit always and overriding session/local storage seems to be a little magic. I'd go with creating a module called "storage" that can work with local/session/indexed db and you can chose which one you want. Also this would contain a fallback to the ram if these are not available. What do you think ?


Recommended timestamp format is not consistent with Syslog standard

Hi IoT Edge team,
The documentation recommends a timestamp format of "yyyy-mm-dd hh:mm:ss.fff zzz" and a Syslog format for Severity. Those are not really consistent with each other, which leads to some confusion. Also, the angle brackets make it appear that you really intend a Syslog Priority but if I understand correctly IoT Edge only looks at the Severity part of the Syslog Priority and doesn't expect the Facility part to be included. E.g., I assume IoT Edge expects <0> for "emergency" severity, and not something like <16> or <160> which is what a quick glance at the Syslog documentation (or familiarity with that standard) might lead someone to believe.
My recommendation would be to simply avoided mentioning Syslog and just copy the table of Syslog's Severity codes into the documentation to avoid any confusion. You can always add a footnote that the severity levels are derived from the Severity code in the Syslog standard.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3dedace3-fcb7-45b7-8bc1-11b5485d033a
Version Independent ID: 1af36bac-1b08-f493-285f-23b64f12c500
Content: Retrieve IoT Edge logs - Azure IoT Edge
Content Source: articles/iot-edge/how-to-retrieve-iot-edge-logs.md
Service: iot-edge
GitHub Login: @v-tcassi
Microsoft Alias: v-tcassi

@LarsKemmann
Thanks for your feedback! We will investigate and update as appropriate.

Hello @LarsKemmann
I have assigned the issue to the content author for further review and update the doc as appropriate.

Hello! I know this is an old GitHub issue, but I had some time to take care of it, and the changes are merged.
You should see the next doc publish around 3pm PST, and the changes will be reflected in that publish.
@LarsKemmann thanks for the feedback! If you have any additional comments, they'd be greatly appreciated. I'm not an expert on Syslog standard, so getting your input was invaluable for the accessibility of our docs.
#please-close


Update sdk for M4 change

Apply for https://github.com/Azure/autorest.csharp/pull/2834

API change check
API changes are not detected in this pull request.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.ResourceManager.ManagedServiceIdentities

This is a breaking change that we need to undo.

Not sure if it is the APIView issue, but if take a look at the change of source code, there is no breaking change.


Add latency1 paths to access controller

Adds /latency/v1/authorize and /latency/v1/result to the list of paths managed by the access controller.

This change is

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage remained the same at 84.327%

Files with Coverage Reduction
New Missed Lines
%

pkg/throughput1/protocol.go
4
84.75%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
764

Relevant Lines:
906

💛  - Coveralls


need to update for null safety

I close this issue because you have created a PR for this issue.
Thanks again!


[SwiftASTContext] Remove IsOptionalChain.

Unused, and unneeded. Found by inspection (when looking at stuffs that can be moved to RemoteMirrors).

@swift-ci test and merge

@swift-ci please test and merge

@swift-ci please test

@shahmishal on lldb PRs, please test works, but please test and merge doesn't.
Can you please take a look?

Code removal generally lgtm, provided we're not using the code internally.


Triggering scene_on without a state:on attribute causes HaSS to crash

Home Assistant release (hass --version):
0.30.0.dev0
Python release (python3 --version):
Python 3.4.2
Component/platform:
scene/turn_on
Description of problem:
Attempting to trigger a scene_on command to a scene which does not contain a state:on attribute (see below) causes a total failure of HaSS with nothing written to log. The front end applications stops responding and you get an infinite browser poll until the service is restarted.
Expected:
Something is written to the log and HaSS does not crash (or) scenes can be triggered without providing a state:on attribute.
Problem-relevant configuration.yaml entries and steps to reproduce:
- name: Frontroom Lights Default
  entities:
    light.kitchen_paper_lantern:
      #state: on
      xy_color: [0.457, 0.4098]
      brightness: 255
      color_temp: 362
    light.kitchen_sink_bulb:
      #state: on
      xy_color: [0.457, 0.4098]
      brightness: 255
      color_temp: 362
    light.piano_lamp:
      #state: on
      xy_color: [0.457, 0.4098]
      brightness: 255
      color_temp: 362

Additional info:
Using a Hue Bridge and Raspberry Pi 3 for this test.

Is this still a thing?


When 'react-dom' is used in shared the remote app itself breaks and no error is logged

Bug report
In shared if 'react-dom' is added the remote app itself breaks and no errors are logged
the module federation plugin config is:

exposed component is :

What is the current behavior?
On using ExposedRoutes component and adding 'react-dom' to shared the app breaks.
If the current behavior is a bug, please provide the steps to reproduce.
add exposedRoutes component in exposes and add 'react-dom' to shared.The remote app will break on client without any error on console.

What is the expected behavior?
Why only 'react-dom' is breaking the app and not any other dependency

Other relevant information:
webpack version:  5.4.0
Node.js version: 10.15.0
Operating System: mac os
Additional tools:

No reproducible steps - no answer

If the current behavior is a bug, please provide the steps to reproduce.
add exposedRoutes component in exposes and add 'react-dom' to shared.The remote app will break on client without any error on console.

We don't know your config, we don't know your code, we don't know your plugins, we nothing know

ok i will also shared the whole config


Add a phoron crate, a new requisitions tab and make phoron obtainable.

About the PR

Added a phoron crate, a new requisitions tab, Research and made phoron obtainable through requisitions.
Why / Balance

The phoron crate was ported so the items added in the future to the research tab for requisitions have their own crate to use, they use the phoron crate in CM13.
Made phoron obtainable through requisitions so the bars can be ordered and grinded for the Phoron reagent, it is needed to make some medicinal reagents.
Media

https://github.com/RMC-14/RMC-14/assets/75623951/1aac0567-2faa-4f75-a67f-d7ae3c020f56

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl:

add: Added a new requisition tab, Research.
tweak: Made phoron obtainable through requisitions.

Done,  made the changes requested, tested and they seem to work for me.

https://github.com/RMC-14/RMC-14/assets/75623951/fa8a6781-8488-4a53-bde9-8b6dacf938df


Questions on evaluation results

Dear Authors,
Firstly, I appreciate for your outstanding project.
I've been playing with your benchmark using the provided codebase, and noticed some discrepancies between the evaluation results I obtained and those reported in your paper.
Below is a comparative overview table of my evaluation results on the VG datasets and PRC tasks using COCO_order and Flickr30k_order:

model
pretrained
vg_relation
vg_attribution
coco_order
flickr30k_order
Task Avg.

ViT-B-32
openai
59.9%
63.2%
47.4%
58.8%
57.3%

NegCLIP
coco ft
80.2%
70.5%
86.8%
89.7%
81.8%

BLIP-base
flickr ft
49.7%
89.9%
42.5%
40.5%
55.7%

BLIP-base
coco ft
58.4%
89.5%
37.1%
46.3%
57.8%

I observed that my reproduced results for VG_Relation and VG_Attribution closely align with the numbers presented in your paper. However, I have concerns regarding the NegCLIP results for flickr30k_order, where a 91% (0.91) is reported in your paper (Appendix Table 6).
In addition, regarding the BLIP models, there seems to be a somewhat higher discrepancy.
In your paper from Appendix Table 5, the results reported are 0.369 for Flickr30k-PRC (BLIP-flickr-base) and 0.321 for COCO-PRC (BLIP-coco-base). In contrast, my results showed significantly higher scores of 40.5% and 37.1%, respectively, for the same models.
Note 1: I observed that some level of randomness arises when creating order annotations from the original annotation file. However, this randomness does not seem to cause the large gap observed.
Note 2: To account for the randomness, I maintained the same order annotations across different models in my experiments.
Given that these results were obtained using the provided codes and checkpoints, I would like to see any potential my mistakes or what was gone wrong by any reason.
Best regards,

I got the similar results with you.


Build error in master "Failed to parse source map from @nexucis/src/index.ts"

What did you do?
Cloned the latest version and executing
make build
What did you expect to see?
Successful build
What did you see instead? Under which circumstances?
Darwin X64, nvm version v16.15.0, node v16.15.0, npm version '8.5.5', go version go1.18.1 darwin/amd64
git clone https://github.com/prometheus/prometheus.git
cd prometheus
make build
...
Creating an optimized production build...
Compiled with warnings.
Failed to parse source map from<EMAIL_ADDRESS>file: Error: ENOENT: no such file or directory, open<EMAIL_ADDRESS>Search for the keywords to learn more about each warning.
To ignore, add // eslint-disable-next-line to the line before.
File sizes after gzip:
454.65 kB  build/static/js/main.7fd31b42.js
52.38 kB   build/static/css/main.faad45b4.css
The project was built assuming it is hosted at ./.
You can control this with the homepage field in your package.json.
The build folder is ready to be deployed.
Find out more about deployment here:
https://cra.link/deployment

bundling npm licenses
rm -f "npm_licenses.tar.bz2"
find web/ui/node_modules -iname "license*" | tar cfj "npm_licenses.tar.bz2" --transform 's/^/npm_licenses//' --files-from=-
tar: Option --transform is not supported
Usage:
List:    tar -tf
Extract: tar -xf
Create:  tar -cf  [filenames...]
Help:    tar --help
make: *** [npm_licenses] Error 1

System information
Darwin X64, nvm version v16.15.0, node v16.15.0, npm version '8.5.5', go version go1.18.1 darwin/amd64
Prometheus version
Master branch

Prometheus configuration file
No response
Alertmanager version
No response
Alertmanager configuration file
No response
Logs
No response

thanks for reporting this issue.
Even if it looks super bad it's actually more a warning than an error. So the build of the UI still work as expected.
That doesn't mean we shouldn't fix it, it's just less urgent

hmm, the @nexucis directory has no src/index.ts

maybe forget to ship it

Thanks @fatelei for the link. That was helpful :)
I read the different comments there and I think I will just remove the source map. That actually makes sense to remove it as I don't have the wish to put the source code in the package.


Optimize sort by date

This optimization is more important than it might look like. In particular it considerably improves
the AllQuery we run when reaching the UI screen, and the same logic could apply to tracing. (although we will have to replicate this logic)
The optim can be done on the leaf side (although it can be done on the root side in the case of the MatchAllQuery).
On the leaf side, if a leaf node has a lot of splits, it could for instance process the splits in the most recent order.
If a split about to be processed has max(timestamp) < current bottom k, we know it won't contribute to the top K.
We can disable the top K computation, hence removing the need to download the timestamp column.
If there are no aggregation, in the future we can also just run a count query.

[x] Avoid downlading the sorting field if K's top K = 0
[ ] Nullify K depending on the split metadata and previously processed splits.
[ ] Integrate a similar optim in tracing.

To complicate stuff a little more... In the future we might want to remove "accurate count", and let quickwit tell us "More than 10000 docs matching" for instance. Entire split could then be skipped.

Integrate a similar optim in tracing.

could you clarify? The jaeger interface either uses root_search which should benefit from the change anyway, and root_list_terms which isn't concerned by this optimization, so I think this comes free?


headers vs _headers

app.use((req, res) => {
  res.set('Logged-In', true);
  console.log('headers', res.headers);
  console.log('headers', res._headers);
}

is it expected behavior that res.headers does not show current state? even chaining middleware has the problem.

Hi @bdefore , we rely on the Node.js HTTP API and they do not provide any API (that's not private) to access the headers on the response object (https://nodejs.org/api/http.html#http_class_http_serverresponse). I don't think we have res.headers or res._headers in our documentation, unless I'm' mistaken somehow :)
Node.js is currently considering adding an API for this (that's not private) over at https://github.com/nodejs/node/issues/1873 if you want to chime in :)

thanks for the follow up @dougwilson ... it's a bit of a shame but good to hear you know of it.


Explain in GitHub issue template how to copy exact Godot version

Copying the exact version including the commit hash can be done with a single mouse click, it's worth mentioning in the issue template.
Rewording suggestions welcomed as always.

Thanks!


Fix deprecated scoring function

'log_loss' is deprecated; replaced by 'neg_log_loss'

Send this PR to the keras-2 branch instead.


Not allowing to select two elements at the same time.

Seeing, for example, the C and H chemical shifts at the same time is invaluable for assigning a CH correlation spectrum.
It's possible that other workflows including CIF labels circumvent this issue, however.
Expanding on issue raised by @AKM2022

I think that the selection controls:
CLICK to select an atom/element/etc.
SHIFT+CLICK to add to the current selection
CTRL+CLICK to add or remove (XOR) from the current selection

already allow the desired behaviour, so this issue can be closed.


[GHSA-78wr-2p64-hpwj] Apache Commons IO: Possible denial of service attack on untrusted input to XmlStreamReader

Updates

CVSS v3
CVSS v4
Severity

Comments
No NVD assessments currently available, maintainers self assessed as low per https://lists.apache.org/thread/6ozr91rr9cj5lm0zyhv30bsp317hk5z1

Hi @wwwjames, although there is currently no CVSS assessment provided by the assigning CVE Numbering Authority or another data source such as NVD or CISA ADP, the advisory description is clear that the vulnerability leads the software to excessively consume CPU resources, which typically has a high availability impact. Because the description hasn't indicated the vulnerability has a limited availability impact, it's appropriate to assess that denial of service or high availability impact is possible. In this case, it's not appropriate to say the vulnerability has no impact on software availability. Therefore, I'm closing the PR and not accepting the contribution. Thank you for your interest in GHSA-78wr-2p64-hpwj and have a good day.


Failed to match first line: ???

Trying to use this with mymonero app but can't find the way how to bypass this error:

Although, calling the API manually seems to be working.
Can't figure out why in mymonero case it doesn't work, any ideas?

What is the value for --rest-server ? Default?

monero-lws-daemon --rest-server http://<IP_ADDRESS>:8443 --confirm-external-bind

MyMonero app is trying to initiate a SSL connection, whereas monero-lws is immediately looking for a HTTP header. Starting with --rest-server https://<IP_ADDRESS>:8443 will listen for SSL connections, but MyMonero app will likely reject unless you have a CA-signed (LetEncrypt, etc.) certificate.
Try:

Listening for HTTPS connections to see how MyMonero app responds (override possible in UI?).
See if MyMonero app accepts http:// as a server input. I used to do this, but things have changed a bit since I last tried. I might need to download latest version myself. I think it may assume HTTPS, and only the hostname is configurable (I was changing the build itself).
Ask MyMonero to somehow make this configurable.
Get a signed cert.

The last points (3)&(4) are regrettable, but if MyMonero app requires HTTPS with a signed-certificate there is no code fix in monero-lws to get it working.

There's also DANE/TLSA. That would allow self-signed SSL certificates with fingerprints put in DNSSEC records. I think the OpenAlias support is client side, so MyMonero should already have DNSSEC support in clients. But adding DANE/TLSA is a bit more heavy lifting than they really want (there is no use for them directly).

Thanks for very detailed answer!
I've looked into mymonero codebase and it seems you're correct - they are stripping http(s):// prefix and forces to use https:// under the hood.
Although this SSL topic is pretty foggy to me I had a success with a self-signed certificate from desktop client of mymonero. But not yet from the iOS version - having difficulties trusting the certificate, need to read more on that.
Anyway, thanks for the help! much appreciated! 🍻

Hi @dzonatan
Can you summarise or point me in the direction you took for monero-lws to accept a certificate when using MyMonero desktop please?
I've messed around with SSL for web pages in the past, but using them to get applications talking is new to me. Need a little nudge.

@shermand100

You need a key and certificate. You can generate both of them using openssl through command line which can be a bit overwhelming to do if you haven't done it before. But you can find tutorials online.
The certificate needs to be self-trusted on machine where MyMonero will be used. Not sure what OS you use but again there are plenty of tutorials online how it can be done.

1 and 2 points can be done using https://github.com/FiloSottile/mkcert, although I haven't used it myself.

Start the daemon with ssl arguments:
monero-lws-daemon --rest-ssl-key my-cert.key rest-ssl-certificate my-cert.crt

@shermand100 You could Search GitHub for EasyRSA there are plenty of options to choose from.


Update README.md

https://circleci.com/gh/sabeurthabti/react-native-css/60
new version is<EMAIL_ADDRESS>

thank you so much :D


add alacritty

Motivation for this change
Add alacritty.
This package will only build once https://github.com/NixOS/nixpkgs/pull/21800 is merged

@globin some love?

Should we make hydra build this package?  Right now we don't build rustNightly (or rustBeta), see #18111.  cc @the-kenny

I was unable to build locally due to the Rust compiler stopping compilation with:

udp_clone_smoke has been running for over 60 seconds

But was able to build by overriding it with rustPlatform = (makeRustPlatform rustNightlyBin); - tried it out, it runs well!

@puffnfresh i suspect that this happens because this branch is not rebased onto the latest master.
I just rebased and force pushed it and will try the build again myself.

@puffnfresh just tried it with this branch on top of the current master and rust beta, rust nightly and alacritty build without issues

I can't seem to build either, I'm getting this: https://gist.github.com/jb55/7c438c1ecbb6ee34551aeb771e4841fe

@jb55 you are not building from the right branch, the nightly version this is trying to build is way too old.
did you forget to "git pull" your master or something?

oops looks like my nixpkgs was dirty and had stuff in staging area. retrying now

works great :+1:

I'm getting the same UDP test problems so it must be something to do with my system.

@puffnfresh what operating system do you use? I had problems with failing udp tests on debian in a nix-user-chroot, but not on nixos.

@Mic92 I use NixOS

@puffnfresh @Mic92 could you check out the latest master and try again? I am wondering if this was an issue with the parallel/codegen PR that has been reverted 3 days ago

I merged master into this branch and tried to build but I got the hang again:

test net::udp::tests::udp_clone_smoke has been running for over 60 seconds

@puffnfresh this seems like a bug that might be worth raising as a separate issue.

sandbox build failed because a dependency was attempt to download from git.
warning: custom registry support via the `registry.index` configuration is being removed, thisfunctionality will not work in the future
    Updating git repository `https://github.com/jwilm/glutin`
error: failed to load source for a dependency on `glutin`

@Mic92 this happens because alacritty uses a git-dependency of glutin. Not supported (yet?) on our build infrastructure. I think this error is caused by cargo not downloading git repositories in a non-deterministic way.
One would need to pin that revision and provide a separate fetchgit to download it. Alternative would be fixing cargo to use git archive or something instead of just cloning the repo.

@the-kenny actually buildRustPackage support that, but it seems that cargo tries to update the pre-fetched git repository.

Hmm, termite is now marked broken, so I am very interested in seeing this finished :).

I'd also like to use alacritty, but what's the status of this? #21800 has been merged, but I don't think this works regardless?
If I build manually, having added the dependencies to my configuration.nix, I have the issue described in jwilm/alacritty#275 - but the solution there of adding a directory to $LD_LIBRARY_PATH is no good, since the directory doesn't exist on my system...

After this applying this patch:
diff --git a/pkgs/applications/misc/alacritty/default.nix b/pkgs/applications/misc/alacritty/default.nix
index ec312ed..952bcda 100644
--- a/pkgs/applications/misc/alacritty/default.nix
+++ b/pkgs/applications/misc/alacritty/default.nix
@@ -7,13 +7,13 @@ buildRustPackage rec {
   name = "alacritty-unstable-${version}";
   version = "2017-01-07";

-  depsSha256 = "138bfnrg3j49vl6j2daf1jyyng5r6d088qhsqikhyyqzjx1ih0v2";
+  depsSha256 = "1yv7nhppixgf62yy3is8wlbcpsgid3qjwp2aaj54c456k4gzhxpd";

   src = fetchFromGitHub {
     owner = "jwilm";
     repo = "alacritty";
-    rev = "f4b10a1dbb991861a84c5085a0ee4384d2377448";
-    sha256 = "044l5s1w2g5krngr1v4lfxv7smh6wzy9zrabnihnpf1bsg6q73nb";
+    rev = "59295e44312b3936132965636e5fac92118e5c27";
+    sha256 = "0jk0nyc8v4ky1riyfbv1z52a35zhiaspggmzqxpggbq7vnsbirx1";
   };

   nativeBuildInputs = [
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index be9b1f0..78b3564 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -380,7 +380,6 @@ with pkgs;

   alacritty = callPackage ../applications/misc/alacritty {
     inherit (xorg) libXcursor libXxf86vm libXi;
-    rustPlatform = (makeRustPlatform rustNightly);
   };

   amazon-glacier-cmd-interface = callPackage ../tools/backup/amazon-glacier-cmd-interface { };
diff --git a/pkgs/top-level/rust-packages.nix b/pkgs/top-level/rust-packages.nix
index e35153a..db067a1 100644
--- a/pkgs/top-level/rust-packages.nix
+++ b/pkgs/top-level/rust-packages.nix
@@ -7,9 +7,9 @@
 { runCommand, fetchFromGitHub, git }:

 let
-  version = "2017-01-27";
-  rev = "6a73a15e27364a0c191d61d52406bebb7639b657";
-  sha256 = "1dklswbf3acfqid4vv7g2xpqc4gswjgh4ih9xjx3a0m3a69cw9lb";
+  version = "2017-02-07";
+  rev = "e56dbd2ee8dbcc29b8c72586bff64a99268fecf3";
+  sha256 = "0n69ia1r67p9dgrhagrlii9n6wqqasbb1ggma90mawfmvfr7ay7c";

   src = fetchFromGitHub {
       inherit rev;

I'm seeing:
Using cargo deps from /nix/store/0hm0mfx0m7c8477yn1gp1llh8rk9mmi5-alacritty-unstable-2017-01-07-fetch
Using indexHash '-ba82b75dd6681d6f'
Using rust registry from /nix/store/11lvmj2525ri3g3s2xsfggxaq8sb1wsk-rustRegistry-2017-02-07-e56dbd2
warning: custom registry support via the `registry.index` configuration is being removed, this functionality will not work in the future
    Updating git repository `https://github.com/jwilm/glutin`
warning: spurious network error (2 tries remaining): [12/-1] curl error: Couldn't resolve host 'github.com'

warning: spurious network error (1 tries remaining): [12/-1] curl error: Couldn't resolve host 'github.com'

error: failed to load source for a dependency on `glutin`

Caused by:
  Unable to update https://github.com/jwilm/glutin?rev=af7fe340bd4a2af53ea521defcb4f377cdc588cf#af7fe340

Caused by:
  failed to fetch into /tmp/nix-build-alacritty-unstable-2017-01-07.drv-0/deps/git/db/glutin-2b5ecc80feb2e4c5

To learn more, run the command again with --verbose.
builder for ‘/nix/store/hfx0vyils7fi6hp327alv7v8j5pr4p4q-alacritty-unstable-2017-01-07.drv’ failed with exit code 101
error: build of ‘/nix/store/hfx0vyils7fi6hp327alv7v8j5pr4p4q-alacritty-unstable-2017-01-07.drv’ failed

any update?

I didn't check open PRs before packaging it on my own: https://gist.github.com/gilligan/63d4d4832fae996f3225cb59345c689e
It is working just fine for me on NixOS.

@gilligan, do you have any progress?

The following works for me: default.nix
I used stable rust instead of nightly:
alacritty = callPackage ../applications/misc/alacritty {
  inherit (xorg) libXcursor libXxf86vm libXi;
};

@trizinix Building that with the sandbox enabled, I got:
warning: custom registry support via the `registry.index` configuration is being removed, this functionality will not work in the future
    Updating git repository `https://github.com/jwilm/glutin`
warning: spurious network error (2 tries remaining): [12/-1] curl error: Couldn't resolve host 'github.com'

warning: spurious network error (1 tries remaining): [12/-1] curl error: Couldn't resolve host 'github.com'

error: failed to load source for a dependency on `glutin`

Caused by:
  Unable to update https://github.com/jwilm/glutin?rev=cc64178d39a1fa06b2c5403117e5e0ef24deeac4#cc64178d

Caused by:
  failed to fetch into /tmp/nix-build-alacritty-0.1.0.drv-0/deps/git/db/glutin-2b5ecc80feb2e4c5

@grahamc This issue is blocked by jwilm/alacritty#234. Alacritty depends on a fork of glutin, as specified in Cargo.toml. Cargo tries to fetch the glutin dependency from github during build time, which fails in the sandbox. As a workaround we could download glutin before the build-phase and then modify Cargo.toml accordingly.

@trizinix I just tried doing that, but I couldn't get it to work. Does buildRustPackage not handle the patches and postPatchPhase attributes in a normal way?

@therealpxc cargo runs before the patch phase. You can patch it like this: https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/exa/default.nix#L47

Thanks, @mic92 . Now I've implemented a temporary workaround on my machine parallel to the one they use in the exa package. But there's another problem: jwilm's custom glutin fork also uses git dependencies, so now I get the same failure because glutin depends on jwilm/rust-fontconfig. That version of fontconfig further depends on jwilm/libfontconfig, also specified as a git dependency in its Cargo.toml file.
What can we do to patch the additional sources? Can we still define them using fetchFromGitHub or do we need real derivations now, since we have to patch them?

@therealpxc this was also the showstopper for me. I hope that https://github.com/NixOS/nixpkgs/pull/24991 will handle git support at some point.


DbFunctions documentation missing methods

The documentation for methods in DbFunctions seems to be missing a few methods, such as DateFromParts, TimeFromParts, SmallDateTimeFromParts, DataLength.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c516f9eb-928c-2f34-63e1-2285f2c524e5
Version Independent ID: 27061b6e-0ab1-de5a-d03d-d7cbd2a2618e
Content: DbFunctions Class (Microsoft.EntityFrameworkCore)
Content Source: dotnet/xml/Microsoft.EntityFrameworkCore/DbFunctions.xml
Product: entity-framework-core
GitHub Login: @dotnet-bot
Microsoft Alias: divega

@NetMage API docs are typically not updated until the RTM release, at which point they are generated from the doc comments in the code.

Thank you, I didn't realize it was a future feature.


TLS troubleshooting and migration guide

As part of the Fastly TLS deprecation, RubyGems.org is going to lose the ability to allow TLS v1.0 and v1.1. A few weeks ago, Fastly disabled TLS v1.0 and v1.1 for us as part of their plan, and we discovered that a lot of Ruby users still aren't able to use TLS v1.2 yet. Unfortunately, the older versions of TLS have known problems that make them insecure.
We would like to migrate everyone, and Fastly is going to force all of their customers to migrate no later than April 2018. We plan to disable older TLS versions in January 2018, with the goal of releasing a new version with a warning that explains how to fix the problem it at least 3 months in advance.
In order to be able to use TLS v1.2, users need to be using OpenSSL version 1.0.1 or later (first released March 14, 2012). Then, they need to make sure that they are using a version of Ruby that includes OpenSSL support, and binds against OpenSSL 1.0.1 or later. Unfortunately, there are a lot of ways that can be messed up, and problems with OpenSSL versions can interact with problems with certificates, sometimes making it hard to tell exactly where the problem lies.
I am currently imagining that our explanation of the problem and possible solutions will take the form of a guide on the Bundler website. I'm hoping we can create a page that explains what the problem is, why we are changing things, and how to update the OpenSSL library and/or Ruby to fix the problem. Then, we can link to that page from the warning that we print when Bundler is used on a version of Ruby that will not be able to connect to RubyGems.org after the change.
Separate from the migration to TLS v1.2, but related in that it causes a similar problem is general SSL and certificate issues. On the whole, even without the TLS version change, these have been the source of a lot of trouble. rubygems/rubygems#1758 is a great example of the kinds of problems that people have with SSL in general, and the kinds of things that they need to do to get it working again. We have a RubyGems guide to solving SSL problems, but it seems to be insufficient based on how many people still open new issues or comment on old ones like the ticket I linked above. The source for the RubyGems SSL guide is in the rubygems/guides repo in this file.
Another super helpful resource that I refer to a lot while troubleshooting SSL problems with Ruby is Mislav's guide to Ruby and SSL. It's a good explanation of the kinds of problems that Ruby devs often see with SSL (although it doesn't mention the TLS version migration, because that is a newer problem than the guide). He also wrote a Ruby to help debug SSL issues, which is another helpful resource.
In the Bundler guide, we'll probably need to not only explain the TLS v1.2 migration, but also include most of the information from the RubyGems guide (and even additional information above and beyond that guide, like what users reported in that ticket). I'm sure users having any kind of SSL problem will end up checking out our guide, and if we can successfully help them solve their own problems, that will be a huge win.
I'm sure you'll have questions once you start tackling this, feel free to ask here or ping me in Slack for more details. Thanks!

Hey!
So I've started reading all of the supporting material and I think I'm ready to get started. Here are a few q's:

It sounds like we want to incorporate this guide into the new Bundler guide: SSL Cert Update
The steps outlined in that guide are as follows:

Step 1: Obtain new trust certificate
Step 2: Locate RubyGems cert directory in installation
Step 3: Copy new trust certificate

Is this guide^^^ a prerequisite to the Bundler migration guide (as in, should we link out to it), or are we trying to incorporate the above guide into this new, Bundler migration guide?

You mention how “In order to use TLS v1.2, users need to be using OpenSSL version 1.0.1 or later and to ensure they are using a version of Ruby that includes OpenSSL support. This sounds like the first step in the process. Can you outline what this actually looks like in terms of actions users need to take to do this? (bullet list is fine: i.e. Step 1, use this command in your CLI to check OpenSSL version, step 2, if you’re using v1.x go to [website] to download new version, etc etc). I’ll in turn flesh these out in the guide.

What are the Bundler-specific steps and commands we want for the migration?

I think once I have the above information, I can start taking a stab on a first draft for you and the team to review, provided other q’s don’t come up when I get your responses!

I thought of a few more @indirect:

How much explaining do we have to do of how TLS certs work with gems beforehand? (I'm guessing the guide itself won't be the best place for this, but is this a source of confusion in and of itself?)

Are there FAQ that this guide must answer? I know we want it to touch the points you've raised in the issue, but are there specific questions that might be easily missed that we didn't include here? Thx again!

@rubymorillo here you go!

Is [the SSL Cert Update Guide] a prerequisite to the Bundler migration guide (as in, should we link out to it), or are we trying to incorporate the above guide into this new, Bundler migration guide?

It is not a prerequisite. I expect that users who are having trouble with an old OpenSSL version are also likely to have trouble with their SSL certs, and therefore need that guide as well. As a result, I think we should either refer them to that guide or preferably update that guide and include it (as an optional aside) in the new TLS migration guide.
In an ideal world, the issues that the SSL Cert Guide tries to help with would always be solved by installing the latest Bundler or RubyGems. For complicated reasons, sometimes that isn’t enough, and we’ve basically written that guide by combining all of the troubleshooting steps that people report have helped them. There are several new suggestions that we would like to add to the SSL cert guide as we update it, mostly reported by people in this thread: rubygems/rubygems#1758

You mention how “In order to use TLS v1.2, users need to be using OpenSSL version 1.0.1 or later and to ensure they are using a version of Ruby that includes OpenSSL support. This sounds like the first step in the process. Can you outline what this actually looks like in terms of actions users need to take to do this?

Unfortunately, it varies wildly depending on not just the exact OS that a user is running, but also how they have installed both Ruby and OpenSSL. :( For example, I can give you steps for someone on a Mac, who installed OpenSSL with Homebrew, and then installed Ruby with ruby-install. There are completely separate steps for someone on a Mac who used RVM to install Ruby. We’re probably going to need to create a huge list of the many ways to update your OpenSSL and then recompile Ruby, and I don’t know the specific steps needed for most of the possible combinations.
Off the top of my head, I expect people will ask us for instructions for each combination of:

operating system, which could be: macOS, Windows, Debian/Ubuntu, Fedora/RedHat/CentOS, Arch, Gentoo, maybe even FreeBSD
ruby installation method, which could be: OS package manager, rvm, ruby-build, ruby-install, pik, RubyInstaller2, compiled from source
openssl installation method, which could be: OS package manager, rvm, ruby-build, compiled from source

As you can see, that’s… a lot of possibilities. Maybe more than a hundred. 😬 I don’t think it’s realistic for us to write and test that many combinations, so here are the ones that I think we will need to be able to announce the migration:

macOS with ruby+openssl from rvm
macOS with ruby+openssl rbenv/ruby-build
macOS with ruby from chruby/ruby-install and openssl from homebrew
Debian/Ubuntu with ruby+openssl from rvm
Debian/Ubuntu with ruby+openssl from rbenv/ruby-build
Fedora/RedHat/CentOS with ruby+openssl from rvm
Fedora/RedHat/CentOS with ruby+openssl from rbenv/ruby-build
Windows with ruby+openssl from RubyInstaller

I can give individual steps for some of those, but we’ll probably need to make it a team effort across the entire Bundler+RubyGems teams to figure out the steps for all of those options.

What are the Bundler-specific steps and commands we want for the migration?

Sadly, there aren’t any. Bundler is entirely at the mercy of Ruby and OpenSSL about whether it will be able to connect to RubyGems.org after the cutoff date.

How much explaining do we have to do of how TLS certs work with gems beforehand? (I'm guessing the guide itself won't be the best place for this, but is this a source of confusion in and of itself?)

It seems like this is a source of confusion, yes, and I would love to include a section or aside or optional secondary guide that explains this.

Are there FAQ that this guide must answer? I know we want it to touch the points you've raised in the issue, but are there specific questions that might be easily missed that we didn't include here? Thx again!

My imagined FAQ goes like this:
What’s happening?
RubyGems.org will be requiring TLS v1.2 or higher in January 2018.
What does that mean?
It means that installing gems using gem install or bundle install will require that your Ruby installation be able to use TLS v1.2. The TLS v1.2 protocol is provided by the OpenSSL gem, which uses the OpenSSL library written in C.
Why are you doing this so abruptly?
We don’t think it’s abrupt. OpenSSL has supported TLS v1.2 since March 2012. Versions 1.0 and 1.1 have been shown repeatedly to be dangerously insecure, and it’s not safe to use them anymore.
This means I can’t install gems!
If you are using a Ruby linked against OpenSSL from before March 2012, we’re providing a community-maintained guide to help you upgrade. If the guide doesn’t work for you, please open a ticket and we’ll try to help you.
Your guide doesn’t work for me!
That’s not a question, but we would be happy to help you if you open a new ticket at <some repo>, and provide the following information:
Operating system and version:
Ruby version:
RubyGems version:
Bundler version:
Output from running ruby -ropenssl -e 'puts OpenSSL::OPENSSL_LIBRARY_VERSION':
Ruby version manager (if any):
OpenSSL installed from (if any):

Hey hey @indirect!
Thanks for this!! It gives me a lot of context. For next steps on my end, here's what I'll do:

Craft an intro based on the imagined FAQ above ^^^
Include a link to the SSL cert guide in the TLS migration guides (Separately, it sounds like the SSL guide should get updated once we create this one, but if you think it's the other way around, let me know.)

What we'll need is:

From the team. Figuring out who will be the right people to add steps to each of the following, and get them to send us this information (perhaps as a comment in this issue):

macOS with ruby+openssl from rvm
macOS with ruby+openssl rbenv/ruby-build
macOS with ruby from chruby/ruby-install and openssl from homebrew
Debian/Ubuntu with ruby+openssl from rvm
Debian/Ubuntu with ruby+openssl from rbenv/ruby-build
Fedora/RedHat/CentOS with ruby+openssl from rvm
Fedora/RedHat/CentOS with ruby+openssl from rbenv/ruby-build
Windows with ruby+openssl from RubyInstaller

From you. More info about this:

How much explaining do we have to do of how TLS certs work with gems beforehand?

Let me know if there's anything I'm missing. Feel free to send me whatever information you can and I'll fill those sections in in the meanwhile 😄. I'll work on an outline and will send to you either tomorrow or Wednesday when I'm done.

@indirect here's the outline:
Introduction

2-3 sentences about Fastly deprecating older versions and what this means for RubyGems

Date when RubyGems.org will move over to TLSv1.2 and up
What this looks like

What prerequisites they should have (i.e. Ruby, rvm, rbenv, OpenSSL versions, etc)
Mention the setups covered in this guide
A separation section (like a separate, blue box) that gives some background into how TLS certs work with gems.

Instructions by setup (we should also specify OS versions, if possible)

macOS with ruby+openssl from rvm

macOS with ruby+openssl rbenv/ruby-build

macOS with ruby from chruby/ruby-install and openssl from homebrew

Debian/Ubuntu with ruby+openssl from rvm

Debian/Ubuntu with ruby+openssl from rbenv/ruby-build

Fedora/RedHat/CentOS with ruby+openssl from rvm

Fedora/RedHat/CentOS with ruby+openssl from rbenv/ruby-build

Windows with ruby+openssl from RubyInstaller

What if my setup isn’t covered here?

Direct folks to where they can open a ticket [repo here] and include the following info:

Ruby version:
RubyGems version:
Bundler version:
Output from running ruby -ropenssl -e 'puts OpenSSL::OPENSSL_LIBRARY_VERSION':
Ruby version manager (if any):
OpenSSL installed from (if any):

Next steps (link out to additional resources they should look at)

The SSL guide, why they might want to update that as well, and link to the guide
Anything else?

Let me know what your thoughts are and if you think this rough outline covers what we need!

Hey @indirect I've an update!
So I've made inroads with the SSL guide updates. I'll send you the working doc for that separately.
Here's what I've done:

Separated out the actual tutorial/guide sections from the background sections. I propose we turn the "background" and "specific problems with RubyGems" sections into an article which we can reference in the guide. Since most folks just want to know how to solve the problem, leaving those sections might add more friction. I've formatted it that way in the Google doc.
Cleaned up the language to make it easier to read.
Added comments in the areas that we need more clarification. I've also added some sentences and want to get someone to look at them for technical accuracy.
Added a few of the community-sourced solutions we saw here. It would be great to get your eyes and @duckinator 's to ensure that we have the correct solutions in there. A few in the issue were referenced directly in other comments or had emojis which I took as a vote of confidence, but a few others didn't appear to have been tested out by anyone. So having a set of eyes on that would be great!

In short, next steps:

Get your eyes on the doc to ensure language looks good, the added content is technically accurate, and that we're featuring the community-sourced solutions that were tested out by other users.

I'll send you the doc in short order.
Thanks!

@rubymorillo That outline for the TLS guide looks great! After seeing the list of combinations written down, I think we'll need to adjust it:

macOS built-in ruby (solve by upgrading macOS to 10.13 High Sierra, not yet released)
macOS with ruby from chruby/ruby-install and openssl from homebrew (solve by upgrading openssl with homebrew)
any OS with ruby+openssl from rvm (solve with rvm implode and reinstall rvm)
any OS with ruby+openssl rbenv/ruby-build (solve by removing and reinstalling rubies)
debian/ubuntu with ruby installed from apt (I assume upgrade ruby and openssl with apt, but I haven't tested. I think @BanzaiMan can tell us how Travis did this.)
fedora/redhat/centos with ruby install from yum (I assume upgrade ruby and openssl with yum, but I don't actually know.)
Windows with ruby+openssl from RubyInstaller (solve by removing ruby and reinstalling with RubyInstaller)

Should I try to set up a server that only uses TLS 1.2+, and write a program that tries to connect to said server and tells you whether or not your version of Ruby + OpenSSL are compatible?
Also, you're doing fantastic work, @rubymorillo!

@duckinator You don't nessesarily need to setup a server to check if Ruby + OpenSSL supports TLS 1.2. There are several ways to inspect the supported versions of TLS in the openssl library.
Ruby 1.9.3
irb(main):01:0> OpenSSL::SSL::SSLContext::METHODS
=> [:TLSv1, :TLSv1_server, :TLSv1_client, :SSLv3, :SSLv3_server, :SSLv3_client, :SSLv23, :SSLv23_server, :SSLv23_client]

irb(main):02:0> OpenSSL::SSL::SSLContext.new(:TLSv1_2)
ArgumentError: unknown SSL method `TLSv1_2'.
        from (irb):14:in `initialize'
        from (irb):14:in `new'
        from (irb):14
        from /usr/local/bin/irb:12:in `<main>'

Ruby 2.4.1
irb(main):003:0> OpenSSL::SSL::SSLContext::METHODS
=> [:TLSv1, :TLSv1_server, :TLSv1_client, :TLSv1_2, :TLSv1_2_server, :TLSv1_2_client, :TLSv1_1, :TLSv1_1_server, :TLSv1_1_client, :SSLv2, :SSLv2_server, :SSLv2_client, :SSLv3, :SSLv3_server, :SSLv3_client, :SSLv23, :SSLv23_server, :SSLv23_client]

irb(main):002:0> OpenSSL::SSL::SSLContext.new(:TLSv1_2)
=> #<OpenSSL::SSL::SSLContext:0x007f9754037f80 @cert=nil, @key=nil, @client_ca=nil, @ca_file=nil, @ca_path=nil, @timeout=nil, @verify_mode=nil, @verify_depth=nil, @renegotiation_cb=nil, @verify_callback=nil, @cert_store=nil, @extra_chain_cert=nil, @client_cert_cb=nil, @session_id_context=nil, @tmp_dh_callback=nil, @session_get_cb=nil, @session_new_cb=nil, @session_remove_cb=nil, @tmp_ecdh_callback=nil, @servername_cb=nil, @npn_protocols=nil, @alpn_protocols=nil, @alpn_select_cb=nil, @npn_select_cb=nil>

This will let write a simple script to check if TLS 1.2 supported in the ruby env.

@colby-swandale thanks for the tip!
So, basically, this:
#!/usr/bin/env ruby

require 'openssl'

def supports_tls_1_2?
  OpenSSL::SSL::SSLContext::METHODS.include?(:TLSv1_2)
end

puts "TLS v1.2 support: #{supports_tls_1_2?}"

I uploaded it to a pastebin, so now you can do the Bad Thing™ and execute arbitrary code from the internet:
$ curl -s sprunge.us/jiRd | ruby
TLS 1.2 support: true
$ wget -qO- sprunge.us/jiRd | ruby
TLS 1.2 support: true
$

Yay @duckinator! Are we cool with me adding this in the guide somehow, prefacing that they can use this script to check whether or not a user's version of Ruby + OpenSSL is compatible? (And if so, is the pastebin link going to be permanent?)

Maybe it would be better to suggest that users run ruby -ropenssl -e 'puts "TLS v1.2 support: #{OpenSSL::SSL::SSLContext::METHODS.include?(:TLSv1_2)}"' instead of the curl | ruby ?

i agree with @segiddins

Just so I'm clear about sequence, we'd want users to run this script^^^^ after they've followed the guides to ensure their Ruby & OpenSSL versions are compatible, not before. Is that correct? @segiddins @colby-swandale @duckinator

@rubymorillo I think we would want to use it as a before-and-after check. If you're having problems, run that snippet to see if your problem is that you need to upgrade OpenSSL for TLSv1.2. If that code prints true, the problem is not that they need to upgrade to get TLSv1.2 support.
If that code prints false, the reader should follow the upgrade guide and then run the snippet again to verify that they have updated OpenSSL successfully.

Hey @BanzaiMan, can you confirm the Debian/Ubuntu instructions for troubleshooting the TLS issue is to upgrade Ruby and OpenSSL w/apt? See comment here for more context: https://github.com/bundler/bundler/issues/5687#issuecomment-308252104

@indirect perf, that's what I initially thought, too. Sounds good!

@segiddins replaced the part of my comment that suggested doing curl | ruby with a link to your comment.

@indirect can this be closed?


Newer CUDA versions in ACI?

This wording can be misunderstood:

We support CUDA 9.0 at this stage. For example, you can use following base images for your Docker file:

nvidia/cuda:9.0-base-ubuntu16.04

Does that mean it isn't possible to use a newer CUDA version as base image, such as nvidia/cuda:10.2-base-ubuntu16.04 for a container, and run GPU workloads in ACI?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 87729a5b-eda2-985e-678a-45498839f6b8
Version Independent ID: 8ce5224f-6b82-73e7-15dd-32a146c6ad53
Content: Deploy GPU-enabled container instance - Azure Container Instances
Content Source: articles/container-instances/container-instances-gpu.md
Service: container-instances
GitHub Login: @dlepow
Microsoft Alias: danlep

@martinnormark
Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate.

@dlepow
Can you please check and add your comments on this.

@macolso - Do you have updated info on whether ACI GPU resources support CUDA >9.0? Thank you

@martinnormark - Apologies for slow response. Yes, currently only CUDA 9 is supported for ACI GPU resources, which are in preview. I updated wording to state "only" to clarify. There is a current user feedback item you can upvote to provide support for more recent CUDA versions such as CUDA 10: https://feedback.azure.com/forums/602224-azure-container-instances/suggestions/38200546-support-cuda-10
I hope this helps. Closing this issue for now.
#please close

@dlepow thanks for clarifying, I will upvote the user voice post.

As the uservoice site has been closed and the link above is dead... Any update on this? Would love to be able to run a more recent version of CUDA on ACI. I would love to be able to run (for example) a more recent version of ONNX in ACI...

any updates mates?

Hello! ACI now supports through CUDA 11. The documentation is in the process of being updated.


Support From & To annotations

Is your feature request related to a problem? Please describe.
Running the Controller in the Operator mode and using an Nginx Ingress that DOESN'T terminate SSL (e.g. using an AWS ALB that handles that), requires not using an SSL block in the Ingress definition and hence the need to manually state the From piece of the policy.
Also we might need to get rid of the Nginx auth-url and auth-signin in favor of routing the traffic to the Pomerium proxy service (happily I can explain the main reason separately in a comment) and for that one would need the To piece.
Describe the solution you'd like
I would like to see the Ingress Controller supporting the following annotations:

ingress.pomerium.io/from
ingress.pomerium.io/to

Describe alternatives you've considered
Keep running the Operator and even forking and changing it beyond the deprecation notice from the project .. Currently we are running EKS v1.21 and we know that the Operator would stop working starting v1.22, however, if it needs be, we will fork it and change it because so far it has been doing a great job to be honest and the migration to the Ingress Controller isn't / wasn't trivial as the docs stated.
Explain any additional use-cases
Nothing.
Additional context
Nothing.

Running the Controller in the Operator mode and using an Nginx Ingress that DOESN'T terminate SSL (e.g. using an AWS ALB that handles that), requires not using an SSL block in the Ingress definition and hence the need to manually state the From piece of the policy.

Can you elaborate on this?  I'm afraid I'm not following the use case and why you'd need to manually specify a from.  The from is implicit in the host parameter of an ingress rule, and the to is implicit in the backend of the path definition.  Why would you want them to be different than what the ingress is actually specifying?  Maybe a concrete example would help clarify.

@travisgroth well I can try to explain .. but thinking about it again it might not be that of a great value to pursue this issue further ..

Regarding the from part of the older Operator behavior was that if you were using an Ingress without a TLS (if an external Load Balancer is handling the TLS termination) the rule always gave 401 and we had to explicitly state a From to https://app.mydomain.com. I think this is not the case anymore with the Controller, as I re-tested that a couple of times. So the From piece can be discarded.
Regarding the to part => as a workaround for the infinite redirects and using a Forward Auth with Nginx (auth-url and auth-signin) we found that if the Ingress intended to be secured can directly go to the pomerium-proxy service, everything works like a charm and one would see a correct 403 so we used that as a good workaround for the infinite redirects issue. In that case one would need to explicitly define to in order to map to the original service intended for the proxy.

To sum it up, having From & To (specially to) might give some flexibility .. however, if that's going to be an overkill we could discard that for now.

I'm not totally following the second use case but that sounds like a workaround at best.  Going to close this.  to and from should really come from the ingres spec.

Hey @travisgroth @wasaga kind request to re-introduce ingress.pomerium.io/to  annotation
As an optionaI annotation I don't believe it poses any conflict with the pomerium ingress controller.
The upside is that it gives greater flexibility in defining policies in other ingresses. Note that this was functional in pomerium operator.
I'll give you a practical example,
We are able to use forward auth with other ingresses see the traefik example for reference.
However, proxy mode is much more desired, and it can be achieved by defining policies as @sherifkayad noted.
Operator provided a way to define this policy on the ingress itself as below
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    ingress.kubernetes.io/ssl-proxy-headers: 'X-Forwarded-Proto: https'
    kubernetes.io/ingress.class: traefik-cert-manager
    kubernetes.io/tls-acme: "true"
    traefik.ingress.kubernetes.io/router.entrypoints: web, websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    ingress.pomerium.io/allowed_domains: '["domain.com"]'
    ingress.pomerium.io/to: http://whoami.whoami:80
    ingress.pomerium.io/tls_skip_verify: "true"
    ingress.pomerium.io/preserve_host_header: "true"
    ingress.pomerium.io/pass_identity_headers: "true"
  name: whoami
  namespace: whoami
spec:
  rules:
  - host: who.domain.com
    http:
      paths:
      - backend:
          service:
            name: pomerium-proxy
            port:
              number: 80
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - who.domain.com
    secretName: whoami-tls

This was extremely convenient for situations where ingresses are tightly controlled as a matter of policy & in other cases where users simply want to use ingress controllers they are familiar with.


Papge properties web part for FixedWebParts

Category
[ ] Bug
[ x ] Enhancement
Expected or Desired Behavior
If possible, please add the 'Page Properties' web part (FieldsWebPart) to the list of the supported fixed web parts.

Hey @robi26,
I do not really understand the question...are you talking about an existing classic FieldsWebPart? If so, can you specify the full name for me / a screenshot of the web part in action on a page. ...or are do want an option to get the modern page properties web part to be added to the created modern page?

Hi @jansenbe
Sorry for the confusion. I'm talking about the page properties web part on the modern page.
Here is the example:

I would like to add this web part to the newly created page as a fixed web part.

Got it @robi26 , that's a good thing to include.

Was thinking of implementing this in below manner, so you'll have to tell which fields will be shown in the web part and where the web part will be hosted. Would that work for you @robi26 ?
<MetaData ShowPageProperties="true" PagePropertiesRow="1" PagePropertiesColumn="2">
       <Field Name="Title" TargetFieldName="Title" Functions="" ShowInPageProperties="true"/>
       <Field Name="SeoKeywords" TargetFieldName="" Functions=""/>
       <!-- Functions allow to 'add' new fields to the metadata collection -->
       <Field Name="MyCustomField" TargetFieldName="MyCustomField" Functions="ConsolidateCustomField({MyCustomField}); {ExtraField}=SplitCustomField({MyCustomField})" />
     </MetaData>

That would work. The question is, if we are limiting the configuration possibilities of the web part for the future. If there will be more configurations available (e.g. new layout possibilities, hiding the title...) the MetaData node will have more attributes. If we handle the configuration as a 'normal' fixed web part, we need no schema change.

Defining it like the other web parts is also not correct as you're not taking a specific field...for now, I've implemented this as mentioned above...if in the future things change we can update properties in the web part mapping file, in the code that generates the web part model and in the layout files if needed.

Implemented in the dev branch + updated dev branch of PnP PS for this. You'll need to ensure to use the latest webpartmapping.xml file to make this work.


Add new Style/ArrayFirstLast cop

Fixes #12406.
I already implemented this cop (so that's why still decided to open a PR) when realised that .first/.last is only suited for arrays. While [0] and [-1] can be also used with strings or hashes. So this can probably generate many false positives. I made it disabled by default.

If the methods are specific only to arrays, I guess we can name the cop "ArrayFirstLast" or something more generic like "ArrayElementAccess". Might be good to make this configurable for whoever prefers indices as well, although I don't feel strongly about this.

I made it disabled by default.

Makes sense.

Documenting the reasons for being disabled by default will help users understand.

Added a line regarding why it is disabled.


App setup should have a step allowing connection to own Electrum Server before vault creation

On first open, we should let the user explicitly choose between connecting to own electrum, or use a public one, instead of using public by default without asking. This is needed so when creating the first hot wallet, it will avoid doing any query that may expose addresses to a public server.
We should still make sure to keep it very easy for users to simply continue with public server, to avoid making setup confusing for beginners.

Important note! If the user connects to their own node in this step, the app should not add any of the default public nodes to the available nodes list. And in case the app cannot connect to the node at a later moment, it should still not connect to any public node, see #5258

I have worked on this issue after doing some R&D on Sparrow and Nunchuck wallet. I would definitely require feedback on these screens as this is new concept for me@ben-kaufman . Please give it a view so I know what I missed out on
https://www.figma.com/design/m5eMFTKD391AiJAXaEzgxB/Bitcoin-Keeper?node-id=3150-6560&t=6LSw0Y7lq1yjdP6a-1

Great start, I added a few comments

Take a look at this flow now @ben-kaufman , see if it is according to requirements.
Figma:
https://www.figma.com/design/m5eMFTKD391AiJAXaEzgxB/Bitcoin-Keeper?node-id=3150-6560&t=FT0OBNt5Qi9LWrGc-1
S.S

Added a few notes 👍

I have left a comment on the file @ben-kaufman , please view that and give suggestion

Here is the udpated UI flow of Electrum server settings at start of app. @ASN-BitHyve would require some content from you. I have commented on the file for you to see where.
Figma link:
https://www.figma.com/design/m5eMFTKD391AiJAXaEzgxB/Bitcoin-Keeper?node-id=3150-6560&t=FT0OBNt5Qi9LWrGc-1

All the changes have been done per feedback @ben-kaufman  - Only thing that is missing is the content for modal rn. The gear icon has been added to the welcome screen now which will let users access to server settings as well apart from modal we talked about earlier.
https://www.figma.com/design/m5eMFTKD391AiJAXaEzgxB/Bitcoin-Keeper?node-id=3150-6560&t=lWZc2rqmf0Yh9QCX-1

Looks great 👍

This issue also includes some UI changes which aren't necessary for the original issue. I'll make a new issue for those

Verified this issue on dev app v 1.2.18(410)


Pin entry with entry id

Currently, when an entry renamed, Pin directing the entry doesn't change it's path automatically.
It can be fixed by keeping entry id for a pin instead of it's path.
Also It knows whether an entry deleted, when no row with the entry id exists in entries table.

Done: c7d9dd9fd3ff0d45bb64bc4e92ede81fe6783c26


Initial JPEG XL support for image input/output

Description

This draft PR is intended for adding JPEG XL support.
Tests

Checklist:

[x] I have read the contribution guidelines.
[ ] I have updated the documentation, if applicable.
[ ] I have ensured that the change is tested somewhere in the testsuite
(adding new test cases if necessary).
[ ] If I added or modified a C++ API call, I have also amended the
corresponding Python bindings (and if altering ImageBufAlgo functions, also
exposed the new functionality as oiiotool options).
[x] My code follows the prevailing code style of this project. If I haven't
already run clang-format before submitting, I definitely will look at the CI
test that runs clang-format and fix anything that it highlights as being
nonconforming.

The CI is failing on Mac. I bet that this is because the Mac CI tests are the only ones with libjxl installed at all, so they are the only ones building this code. That's probably something else to address, would be nice for at least one Linux build to try jxl. But maybe the reason it's failing on Mac is that it's using a different version of libjxl than you are, and something in their API changed?

The CI is failing on Mac. I bet that this is because the Mac CI tests are the only ones with libjxl installed at all, so they are the only ones building this code. That's probably something else to address, would be nice for at least one Linux build to try jxl. But maybe the reason it's failing on Mac is that it's using a different version of libjxl than you are, and something in their API changed?

Found JXL 0.9.1, while the latest is 0.10.1, which I am using now. I may add conditional compilation in order to have som backward compatibilty. Or wait until the newset release will be available everywhere? That takes ages.

Your call on how far back you want to support libjxl. You could set the MIN_VERSION in the checked_find_package call to reject a version that's too old.
If you want 0.10 to be the minimum version, that is less work now in the sense that you don't need any #if now, though you may later when 0.11 or whatever comes out. We'll probably never again be in a position where we can dictate that the only version we support is the very latest.
On the minus side, 0.10 minimum would mean our CI wouldn't currently build and test JPEGXL at all. In that case, I think we would need a build_jxl.bash like the other files in src/build-scripts, which we can run during the CI setup to ensure it's available in the versions you want to test, and that also makes it handy for end users who want a simple way to install it so that OIIO can find it.

Tried that already.
https://ffmpeg.org/pipermail/ffmpeg-devel/2023-July/311369.html

Your call on how far back you want to support libjxl. You could set the MIN_VERSION in the checked_find_package call to reject a version that's too old.
If you want 0.10 to be the minimum version, that is less work now in the sense that you don't need any #if now, though you may later when 0.11 or whatever comes out. We'll probably never again be in a position where we can dictate that the only version we support is the very latest.
On the minus side, 0.10 minimum would mean our CI wouldn't currently build and test JPEGXL at all. In that case, I think we would need a build_jxl.bash like the other files in src/build-scripts, which we can run during the CI setup to ensure it's available in the versions you want to test, and that also makes it handy for end users who want a simple way to install it so that OIIO can find it.

0.10 as the minimum required version seems to be the good choice, especially with the latest improvements:
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

OK, I'm with with making jxl have a supported minimum of 0.10.
But that means that we should write a build_libjxl.bash script, and use it for at least one of our CI tests so that we are for sure building and testing this code during CI.

Guess what? Homebrew JUST upgraded their jpeg-xl package to 0.10.1. Let me force these CI tests to run again, it may run on the right version on the Mac CI, which would let us directly test you new coe.

Weird. I tried myself, and even with libjxl 0.10.1, I'm seeing errors related to JxlDecoderGetICCProfileSize and JxlDecoderGetColorAsICCProfile being passed wrong arguments -- in jxl/decoder.h, neither of those functions seem to take the &format argument you're passing. How are you getting it to work on your end?

I have a few general questions about the plans for this area.
For output:

It looks like this will always write out using a 32bit float format. Are there plans to allow the caller to decide what bit-depth and format to write with?
There's no control over compression settings of any kind. That seems less than ideal.

For input:

Apparently JXL allows both associated and unassociated alpha. How does this work in practice and does this mean it's even more important to at least respect the oiio:UnassociatedAlpha attribute?

I'll review the actual code a bit tomorrow.

Guess what? Homebrew JUST upgraded their jpeg-xl package to 0.10.1. Let me force these CI tests to run again, it may run on the right version on the Mac CI, which would let us directly test you new coe.

Weird. I tried myself, and even with libjxl 0.10.1, I'm seeing errors related to JxlDecoderGetICCProfileSize and JxlDecoderGetColorAsICCProfile being passed wrong arguments -- in jxl/decoder.h, neither of those functions seem to take the &format argument you're passing. How are you getting it to work on your end?

It was unfortunate impedance mismatch between three versions of the libjxl I had installed. So cleaned up and checked against the latest and greatest official release.

Guess what? Homebrew JUST upgraded their jpeg-xl package to 0.10.1. Let me force these CI tests to run again, it may run on the right version on the Mac CI, which would let us directly test you new coe.

Just poured jpeg-xl--0.10.1.x86_64_linux.bottle.tar.gz and going to test against this version as well.
Silly idea: what is preventing us to use Homebrew installation on the Linux CI runs similarly to macOS?

This looks like it's getting very close. Only minor comments about the code itself, as you can see.
Big missing items:
* Documentation -- need a section in builtplugins.rst

* Tests -- the testsuite needs to exercise this in some way, like we do for the other formats.

Color management is unfinished. Nor proper metadata handling. Still so much to do and so little free(time_t).

Silly idea: what is preventing us to use Homebrew installation on the Linux CI runs similarly to macOS?

No particular reason, it just never came up. For CI, at least, we tend to try to use the "native" packager. So adding rpm/yum packages in gh-installdeps.bash is what we usually do for Linux. I'd be slightly afraid that a dependency from homebrew might not be representative of what they'd get installing packages the way most Linux users do -- different version, installed in a different place, who knows.

Looks like we're building ok on Mac with jpeg-xl installed. So I think the minimum requirement for getting this initial PR merged into master are:

Enforce the version limit in externalpackages.cmake.
Fix the clang-format CI failure.
Disable the format (temporarily) in imageinout_test -- we'll come back to this
Resolve what you want to use for the format_name() method.

Then with this as a baseline, the next set of necessary improvements are (not necessarily in this order):

Documentation
Handling alpha correctly (associated vs unassociated)
Track down what's going wrong with imageinout_test
Adding a testsuite/jpegxl that tests basic read and write of jxl files, including a few combinations of supported features.
Full support of all the pixel data types the jxl supports.
Compression options.
Right now, I think you are reading in the entire image at once into a (large) buffer and doling out pieces via memcpy as requested from the caller. I haven't read the libjxl docs -- does it support asking or passing ranges of scanlines or tiles? I don't know if the jxl format allows such things easily.
Getting the supports() method reporting the right set of things.

I'm sure we'll think of other things, but it's ok to get the big hunk of initial experimental support in now (as long as it builds for everyone correctly and passes the tests we already have), and then can have a series of smaller PRs to complete support and bring it all up to parity with the other formats.

Looks like we build successfully on Mac now with jpeg-xl installed via Homebrew!
But we are failing the testsuite, specifically the imageinout_test. That may be tricky, and I'm ok with your modifying imageinout_test.cpp, circa line 324, to simply skip the jxl format for now. We can restore it in subsequent iterations over this code and addition of the tests.

I will try now the macOS Sonoma build in the QEMU KVM based virtual machine.

Adding support for streaming mode comes to top of my wish list. Also, it would be cool to handle stereo and multiview images in this age.

Stereo and multiview should probably look like "subimages" in OIIO speak. Like how OpenEXR handles "parts" which are also used for stereo.

It took bit longer to set up all dependencies in the virtual machine. However, I encountered this:
[ 17%] Built target ustring_test
[ 17%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/imagebufalgo.cpp.o
[ 18%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/imagebufalgo_pixelmath.cpp.o
[ 18%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/imagebufalgo_channels.cpp.o
[ 19%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/imagebufalgo_compare.cpp.o
[ 19%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/imagebufalgo_copy.cpp.o
[ 20%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/imagebufalgo_deep.cpp.o
[ 20%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/imagebufalgo_draw.cpp.o
/Users/peter.kovar/1div0/OpenImageIO/src/libOpenImageIO/imagebufalgo_draw.cpp:743:20: error: unused variable 'default_font_name' [-Werror,-Wunused-variable]
static const char* default_font_name[] = { "DroidSans", "cour", "Courier New",
^
1 error generated.
make[2]: *** [src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/imagebufalgo_draw.cpp.o] Error 1
make[1]: *** [src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/all] Error 2
make: *** [all] Error 2
nice make  593,42s user 102,51s system 99% cpu 11:38,20 total
peter.kovar@Peters-iMac-Pro x86-64 % uname -a
Darwin Peters-iMac-Pro.local 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:54:10 PST 2023; root:xnu-10002.61.3~2/RELEASE_X86_64 x86_64

I see. I think this is a problem where the static variable is declared unconditionally, but it's only used if Freetype dependency is found and enabled. It's unrelated to your code.
I will submit a separate PR that fixes this case. But in the mean time, you can either install freetype or disable that warning.

In the meantime I am analyzing https://github.com/libjxl/libjxl/issues/3326 in order to implement streaming encoding and decoding in the OIIO.

Can you clarify what "streaming" means in this context?

I strongly recommend
git mv src/jxl.imageio src/jpegxl.imageio

and doing other fixups necessary (CMakeLists.txt, the stuff in imgeioplugins.cpp, etc.). We want

The plugin-in name (which is taken from the directory name)
The canonical name returned by the format_name() functions

to match exactly. The reason I want you to do this in time for the initial merge is that if we do the "git mv" later, I think it won't transfer the history and attribution properly, it will look like a new file is created and a git log or git blame won't necessarily show your contributions properly (I think).
You also need to fix imageinout_test to exclude this format from the test, for now.

I am getting this weird error in the test.
jpegxl (jxl):
Writing imageinout_test-jpegxl.jxl ... OK
PtexReader error: read failed (EOF) PtexFile: imageinout_test-jpegxl.jxl
/2TB/usr/src/github.com/1div0/OpenImageIO/src/libOpenImageIO/imageinout_test.cpp:360:
FAILED: in && "Could not create reader"
Writing Proxy jpegxl ... OK
Writing bad to bad/bad.jxl ... OK (Could not open file "bad/bad.jxl")

Yeah, that's the failure we've been seeing in CI with the imageinout_test. Like I said, I think it's acceptable for right now to disable this new format from that test, so we can get an initial merge with everything you've done so far, and then come back with all the little fixes including whatever is necessary to restore this test.
In effect, I want to checkpoint what you've got so far, so that every additional change can be viewed individually as a small patch to consider, rather than continuing to pile things onto this one, which means we need to look at your whole patch again every time there's a modification. Let's accept all the parts that seem good so far and iterate.

With the debug build of JPEG XL library latest modification revealed error in the writer.
m_filename = imageinout_test-jpegxl.jxl
m_basic_info 64×64×4
lib/jxl/encode.cc:1264: Invalid number of color channels
JxlOutput::write_scanlines(ybegin = 0, yend = 64, ...)
data = 0x3605ac0 nvals = 16384
JxlOutput::close()
JxlOutput::save_image()
data = 0x364d920 size = 65536
lib/jxl/encode.cc:2218: Basic info or color encoding not set yet
status = 1
JxlEncoderAddImageFrame failed with error 129
JxlOutput::close()

Apologies if this isn't exactly the right time or place to ask this, But are there any plans to support depth/z channels and maybe even thermal channels? (could possibly be in a later pull request since this one is just "Initial" support?). This would be very useful for projects like Blender to have depth/z maps/data stored/saved in rendered images for example.
libjxl does have support for handling these channel types and there's even a JXL file with such channels here as an example: https://saklistudio.com/jxltests/suz-multichannel-800px.jxl (RGB + Alpha (empty) + Depth + Thermal)
I'm really not too familiar with OpenImageIO as a whole so maybe this would be out of scope? although it seems like the EXR support/code has depth/z channel handling in some form via z_channel? unsure, though I do see a few references to z_channel in the docs.

OpenImageIO can deal with any number of channels having any names. So yes, totally within scope and nothing special at all.
z_channel and alpha_channel are just a special designations in the ImageSpec to mark it for ease of clients of the library so you don't need to go searching for them every time. But it's in no way implies that those are the only channels you can have.

JPEG XL export to RGB with α channel tested by Blender.

Now that we pass the imageinout_test, I believe that we are ready for a merge if you fix the clang format issue! Then we can come back to beef up this format with other improvements.

I pushed a few other minor changes. Tests pass now. Mergins.

@1div0 Don't forget we have some important outstanding issues, including

[ ] Document in builtinformats.rst
[ ] Handle different pixel types -- right now, always reads/writes float.
[ ] Compression options
[ ] EXIF
[ ] Test cases in the testsuite

@1div0 I can probably add support for UINT8, UINT16, and FLOAT16 output. But I want to be sure we are not referring to each other.

@ssh4net OK, I can add EXIF.


Okta KM setup docs needs revamping for APIM 4.1

Description:

Need to update docs  images for latest okta UI
Ex: API tab is now under security tab

Admin portal KM add UI now have a new field, "API Invocation Method field", need to add details regarding that new field.

Need to mention not to select "device code" grant type when generating App keys

I also encountered this while going through an implementation. I think it is essential that we update the doc ASAP with the updated screenshots. Many of them are different now. I was able to map the existing ones to the new ones and if someone needs help I can provide the updated screenshots.

@Mariangela , With this effort, seems we have removed the previous screenshots from OKTA side and just mentioned the instructions in texts. However without proper instructions, it's bit hard and confusing to a user who has no prior experience in OKTA implementation. Shall we at least point to okta docs?
Eg: in the steps, it is mentioned that Add an attribute to the default user profile.[1][2] without mentioning further details.
[1] - https://apim.docs.wso2.com/en/latest/install-and-setup/setup/sso/okta-as-an-external-idp-using-oidc/#step-1-configure-okta
[2] - https://help.okta.com/en-us/Content/Topics/users-groups-profiles/usgp-add-custom-user-attributes.htm


Performance fix when logging req or res

If the data.data object contains req or res the hoek.merge time took ~90ms, blocking the event loop and causing some serious damage to reqs/sec.
Since obj is smaller, merging the other way is way better perf wise.

Awesome, thanks!


Python 3 mode in provision.py

Make provision.py runnable on python 3.
Install a python 3 venv using 'requirements/py3_dev.txt' when provision.py is run from python 3. Retain original behaviour of making a python 2 venv using 'requirments/py2_dev.txt' and a python 3 venv using 'requirements/mypy.txt' when provision.py is run from python 2.
Even though provision.py itself is runnable on python 3, the subprocess calls it makes after installing a venv will not succeed in python 3 because of missing dependencies.

Automated message from Dropbox CLA bot
@sharmaeklavya2, it looks like you've already signed the Dropbox CLA. Thanks!

@sharmaeklavya2 thanks for working on this!  The last commit looks pretty reasonable.  The earlier commits are a bit ugly, so I'm wondering what your thinking is on what our strategy should be in terms of using strings vs. bytes for constants like "v1.2.3".  It feels ugly to be using universal_newlines everywhere (though perhaps no more so than doing a force_text() around them, but I'm not sure whether in clean Python 3, one should just work with these values using the bytes type.

Yeah it does look ugly. But I thought that code will be much easier to understand and maintain if we use str everywhere, instead of somewhere using str and somewhere using bytes. Using bytes everywhere will also increase ugliness because there are so many strings in our code.
It also makes more semantic sense to me. My mind sees the output from these calls as text, so I store them in str. I use bytes for things which are not representable as text, like images or audio or garbled/mangled/encrypted text.
I see that we're repeatedly using subprocess.check_output(..., universal_newlines=True).strip(). We can factor that out into a function to reduce the ugliness.

OK, makes sense.  It's probably worth doing that refactor (would put it as a new function in zulip_tools.py), but otherwise this looks good so I went ahead and merged this since it's blocking other stuff and a pretty minor issue.  Thanks @sharmaeklavya2!


Foundation, jQuery and Prototype.JS: Dropdown & DropdownMenu not working as intended

I'm trying to use jQuery and prototype.js, combined with foundation-sites 6 (tried 6.1.2, 6.2.0-rc.1). What has work with foundation 5 ever since leads to strange results now. The first interaction with the dropdown is working fine, but further interactions increase the offset of the dropdown pane infinitely.
I could reproduce that behaviour with dropdownMenu, too. In this case the dropdown menu is hidden (display:none) after the first interaction.
I have these components imported:
foundation.core.js
foundation.util.keyboard.js
foundation.util.triggers.js
foundation.util.mediaQuery.js
foundation.util.box.js
foundation.dropdown.js
Example: https://jsfiddle.net/4pqzmr7k/1/
Here is the callstack which shows the road to the inwards of prototype.js:
$ (prototype.js:2048)
show (prototype.js:2168)
_methodized (prototype.js:456)
jQuery.extend.trigger (jquery.js:7825) ==> elemtype;
(anonymous function) (jquery.js:7875)
jQuery.extend.each (jquery.js:360)
jQuery.fn.jQuery.each (jquery.js:137)
jQuery.fn.extend.trigger (jquery.js:7874)
Dropdown.open (foundation.dropdown.js:333)
(anonymous function) (foundation.dropdown.js:217)
included prototype.js resource: https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js
included jQuery resource https://cdnjs.cloudflare.com/ajax/libs/jquery/2.2.1/jquery.js

Renaming the events (example: show.zf.dropdown => reveal.zf.dropdown) would solve the problem, event it doesn't feel like the right thing to do. Would that be a valid solution? If yes I would check all components, rename the events and make a pull request.

I don't think we're going to rename all of the events... This kind of interaction with prototype.js is relatively low priority for us, but this is odd, and I suspect may be related to other dropdown positioning issues.  I'll take this, import the test case, and see what I can figure out.

+1

I also encountered this problem. I'm implementing Foundation 6 in a Magento 1.14 site... Magento uses Prototype.js. The drilldown menu does not work as expected because Prototype.js picks up on a Foundation  "hide" event that is triggered when closing a sub menu item.

The only way around this was to rename hide.zf.[whatever obj] to hideMe.zf.[whatever obj]. I know this isn't a best solution, but it works.
I am on magento 2.1.5 (which doesn't use prototype anymore, yay!) but I have to deal with a legacy extension which still does dip into the legacy-build.js (prototype.js).

Closing because of

I don't think we're going to rename all of the events... This kind of interaction with prototype.js is relatively low priority for us, but this is odd, and I suspect may be related to other dropdown positioning issues. I'll take this, import the test case, and see what I can figure out.

Mixing multiple frameworks will always break things.

Having the same issue today. We are working on the responsive styles of our Magento 1 website and I have upgraded to the latest version of Foundation. Foundation.Dropdown does not work correctly with that mix of technologies.

I do agree with some of the above posters that prefixing the events with foundation: would prevent a lot of future headaches.

I do not fully understand. Afaik we gave .zf..

I'm not quite sure of the details of what Prototype does behind the scene.
When something triggers the default hide event, both are going to get triggered.
See: https://jsfiddle.net/hfmuroqx/2/

@DanielRuf
I'm not quite sure on the details of what Prototype does behind the scene.
When something triggers the default hide event, both are going to get triggered.
See: https://jsfiddle.net/qs6oh1kb/

In general this is an issue on the event triggering and filtering in jQuery and other frameworks.
jQuery does the following:
hide and hide.something are catched with hide.something.
The part behind the first dot is the namespace. Namespaced events are described at http://api.jquery.com/on/#event-names
So we have to filter in .on(event) also by namespace.
But the actual event.namespace is not zf.plugin, it is plugin.zf.
If we trigger hide.zf.dropdown.abc too and listen for it, it will be executed on hide.zf.dropdown.abc, hide.zf.dropdown, hide.zf and hide.
See https://codepen.io/DanielRuf/pen/xBZLXM?editors=0010

You are preaching to the choirs. I'm not defending Prototype at all, I absolutely loathe it. However, it is so deeply rooted in Magento 1's front-end that removing it would require rewriting most of its core. Most projects simply eat up the slight performance loss and add jQuery and some responsive framework over it. I've worked with a lot of Magento 1 projects that were using Foundation and it's sad that the latest version does not fit well in the puzzle anymore.

If we trigger hide.zf.dropdown.abc too and listen for it, it will be executed on hide.zf.dropdown.abc, hide.zf.dropdown, hide.zf and hide

Indeed, hence my original suggestion of prefixing with foundation: or perhaps zf:. So zf;hide.dropdown would only trigger hide events as opposed to zf.hide.dropdown which would get trigerred whenever someone triggers a zf event. Apologies if that jsfiddle was confusing, it did not contain my actual suggestion.

Indeed, hence my original suggestion of prefixing with foundation: or perhaps zf:.

This is not recommended. Namespaced events are eventname.namespace. Not prefixed but suffixed afaik.
We will not change them as this would be a breaking change. You can maybd apply a patch file.

Indeed, hence my original suggestion of prefixing with foundation: or perhaps zf:.

This is not recommended. Namespaced events are eventname.namespace. Not prefixed but suffixed afaik.
We will not change them as this would be a breaking change. You can maybe apply a patch file.

Our events are hide.zf.plugin, not zf.hide.plugin ;-)

Indeed.

Indeed. zf.hide.plugin was from the code example that I had linked.
Otherwise, I am merely reporting what is going on with this particular bug and backing up the suggestion that was posted earlier. No need to explain event namespacing to me.

One solution then would be to avoid commonly used names in Foundation's custom events.
The helper to close the dropdown is $('#dropdown').foundation('close'); which fires the hide.zf.dropdown event. What about close.zf.dropdown instead?
That would avoid any possible risk of collision with other plugins or libraries which does not limit their listeners to their own namespaces.
All of this being said, the above fix that I had linked resolves the problem with this particular mix of technologies (Prototype + jQuery & Foundation 6).

We have multiple and different event names;': close, closed, hide, ...
All of them mean different things.
They only thing that we forgot was to filter the events by the namespace in .on.

close.zf.dropdown

.on('close.zf.dropdown ') is called on close, close.zf and close.zf.dropdown so this is not a real solution.

I trust your judgment, you know the code base at hand.

Also see https://github.com/zurb/foundation-sites/pull/10949 for our event naming scheme.

Also see https://github.com/zurb/foundation-sites/pull/10949 for information about our event naming scheme.

I will probably prepare a PR based on https://github.com/zurb/foundation-sites/issues/8221#issuecomment-468596228

I think we should continue the discussion in https://github.com/zurb/foundation-sites/issues/11708 to get an opinion from the other maintainers and contributors who also work on projects like FoundationPress - so we can prevent that we break many things and can maybe provide an optin solution for v6.6.


Remove usage of concrete_of

This PR removes the usage of concrete_of, which was causing issues when
using specialized types, like this:
import strawberry
from strawberry import Schema
from strawberry.extensions import FieldExtension
from strawberry.field import StrawberryField
from typing import Generic, TypeVar

T = TypeVar("T")

class CheckAtRuntime(FieldExtension):
    def apply(self, field: StrawberryField) -> None:
        print('concrete_of when applying extension is', field.type.__strawberry_definition__.concrete_of)

    def resolve(self, next_, source, info, **kwargs):
        return next_(source, info, **kwargs)

@strawberry.type
class MyGenericType(Generic[T]):
    my_value: T

@strawberry.type
class MyConcreteType(MyGenericType[int]):
    pass

@strawberry.type
class Query:
    @strawberry.field(extensions=[CheckAtRuntime()])
    def my_concrete_type(self) -> MyConcreteType:
        return MyConcreteType(my_value=123)

schema = Schema(query=Query)
print('concrete_of when booting is', MyConcreteType.__strawberry_definition__.concrete_of)

this was affecting the creation of connections with filters and also the optimizer

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.01 :tada:

Comparison is base (7a6df61) 87.40% compared to head (dfa00e8) 87.42%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #287      +/-   ##
==========================================
+ Coverage   87.40%   87.42%   +0.01%
==========================================
  Files          32       32
  Lines        2851     2855       +4
==========================================
+ Hits         2492     2496       +4
  Misses        359      359

Impacted Files
Coverage Δ

strawberry_django/fields/base.py
96.90% <100.00%> (+0.06%)
:arrow_up:

strawberry_django/optimizer.py
89.59% <100.00%> (+0.07%)
:arrow_up:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Cannot read property 'searchAndReplaceWidget' of null

Version: 1.33.0-insider
Commit: c1d001a915fe85cac93492393ea69fdb0c49ec0d
Date: 2019-03-13T06:13:28.579Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.15.0-46-generic
Steps to Reproduce:

Search widget location set in the bottom panel ("search.location": "panel")
Press Ctrl+Shift+F or choose View -> Search from menu
Search widget has not been activated, error popup appeared:

Cannot read property 'searchAndReplaceWidget' of null

Does this issue occur when all extensions are disabled?: Yes
This issue occurs only when location of Search widget is set to panel.

Also happens on macOS (10.14.3) with VS Code insiders:
Version 1.33.0-insider (1.33.0-insider)
c1d001a915fe85cac93492393ea69fdb0c49ec0d
2019-03-13T06:06:57.428Z

in case you are stuck with this bug, open the json preferences and disable the "search.location": "panel" then refresh the window.

Sorry for this. This is fixed and will be available in latest insiders.