mage2vs cannot import magento 2.3.1 data

Current behavior

In local machine I have magento 2.3.0 installed and data can be imported smoothly by running mage2vs to VSAPI.
However in server I have magento 2.3.1 installed and it always return 'API call failed: The consumer isn't authorized to access Magento' for all the datas.
I tried to turn on 'store > configuration > services > magento API > Allow Anonymous Guest Access', and succeed to import categories and productcategory, not the others.
It looked to me magento did not regconize mage2vs is not guest, not recognizing the keys tokens. (I have checked more than hundred times that the 4 keys tokens are correct)
Expected behavior

Import all required data from magento 2.3.1 rest API smoothly
Steps to reproduce the issue

Try fetch data from a magento 2.3.1 rest API
Repository

Can you handle fixing this bug by yourself?

[ ] YES
NO

Which Release Cycle state this refers to? Info for developer.
Pick one option.

[ ] This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
[ ] This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
[ ] This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

Browser:
OS:
Node:
Code Version:

Additional information

Hi there! Could You attach a screen of Your Magento integration setup - the Permissions tab for this enabled integration?
Please do also paste the vs-api config / magento2 section for double checking the config.
We haven’t observed this kind of problems on 2.3 - the only thing that wasn’t working properly was MSI support

Dear Piotr,
Here's the screencaps:
#1 all the other check boxes are clicked

#2 vs-api local.json

#3 try running mage2vs/src/test_multistore.sh

Thank you!

Hi, the error message points to invalid permissions to "Categories" resource - on the screen i don't see categories checked (due to limited screenshot area I belive) - make sure it's been checked along with the "Sales" section

Dear Piotr,
No no, I tried to check all and still give the same error. (I've been fighting with this error for whole day and pretty sure its not becoz I missed checking boxes)
I just installed a fresh 2.3.0 magneto on server, and everything works fine again.
It must dealing with some fixing in RestAPI of 2.3.1.
See anyone have tried the same situation.

Hi Michhy, I'm on magento 2.3.1 and have no problems with permissions as you have.

Dear Mdesmet
Thanks, I will try installing 2.3.1 again and test later.


[BUG] Conflict with Polyglot Module

After running Find The Culprit I've determined that when you select a token while both Hey Listen and Polyglot are active, 3 notifications pop up every single time unless you have the chat tab open.
Just wanted to report this issue so it's known.

Not the dev but have you checked settings to try changing the number of maximum messages? I'm not seeing the same behavior with polyglot active. For me it defaults to 3 but can be changed.


Country code select tab navigation

First of all, thanks for this amazing plugin.
Sorry if this is a duplicate, but couldn't find this topic in the README or the closed issues. I'm currently having one problem when tab navigating the form, which is the flags dropdown not getting focus (probably because it is a ul element, and not a form field), is there any way around it?
Thanks

Yes I agree: ideally you would be able to tab to the dropdown, but yes you're right: it would only work if the dropdown was a normal <select> element, which we can't do, as we'd lose all the nice styling. I know some browsers support custom styling of <select> elements, but I know it's difficult (different in each browser), and limited (not sure if we could have flags in the dropdown, not sure if we could style the selected flag in the input to look right, and I know you can't do it at all in older versions of IE). Needs more research.

I suggest adding the tabindex attribute on the .selected-flag, ditch the clickevent and use the focus & blur events and accordingly show/hide the country-list.
I manage to make this work with a quick hacky play around on the demo page:

I think this should be the default plugin behavior as this is a huge improvement for accessibility (tab & click VS click only).
Ref for making an element tabbable:
http://stackoverflow.com/questions/13637223/how-do-you-make-a-div-tabbable

Here's what it look like if you put tabindex and focus/blur event on the .flag-dropdown instead of the .selected-flag

Theoretically, you could even tab trough the list of country, or just the preferred country as tabbing trough 235 element might be quite painful for the user.

Hey, thanks for the quick replies.
@jackocnr
Agreed, using a <select> element is probably not an option.
@kirkas
You're right! This might be the way around this, I personally would expect it to behave just like a <select> element, so tabindex would only be in .selected-flag or .flag-dropdown, I'll try to play around with it.
Thanks.

We also need to decide how you open the dropdown once it's focused. I think it should behave as close to a native <select> as possible. So I don't want it to open on focus, but I think up/down would be good, as the browsers I tested would either open a <select> dropdown, or rotate through it's options on these keys, and as I don't want to implement the latter, I think we should go with the former. Also some browsers open a <select> on space too, so I would be up for that as well. Then once the dropdown is open, they can navigate with up/down or by typing a country name.
Thoughts?

Going as close to select make sense, although the logic should not be to imitate select, but rather to think what's the best user experience for this particular action (selecting a country), which in this case, is imitate select behavior (lolz).
A quick study of different plugin and play around with a native select item show that the common pattern are:

Element is focusable.
Dropdown open on up and down.
When dropdown is open, up and down goes trough the options.
space key open the dropdown.
When dropdown is open, space key close the dropdown and select currently focused item.
When dropdown is open, enter key close the dropdown and select currently focused item.
enter key has otherwise no effect, as it might submit the form by mistake (that should probably be prevented by the plugin, since you're not actually using a select element).
When dropdown is open, tab key has no effect.

Some of those behavior might be to frigid for your plugin, eg: When the dropdown is open and you hit tab, you might want to close and go to the next input?
Overall I think it should first get as close from a select element, then it'll need a lot of testing to see what's the more convenient and comfortable user experience.
Few ref:
http://github.hubspot.com/select/docs/welcome/
http://harvesthq.github.io/chosen/
https://select2.github.io/examples.html
http://jqueryui.com/selectmenu/
http://brianreavis.github.io/selectize.js/

Also I like the way google signup handle it: https://accounts.google.com/signup

Yer Google open the dropdown on enter, which I think makes sense because no one is going to be trying to submit the form when the flag is selected.


Optional property values missing when copying between realms.

Hi!
I have some objects:
class Task: Object {
    dynamic var name: String? = nil
    let steps = List<Step>()
}

class Step: Object {
    dynamic var name: String? = nil
    let duration = RealmOptional<NSTimeInterval>()
}

When I copy a Task from a read-only compressed realm into the default realm, everything is copied over except the duration property which shows up as 0 in the Realm browser. I verified using the Realm browser that the duration property is not 0 in the read-only Realm.
Here's a test project (it's a .zip file, so you'll have to change the extension when you download it):

My built frameworks were too big to upload, but I can find a way to upload them if needed.
Here's the output I get in my console when running the project:
Objects in main realm before deletion: Results<Task> (

)
Deleting all objects from main Realm.
Creating read-only Realm.
Read-only Realm saved to /Users/......./readonly.realm
Objects in the read-only realm: Results<Task> (
	[0] Task {
		name = taskName;
		steps = RLMArray <0x7fcd3b585300> (
			[0] Step {
				name = stepName;
				duration = 3.5;
			}
		);
	}
)
Inserted read-only objects into main Realm.
Objects in main realm after: Results<Task> (
	[0] Task {
		name = taskName;
		steps = RLMArray <0x7fcd3b726d90> (
			[0] Step {
				name = stepName;
				duration = (null);          <<<<< I think this should be 3.5
			}
		);
	}
)
Objects in read-only realm after: Results<Task> (
	[0] Task {
		name = taskName;
		steps = RLMArray <0x7fcd3b738740> (
			[0] Step {
				name = stepName;
				duration = 3.5;
			}
		);
	}
)

This is an almost perfect replica of my issue in my other project. The only difference is that my other project persists the default Realm across launches but this one does not seem to do that.
Let me know what I'm doing wrong or if there's anything else I can provide!
I'm on XCode 7.1 (7B91b) / OS X 10.11.1 / Realm 0.96.2 / Carthage 0.9.2

@smpanaro Thank you for reporting and sample project! It will be fixed by https://github.com/realm/realm-cocoa/pull/2901 .

@kishikawakatsumi are you sure that's the same issue? This one seems to be related to Realm.writeCopyToPath(_:).

@jpsim I'm sure this issue isn't related to Realm.writeCopyToPath(_:). Because it happens regardless whether to copy or not to copy the Realm.
I also confirm it will be fixed by #2901 .
I try a little more investigating whether really the same problem. Thank you for your advice.

@kishikawakatsumi @jpsim Just wanted to report that this bug still exists for me in 0.96.3.

Indeed. That's why it's still open.


resolution 1m is far lesser than 1m

I have downloaded countries-coastline 1m resolution geojson and extracted HKG multi-polygon to plot my map. I found the islands is just some simple polygons, I don't think it is up to 1m resolution.

Yeah sadly is not.
It mostly depends on the quality of the original map.
Can you have a look on Open Street Map directly?

I have tried replacing "simplified-land-polygons-complete-3857.zip" to "land-polygons-complete-3857.zip", it is  much better now.


A couple fixes

Remove exclamation points
Fix a bug with Test-DbaConnection

one pass - previous failures were due to azure being junky


cli: expose portforwarding capability and refactor dashboard cmd

Description:
This change exposes port forwarding capability generically
(previously implemented in the dashboard cmd)
so that other commands that require to port forward to a pod
can leverage this. It updates the dashboard cmd to leverage
the generic port forwarder.
A subsequent change that requires port forwarding from the cli
will also leverage the newly added port forwarding APIs.
There also doesn't seem to be a trivial way to mock
port forwarding to a pod, so this will likely have to be
tested using e2e for automated tests.

Affected area:

New Functionality      [ ]
Documentation          [ ]
Install                [ ]
Control Plane          [ ]
CLI Tool               [X]
Certificate Management [ ]
Networking             [ ]
Metrics                [ ]
SMI Policy             [ ]
Security               [ ]
Tests                  [ ]
CI System              [ ]
Performance            [ ]
Other                  [ ]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project? If so, did you notify the maintainers and provide attribution?
No

Codecov Report

Merging #1878 into main will decrease coverage by 0.47%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main    #1878      +/-   ##
==========================================
- Coverage   59.33%   58.85%   -0.48%
==========================================
  Files         126      127       +1
  Lines        5191     5223      +32
==========================================
- Hits         3080     3074       -6
- Misses       2108     2146      +38
  Partials        3        3

Impacted Files
Coverage Δ

cmd/cli/dashboard.go
0.00% <0.00%> (ø)

cmd/cli/portforward.go
0.00% <0.00%> (ø)

...ertificate/providers/tresor/certificate_manager.go
69.66% <0.00%> (-6.75%)
:arrow_down:

Continue to review full report at Codecov.

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


Update Postgres client DB Name

ENHANCEMENT

Describe the enhancement you are requesting. Enhancements include:
There is a bug in env vars that do not match config tags in the config (referenced in the original issue), so it defaults to value set here. Updates to config to require name here are necessary so we remove the aforementioned line.

Indicate the importance of this enhancement to you (must-have, should-have, nice-to-have).
This is a should-have enhancement.

Originally posted by @dborovcanin in https://github.com/mainflux/mainflux/issues/1913#issuecomment-1747761304

Hey ENHANCEMENT!
Facing issue on installation of mainflux can you please guide me. What we need to do then than installation process given in documentation? At http://localhost/ i am getting 404 page not found error. Please help me.


[Feature Request] Sorting Uniques By DPS increase

This should be somewhat easy to implement but helpful: Currently this search menu is just sorted alphabetically. What would be great is if we had the option to sort it by DPS gain instead.

A greed.

Looks like this was fixed/added in the latest version (1.4.87).

Yup! (finally...)


when is upload date your ARTrackv2?

When is the upload date for ARTrackv2?
I wand to know your source code for implementing about your paper!

We need to consult with the patent department on this point, and I hope that I can open source my code as much as possible within my ability. If open source is not possible, I think you can easily reproduce our code because our structure is so simple that we only need a backbone and a mask decoder extracted from the MAE code.
Based on this codebase, you can make this in one day.
If u have any problem u can email me, or add my wechat if u want to, i will try my best to provide the file u need.

We release a temporal code for inference, if you need the training code, we will released that when we finish the ARTrackV3. (the code is not organized and we will merge that into ARTrackV1 when I have enough time.)


STAR

The pixel sizes of the data in the STAR dataset vary. Do we need to preprocess the data? If data preprocessing is required, can you provide the relevant code for data preprocessing.

Basically, the data preprocessing is the same as DOTA.
Note that for STAR, the validation set does not need to be processed because we provide online large-scale image evaluation.

@yangxue0827 “Note that for STAR, the validation set does not need to be processed because we provide online large-scale image evaluation.”

Training is consistent with DOTA, but what are the specific differences between validation and DOTA? How should this be implemented in detail?
When will the code for HOD-Net be released as open source?

Thank you

Refer to test set  in config.
https://github.com/yangxue0827/STAR-MMRotate/blob/08a475bd0f6cf2ce919c99cc75093fafa5278d6a/configs/h2rbox_v2p/h2rbox_v2p_r50_fpn_1x_dota_le90.py#L92-L95
It will be released after the paper accepted.

I used tools/data/dota/split/img_split.py to process the STAR dataset during both training and testing. When training with oriented_rcnn_r50_fpn_1x_star_le90.py, there is no difference in the results between test=dict(type='STARWSOODDataset', ...) and test=dict(type='STARDataset', ...) when train=dict(type='STARDataset', ...) is used.
In Table 2 of the paper, the mAP of HOD-Net is 43.6 and 55.9, corresponding to single-scale or multi-scale for DOTA ?
In Table 3 of the paper, is the only difference between Resizing and Cropping the use of model = dict(type='OrientedRCNN', ...) and model = dict(type='OrientedRCNNCrop', ...) ?

STARWSOODDataset is for weakly supervised detectors (such as H2RBox-v2), and STARDataset is for fully supervised detectors.

Multi-scale, involving data multi-scale cropping

OrientedRCNNCrop is specifically for STAR data. The difference from OrientedRCNN is that the former can support online evaluation of large images, so there is no need to crop the validation/test set.

I would like to ask a question about the test set. If the test set is cropped 1024x1024 and uploaded to the evaluation website, and the result is empty, can the test set be cropped?


Run styles and scripts in sequence

Prevents potential race condition where styles and scripts write to the
manifest at the same time
fixes https://github.com/roots/sage/issues/1398
Updates changelog

@retlehs pretty big bug. Should def be a release.

@retlehs I reverted all the changes to pleeease so this can get merged. Fixing the pleeease madness will have to be a separate PR.


Publish both snapshots and releases to DockerHub

:clipboard: Description

At the moment, only "snapshots" are being pushed to DockerHub. It is unclear whether these are nightly builds, whether they're done after a pull request, or manually when decided/needed. The community can clearly benefit from these.
The problem with the currently deployed version is that it's simply labelled as next which isn't an actual version and can easily be wiped next time a new version is pushed, making it a silent snapshot release. This is unstable and unreliable for use.
The documentation shows you how you can build your own Docker image from the Dockerfile, but it would be much better to have official releases for this. There should be a dedicated page on Docker and how to use the image.
Also, the currently available shieldsio/shields:next image, places the code under /usr/src/app. This is not really a conventional place to put an appliction and is actually mean for source code for various applications.

Thanks for reaching out!
The current versioning approach is deliberate: it always reflects latest from trunk branch, which has all changes validated via our CI and PR/merge processes. The version of the Shields server in the image on DockerHub is basically identical to what's running on Shields.io service (with a couple days lag on average). However, we've been having discussions in the ops team meetings about potentially changing this to something like CalVer.
Are there any specific problems that you've encountered, or are you just offering some general feedback and suggestions?
I think it's important to note for context that we're a small team and are focused on the development and support of the Shields.io service itself. The vast, vast majority of our users are consuming the Shields.io service and comparatively the self-hosted Shields server is not really a core use case nor one that's formally supported in any capacity at this time. That's largely because self-hosting is really only necessary in a handful of edgier cases where a user needs badges for a private service/tool (or private project), or from services/tools that are not internet facing (e.g. private corporate intranet).
We still try to enable that uncommon self-hosting case by having a couple straightforward ways to get up and running simply and quickly, because it tends to be a one-and-done action. For example, a typical self-hoster just wants to get setup so they can have badges for their private GitHub repos or from their Jira server; they neither care about nor need the random assortment of new badges for new services that get added every month.
As I mentioned before, we're open to potential improvements in this space and some discussions are under way, but the above context will still be in place unless and until something significant changes. We're not going to start formally "releasing" the server (we intentionally don't even version it) as an on-prem/server-equivalent offering of Shields with LTS, etc., and DockerHub as one distribution channel. Like many open source projects we've only got a handful of unpaid volunteers with limited bandwidth that's essentially entirely occupied by Shields.io itself. The capacity to do more with self-hosting is extremely constrained.

It is unclear whether these are nightly builds, whether they're done after a pull request, or manually when decided/needed

I think that's a fair point, and agree we can add some additional documentation to clarify.

The problem with the currently deployed version is that it's simply labelled as next which isn't an actual version and can easily be wiped next time a new version is pushed, making it a silent snapshot release

I'm not really sure about some of the terminology being used here (e.g. "snapshot", "silent"), which seems intended to connote meaning that I can only associate to unrelated ecosystems (Java/maven). However, think I get the gist of the point, but I'd refer back to this being intentional. Though I have my personal qualms with the utilization of the publishing and consumption of latest with Docker images, it's not exactly a novel pattern and we're doing the exact same thing here, just with a different label.

This is unstable and unreliable for use.

Have to say I strongly disagree with this, especially with the dearth of supporting evidence/real issues encountered. I can definitely appreciate the desire for additional documentation and tagging/release strategy, but that doesn't mean that the server we make available as an image is inherently unstable or unreliable.
Yes, we're aware that this means one can not go to DockerHub to grab an image that has the Shields server from a specific point in time from the past, but again this has been by design. Certainly aware of the benefits of being able to rollback in the abstract, but specifically within the Shields self-hosting context, to date there's hasn't been any need nor use case communicated as to why a self-hoster would need to rollback to an earlier version.

The documentation shows you how you can build your own Docker image from the Dockerfile, but it would be much better to have official releases for this.

Largely covered in previous commentary above, but will note "Official" can obviously have different meanings for different folks. Our core goal for the Docker image has simply been to provide an easy option for someone wants to use Docker as the means for self-hosting, and which was provided directly by the Shields team (not a random community image). Whereas you seem to be requesting the more formal/supported type of offering which is quite different.

places the code under /usr/src/app. This is not really a conventional place to put an appliction and is actually mean for source code for various applications

I suppose that's also fair, though would suggest those that want to run a self-hosted Shields server via the simplest route of just grabbing a Docker image most likely aren't particularly concerned with the inner fs structure. Feel free to submit a PR with a suggested change though if you think changing this would be helpful!

See also #3558

Thanks for reaching out!
The current versioning approach is deliberate: it always reflects latest from trunk branch, which has all changes validated via our CI and PR/merge processes. The version of the Shields server in the image on DockerHub is basically identical to what's running on Shields.io service (with a couple days lag on average). However, we've been having discussions in the ops team meetings about potentially changing this to something like CalVer.
Are there any specific problems that you've encountered, or are you just offering some general feedback and suggestions?
I think it's important to note for context that we're a small team and are focused on the development and support of the Shields.io service itself. The vast, vast majority of our users are consuming the Shields.io service and comparatively the self-hosted Shields server is not really a core use case nor one that's formally supported in any capacity at this time. That's largely because self-hosting is really only necessary in a handful of edgier cases where a user needs badges for a private service/tool (or private project), or from services/tools that are not internet facing (e.g. private corporate intranet).
We still try to enable that uncommon self-hosting case by having a couple straightforward ways to get up and running simply and quickly, because it tends to be a one-and-done action. For example, a typical self-hoster just wants to get setup so they can have badges for their private GitHub repos or from their Jira server; they neither care about nor need the random assortment of new badges for new services that get added every month.
As I mentioned before, we're open to potential improvements in this space and some discussions are under way, but the above context will still be in place unless and until something significant changes. We're not going to start formally "releasing" the server (we intentionally don't even version it) as an on-prem/server-equivalent offering of Shields with LTS, etc., and DockerHub as one distribution channel. Like many open source projects we've only got a handful of unpaid volunteers with limited bandwidth that's essentially entirely occupied by Shields.io itself. The capacity to do more with self-hosting is extremely constrained.

It is unclear whether these are nightly builds, whether they're done after a pull request, or manually when decided/needed

I think that's a fair point, and agree we can add some additional documentation to clarify.

The problem with the currently deployed version is that it's simply labelled as next which isn't an actual version and can easily be wiped next time a new version is pushed, making it a silent snapshot release

I'm not really sure about some of the terminology being used here (e.g. "snapshot", "silent"), which seems intended to connote meaning that I can only associate to unrelated ecosystems (Java/maven). However, think I get the gist of the point, but I'd refer back to this being intentional. Though I have my personal qualms with the utilization of the publishing and consumption of latest with Docker images, it's not exactly a novel pattern and we're doing the exact same thing here, just with a different label.

This is unstable and unreliable for use.

Have to say I strongly disagree with this, especially with the dearth of supporting evidence/real issues encountered. I can definitely appreciate the desire for additional documentation and tagging/release strategy, but that doesn't mean that the server we make available as an image is inherently unstable or unreliable.
Yes, we're aware that this means one can not go to DockerHub to grab an image that has the Shields server from a specific point in time from the past, but again this has been by design. Certainly aware of the benefits of being able to rollback in the abstract, but specifically within the Shields self-hosting context, to date there's hasn't been any need nor use case communicated as to why a self-hoster would need to rollback to an earlier version.

The documentation shows you how you can build your own Docker image from the Dockerfile, but it would be much better to have official releases for this.

Largely covered in previous commentary above, but will note "Official" can obviously have different meanings for different folks. Our core goal for the Docker image has simply been to provide an easy option for someone wants to use Docker as the means for self-hosting, and which was provided directly by the Shields team (not a random community image). Whereas you seem to be requesting the more formal/supported type of offering which is quite different.

places the code under /usr/src/app. This is not really a conventional place to put an appliction and is actually mean for source code for various applications

I suppose that's also fair, though would suggest those that want to run a self-hosted Shields server via the simplest route of just grabbing a Docker image most likely aren't particularly concerned with the inner fs structure. Feel free to submit a PR with a suggested change though if you think changing this would be helpful!

See also #3558

Hi @calebcartwright ,
Thanks for getting back to me and thank you for going into so much details in your explanation!

The current versioning approach is deliberate: it always reflects latest from trunk branch, which has all changes validated via our CI and PR/merge processes. The version of the Shields server in the image on DockerHub is basically identical to what's running on Shields.io service (with a couple days lag on average). However, we've been having discussions in the ops team meetings about potentially changing this to something like CalVer.
Are there any specific problems that you've encountered, or are you just offering some general feedback and suggestions?

There are currently no concrete problems, but we're planning on running this on-prem in our organization and while this will not be a mission-critical service, we are expected to have some form of guaranteed stability, which one would normally expect to get from a "released" (or otherwise "tagged") version that is a reproducible binary/image from a given point in time.
Both CalVer and Semver would be excellent choices and are widely used.

I think it's important to note for context that we're a small team and are focused on the development and support of the Shields.io service itself. The vast, vast majority of our users are consuming the Shields.io service and comparatively the self-hosted Shields server is not really a core use case nor one that's formally supported in any capacity at this time. That's largely because self-hosting is really only necessary in a handful of edgier cases where a user needs badges for a private service/tool (or private project), or from services/tools that are not internet facing (e.g. private corporate intranet).
We still try to enable that uncommon self-hosting case by having a couple straightforward ways to get up and running simply and quickly, because it tends to be a one-and-done action. For example, a typical self-hoster just wants to get setup so they can have badges for their private GitHub repos or from their Jira server; they neither care about nor need the random assortment of new badges for new services that get added every month.
As I mentioned before, we're open to potential improvements in this space and some discussions are under way, but the above context will still be in place unless and until something significant changes. We're not going to start formally "releasing" the server (we intentionally don't even version it) as an on-prem/server-equivalent offering of Shields with LTS, etc., and DockerHub as one distribution channel. Like many open source projects we've only got a handful of unpaid volunteers with limited bandwidth that's essentially entirely occupied by Shields.io itself. The capacity to do more with self-hosting is extremely constrained.

I appreciate that you are a small OSS team! You're providing an excellent service for a very broad OSS community.
There are however, valid cases where an organization/company might want to host their own Shields service on-premise (mostly for security reasons), which is why I am pointing this out. :)
Would you mind providing some more details around why you've chosen to not use a version and are sticking with 0.0.0? What benefits is this bringing you? As a Build & Release/DevOps Engineer, I'm really keen to find out. Is it about forcing everyone to be with the latest code?

It is unclear whether these are nightly builds, whether they're done after a pull request, or manually when decided/needed

I think that's a fair point, and agree we can add some additional documentation to clarify.

:+1:

The problem with the currently deployed version is that it's simply labelled as next which isn't an actual version and can easily be wiped next time a new version is pushed, making it a silent snapshot release

I'm not really sure about some of the terminology being used here (e.g. "snapshot", "silent"), which seems intended to connote meaning that I can only associate to unrelated ecosystems (Java/maven). However, think I get the gist of the point, but I'd refer back to this being intentional. Though I have my personal qualms with the utilization of the publishing and consumption of latest with Docker images, it's not exactly a novel pattern and we're doing the exact same thing here, just with a different label.

In the Maven/Java world (but not only), a snapshot is the next unstable development version. In your case, since it's a version that will be overwritten next time you've merged changes and built and pushed a new image, it will still be under the same next version, (which is, effectively, the same thing).

This is unstable and unreliable for use.

Have to say I strongly disagree with this, especially with the dearth of supporting evidence/real issues encountered. I can definitely appreciate the desire for additional documentation and tagging/release strategy, but that doesn't mean that the server we make available as an image is inherently unstable or unreliable.
Yes, we're aware that this means one can not go to DockerHub to grab an image that has the Shields server from a specific point in time from the past, but again this has been by design. Certainly aware of the benefits of being able to rollback in the abstract, but specifically within the Shields self-hosting context, to date there's hasn't been any need nor use case communicated as to why a self-hoster would need to rollback to an earlier version.

Perhaps I misspoke. Sure, you can use it. By "unreliable" I meant that you have no guarantee that the image might not change and you might be surprised by changes that unexpectely start breaking things for you. This is why code gets versioned and released.

The documentation shows you how you can build your own Docker image from the Dockerfile, but it would be much better to have official releases for this.

Largely covered in previous commentary above, but will note "Official" can obviously have different meanings for different folks. Our core goal for the Docker image has simply been to provide an easy option for someone wants to use Docker as the means for self-hosting, and which was provided directly by the Shields team (not a random community image). Whereas you seem to be requesting the more formal/supported type of offering which is quite different.

Yeah, in our case, we would be hosting it on-premise and we were hoping to use a "release" (fixed in time) version.

places the code under /usr/src/app. This is not really a conventional place to put an appliction and is actually mean for source code for various applications

I suppose that's also fair, though would suggest those that want to run a self-hosted Shields server via the simplest route of just grabbing a Docker image most likely aren't particularly concerned with the inner fs structure. Feel free to submit a PR with a suggested change though if you think changing this would be helpful!

This is a trivial fix, but it would be up to your team to decide where you're like to place this. I was just saying that, while it doesn't really matter where it's placed, (as long as it works), it's not exactly following any common conventions and they your might like to look into it.

See also #3558

Thanks! And thanks again for your very detailed answer!
I hope you view my notes and remarks as something constructive and useful (I have been building, releasing and deploying software, as well as contributing to OSS projects for quite a few years now and just wanted to share my thoughts on how things could be improved).

Hi @calebcartwright ,
Thanks for getting back to me and thank you for going into so much details in your explanation!

The current versioning approach is deliberate: it always reflects latest from trunk branch, which has all changes validated via our CI and PR/merge processes. The version of the Shields server in the image on DockerHub is basically identical to what's running on Shields.io service (with a couple days lag on average). However, we've been having discussions in the ops team meetings about potentially changing this to something like CalVer.
Are there any specific problems that you've encountered, or are you just offering some general feedback and suggestions?

There are currently no concrete problems, but we're planning on running this on-prem in our organization and while this will not be a mission-critical service, we are expected to have some form of guaranteed stability, which one would normally expect to get from a "released" (or otherwise "tagged") version that is a reproducible binary/image from a given point in time.
Both CalVer and Semver would be excellent choices and are widely used.

I think it's important to note for context that we're a small team and are focused on the development and support of the Shields.io service itself. The vast, vast majority of our users are consuming the Shields.io service and comparatively the self-hosted Shields server is not really a core use case nor one that's formally supported in any capacity at this time. That's largely because self-hosting is really only necessary in a handful of edgier cases where a user needs badges for a private service/tool (or private project), or from services/tools that are not internet facing (e.g. private corporate intranet).
We still try to enable that uncommon self-hosting case by having a couple straightforward ways to get up and running simply and quickly, because it tends to be a one-and-done action. For example, a typical self-hoster just wants to get setup so they can have badges for their private GitHub repos or from their Jira server; they neither care about nor need the random assortment of new badges for new services that get added every month.
As I mentioned before, we're open to potential improvements in this space and some discussions are under way, but the above context will still be in place unless and until something significant changes. We're not going to start formally "releasing" the server (we intentionally don't even version it) as an on-prem/server-equivalent offering of Shields with LTS, etc., and DockerHub as one distribution channel. Like many open source projects we've only got a handful of unpaid volunteers with limited bandwidth that's essentially entirely occupied by Shields.io itself. The capacity to do more with self-hosting is extremely constrained.

I appreciate that you are a small OSS team! You're providing an excellent service for a very broad OSS community.
There are however, valid cases where an organization/company might want to host their own Shields service on-premise (mostly for security reasons), which is why I am pointing this out. :)
Would you mind providing some more details around why you've chosen to not use a version and are sticking with 0.0.0? What benefits is this bringing you? As a Build & Release/DevOps Engineer, I'm really keen to find out. Is it about forcing everyone to be with the latest code?

It is unclear whether these are nightly builds, whether they're done after a pull request, or manually when decided/needed

I think that's a fair point, and agree we can add some additional documentation to clarify.

:+1:

The problem with the currently deployed version is that it's simply labelled as next which isn't an actual version and can easily be wiped next time a new version is pushed, making it a silent snapshot release

I'm not really sure about some of the terminology being used here (e.g. "snapshot", "silent"), which seems intended to connote meaning that I can only associate to unrelated ecosystems (Java/maven). However, think I get the gist of the point, but I'd refer back to this being intentional. Though I have my personal qualms with the utilization of the publishing and consumption of latest with Docker images, it's not exactly a novel pattern and we're doing the exact same thing here, just with a different label.

In the Maven/Java world (but not only), a snapshot is the next unstable development version. In your case, since it's a version that will be overwritten next time you've merged changes and built and pushed a new image, it will still be under the same next version, (which is, effectively, the same thing).

This is unstable and unreliable for use.

Have to say I strongly disagree with this, especially with the dearth of supporting evidence/real issues encountered. I can definitely appreciate the desire for additional documentation and tagging/release strategy, but that doesn't mean that the server we make available as an image is inherently unstable or unreliable.
Yes, we're aware that this means one can not go to DockerHub to grab an image that has the Shields server from a specific point in time from the past, but again this has been by design. Certainly aware of the benefits of being able to rollback in the abstract, but specifically within the Shields self-hosting context, to date there's hasn't been any need nor use case communicated as to why a self-hoster would need to rollback to an earlier version.

Perhaps I misspoke. Sure, you can use it. By "unreliable" I meant that you have no guarantee that the image might not change and you might be surprised by changes that unexpectely start breaking things for you. This is why code gets versioned and released.

The documentation shows you how you can build your own Docker image from the Dockerfile, but it would be much better to have official releases for this.

Largely covered in previous commentary above, but will note "Official" can obviously have different meanings for different folks. Our core goal for the Docker image has simply been to provide an easy option for someone wants to use Docker as the means for self-hosting, and which was provided directly by the Shields team (not a random community image). Whereas you seem to be requesting the more formal/supported type of offering which is quite different.

Yeah, in our case, we would be hosting it on-premise and we were hoping to use a "release" (fixed in time) version.

places the code under /usr/src/app. This is not really a conventional place to put an appliction and is actually mean for source code for various applications

I suppose that's also fair, though would suggest those that want to run a self-hosted Shields server via the simplest route of just grabbing a Docker image most likely aren't particularly concerned with the inner fs structure. Feel free to submit a PR with a suggested change though if you think changing this would be helpful!

This is a trivial fix, but it would be up to your team to decide where you're like to place this. I was just saying that, while it doesn't really matter where it's placed, (as long as it works), it's not exactly following any common conventions and they your might like to look into it.

See also #3558

Thanks! And thanks again for your very detailed answer!
I hope you view my notes and remarks as something constructive and useful (I have been building, releasing and deploying software, as well as contributing to OSS projects for quite a few years now and just wanted to share my thoughts on how things could be improved).

Would you mind providing some more details around why you've chosen to not use a version and are sticking with 0.0.0? What benefits is this bringing you?

Basically the "advantages" of not versioning it, or reasons why we've not done it  are:

Shields.io itself is essentially a "rolling" release: We don't really version it for our own purposes.
We don't have to think about cutting releases. We merge PRs and dockerhub updates.
We've struggled to work to how/when to version. We use semver for the badge-maker library because it is relatively clearly defined how to determine what is a breaking change/feature/fix for a library or API. It is less clear what it means to make a breaking change when the deliverable is a website. I think the consensus we've arrived at is that calendar versioning makes more sense and solves that problem and we should just pick an interval rather than thinking of a release as a "milestone".

Personally I would like us to start versioning for self hosting users and providing some kind of changelog. We did talk about this at a recent core team meeting and I wrote up a plan for how we think we can start doing that in a relatively automated/low overhead way at https://github.com/badges/shields/issues/5866 . Nobody has started working on it (yet) but it is on my radar. I would like to pick it up soon. I think once we are creating tags on the repo it is relatively easy to have dockerhub create tagged builds too.
It is an infrequent occurrence, but the big advantage of versioning for me would be that it would make it easier to communicate about security issues. When we've published advisories affecting self-hosting users its is currently hard to say "if you're on version X or lower, you're vulnerable. Upgrade to version Y or higher to fix it". Putting out https://github.com/badges/shields/security/advisories/GHSA-pc52-cfhv-93g5 a few days ago has kind of re-focussed my mind on this.

Would you mind providing some more details around why you've chosen to not use a version and are sticking with 0.0.0? What benefits is this bringing you?

Basically the "advantages" of not versioning it, or reasons why we've not done it  are:

Shields.io itself is essentially a "rolling" release: We don't really version it for our own purposes.
We don't have to think about cutting releases. We merge PRs and dockerhub updates.
We've struggled to work to how/when to version. We use semver for the badge-maker library because it is relatively clearly defined how to determine what is a breaking change/feature/fix for a library or API. It is less clear what it means to make a breaking change when the deliverable is a website. I think the consensus we've arrived at is that calendar versioning makes more sense and solves that problem and we should just pick an interval rather than thinking of a release as a "milestone".

Personally I would like us to start versioning for self hosting users and providing some kind of changelog. We did talk about this at a recent core team meeting and I wrote up a plan for how we think we can start doing that in a relatively automated/low overhead way at https://github.com/badges/shields/issues/5866 . Nobody has started working on it (yet) but it is on my radar. I would like to pick it up soon. I think once we are creating tags on the repo it is relatively easy to have dockerhub create tagged builds too.
It is an infrequent occurrence, but the big advantage of versioning for me would be that it would make it easier to communicate about security issues. When we've published advisories affecting self-hosting users its is currently hard to say "if you're on version X or lower, you're vulnerable. Upgrade to version Y or higher to fix it". Putting out https://github.com/badges/shields/security/advisories/GHSA-pc52-cfhv-93g5 a few days ago has kind of re-focussed my mind on this.

we are expected to have some form of guaranteed stability, which one would normally expect to get from a "released" (or otherwise "tagged") version that is a reproducible binary/image from a given point in time.

@carlspring - I figured this was the case :+1: This tends to be the modus operandi in the corporate world, and I can definitely relate as it's the experience I have at my day job as well. I think the difference though with Shields as compared to say a product like Sonatype's Nexus is that we focus almost exclusively on the SaaS offering, with the on-prem/self-hosted being very minimal and secondary.
I run a self-hosted Shields server at my day job as well, and for some of these same reasons, I build the docker image from source which is then used for internal deployment. This is primarily driven by the need to not have stale components in there for security concerns, both from the app deps and the image itself (i also have to swap to an in-house base image for managing image updates)

I hope you view my notes and remarks as something constructive and useful

Absolutely! I felt like I had a sense of what you were looking for, and just wanted to provide detail on the self-hosted offering so you'd know what you're getting into: the only products that we offer and maintain today are Shields.io (SaaS) and the npm package, not a released/self-hosted version of the product that one typically thinks of in the enterprise world

It is an infrequent occurrence, but the big advantage of versioning for me would be that it would make it easier to communicate about security issues. When we've published advisories affecting self-hosting users its is currently hard to say "if you're on version X or lower, you're vulnerable. Upgrade to version Y or higher to fix it"

@chris48s - yeah I had this in the back of my mind too and almost mentioned it, but decided against it because, at least at this time, I feel like our guidance is always going to be: upgrade to latest. The case where I think it would probably be most useful would be something like #4655 where we'd potentially need to make a "breaking" change (which to my recollection hasn't happened since we started pushing to DHub)
This thread actually emphasizes some of the concerns I have about expanding/enhancing our offerings of the server itself, via Docker or otherwise, namely what should users be expecting from versioned releases? What would we have done with the recent advisory (or previous) relative to affected versions? Remove them? Release some kind of Patch for each released version with a fix (so CalVer.Something?). What about Dependabot-raised security alerts for direct/indirect dependencies? What about issues stemming from the base layers? And on and on it goes :smile:
There's a lot of reasonable assumptions users could make about what a released version means, and I think we need to have very explicit and obvious documentation about what we would/won't do for server versions to eliminate any ambiguity or interpretation.
What we've talked about so far would be (entirely my words) essentially: this is the server we had in source on this date. there's absolutely zero guarantees and zero support for this, use at your own discretion.

we are expected to have some form of guaranteed stability, which one would normally expect to get from a "released" (or otherwise "tagged") version that is a reproducible binary/image from a given point in time.

@carlspring - I figured this was the case :+1: This tends to be the modus operandi in the corporate world, and I can definitely relate as it's the experience I have at my day job as well. I think the difference though with Shields as compared to say a product like Sonatype's Nexus is that we focus almost exclusively on the SaaS offering, with the on-prem/self-hosted being very minimal and secondary.
I run a self-hosted Shields server at my day job as well, and for some of these same reasons, I build the docker image from source which is then used for internal deployment. This is primarily driven by the need to not have stale components in there for security concerns, both from the app deps and the image itself (i also have to swap to an in-house base image for managing image updates)

I hope you view my notes and remarks as something constructive and useful

Absolutely! I felt like I had a sense of what you were looking for, and just wanted to provide detail on the self-hosted offering so you'd know what you're getting into: the only products that we offer and maintain today are Shields.io (SaaS) and the npm package, not a released/self-hosted version of the product that one typically thinks of in the enterprise world

It is an infrequent occurrence, but the big advantage of versioning for me would be that it would make it easier to communicate about security issues. When we've published advisories affecting self-hosting users its is currently hard to say "if you're on version X or lower, you're vulnerable. Upgrade to version Y or higher to fix it"

@chris48s - yeah I had this in the back of my mind too and almost mentioned it, but decided against it because, at least at this time, I feel like our guidance is always going to be: upgrade to latest. The case where I think it would probably be most useful would be something like #4655 where we'd potentially need to make a "breaking" change (which to my recollection hasn't happened since we started pushing to DHub)
This thread actually emphasizes some of the concerns I have about expanding/enhancing our offerings of the server itself, via Docker or otherwise, namely what should users be expecting from versioned releases? What would we have done with the recent advisory (or previous) relative to affected versions? Remove them? Release some kind of Patch for each released version with a fix (so CalVer.Something?). What about Dependabot-raised security alerts for direct/indirect dependencies? What about issues stemming from the base layers? And on and on it goes :smile:
There's a lot of reasonable assumptions users could make about what a released version means, and I think we need to have very explicit and obvious documentation about what we would/won't do for server versions to eliminate any ambiguity or interpretation.
What we've talked about so far would be (entirely my words) essentially: this is the server we had in source on this date. there's absolutely zero guarantees and zero support for this, use at your own discretion.

The case where I think it would probably be most useful would be something like #4655 where we'd potentially need to make a "breaking" change (which to my recollection hasn't happened since we started pushing to DHub)

That's also a good point. Putting aside the issue that it is hard to define "breaking" when the deliverable isn't a library or API, I'd say we probably made a breaking change for self-hosting users a couple of months back (albeit one more likely to affect users who run from source): https://github.com/badges/shields/pull/5864 Either way, "breaking" or "non-breaking" it was a change we wanted to tell self-hosting users about. I agree that's another case where it would have been nicer if when we posted https://twitter.com/Shields_io/status/1330984982710525953 we could have said "support for .env files will be dropped in server-2020.12" or whatever. It would also have been nicer if it was in a changelog somewhere.

What would we have done with the recent advisory (or previous) relative to affected versions? Remove them? Release some kind of Patch for each released version with a fix (so CalVer.Something?)

I don't suggest doing either of those things and I don't think tagging the repo (or images) with a date implies we would, but if you're super worried it does we can add some notes in the self-hosting docs/security policy/wherever.

this is the server we had in source on this date. there's absolutely zero guarantees and zero support for this, use at your own discretion

Sure, so exactly what we do now really.. only if you follow tags, then you actually know what version you're running and might be able to look at a changelog and find out what changed since the last one :)

The case where I think it would probably be most useful would be something like #4655 where we'd potentially need to make a "breaking" change (which to my recollection hasn't happened since we started pushing to DHub)

That's also a good point. Putting aside the issue that it is hard to define "breaking" when the deliverable isn't a library or API, I'd say we probably made a breaking change for self-hosting users a couple of months back (albeit one more likely to affect users who run from source): https://github.com/badges/shields/pull/5864 Either way, "breaking" or "non-breaking" it was a change we wanted to tell self-hosting users about. I agree that's another case where it would have been nicer if when we posted https://twitter.com/Shields_io/status/1330984982710525953 we could have said "support for .env files will be dropped in server-2020.12" or whatever. It would also have been nicer if it was in a changelog somewhere.

What would we have done with the recent advisory (or previous) relative to affected versions? Remove them? Release some kind of Patch for each released version with a fix (so CalVer.Something?)

I don't suggest doing either of those things and I don't think tagging the repo (or images) with a date implies we would, but if you're super worried it does we can add some notes in the self-hosting docs/security policy/wherever.

this is the server we had in source on this date. there's absolutely zero guarantees and zero support for this, use at your own discretion

Sure, so exactly what we do now really.. only if you follow tags, then you actually know what version you're running and might be able to look at a changelog and find out what changed since the last one :)

I'd say we probably made a breaking change for self-hosting users a couple of months back (albeit one more likely to affect users who run from source): #5864

Yup, agreed! I was thinking about the Docker image with the next specifically where also agreed it almost certainly wouldn't have had real world impact because of how wonky it'd be to mount in the file instead of using more Docker friendly means, but it falls in the same category regardless.

Sure, so exactly what we do now really.. only if you follow tags, then you actually know what version you're running and might be able to look at a changelog and find out what changed since the last one :)

Agreed. It's more that current state is singular, constantly rolling/non-immutable tag on DockerHub, and we're moving to (as an augmentation of the current state) point-in-time tags that are immutable and have some associated change notes.

but if you're super worried it does we can add some notes in the self-hosting docs/security policy/wherever.

It's more so that I want to lean on the side of over communication rather than leaving anything to be interpreted subjectively by users, especially given some of the wording @carlspring used above:

we are expected to have some form of guaranteed stability

Maybe the type of documentation I'm suggesting is duplicative and it'll be clear to all users what a calversioned tagged release of the server means, but I'm not convinced that's the case. We do not do any testing with the Docker image itself (if the image builds then it's pushed), we don't use any of the Docker images for the Shields.io deployments, we don't do any actual integration/functional tests with a self-hosted instance (e.g. with configured credentials and against integrated tools/services).
The calver tag is just whatever happened to be at the HEAD whenever the publish job was triggered that month, with no real difference in validation/quality in the preceding nor proceeding commits, and it is whatever it is: we don't support it, we don't provide any guarantees, we're not going to patch it, etc.

I'd say we probably made a breaking change for self-hosting users a couple of months back (albeit one more likely to affect users who run from source): #5864

Yup, agreed! I was thinking about the Docker image with the next specifically where also agreed it almost certainly wouldn't have had real world impact because of how wonky it'd be to mount in the file instead of using more Docker friendly means, but it falls in the same category regardless.

Sure, so exactly what we do now really.. only if you follow tags, then you actually know what version you're running and might be able to look at a changelog and find out what changed since the last one :)

Agreed. It's more that current state is singular, constantly rolling/non-immutable tag on DockerHub, and we're moving to (as an augmentation of the current state) point-in-time tags that are immutable and have some associated change notes.

but if you're super worried it does we can add some notes in the self-hosting docs/security policy/wherever.

It's more so that I want to lean on the side of over communication rather than leaving anything to be interpreted subjectively by users, especially given some of the wording @carlspring used above:

we are expected to have some form of guaranteed stability

Maybe the type of documentation I'm suggesting is duplicative and it'll be clear to all users what a calversioned tagged release of the server means, but I'm not convinced that's the case. We do not do any testing with the Docker image itself (if the image builds then it's pushed), we don't use any of the Docker images for the Shields.io deployments, we don't do any actual integration/functional tests with a self-hosted instance (e.g. with configured credentials and against integrated tools/services).
The calver tag is just whatever happened to be at the HEAD whenever the publish job was triggered that month, with no real difference in validation/quality in the preceding nor proceeding commits, and it is whatever it is: we don't support it, we don't provide any guarantees, we're not going to patch it, etc.

We're now publishing tags to dockerhub: https://registry.hub.docker.com/r/shieldsio/shields/tags?page=1&ordering=last_updated
More context on this in the docs: https://github.com/badges/shields/blob/master/doc/releases.md#shields-server


$translateChangeSuccess event $emit instead of $broadcast?

I've been trying to use the $translateChangeSuccess in a scope. but it is not getting invoked. Looking at the code 950 - translate.js
It is emitting instead of broadcasting the event. Is that right?

Hello, @vanthiyathevan. Yes, such behavior is expected. You can find more information about events here: http://angular-translate.github.io/docs/#/guide/18_events

@DWand Thanks for the info.


chore: rename in PartialEquiv, Homeomorph, PartialHomeomorph

Items 4-5 in reference Zulip
Also added @[pp_dot] to symm and trans definitions for PartialEquiv, Homeomorph, and PartialHomeomorph.

I undid the addition of @[pp_dot] since it creates ambiguities in pretty printing in cases like e.toEquiv.symm for e : Homeomorph A B showing up as e.symm.
Also, do the symm and trans attributes make sense here?

bors r+


Time step vs. RoboRIO cycle

First, thank you for making this available -- it was super easy to add to our FRC robot code with gradle and we had the robot going in minutes.
Please help us understand the relationship between Time Step and RoboRIO cycle time. The command execute method is called pretty consistently every 0.02 seconds. Your example uses the time step of 0.05 seconds.
// Time Step:           0.05 Seconds
Should we try to stick with the standard 50Hz/20ms RoboRIO timing? If we use a larger time step, do you interpolate values for actual time when RoboRIO needs the input values? We haven't dug into the code enough to understand how this works and your guidance would be welcome.
Thank you!

The time step is how often your control loop is called. Generally, the higher, the better. You can tune it to whatever time period your code is running at, which in the case of timedrobot, is about 0.02. We use 0.05 as the default since pathfinder was written before timedrobot.


⚠ Bofrost.de has degraded performance

In 5f44a18, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 731 ms

Resolved: Bofrost.de performance has improved in c683048.


[BUG][SanityTest] Query on nested fields trigger "failed to query status"

What is the bug?
Query on nested fields trigger "failed to query status"
The underly Spark job works fine.

Seems a Flint bug

How can one reproduce the bug?
Steps to reproduce the behavior:

Go to Workbench page. For example https://search-flint05-sanity-h5if7yelmxws5hc35cap2lauf4.us-east-1.es-integ.amazonaws.com/_dashboards/app/opensearch-query-workbench#/
Execute a PPL query source = myglue_test.default.nested | fields int_col, struct_col.field1, struct_col2.field1 | head 10

What is the expected behavior?
Return correct results
What is your host/environment?

OS: [e.g. iOS]
Version [e.g. 22]
Plugins

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.
Do you have any additional context?
Add any other context about the problem.

So does query on date format fields
source = myglue_test.default.http_logs | eval c1 = data_add(@timestamp, 1) | eval c2 = data_sub(@timestamp, 1) | fields c1, c2 | head 10

[Catch All Triage - 1, 2]


Fix windows_package not allowing version to be an array

Due to the way the resource is built we need to be able to store an
array of current versions. I added some tests and comments so we don't
refactor this away later.
Signed-off-by: Tim Smith<EMAIL_ADDRESS>

Fixes https://github.com/chef/chef/issues/9806


merge master into staging

Motivation for this change
I want to push the rest of libcardiacarrest switch (see #35374), but it's a mass-rebuild, so I need this.
I'm sure I screwed up some of the src hashes, because some packages switched src sources. Currently building the new stdenv to check it.

[X] Conflicted src build.

Btw, @grahamc, is it possible to make ofborg test mergability with staging too?

@GrahamcOfBorg build systemd epoxy gtk3 python3Packages.asgiref python3Packages.daphne

Requesting review of the resolved conflicts from @shlevy @xeji @lsix @FRidh.

LGTM. No longer WIP.

Success on x86_64-linux (full log)
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/fzs4hf0cz880mdmws3y4vbixnnj8bns4-gtk+3-3.22.28-dev
shrinking /nix/store/fzs4hf0cz880mdmws3y4vbixnnj8bns4-gtk+3-3.22.28-dev/bin/gtk-query-immodules-3.0
shrinking /nix/store/fzs4hf0cz880mdmws3y4vbixnnj8bns4-gtk+3-3.22.28-dev/bin/gtk-builder-tool
shrinking /nix/store/fzs4hf0cz880mdmws3y4vbixnnj8bns4-gtk+3-3.22.28-dev/bin/gtk-encode-symbolic-svg
shrinking /nix/store/fzs4hf0cz880mdmws3y4vbixnnj8bns4-gtk+3-3.22.28-dev/bin/gtk-query-settings
gzipping man pages under /nix/store/fzs4hf0cz880mdmws3y4vbixnnj8bns4-gtk+3-3.22.28-dev/share/man/
strip is /nix/store/y2z2g4n8dsv0isjq36cjn9ldp8h9z3gs-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/fzs4hf0cz880mdmws3y4vbixnnj8bns4-gtk+3-3.22.28-dev/lib  /nix/store/fzs4hf0cz880mdmws3y4vbixnnj8bns4-gtk+3-3.22.28-dev/bin
patching script interpreter paths in /nix/store/fzs4hf0cz880mdmws3y4vbixnnj8bns4-gtk+3-3.22.28-dev
checking for references to /tmp/nix-build-gtk+3-3.22.28.drv-0 in /nix/store/fzs4hf0cz880mdmws3y4vbixnnj8bns4-gtk+3-3.22.28-dev...

pkgs/development/libraries/epoxy/default.nix LGTM.

Success on aarch64-linux (full log)
Partial log (click to expand)
gzipping man pages under /nix/store/xixyabhd06g78yxw0jxp9hsg6h88jry2-gtk+3-3.22.28-dev/share/man/
strip is /nix/store/fib7s4bkwwh54jz3b9yhb3sqmlcdks0n-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/xixyabhd06g78yxw0jxp9hsg6h88jry2-gtk+3-3.22.28-dev/lib  /nix/store/xixyabhd06g78yxw0jxp9hsg6h88jry2-gtk+3-3.22.28-dev/bin
patching script interpreter paths in /nix/store/xixyabhd06g78yxw0jxp9hsg6h88jry2-gtk+3-3.22.28-dev
checking for references to /build in /nix/store/xixyabhd06g78yxw0jxp9hsg6h88jry2-gtk+3-3.22.28-dev...
/nix/store/6i8vby3isp29dg4kr0dvizkia1ynwf3w-systemd-237
/nix/store/4b561rwsn4rjp2j0mazszldj7a1w9lp3-epoxy-1.5.0
/nix/store/9bcla3zsicha9aaflb968zrqx78mrc2n-gtk+3-3.22.28
/nix/store/d92cz4pwcr2igz9lrd4kbqahfsyxc6j4-python3.6-asgiref-2.2.0
/nix/store/j5zqn3apnhc5gq1bgmsc08gmzjcaisxl-python3.6-daphne-2.1.0

Thanks. Paths with conflicts:
        both modified:   pkgs/development/libraries/epoxy/default.nix
        both modified:   pkgs/development/libraries/gtk+/3.x.nix
        both modified:   pkgs/development/python-modules/asgiref/default.nix
        both modified:   pkgs/development/python-modules/daphne/default.nix
        both modified:   pkgs/os-specific/linux/systemd/default.nix

The Python modules look fine.
@shlevy @aszlig can you check the merge of systemd?

@FRidh: :+1: - Diffed against a rebase and the contents of systemd/default.nix match with the contents of the merge commit.

Will merge at the sooner of @lsix's positive review or a day.

Hi all, sorry for the delay.
I have checked and tested the parts I am involved with. Everything is fine for me.
@shlevy you can merge when you like.


Library not loaded: @rpath/GTMSessionFetcher.framework/GTMSessionFetcher

On iOS the app launches and crashes on splash screen. It is looking for GTMSessionFetcher. "GTMSessionFetcher makes it easy for Cocoa applications to perform http operations."  Why is this needed in this Viro starter kit?
dyld[64201]: Library not loaded: @rpath/GTMSessionFetcher.framework/GTMSessionFetcher
  Referenced from: <user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/ViroKit.framework/ViroKit
  Reason: tried: '~/starter-kit/ios/DerivedData/myviroapp/Build/Products/Debug-iphonesimulator/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/ViroKit.framework/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/../../Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/ViroKit.framework/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 15.2.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '/usr/lib/swift/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 15.2.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '/usr/lib/swift/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 15.2.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file)
Library not loaded: @rpath/GTMSessionFetcher.framework/GTMSessionFetcher
  Referenced from: <user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/ViroKit.framework/ViroKit
  Reason: tried: '~/starter-kit/ios/DerivedData/myviroapp/Build/Products/Debug-iphonesimulator/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/GTMSessionFetcher.framework/GTMSessionFetcher' (no such file),
   '<user path>/Library/Developer/CoreSimulator/Devices/81337AB7-6E0C-416B-BFAA-3D5C417E2F7D/data/Containers/Bundle/Application/F5494F8F-2D62-4658-A6EC-FFC40DD8515F/myviroapp.app/Frameworks/ViroKit.framework/Frameworks/GTMSessionFetcher.framework/
(lldb)

Please let me know if more information is needed.

Hi i getting this issue also. Did u able to fix?

+1

+1

Can you try again with the latest code? I've updated to React Native 0.73


is.Email not working for<EMAIL_ADDRESS>

I am using this code and getting Error Email must be a valid email address so it seems not working for custom domains ?
func Validate()  {
	errors := validation.ValidateStruct(&a,
		validation.Field(&a.ID, validation.Required),
		validation.Field(&a.Email, validation.Required, is.Email),
	)
       fmt.Println(errors)
}

I think this is related to https://github.com/asaskevich/govalidator/pull/382
Can you update the govalidator package into your module so issue can fixed ?
I tested the govalidator package and it's working good. So please fix the issue ASAP my application is dependent on your package.
Working Playground: https://play.golang.org/p/Dao-5eF-ZMR
package main

import "github.com/asaskevich/govalidator"

func main() {

	type User struct {
		Email string `valid:"email"`
	}
	result, err :=<EMAIL_ADDRESS>	if err != nil {
		println("error: " + err.Error())
	}
	println(result)
}

I figured it out isEmail do the MX lookup and fails.
I used validation.Field(&a.Email, validation.Required, is.EmailFormat) and it works great.


Value based heatmap

Hi, this is a great project! It would be nice to be able to support values that are not measured as time. I have a requirement where I just want the number of occurrences in a day however because the map deals with totals and values as time it makes the month, week and day views blank.

Hi! that is a good point, at the moment the visualization is focused on time series data but I would love to see it become more generic in the future.
I know some people managed to tweak the timeline to fit their specific use case, but not something that is generalizable to support most values - including but not limited to time based values.

Up,
It would be nice to have a value based heat map with tool-tip templates so we can display different values.

Interesting suggestion, what kind of values (if not time) are used in your example and what would the tooltip template look like?
PS. as long as this feature is not strictly related to angular 2 you could add the suggestion to the main repo vanilla js version: github.com/g1eb/calendar-heatmap

For example number of events per day.
For the tool tip  template it should be set in the configuration as HTML.
Website: https://raed.it
Tel: (+33) 06 44 71 53 30
PGP: 0x034D9395
894B 45E3 BD8C A40C 85A6 8CA1 8AD8 803C 034D 9395
On Oct 17, 2017 4:16 PM, "Gleb"<EMAIL_ADDRESS>wrote:

Interesting suggestion, what kind of values (if not time) are used in your
example and what would the tooltip template look like?
PS. as long as this feature is not strictly related to angular 2 you could
add the suggestion to the main repo vanilla js version:
github.com/g1eb/calendar-heatmap
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/g1eb/angular2-calendar-heatmap/issues/3#issuecomment-337245798,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYDgkANfu6cO78TyNIIVKwZOGMRQhMmks5stLa6gaJpZM4OJh8-
.

Hello , is there an update for this request?
Is there a way to use a value instead of times - like the count of events for that particular day.
Also, is there a way to display the days without data with a different color.
For example, if the data is not passed for a particular day - I would display it in green color  and the total values in tooltip will be 0. @g1eb

Hi svsgdev, unfortunately there is no update on this yet.
I would like to make the heatmap more generic and applicable to other projects not based on time-series data. As it stands the library is pretty lightweight and works well for what it was originally designed to do.
I would need more time to come up with a generalized solution that would be open to new types of data, display customization and other features while still being maintainable and lightweight.

Hey @g1eb  great work !
is it possible to make as is like cal-heat map like tiles arranged as calendar

We don't have color code for each specific data element and if data is null we can set some default color instead of having global color.
And if we can have option of custom width and height that is great and appreciable.

Hi! Apologies for the late reply, generalization of this component has been raised before.
At this point I'm not sure if it would be easier to start a new library for it instead.
I've been able to tweak the source to fit my needs, including the example you posted above.
For what you want, I'd recommend forking the repo and playing around until satisfied :)


Error: Parameter token or opts.auth is required

Receiving the error "Parameter token or opts.auth is required" when running an example configuration on a test organization and repo.  Attached are the yaml file (renamed .txt for upload) and the action output.
err.log
main.yml.txt

What was the solution here? I’m running into the same issue.


Unable to build rust "hello world" on aarch64-darwin

Describe the bug
oxalica was previously working, but I'm suddenly getting an Operation not permitted error for /private/etc/ssl/openssl.cnf that is prohibiting even a rust "hello world" from building on aarch64-darwin.
Oddly nix develop and nix develop -c cargo build works. buildRustPackage works fine if I use it from nixpkgs and only gives this error when I'm using it from the oxalica toolchain, so this may not be a oxalica problem (in which case I apologize), but that's why I opened the issue here.
I wonder if my recent update to Sonoma 14.2 (23C64) may be the culprit?
Steps To Reproduce
Using this as flake.nix:
{
  description = "Basic template for nix + rust";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    rust-overlay = {
      url = "github:oxalica/rust-overlay";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  outputs = {
    self,
    nixpkgs,
    rust-overlay,
  }: let
    system = "aarch64-darwin";
    pkgs = import nixpkgs {
      inherit system;
      overlays = [
        (import rust-overlay)
      ];
    };
    toolchain = pkgs.rust-bin.stable.latest.default;
    rustPlatform = pkgs.makeRustPlatform {
      rustc = toolchain;
      cargo = toolchain;
    };
    name = "foo";
  in {
    packages.${system} = {
      default = self.packages.${system}.${name};
      ${name} = rustPlatform.buildRustPackage {
        inherit name;
        version = "0.0.1";
        src = ./.;
        cargoLock.lockFile = ./Cargo.lock;
      };
    };

    apps.${system}.default = {
      type = "app";
      program = "${self.packages.${system}.${name}}/bin/${name}";
    };

    devShells.${system}.default = pkgs.mkShell {
      buildInputs = [toolchain];
    };
  };
}

To reproduce:
$ nix develop
$ cargo init --name foo
     Created binary (application) package
$ cargo update
$ exit
$ git add .
$ nix build
error: builder for '/nix/store/h05s2pzw6qb5m50njk0vr7j6cimhcxmj-foo.drv' failed with exit code 1;
       last 10 log lines:
       > Finished cargoSetupPostPatchHook
       > Running phase: updateAutotoolsGnuConfigScriptsPhase
       > Running phase: configurePhase
       > Running phase: buildPhase
       > Executing cargoBuildHook
       > ++ env CC_AARCH64_APPLE_DARWIN=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/cc CXX_AARCH64_APPLE_DARWIN=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/c++ CARGO_TARGET_AARCH64_APPLE_DARWIN_LINKER=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/cc CC_AARCH64_APPLE_DARWIN=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/cc CXX_AARCH64_APPLE_DARWIN=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/c++ CARGO_TARGET_AARCH64_APPLE_DARWIN_LINKER=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/cc CARGO_BUILD_TARGET=aarch64-apple-darwin HOST_CC=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/cc HOST_CXX=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/c++ cargo build -j 8 --target aarch64-apple-darwin --frozen --profile release
       > Auto configuration failed
       ><PHONE_NUMBER>:error:02FFF001:system library:func(4095):Operation not permitted:/AppleInternal/Library/BuildRoots/0032d1ee-80fd-11ee-8227-6aecfccc70fe/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/crypto/bio/bss_file.c:122:fopen('/private/etc/ssl/openssl.cnf', 'rb')
       ><PHONE_NUMBER>:error:20FFF002:BIO routines:CRYPTO_internal:system lib:/AppleInternal/Library/BuildRoots/0032d1ee-80fd-11ee-8227-6aecfccc70fe/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/crypto/bio/bss_file.c:127:
       ><PHONE_NUMBER>:error:0EFFF002:configuration file routines:CRYPTO_internal:system lib:/AppleInternal/Library/BuildRoots/0032d1ee-80fd-11ee-8227-6aecfccc70fe/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/crypto/conf/conf_def.c:202:
       For full logs, run 'nix log /nix/store/h05s2pzw6qb5m50njk0vr7j6cimhcxmj-foo.drv'.

Full log:
$ nix log /nix/store/h05s2pzw6qb5m50njk0vr7j6cimhcxmj-foo.drv
@nix { "action": "setPhase", "phase": "unpackPhase" }
Running phase: unpackPhase
unpacking source archive /nix/store/c901gw0lcjmnknifw9cfylci0s8m0d66-fz3xf2fz0i6smfp131diaw8msdniygfd-source
source root is fz3xf2fz0i6smfp131diaw8msdniygfd-source
Executing cargoSetupPostUnpackHook
Finished cargoSetupPostUnpackHook
@nix { "action": "setPhase", "phase": "patchPhase" }
Running phase: patchPhase
Executing cargoSetupPostPatchHook
Validating consistency between /private/tmp/nix-build-foo.drv-0/fz3xf2fz0i6smfp131diaw8msdniygfd-source/Cargo.lock and /private/tmp/nix-build-foo.drv-0/cargo-vendor-dir/Cargo.lock
Finished cargoSetupPostPatchHook
@nix { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" }
Running phase: updateAutotoolsGnuConfigScriptsPhase
@nix { "action": "setPhase", "phase": "configurePhase" }
Running phase: configurePhase
@nix { "action": "setPhase", "phase": "buildPhase" }
Running phase: buildPhase
Executing cargoBuildHook
++ env CC_AARCH64_APPLE_DARWIN=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/cc CXX_AARCH64_APPLE_DARWIN=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/c++ CARGO_TARGET_AARCH64_APPLE_DARWIN_LINKER=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/cc CC_AARCH64_APPLE_DARWIN=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/cc CXX_AARCH64_APPLE_DARWIN=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/c++ CARGO_TARGET_AARCH64_APPLE_DARWIN_LINKER=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/cc CARGO_BUILD_TARGET=aarch64-apple-darwin HOST_CC=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/cc HOST_CXX=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/c++ cargo build -j 8 --target aarch64-apple-darwin --frozen --profile release
Auto configuration failed
8082083840:error:02FFF001:system library:func(4095):Operation not permitted:/AppleInternal/Library/BuildRoots/0032d1ee-80fd-11ee-8227-6aecfccc70fe/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/crypto/bio/bss_file.c:122:fopen('/private/etc/ssl/openssl.cnf', 'rb')
8082083840:error:20FFF002:BIO routines:CRYPTO_internal:system lib:/AppleInternal/Library/BuildRoots/0032d1ee-80fd-11ee-8227-6aecfccc70fe/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/crypto/bio/bss_file.c:127:
8082083840:error:0EFFF002:configuration file routines:CRYPTO_internal:system lib:/AppleInternal/Library/BuildRoots/0032d1ee-80fd-11ee-8227-6aecfccc70fe/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/crypto/conf/conf_def.c:202:

Expected behavior
nix build was previously working for me.
Notify maintainers
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"aarch64-darwin"`
 - host os: `Darwin 23.2.0, macOS 14.2`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(n8henrie): `""`
 - channels(root): `""`
 - nixpkgs: `/nix/store/g9cdcpm9vndl47dmkbi32073zxn0qn4g-source`

Add a :+1: reaction to issues you find important.

The above flake builds and runs fine on x86_64-linux.
I get the same failure trying the beta toolchain (latest, default) on aarch64-darwin.
I'm not finding any relevant issues googling or searching nixpkgs issues for "/private/etc/ssl/openssl.cnf" or "Auto configuration failed".

I don't see anything interesting about that file:
$ stat /private/etc/ssl/openssl.cnf
  File: /private/etc/ssl/openssl.cnf
  Size: 745             Blocks: 8          IO Block: 4096   regular file
Device: 1,25    Inode: 463498578   Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/   wheel)
Access: 2023-12-05 00:37:15.000000000 -0700
Modify: 2023-12-05 00:37:15.000000000 -0700
Change: 2023-12-12 12:15:52.130035727 -0700
 Birth: 2023-12-05 00:37:15.000000000 -0700

Actually, looks like it's a sandbox issue:
$ nix build --option sandbox false
$ echo $?
0
$ nix run
Hello, world!

I imagine this should get moved to https://github.com/NixOS/nix/issues


community: remove unused verify_ssl kwarg from aiohttp request

it's not a valid kwarg in aiohttp request

Now self.verify isn't honored anymore and SSL validation is enabled by default with no option for LangChain users to disable it for async requests. Maybe a better solution would've been to add ssl=bool(self.verify) as a keyword argument since ssl supersedes verify_ssl.


OrderBook() crashes

Crash with OrderBook()
C:\>C:\Python36-64\python.exe c:\python36-64\lib\site-packages\gdax\order_book.py
Traceback (most recent call last):
  File "c:\python36-64\lib\site-packages\gdax\order_book.py", line 236, in <module>
    order_book = OrderBook()
  File "c:\python36-64\lib\site-packages\gdax\order_book.py", line 20, in __init__
    self._client = PublicClient(product_id=product_id)
TypeError: __init__() got an unexpected keyword argument 'product_id'

Indeed PublicClient is not expecting any product_id parameter:
def __init__(self, api_url='https://api.gdax.com'):
        """Create GDAX API public client.

        Args:
            api_url (Optional[str]): API URL. Defaults to GDAX API.

        """
        self.url = api_url.rstrip('/')

@illera88 We made a decision quite some time ago to not include product_id in init to ensure each call is being made as expected.  Since your implementation may vary, feel free to add self.product_id!  If more people request it, a PR might be a way to attract attention to the idea.
Thanks for your support!
Dan

I am having the same issue. Running the example results in above error:
import gdax, time
order_book = gdax.OrderBook(product_id='BTC-USD')
order_book.start()
time.sleep(10)
order_book.close()

If I remove product_id=product_id from self._client = PublicClient(product_id=product_id) then I get the next error:
File "/usr/local/lib/python3.6/site-packages/gdax/order_book.py", line 22, in __init__
self._log_to = log_to
NameError: name 'log_to' is not defined


Pretty-printing checked output is not equal to pretty-printing unchecked output

Consider the following example:
-- | The Martin-Löf equality type.
data Eq(implicit a: Type, x y: a) {
    -- | The reflexivity constructor.
    Refl(implicit a: Type, x: a): Eq(a:=a, x, x)
}

-- | Proof of symmetry of equality.
def Eq(x, y).sym(implicit a: Type, x y: a): Eq(a:=a, y, x) {
    Refl(a, x) => Refl(a:=a, x)
}

Our dependent pattern matching substitutes  the unification not only on the rhs's expected type but also on the rhs expression. This means that the AST changes during typechecking.
Therefore, it makes a difference whether we pretty-print the checked vs. the unchecked output:
cargo run -- fmt examples/foo.pol
-- | The Martin-Löf equality type.
data Eq(implicit a: Type, x y: a) {
    -- | The reflexivity constructor.
    Refl(implicit a: Type, x: a): Eq(a:=a, x, x)
}

-- | Proof of symmetry of equality.
def Eq(x, y).sym(implicit a: Type, x y: a): Eq(a:=a, y, x) { Refl(a, x) => Refl(a:=a, x) }

cargo run -- fmt --checked examples/foo.pol
-- | The Martin-Löf equality type.
data Eq(implicit a: Type, x y: a) {
    -- | The reflexivity constructor.
    Refl(implicit a: Type, x: a): Eq(a:=a, x, x)
}

-- | Proof of symmetry of equality.
def Eq(x, y).sym(implicit a: Type, x y: a): Eq(a:=a, y, x) { Refl(a, x) => Refl(a:=<a>, y) }

Here is one idea I had about how to solve this: First, observe that substitution only changes variables. So we could change the AST node for variables to add an extra field:
struct Variable {
    ...,
    /// Elaborated due to dependent. pattern matching.
    elaborated: Option<Exp>
 }

And then we define an operation elaborate which is just like substitution, but fills in this elaboration instead of replacing the variable. We could also avoid code duplication by reusing the substitution code appropriately.


fix: set hook for email change when only phone identity present

What kind of change does this PR introduce?
Currently, there is no token passed in into the email hook when an email change is attempted right after a phone sign up.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>7
Details

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 57.268%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

internal/api/mail.go
0
1
0.0%

Totals

Change from base Build<PHONE_NUMBER>1:
0.0%

Covered Lines:
9696

Relevant Lines:
16931

💛  - Coveralls

Are you ready to move this out of draft @J0 - change looks good.

Thanks for looking through the PRs! Have manually tested here but wanted to also:

Document the expected behaviour with secure / non-secure email change as it's currently not surfaced in the docs
a. Email Change (w/o secure)  - new_token and new_token_hash should be populated
b. Secure Email Change - new_token, token, new_token_hash and token_hash should all be populated in the hook payload
Maybe write an automated test (maybe a contract test like mentioned in channel) but not sure where it'd live as not sure we should introduce a framework solely for htis PR


1.12 fluid crafting gets confused

i'm not really sure what's going on here, but here's what i have:

an RS Crafter pointing into a Portable Tank. the Crafter contains:

fluid processing recipe 0.2 B Liquefacted Coal -> 0.1 B Naptha
fluid processing recipe 0.15 B Naptha -> 0.1 B Refined Fuel

pulling from the tank, a fractionating still, and fluiducts pumping the output back into an RS Interface.
several buckets of Liquefacted Coal in the RS storage

when I craft 1000mb Refined Fuel in the Fluid Grid, the amount of Naptha goes down 1 bucket, and then slowly increases back to the original value. no Refined Fuel is created.
Version (make sure you are on the latest version before reporting):
FTB Academy

Minecraft: 1.12.2
Forge: <IP_ADDRESS>46
Refined Storage: 1.6.15

Does this issue occur on a server? yes
the logs show the folloing repeated several times:
[13:56:53] [Server thread/WARN] [com.raoulvdberge.refinedstorage.apiimpl.autocrafting.task.CraftingTask]: null unexpectedly didn't accept items, the remainder has been voided!

That sounds like the naptha is being put into the tank and then imported without ever going through the fractioning still. Make sure to watch the process to see what is happening.
The error message says items and that means some inventory is reporting it is able to accept items but then does not. As your described pattern only contains fluids it can not be the reason for that message.
Images are always a good idea to share when looking at logistical issues. Pictures of your setup would go a long way towards making sure I don't have to ask unnecessary questions.

i don't think it's being imported from the tank. I tried watching it in the crafting monitor, but i don't really understand what it's telling me.
that error message only occurs when i try the fluid crafting recipe., and it starts exactly after i click 'Start' on that recipe, and repeats 10 times and then stops.
here's a pic:

in the foreground you can see the underside of the crafter pointing into the portable tank, the fluiduct pulls from the tank into the side of the still, and the other fluiduct pulls from the bottom of the still away to a fluid interface off to the right. [[ i originally had the crafter point into the back of the still, but that didn't work either, so i added the tank. ]]

The problem is most likely the servo at the bottom of the machine extracting from the input. Almost all thermal machines do automatically output as long as they are configured normally. Also make sure that the sides are configured correctly. (left side blue bottom orange nothing else).
Double-check your recipe to see if there are any items on it that could cause that message.

i'm going to close this, as i now think it's a thermal issue. i removed all the RS stuff and it still acts weirdly... it's pumping the input out from the bottom even though it's not configured to do this. thanks for your help!

incidentally, it was the servo on the bottom of the still that was causing the issue. even though the still's bottom side was only bound to the output tank, the servo on that side was pulling from the input. removing the servo and enabling auto-output fixed the issue....

Thanks that's actually really helpful. Not the first time I've seen similar issues. Kinda glad to know it's thermal that is the problem.


Add Drag and Drop Functionality to the Smart Compressor

Hello,
I have a suggestion to enhance the usability of the Smart Compressor project by adding a drag and drop feature for file uploads. Currently, users must manually select files for compression, which might be less intuitive for some users. A drag-and-drop option would:
Improve the user experience by making file selection faster and easier.
If needed, I can contribute to implementing this feature.
Thank you for considering my suggestion!

Hello,
I have a suggestion to enhance the usability of the Smart Compressor project by adding a drag and drop feature for file uploads. Currently, users must manually select files for compression, which might be less intuitive for some users. A drag-and-drop option would:
Improve the user experience by making file selection faster and easier.
If needed, I can contribute to implementing this feature.
Thank you for considering my suggestion!

@yashshree7 This is great idea! Can you propose solution and couple of screenshots for same

Attached screenshots for the same.

Attaching Screenshots for the same.

Attaching Screenshots for the same.

Looks great! I have created new branch please go ahead with PR. Thank you

Sure, Thank you.


1.20.2 Version?

Would it be possible to get a version for 1.20.2? If not, I understand completely.

No plans.  Seems like the community is mostly on 1.20.1 or 1.20.4. I did look at 1.20.2 briefly and there are a good number of changes I would have to make to make it compatible. Keeping up with both 1.20.1 and 1.20.4 is taking up most of my modding time.

Okay, that makes sense.


Event driver not properly initialized

I'm trying to build the REST API with HTTPServerOption.distribute on but it often fails with:
Worker thread terminated due to uncaught error: No event driver loaded. Did the vibe.core.core module constructor run?
after startup.
I'm on windows 8.1 x86_64, vibe latest alpha, compiled with libevent configuration, dmd 2.068.1

I recommend DMD 2.067.1,  due to a struct dtor issue in 2.068+
I also don't think the distribute option should exist. You should either run worker tasks and send/receive in vibe.core.concurrency at higher level for compute-intensive jobs, or create multiple processes listening to different ports serving a load balancer.

I noticed the same behavior when calling runWorkerTaskH
It seems to be new with 2.068.1 because it works ok with 2.068.0

Ok, I've made a sample to reproduce it.
Just used upload sample from examples with a added worker thread after fileupload.
http://pastebin.com/9mj6MSkU
When used without custom main (same as in vibe.d sources) it works. When used with custom main, it fails.
At least with dmd 2.068.1 and 2.068.2-b1 on windows x86_64 with default libevent driver.
It is ok on linux and same windows with 2.068.0

I recommend DMD 2.067.1, due to a struct dtor issue in 2.068+ which wasn't patched yet in vibe.d

Do you have more details about this @etcimon?

@MartinNowak, see also #1240.

I've tried this again at home on linux and there is an error with dmd-2.068.1, but not with dmd-2.068.2-b1 or dmd-2.068.0 so I think, this can be closed

I saw the same problem with 2.068.1 in one of my projects, and can confirm it's gone in 2.068.2-b1.