Fix HostMetricsResponse unit test

Description
The unit tests of class HostMetricsResponse will fail when they are executed on machines with locale other than en_US. This happens because locales can have distinct decimal separators, for instance, . in en_US and , in pt_BR.
This PR solves the mentioned problem by modifying the tests to use the decimal separator character according to the Locale set on the local machine (which is running the tests), instead of using a hardcoded decimal separator.
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[x] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[x] Minor
[ ] Trivial

How Has This Been Tested?
I ran the unit tests of class HostMetricsResponse with locale pt_BR and en_US. In both cases, the tests passed.

If packaging succeeds it compiles and the test is good. No testing needed as it is a unit test only.
@blueorangutan package

@DaanHoogland a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 1785

@joseflauzino if you want this in 4.16.1 please rebase. otherwise just wait for a second review and we are good to merge.

@DaanHoogland we can keep in main (4.17).
Thanks

Merging based on 2x LGTM (https://github.com/apache/cloudstack/pull/5713#pullrequestreview-815700415 and https://github.com/apache/cloudstack/pull/5713#pullrequestreview-815996701) and package results (https://github.com/apache/cloudstack/pull/5713#issuecomment-979016151).


Option to force or manually switch to software encoding mode

In my Nvidia Optimus laptop, on Linux, after installing optimus-manager as mentioned in issue #741 , I have come across another issue.
ALVR does not support hardware encoding on Nvidia GPUs currently, and as a result VAAPI should report a failure on startup before it falls back to software encoding.
Unfortunately for my system, it seems like VAAPI has found some way to not fail, at least according to the lack of reporting it in the logs, and as a result I am getting a black screen to the headset.
I suspect it is trying to render on the Intel GPU even though it is disabled, although even when I switch to Intel graphics only it does the same thing, so it must be a general Intel issue.
A simple solution, at least for until hardware encoding can be properly supported on these GPUs, would be to add an option to bypass hardware encoding.

A temporary patch to work around this issue:
diff --git a/alvr/server/cpp/platform/linux/EncodePipeline.cpp b/alvr/server/cpp/platform/linux/EncodePipeline.cpp
index a0c1ca08..537fb13d 100644
--- a/alvr/server/cpp/platform/linux/EncodePipeline.cpp
+++ b/alvr/server/cpp/platform/linux/EncodePipeline.cpp
@@ -65,12 +65,6 @@ void filter_NAL(const uint8_t* input, size_t input_size, std::vector<uint8_t> &o

 std::unique_ptr<alvr::EncodePipeline> alvr::EncodePipeline::Create(std::vector<VkFrame> &input_frames, VkFrameCtx &vk_frame_ctx)
 {
-  try {
-    return std::make_unique<alvr::EncodePipelineVAAPI>(input_frames, vk_frame_ctx);
-  } catch (...)
-  {
-    Info("failed to create VAAPI encoder");
-  }
   return std::make_unique<alvr::EncodePipelineSW>(input_frames, vk_frame_ctx);
 }


autocompletion fails with "translate-x/y-" (but works with "translate-")

As discussed here:
https://github.com/tw-in-js/typescript-plugin/issues/8
...the hover preview of raw CSS, and the error highlighting both work fine. It is just the completion that fails.
translate-14 autocompletes fine (after the dash -), but translate-x-14 fails.
I am filing this here as I suspect the issue is in the VSCode extension, rather than in Twind core (i.e. where the transform tokens are defined).

Should be fixed with<EMAIL_ADDRESS>

Great thanks :)

And there is a new version this plugin with better autocomplete, context aware hover (depending on active grouping) and warnings for unknown variants.


add support for valueLink

@gabro
usually React components work with value and onChange but our datepicker accepts date instead of value.
Do you think we should standardize it?
PS: valueLink support can be added also if we keep date

Let's use value, it makes more sense in the context of standard components API

agreed

for the change of the API please refer to this issue: #39


Playready on Edge

Have you read the FAQ and checked for duplicate open issues?
yes
What link can we use to reproduce this?
https://shaka-player-demo.appspot.com/demo/#audiolang=pt-BR;textlang=pt-BR;uilang=pt-BR;asset=https://test.playready.microsoft.com/media/dash/APPLEENC_CBCS_BBB_1080p/1080p_alternate.m3u8;panel=ALL_CONTENT;panelData=drm:PLAYREADY;build=uncompiled
What version of Shaka Player are you using?
v3.3.1-uncompiled
What browser and OS are you using?
Edg/97.0.1072.69 Windows 10 Pro
What did you do?
I played a playready-only video on shaka player demo and received an 6001 error (Shaka Error DRM.REQUESTED_KEY_SYSTEM_CONFIG_UNAVAILABLE ()).
What did you expect to happen?
I expected the video to play correctly since in other players it was possible to play videos with playready only.
What actually happened?
The browser and OS supports playready drm, but shaka apparently not.

It's possible that the request key system config is truly unavailable.  It could be the wrong configuration, or it could be that something is wrong or missing on your system.
Can you please copy and paste the results of this page for us?  https://shaka-player-demo.appspot.com/support.html  Thanks!

Yes, sure!
  Shaka Player does support PlayReady, and you can try other PlayReady content in our demo to confirm that.
However, some aspect of this content causes the check to fail.  Things like container, codec, etc are passed to the EME API to check if it can be decrypted and played.  I would suggest that either:

Some detail of the content is being rejected by PlayReady
OR we are sending the wrong details to PlayReady through EME

Thank you for giving us such a simple repro case, though.  Any volunteers to debug this through DrmEngine, MediaCapabilities, etc?
https://shaka-player-demo.appspot.com/demo/#audiolang=pt-BR;textlang=pt-BR;uilang=pt-BR;asset=https://test.playready.microsoft.com/media/dash/APPLEENC_CBCS_BBB_1080p/1080p_alternate.m3u8;panel=ALL_CONTENT;panelData=drm:PLAYREADY;build=uncompiled

The m3u8 playlist does not provide value in CODECS tag for audio
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=4333805,BANDWIDTH=10968495,CODECS="avc1.64002a",RESOLUTION=1920x1080,FRAME-RATE=60.000,CLOSED-CAPTIONS=NONE,AUDIO="ac-3"
video/prog_index.m3u8

requestMediaKeySystemAccess() then fails with
MediaCapabilities.decodingInfo() failed. {"type":"media-source","video":{"contentType":"video/mp4; codecs=\"avc1.64002a\"","width":1920,"height":1080,"bitrate":4333805,"framerate":60},"audio":{"contentType":"audio/mp4; codecs=\"avc1.64002a\"","channels":2,"bitrate":4333805,"samplerate":1,"spatialRendering":false},"keySystemConfiguration":{"keySystem":"com.microsoft.playready","initDataType":"cenc","persistentState":"optional","distinctiveIdentifier":"optional","sessionTypes":["temporary"],"audio":{"robustness":""},"video":{"robustness":""}}} DOMException: Unsupported keySystem or supportedConfigurations.
as video codec is used for audio as well.

Ah, that makes sense.  With only one codecs value for a variant with audio, the HLS parser gets confused.  It could probably be fixed to default to mp4a.40.2 in situations like this.


Update FilterValidator.php

fixing: trim(): Passing null to parameter 1 ($string) of type string is deprecated on PHP 8.2

Q
A

Is bugfix?
✔

New feature?
❌

Breaks BC?
❌

Fixed issues

There is a TrimValidator for that case now, please use it.


Feature Viewer

Added ProteinFeatureViewer component to allow a user to submit a query to European Biomatics Institute to fetch protein data and display the domain data in...
The new FeatureViewer component! Displays 1D data as either grouped or ungrouped, with callback to set potential annotation data.
Also added ColorMapper to more easily assign colors to data labels for faster retrieval.

 timebox 2 days: domain diagram with range selector


Fails prematurely due to miscalculated elapsed time

Please look at the timestams and the message in this log
2024-04-30T13:21:22.8890775Z [INFO] Running foo.Bar
2024-04-30T13:21:23.0238921Z 13:16:17 INFO  [foo.Bar] (main) Starting evaluation
2024-04-30T13:21:23.0575168Z 13:16:22 INFO  [foo.Bar] (main) Condition foo.Bar$$Lambda/0x00007f344253f6d8 was not fulfilled within 5 seconds.
2024-04-30T13:21:23.1000272Z 13:16:23 INFO  [foo.Bar] (awaitility-thread) Callable condition returned false (elapsed time 6100 milliseconds, remaining time -1100 milliseconds (last poll interval was 100 milliseconds))

As can be seen, Awaitility claims to have waited 6100 ms while the clock has ticked some ~76 ms.
Have so far only been able recreate this running as a GitHub Action, where however it seems consistent.
Stacktrace:
2024-04-30T13:21:23.1002692Z org.awaitility.core.ConditionTimeoutException: Condition foo.Bar$$Lambda/0x00007f344253f6d8 was not fulfilled within 5 seconds.
2024-04-30T13:21:23.1003061Z 	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
2024-04-30T13:21:23.1003362Z 	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
2024-04-30T13:21:23.1003651Z 	at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
2024-04-30T13:21:23.1003935Z 	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
2024-04-30T13:21:23.1004219Z 	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:954)
...
2024-04-30T13:21:23.1008130Z Caused by: java.util.concurrent.TimeoutException
2024-04-30T13:21:23.1008400Z 	at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
2024-04-30T13:21:23.1008762Z 	at org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101)
2024-04-30T13:21:23.1009123Z 	at org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81)
2024-04-30T13:21:23.1009402Z 	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103)
2024-04-30T13:21:23.1009501Z 	... 14 more

Please advice how to debug further.

Noticed the dual timestamps and need to investigate more what's going on in GitHub Action. Sometime time differs by several minutes.


feat(RHTAPWATCH-300): Add container image

Adding a container image to run the UJ data sync pipeline.
To make everything runnable in a container, made the location of the ~/.netrc file configuratble via an enviromnet variable, so it can be made to point to a file mounted on the container.

Overall LGTM. Left a few comments.


additional functionality for terraform output

TF_OUT-variables are logged now
warning if a key is not considered

THese changes will resolve no1&2 for #36

The convertToHex function is so one can compare strings why they don't match.

Thought this is more of a debug function but one to actually use in the testing.

@DenWin rather than verifying log messages are appearing by comparing build log samples, i modified this to use the logs that are available from the TestRunner object. From the task.steps.ts, this is accessible via this.test.logs. This is an array of the build output. I used this to compare with expected log messages in the feature file. I was concerned that expecting the entire output to match would make the test very prone to failure when adjusting things that have nothing to do with output (version for example which runs with every command).
I was however, able to take the formatting helpers you added alongside the log messages in the TestRunner and use that to remove completely the need for the mock-logger.ts object. This significantly simplified the testing approach for the warning messages.
Please take a look and let me know if there are any issues with these adjustments. If not, this should be good to merge.

Was fighting quite a bit with the output. Thx, this looks a lot nicer!

there is no test to check whether it is possible to specify a certain output variable rather than all, e.g.
- task                          : charleszipp.azure-pipelines-tasks-terraform.azure-pipelines-tasks-terraform-cli.TerraformCLI@0
  inputs:
    command                     : output
    commandOptions              : some_string

Though if you test for this the test fails with the message AssertionError: Error: No exec answer found for command "terraform output -json some_string". Make sure to mock answer for commands!: expected 2 to equal 0

Btw. the specific error message only appeared after changing the code as seen in "the error message why a command did not run successful is added"

I would go with this one as it is right now.


A question about re/using of Props

@davidzbiral, this one is for you, but maybe also you @rljshaw
One of the main new features for 1.4 is the reusing (let's call it "reusing" for the purpose of this issue) of the props to have better control over the data collection.  If you want to re/use P within another actant, we always talk about moving all the children (P + P1 + P2...), not only the original type-value tuple (P).
Similarly, here is another question that is important before designing the UX. Let's say we have S1 with subject P1 and with a branch of various Props. And a user creates a new S2 with a subject P3. Now, the user wants to reuse the P1 props from S1 (see Picture). Is it more relevant to think that the user wants

(i) reuse all the props from P1 in S1 on P2 in S2,
(ii) reuse just some specific props (with their children), one by one (e.g., just C1-va1 pair with children )
(iii) both tasks are important

I think it is fine to copy all, because removing those not applicable is very quick and easy.

@adammertel : I think this was answered? What do you remember we opted for?


What if I just want to change a domain?

Thank you for the truly useful configurations, I'm quite enjoy to make these things automatically.
I don't want to lose the data, but destroy all of them, including the data container isn't fair if I'm just trying to change a domain...
Changed the domain and recreate the nginx container doesn't work.
Thanks

Invalid, sorry.


Added missing kind parameter required when adding a partition key

Fixes #3991

This checklist is used to make sure that common guidelines for a pull request are followed.
General Guidelines

[x] The PR has modified HISTORY.rst with an appropriate description of the change (see Modifying change log).

Command Guidelines

[x] Each command and parameter has a meaningful description.
[x] Each new command has a test.

(see Authoring Command Modules)

@CameronVetter,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Codecov Report

Merging #3993 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master    #3993   +/-   ##
=======================================
  Coverage   70.59%   70.59%
=======================================
  Files         427      427
  Lines       27521    27521
  Branches     4208     4208
=======================================
  Hits        19429    19429
- Misses       6834     6838    +4
+ Partials     1258     1254    -4

Impacted Files
Coverage Δ

...mosdb/azure/cli/command_modules/cosmosdb/custom.py
42.74% <0%> (ø)
:arrow_up:

src/azure-cli-core/azure/cli/core/util.py
70.66% <0%> (ø)
:arrow_up:

...dback/azure/cli/command_modules/feedback/custom.py
31.25% <0%> (ø)
:arrow_up:

...nent/azure/cli/command_modules/component/custom.py
16.23% <0%> (ø)
:arrow_up:

...li-cloud/azure/cli/command_modules/cloud/custom.py
14.45% <0%> (ø)
:arrow_up:

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 18838f5...93edf11. Read the comment docs.

It would be nice if the change comes with a test.

Agreed that there was a missing test which is what allowed this bug through to begin with.  There is quite a bit of friction for me to be able to write the test since I'm not a python developer, otherwise I would have done it right away.  Is this going to be blocked until I write a test?

It's fine. I'd like to have @moderakh take a look your PR. Once @moderakh approves this PR it's good to go.

@CameronVetter
if the partition key kind is not explicitly specified the default of 'Hash' will be used.
Any particular reason that you explicitly specified the partition key kind in the code? Were you getting failure without this?
@troydai thanks for tagging me.

Take a look at issue #3991 I have a cut and paste of the error message with v 2.0.9, it appears that the REST interface is defaulting to an empty string without the property explicitly specified in JSON of the call.

It seems there is recent change in behavour in the cosmosdb endpoint. And due to that partition key kind must be present in the collection definition.
@CameronVetter thank you for reporting this, and thanks for the fix.

Hello all, I need exactly this fix for my vsts release management.  Do you have any idea when this will be rolled out onto the VSTS servers?  Is there a way to workaround this issue, until then?  (exception when I want to create a collection with a partition property)

I did not find any workaround for this, my scripts currently fail and we have to manually do these steps.  I'm also very eager to see this roll into the CLI...


Do not cancel  already done/failed/doing tuples

related to https://github.com/SubstraFoundation/substra-chaincode/pull/62

Instead of just making sure that assets are not in todo/waiting, what do you think of making the second traintuple last a few more seconds so that we are sure that the first tuple will end in status done, the second one is in status doing and all remaining ones are in status canceled?

Instead of just making sure that assets are not in todo/waiting, what do you think of making the second traintuple last a few more seconds so that we are sure that the first tuple will end in status done, the second one is in status doing and all remaining ones are in status canceled?

I don't think it is a good idea. In my opinion the tests should stay as simple as possible and as fast as possible. This is adding a bit of complexity and I don't think it is worth it.

Doing cp.wait() already checks that all tuples are done, so there's no need to add an explicit test that they are not in todo or doing.


Guide2020

[x] I followed the CONTRIBUTING guidelines.

Below, describe what this Pull Request adds:
Use VuePress to build a new guide.

Hi @ehabdevel, thank you for your effort in putting in this pull request. Can you elaborate a bit on what it adds and why we would need this please?

Hi @bouweandela ,
Thank you for your comment. in this pull request I choose VuePress cause it gives the most important needed features for the guide as I think.
What it adds and why we would need this?

Better nice looking front-end.
Easy looking navigation to keep clear structure as long as the guide pages grows.
Mobile ready PWA.
Easy for content contributors with just editing Markdown files and in the root directory.

The ability to add more from VuePress Features (https://vuepress.vuejs.org/guide/#features)

(The primary problem with GitBook is that its development reload performance is intolerable with a large amount of files. The default theme also has a pretty limiting navigation structure, and the theming system is, again, not Vue based. The team behind GitBook is also more focused on turning it into a commercial product rather than an open-source tool.) https://vuepress.vuejs.org/guide/#gitbook

Sorry, Not editing Markdown files.


Chapter 10 - missing/wrong highlight in code block

The handleSearch function changes slightly, but only line 7 is highlighted. Looks like this could be fixed a bit.

Line 10, 11, 12  => Line 12, 13, 14

@imhalid @mrmahatva thank you for your feedback! We have a PR fixing these code block highlights


Gridded sample not working properly

Hi,
We were trying to create a new project with our own csv file as plot centers. Within each plot we were trying to do a gridded sample. We set the plot size as 80 meters and the sample space as 10 meters. Usually we would end up with 81 regularly gridded samples in each of our plots. But now we only have 1 sample in each plot.
We tried again without our own csv file when creating a new project, instead we did 100 random plots within a polygon we drew. And again we used 80 meters as plot size and 10 meters and sample spacing and it worked.
So we are wondering if this has something to do with the csv file since we noticed that a plotid field is required which wasn't in the previous version of collect earth online.
Thanks for your help.
Wenjie

I think this was already fixed awhile ago, but someone should verify that Plot Distribution = CSV and Sample Distribution = Gridded works correctly.


[apostrophe-docs] Cursor clone doesn't always clone everything

Docs cursor has a .clone() method, which is notably used to run toCount queries using an equivalent cursor ahead of running a toArray query. However, since it creates a new cursor through:
var cursor = self.apos.create(self.__meta.name, options);

It doesn't get piece-specific filters added to it that are added by overriding the pieces .find() method and adding filters to the retrieved cursor. For example, running a toCount on the image piece type doesn't get the minSize filter added, causing the toCount results to potentially differ from the results of the toArray. (The implementation of the minSize filter is in images cursor.js, the override of the pieces find for images is in images api.js).
@boutell Not sure where the fix belongs on this one. Should we change how we are adding filters for specific piece types, or change how we construct an additional cursor when cloning?

Resolved in #573


about flow_test.

When I run the eval_flow.py. I got 'module' object has no attribute 'CV_LOAD_IMAGE_UNCHANGED'. It seems that OpenCV 3.20 has renamed the flag. So I changed it to cv2.IMREAD_UNCHANGED. I got the images but with a None Object at the end.
` [[    0 32768 32768]
[    0 32768 32768]
[    0 32768 32768]
...
[    0 32768 32768]
[    0 32768 32768]
[    0 32768 32768]]]
None
Traceback (most recent call last):
File "kitti_eval/eval_flow.py", line 61, in
main()
File "kitti_eval/eval_flow.py", line 34, in main
pred_flow = fl.read_flow(pred_flow_fn)
File "/home/chenxigeng/GeoNet/kitti_eval/flow_tool/flowlib.py", line 97, in read_flow
flow = read_kitti_png_file(filename)
File "/home/chenxigeng/GeoNet/kitti_eval/flow_tool/flowlib.py", line 656, in read_kitti_png_file
flow_img = flow_img.astype(float)
AttributeError: 'NoneType' object has no attribute 'astype'  `
I printed the shape of flow_img. It was (375, 1242, 3) (375, 1242, 3) and the type it was
<type 'numpy.ndarray'>
<type 'numpy.ndarray'>
<type 'NoneType'>
I don't know why there is a third type NoneType..
I would like to know which version of Opencv have you used?
After this I also want to use your code to process my own live videos (captured by a camera), I saw the previous Issues that you saw with cv2.imwrite.  So the live videos should also first written as many frames and then create the scripts like the examples at the same time?

The issue mainly results from the image io of opencv I guess. Can you try the code with opencv 2.4.13 (the version we used)?


ds5lr camera

Question: Does somebody know when the ds5lr camera will be available.
It is a long range camera with a larger baseline than the d400-serie.
Best Regards,
Martijn Kusters

[Realsense Customer Engineering Team Comment]
hi @martijnkusters,
let me check on this for you, and I assume you are checking for peripheral not bare module, right?

[Realsense Customer Engineering Team Comment]
hi @martijnkusters,
per checked, we don't have plan for DS5lr peripheral at this point, sorry for this.

what about the bare module? @RealSense-Customer-Engineering

[Realsense Customer Engineering Team Comment]
hi @TheMikeyR,
do you have contact with intel sales?
if no, would you provide your contact so we can reach you and check for your need?

I'm not much for giving up my email address in a public forum, is it possible to find the contact info by looking me up on designintools by username? If so my username is MikeyR.

[Realsense Customer Engineering Team Comment]
hi @TheMikeyR,
sure, let me try with that approach.

@RealSense-Customer-Engineering a representative from Intel have contacted me now, thanks!

[Realsense Customer Engineering Team Comment]
hi @TheMikeyR,
great, cheers.
hi @martijnkusters,
do you have any follow up question for this topic?

No, you can close this topic

[Realsense Customer Engineering Team Comment]
thanks and please feel free to create a new ticket if any question


Licensing and F-Droid

First of all, thanks for this super useful and versatile application. Now I do not need to borrow my friends switch pro controller anymore and can just use my phone on demand when I have to solve one of those apparatus shrines.
Because it is so useful, have you considered putting it on https://f-droid.org?
If you do not care but would generally allow that, please explicitely say so, I would submit it for you. All credit will still be given to you plus it is now packaged by a trustworthy source and easier to download, especially for F-Droid users like me.
However, in order for this to be able to happen, you must have a license in your project. Every repo on github should have a license (easy github tutorial) or the default licensing applies, which means, to quote, with highlighting added:

However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work. If you're creating an open source project, we strongly encourage you to include an open source license.

Which is very likely unintended. You are free to choose whatever license you want, but given I ask in F-Droid context, it would be cool if a compatible license would be chosen (as listed in https://f-droid.org/docs/Inclusion_Policy/), e.g GPL3.0, MIT or Apache 2.0.

Thanks for your support ☺

@PlayXboxtion963 You still need to add a LICENSE and give me your explicit permission to submit it to F-Droid.

@PlayXboxtion963 You still need to add a LICENSE and give me your explicit permission to submit it to F-Droid.

Finish.


Error while loading a GLTF in index.js

I am trying to load my GLTF model by changing the url in index.js file, but when I run the index.html in browser i receive the following error. Can anyone help me with this error. I am able to load other GLTF models, but above mentioned GLTF is throwing error.

The model loads just fine:

Perhaps the issue was related to #463 depending on your platform. In the future please provide the information in the issue templates.


Adding missing undocumented rabbitmq tcp_listen_options directive

We've noticed changes in our RabbitMQ infrastructure after upgrading  Puppet module to the latest forge release, tcp_listen_options were added to RabbitMQ configuration template. Unfortunately, one option was missing and it changes significantly on how broker terminates connections after heartbeat has expired - instead of previous behaviour of sending RST,ACK it starts sending FIN,ACKs instead causing libraries that don't have good exception handling or they aren't using publisher confirms options for publishing messages to start losing messages.
Adding this directive as per https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit.app.src as it's listed as default but not documented on RabbitMQ website.

https://github.com/rabbitmq/rabbitmq-website/pull/237#event-749710289

https://github.com/rabbitmq/rabbitmq-website/pull/238


Fix parsing of decimal numbers

https://github.com/Prots/olifer/issues/8

Fixed https://github.com/asholok/python-validator-livr/issues/14#issuecomment-352129603


Add event to easily add data to rule context before active rules are determined / rule matching  due to missing dependency injection or allow dependency injection

Please describe the feature you would like to see implemented.
As there is not dependency injection it is sometimes necessary to add additional data for rules to match. However, to get the data correctly this has to be done just before the rules are matched and there is no such event yet.
Maybe it is enough to just add an event and add data to the context before the filter matching rules is called but even better would be to allow custom payload to be added to rule objects and provide it for matching purposes.
Even better would be to restructure the rule system to separate payload and mach service, so the mach service could use dependency injection - similar to how Symfony validator separates the constraints and the validator. And it really should not be a performance issue as e.g. one can do performance slow operation with and without dependency injection, so this really should not have any impact - it is up to the developers to ensure this does not happen.

See https://github.com/shopware/proposal/issues/15

I would also be happy with a better solution but I don't think there is any without readjusting the complete cart / rule loading behavior.


Stable memory for event log.

The event log permits re-generation of each other table/relation/map stored in the canister state.

This issue is tied to a larger idea, and a larger motivation, about inserting established incremental computation techniques into the prototypical canister design and its lifecycle of upgrades.
The benefit is a simple design that is efficient and correct, but also flexible and supportive for canister feature evolution.
In particular, there is a tension between adding features, and the complexity of doing upgrades and managing state in stable memory.  In general, it would be simplest if adding new features only meant minimal extensions to the data types within stable memory.
For instance, a minimal addition would be adding a new log record and variant type for each new major operation performed by the canister, so as to record it, and re-produce its effects upon a replay (during a migration or upgrade, etc).
This issue proposes that we store the event log in stable memory, so as to always have a source of truth from which to upgrade and recover, later.
If we additionally store an incremental computing cache in stable memory as a companion to this event log, and we use that incremental cache in the upgrade hooks (reading from it to avoid re-processing the log), we should (in theory) be able to make "automatically incremental" the process of walking over the entire event log from the start of the canister's life, and re-generating the acceleration structures that provide efficient access to canister state (the tables/maps used by update and query calls, post upgrade).
Thoughts @chenyan-dfinity ?

Regarding the "please repeat yourself" idea above (what I would call the idea of complete replay as the "ordinary semantics" of incremental updates) --- a former student colleague and I thought about this problem together, and it seemed promising to us as the time.
Here are some initial results, along with unrelated ideas, circa 2016.  For a variety of reasons, that work did not continue.  But I think the ideas remain very promising, and always have.

I don't quite see how this works. Let's start with an example. In version 1, my canister uses an array of key-value pairs to store the user profiles. In version 2, I upgrade the profile to use HashMap. I think the event-log in the stable memory is unchanged. How do we propagate the event log to the concrete data structure?

In version 1, my canister uses an array of key-value pairs to store the user profiles. In version 2, I upgrade the profile to use HashMap.

I propose a different example.
In version 1, we have an app with users and profiles, but no follows relation.
In version 2, we add a follows relation, and the API for updating it.  Those operations become new events in the event log type (the only thing in stable memory other than the adapton cache).  Those operations have an interpretation (like operations in a DSL, which they are) and their interpretation is to populate the HashMaps and other structures that represent the follows relation.
During an upgrade from version 2 into version 3, where the follows relation does not change definition, we recover the cached representation from its initial construction, as a cached interpretation of the same log event.
Summary:

in transition from version 1 to version 2, we update with a new feature (follows relation); there is no incremental reuse yet (if there is, let's ignore it for now).  But the update is simple because we need not add that relation directly to the representation of stable memory, or the upgrade hooks.
in transition from version 2 to version 3, we get to recover the follows relation representation from the cache, and it's important that to get further reuse, we do not change this representation's type in subsequent upgrades; it must stay representing the same thing, in the same way.  That's fine.  What's more likely is adding additional relations, which would be similar to the original transition from version 1 to version 2.

I should also add that incremental reuse during upgrades is only one time when these caches would help.  In general, they'd help for hypothetical transactions that get rolled back and replayed, for similar reasons.

I can see how this works for schema changes. But if we want to refactor the code to a different data structure, like in my example, it's unclear how to do it.
As you mentioned, the upgrade is a one-time job. Do we really care about incremental reuse? The adapton cache size is probably more than the event-log size, because of meta data and closures?
The real difficulty in upgrade is that we lose all correctness guarantees provided by the type system. If we mess up during an upgrade, there is no way to rollback. If the event log idea can somehow give a correctness guarantee, that would be a big selling point. I think the efficiency of data migration is not a concern here. It's fine to take a few days to migrate the data, as long as the data is not lost.

I think the whole concept of upgrade is wrong. It's imperative with no persistency. The more functional way of "upgrade" would be to start a new canister, and importing data from the old canister. After we validate the data is intact, we tell the system to switch routing to the new canister.

But if we want to refactor the code to a different data structure, like in my example, it's unclear how to do it.

I agree.  That kind of change seems to be common in practice, but perhaps with some incentive to migrate data structure designs more incrementally, people would choose those more incremental design paths.  Only time and more experience will tell.  But I totally understand that there are serious limitations to what I am proposing.  This is one of them, certainly.

the upgrade is a one-time job. Do we really care about incremental reuse?

Good question.  Maybe not, but maybe so, depending on the developer and how frequently they push new Wasm.
Imagine a live programming system that can do incremental Wasm builds.  In that case, an ordinary session of development could be to push Wasm binaries quite frequently, and rely on upgrades being incremental and most data being stable (all bulk long-term data in stable memory, and never moved out of it) for efficiency and responsiveness in the face of that high frequency.
That's the direction I want to push for "live programming the IC", at least eventually, if not the medium term.  Perhaps other live experiences are possible too (with no Wasm recompilation, for instance, by using an interpreter for a live programming DSL that stays fixed as the DSL AST changes over time); but I find myself wanting to push new Motoko-based Wasm quite frequently as I play with canisters that I create in Motoko, either "locally" or remotely, on the main network.
It would be really cool to have the model where reinstall + upgrade is nearly "real time" (a second or a few, not minutes).

I think the whole concept of upgrade is wrong. It's imperative with no persistency. The more functional way of "upgrade" would be to start a new canister, and importing data from the old canister. After we validate the data is intact, we tell the system to switch routing to the new canister.

That's a functional update versus an imperative one (where the canister identity stays fixed, but its "meaning" changes).
Surely you can support functional updates as a "mode of use" of the model we have now?  You need to somehow migrate the state, but that could be done on demand, perhaps?

After we validate the data is intact, we tell the system to switch routing to the new canister.

What would that entail, generally?  Perhaps a simple example would help me see what you envision there.

If the event log idea can somehow give a correctness guarantee, that would be a big selling point. I think the efficiency of data migration is not a concern here. It's fine to take a few days to migrate the data, as long as the data is not lost.

As usual, you are the better salesperson.
I think that focusing the promise of "lossless representation of canister history" is the key selling point, as you suggest.

This PR shows that the sequence type works as a stable var, though that wasn't in doubt.  Just a sanity test, and initial baby step to try the idea somewhere.

It would be really cool to have the model where reinstall + upgrade is nearly "real time" (a second or a few, not minutes).

This seems to be a different problem though. Update call (Installing Wasm) takes a few seconds, even if the there is no stable memory to migrate. It's hard for IC to be "real time".

functional upgrade

My complaint is that nobody is doing in-place upgrade in today's world. It doesn't work. You cannot rollback if there is a bug. If you deploy a new canister, you can throughly test the new canister before using the new canister in production.
Instead of pre-/post-upgrade hook, each canister exposes import and export methods, so that it can migrate data from one canister to the other.

After we validate the data is intact, we tell the system to switch routing to the new canister.
What would that entail, generally? Perhaps a simple example would help me see what you envision there.

Imagine a proxy service that simply relay request to the old canister. When you deploy a new/upgraded canister and migrate data from the old canister, you can ask the proxy to relay request to both canisters, so that we can monitor if any runtime metric look good, or any diff between the old and new canisters. After you have enough confident you can stop relaying requests to the old canister.
This runtime validation is never possible with in-place upgrade. Plus there is no static correctness guarantee, why would anyone want to upgrade canisters in-place?

why would anyone want to upgrade canisters in-place?

A developer that is just getting going, with no users.
Canister IDs are system resources that cost something to create?  Not sure about this actually.

I think this is a very good question, FWIW.  These are a couple of answers that come to my mind, but I think you raise some very good points about another approach (the import and export idea).

Imagine a proxy service ...

Yes, I see the value in such a service.  I expect that this will become a business area on the IC, not just something that we need to "solve" once and for all.

Interestingly, I have upgraded my instance of CandidSpaces a few times now, and once with a type change that may not be compatible, but it seems that no problems have occurred yet.  The log still seems readable, as I put entire trees of files into it now.

Spoke too soon.  I lost the eventLog while doing an upgrade tonight.  I'm not entirely sure why, since I think I was changing other things, and not the stable vars.


[TypeError: undefined is not an object (evaluating 'row[OBJECT_COLUMN_NAME] = key')]

Description:
Currently, I am building a MobileApp with React-Native and everything works fine until today :/
Because now the app starts to throw an error (see below) after a successful build!
[TypeError: undefined is not an object (evaluating 'row[OBJECT_COLUMN_NAME] = key')]
BUT this error only appears in the normal mode -> if I switch to the debug mode everything is working without any further problems.
See further details on Stackoverflow:
https://stackoverflow.com/questions/60745771/typeerror-undefined-is-not-an-object-evaluating-rowobject-column-name-key
React Native version:
react-native 0.61.5

After I filled my code completely with console.logs... I found out that React Native does not work with console.table in non debug mode. This is easily fixed by using console.table only when the app is in debug mode. Just check if the debug mode is enabled ^^
const isDebuggingEnabled = (typeof atob !== 'undefined');
That's it


Images created by Jib randomly causes 500 Internal server error in Red Hat Quay

Environment:

Jib version: 1.5.1
Build tool: Maven
OS: Linux and Windows

Description of the issue:
Images created by Jib randomly causes 500 Internal server error in Red Hat Quay.
This has been reproduced with the HelloWorld example from Jib, but does not happen
with images created in any other way than with Jib.
Expected behavior:
Images created by Jib should consistently be accepted by Quay.
Steps to reproduce:

Download https://github.com/GoogleContainerTools/jib/tree/master/examples/helloworld
Change
gcr.io/REPLACE-WITH-YOUR-GCP-PROJECT/image-built-with-jib
to
QUAY-REGISTRY/image-built-with-jib
Run mvn compile jib:build

jib-maven-plugin Configuration:
<configuration>
    <to>
        <image>QUAY-REGISTRY/image-built-with-jib</image>
    </to>
</configuration>

Log output:
> [2019-09-13T07:50:47.986Z] [ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:1.5.1:build (build_docker_image) on project xx: 500 Internal Server Error
> [2019-09-13T07:50:47.986Z] [ERROR]
> [2019-09-13T07:50:47.986Z] [ERROR]
> [2019-09-13T07:50:47.986Z] [ERROR]     <title>Internal Server Error</title>
> [2019-09-13T07:50:47.986Z] [ERROR]
> [2019-09-13T07:50:47.986Z] [ERROR]
> [2019-09-13T07:50:47.986Z] [ERROR]
Internal Server Error

> [2019-09-13T07:50:47.986Z] [ERROR]
> [2019-09-13T07:50:47.986Z] [ERROR]
> [2019-09-13T07:50:47.986Z] [ERROR]

Additional Information:
Red Hat's response is that this only happens with Jib-created images and therefore points the finger at Jib.
Is it possible to get Google and Red Hat to cooperate in finding a solution to this?
Red Hat Case #: 02456747

Hi @hbjastad.  Does this happen with quay.io?  Or is there a container image with Quay that we can use to reproduce?

Probably because jib creates schema 2 images? Has quay rolled out schema 2 support fully yet?

I just tried pushing to quay.io, and the push is rejected:
[ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:1.5.1:build (default-cli) on project first: Tried to push image manifest for quay.io/briandealwis/jibtest:latest but failed because: Registry may not support pushing OCI Manifest or Docker Image Manifest Version 2, Schema 2 | If this is a bug, please file an issue at https://github.com/GoogleContainerTools/jib/issues/new: 415 UNSUPPORTED MEDIA TYPE
[ERROR] {"errors":[{"code":"MANIFEST_INVALID","detail":{"message":"manifest schema version not supported"},"message":"manifest invalid"}]}

@jonjohnsonjr Quay still seems to default to Schema 1, as @briandealwis and I observed today. People have been individually requesting whitelisting their namespaces, even until recently

I'm surprised it's causing a 500 instead of the 415 like you're seeing.

@hbjastad An internal server error usually indicates a bug in the server implementation.  Jib has revealed implementation bugs in other registries (#534).
Perhaps RedHat support could reach out to<EMAIL_ADDRESS>with a way to test against a hosted Quay as the [instructions are somewhat involved.

Yes, I agree it's surprising to get a 500, and yes, that usually indicates a bug in the server implementation. So while I firmly put the blame on RedHat in this case, they have not been able to find the problem. And since the problem has only occured with images generated by Jib, I was hoping that they could get some assistance...
Unfortunately, quay.io has not been upgraded to version 3 (which is required for schema 2 support), so that instance can not be used for reproducing the problem.

Is there any useful information in the Red Hat Case #: 02456747? We can't access it. If they hit 500, they must have logged something in their server logs and should be able to relate that to their code where in the code the error is coming.
If there is a Quay repository against which we can directly test and reproduce this, we could also try various things. At least you can provide us detailed Jib logs so that we get to know at which stage this error happens; follow these instructions to capture low-level HTTP traffic. Also pass -X to Maven to log debug output. Then strip out any sensitive info and upload the file here. (You can also easily inspect the log on your own to pinpoint which HTTP request endpoint URL the server returns 500 for.)
And what's the frequency of this happening? It's weird because what Jib generates and pushes will always be identical.

The only interesting thing in the RH case (which is internal and only available to RH), is that
they say they have tried 100 runs without being able to reproduce the problem.
Makes me think that it could be a problem with the registry installation we use (internally hosted),
but we need help from RH to identify why they go 500 on us...
It fails roughly 20% of the runs.
Here is the last part of the log output, with the suggested options enabled:
18:28:40  CONFIG: -------------- REQUEST  --------------
18:28:40  PUT https://QUAY-REGISTRY/v2/group/app/blobs/uploads/a5fbdf2f-1744-45ca-b31c-97f9da10806e?digest=sha256:716c75ad66f56d3d4d9bc8c60c9e98e672e86604bf74b41002ef0b748cc10363
18:28:40  Accept:
18:28:40  Accept-Encoding: gzip
18:28:40  Authorization:
18:28:40  User-Agent: jib 1.5.0 jib-maven-plugin Google-HTTP-Java-Client/1.30.0 (gzip)
18:28:40
18:28:40  Sep 17, 2019 6:28:40 PM com.google.api.client.http.HttpRequest execute
18:28:40  CONFIG: curl -v --compressed -X PUT -H 'Accept: ' -H 'Accept-Encoding: gzip' -H 'Authorization: ' -H 'User-Agent: jib 1.5.0 jib-maven-plugin Google-HTTP-Java-Client/1.30.0 (gzip)' -- 'https://QUAY-REGISTRY/v2/group/app/blobs/uploads/a5fbdf2f-1744-45ca-b31c-97f9da10806e?digest=sha256:716c75ad66f56d3d4d9bc8c60c9e98e672e86604bf74b41002ef0b748cc10363'
18:28:40  Sep 17, 2019 6:28:40 PM com.google.api.client.http.HttpResponse
18:28:40  CONFIG: -------------- RESPONSE --------------
18:28:40  HTTP/1.1 201 CREATED
18:28:40  Server: nginx/1.12.1
18:28:40  Date: Tue, 17 Sep 2019 16:28:40 GMT
18:28:40  Content-Type: text/html; charset=utf-8
18:28:40  Content-Length: 0
18:28:40  Connection: close
18:28:40  Docker-Content-Digest: sha256:716c75ad66f56d3d4d9bc8c60c9e98e672e86604bf74b41002ef0b748cc10363
18:28:40  Location: https://QUAY-REGISTRY/v2/group/app/blobs/sha256:716c75ad66f56d3d4d9bc8c60c9e98e672e86604bf74b41002ef0b748cc10363
18:28:40  X-Frame-Options: DENY
18:28:40  Strict-Transport-Security: max-age=63072000; preload
18:28:40
18:28:40  Sep 17, 2019 6:28:40 PM com.google.api.client.http.HttpRequest execute
18:28:40  CONFIG: -------------- REQUEST  --------------
18:28:40  PUT https://QUAY-REGISTRY/v2/group/app/manifests/0.2.7-SNAPSHOT
18:28:40  Accept:
18:28:40  Accept-Encoding: gzip
18:28:40  Authorization:
18:28:40  User-Agent: jib 1.5.0 jib-maven-plugin Google-HTTP-Java-Client/1.30.0 (gzip)
18:28:40  Content-Type: application/vnd.docker.distribution.manifest.v2+json
18:28:40
18:28:40  Sep 17, 2019 6:28:40 PM com.google.api.client.http.HttpRequest execute
18:28:40  CONFIG: -------------- REQUEST  --------------
18:28:40  PUT https://QUAY-REGISTRY/v2/group/app/manifests/latest
18:28:40  Accept:
18:28:40  Accept-Encoding: gzip
18:28:40  Authorization:
18:28:40  User-Agent: jib 1.5.0 jib-maven-plugin Google-HTTP-Java-Client/1.30.0 (gzip)
18:28:40  Content-Type: application/vnd.docker.distribution.manifest.v2+json
18:28:40
18:28:40  Sep 17, 2019 6:28:40 PM com.google.api.client.http.HttpRequest execute
18:28:40  CONFIG: curl -v --compressed -X PUT -H 'Accept: ' -H 'Accept-Encoding: gzip' -H 'Authorization: ' -H 'User-Agent: jib 1.5.0 jib-maven-plugin Google-HTTP-Java-Client/1.30.0 (gzip)' -H 'Content-Type: application/vnd.docker.distribution.manifest.v2+json' -d '@-' -- 'https://QUAY-REGISTRY/v2/group/app/manifests/latest' << $$$
18:28:40  Sep 17, 2019 6:28:40 PM com.google.api.client.http.HttpRequest execute
18:28:40  CONFIG: curl -v --compressed -X PUT -H 'Accept: ' -H 'Accept-Encoding: gzip' -H 'Authorization: ' -H 'User-Agent: jib 1.5.0 jib-maven-plugin Google-HTTP-Java-Client/1.30.0 (gzip)' -H 'Content-Type: application/vnd.docker.distribution.manifest.v2+json' -d '@-' -- 'https://QUAY-REGISTRY/v2/group/app/manifests/0.2.7-SNAPSHOT' << $$$
18:28:40  Sep 17, 2019 6:28:40 PM com.google.api.client.util.LoggingByteArrayOutputStream close
18:28:40  CONFIG: Total: 1,899 bytes
18:28:40  Sep 17, 2019 6:28:40 PM com.google.api.client.util.LoggingByteArrayOutputStream close
18:28:40  CONFIG: Total: 1,899 bytes
18:28:40  Sep 17, 2019 6:28:40 PM com.google.api.client.util.LoggingByteArrayOutputStream close
18:28:40  CONFIG: {"schemaVersion":2,"mediaType":"application/vnd.docker.distribution.manifest.v2+json","config":{"mediaType":"application/vnd.docker.container.image.v1+json","digest":"sha256:716c75ad66f56d3d4d9bc8c60c9e98e672e86604bf74b41002ef0b748cc10363","size":6394},"layers":[{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:dc4e07da33bca48edefbcba8dadefa8e7ffc6fe3e8ee4db140600a62862a16ac","size":75838348},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:5c2598df456066d90ae3ed81592c54247800071c7ee8845985a93db7e95e936f","size":1318},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:50408d34b7db1a7cac449215c8bf82b020a4e61bd542f66a8766b4804f3882fe","size":107047961},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:4ba3169fe2368e12f3c389fcbb4a50b5de415158498523d4de8fc9a26b222c86","size":73145},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:c0c6d1b7edbf7547f7097c8f5526df037f79ac8ec4d19bc1837111002f691a13","size":201442152},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:39695cdcbd9269bf29fd1c1cfc51059b8015f157efeaabfc461b82f069663a4e","size":68161562},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:68c6c0f7af33cdc5751c57a2395c557471fe8228946456b91ce8e46bcb66a113","size":2057357},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:1fc1bfa6e7965b4df5526e5b61e308223301cf1d336994c6bb3dcecc3303c4ac","size":23282},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:046e7a6c5df301fd2c1a1615b4712bd733ea3d7a38813c09d550aa48d7c9137a","size":124861},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:539a556737849eab550afdd62d11bbe72faa16642c0f2419d1ed25ec36e04243","size":1483}]}
18:28:40  Sep 17, 2019 6:28:40 PM com.google.api.client.util.LoggingByteArrayOutputStream close
18:28:40  CONFIG: {"schemaVersion":2,"mediaType":"application/vnd.docker.distribution.manifest.v2+json","config":{"mediaType":"application/vnd.docker.container.image.v1+json","digest":"sha256:716c75ad66f56d3d4d9bc8c60c9e98e672e86604bf74b41002ef0b748cc10363","size":6394},"layers":[{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:dc4e07da33bca48edefbcba8dadefa8e7ffc6fe3e8ee4db140600a62862a16ac","size":75838348},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:5c2598df456066d90ae3ed81592c54247800071c7ee8845985a93db7e95e936f","size":1318},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:50408d34b7db1a7cac449215c8bf82b020a4e61bd542f66a8766b4804f3882fe","size":107047961},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:4ba3169fe2368e12f3c389fcbb4a50b5de415158498523d4de8fc9a26b222c86","size":73145},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:c0c6d1b7edbf7547f7097c8f5526df037f79ac8ec4d19bc1837111002f691a13","size":201442152},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:39695cdcbd9269bf29fd1c1cfc51059b8015f157efeaabfc461b82f069663a4e","size":68161562},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:68c6c0f7af33cdc5751c57a2395c557471fe8228946456b91ce8e46bcb66a113","size":2057357},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:1fc1bfa6e7965b4df5526e5b61e308223301cf1d336994c6bb3dcecc3303c4ac","size":23282},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:046e7a6c5df301fd2c1a1615b4712bd733ea3d7a38813c09d550aa48d7c9137a","size":124861},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:539a556737849eab550afdd62d11bbe72faa16642c0f2419d1ed25ec36e04243","size":1483}]}
18:28:41  Sep 17, 2019 6:28:40 PM com.google.api.client.http.HttpResponse
18:28:41  CONFIG: -------------- RESPONSE --------------
18:28:41  HTTP/1.1 500 Internal Server Error
18:28:41  Server: nginx/1.12.1
18:28:41  Date: Tue, 17 Sep 2019 16:28:40 GMT
18:28:41  Content-Type: text/html
18:28:41  Content-Length: 134
18:28:41  Connection: close
18:28:41
18:28:41  Sep 17, 2019 6:28:40 PM com.google.api.client.util.LoggingByteArrayOutputStream close
18:28:41  CONFIG: Total: 134 bytes
18:28:41  Sep 17, 2019 6:28:40 PM com.google.api.client.util.LoggingByteArrayOutputStream close
18:28:41  CONFIG:
18:28:41
18:28:41      Internal Server Error
18:28:41
18:28:41
18:28:41      Internal Server Error
18:28:41
18:28:41
18:28:41
Sorry for the lack of formatting, I'm on an old version of IE that is a struggle to use.
I can see that it makes 2 manifest PUT requests, but not sure if we can conclude which of them fails.
I'm assuming they're made asynchronously, since both requests are logged before there is a response.

If you run with -DjibSerialize=true then the requests should be serialized. But my bet is on lack of schema v2-2 support.

or -Djib.serialize=true if you're using jib 1.6.0 or newer

@hbjastad sorry, looks like the requests were not serialized. The instructions says to use -Djib.serialize=true but it should have been -DjibSerialize=true for Jib < 1.6.0. My fault. (I strongly recommend upgrading to 1.6.1, since 1.5.x has a significant network performance issue.) So, at this point, it isn't certain which HTTP request made the server respond with 500.
But I can already infer from the above log that it is either one of these:

PUT https://QUAY-REGISTRY/v2/group/app/manifests/0.2.7-SNAPSHOT
PUT https://QUAY-REGISTRY/v2/group/app/manifests/latest

These are the final HTTP requests of the last push stage to complete an image push by uploading image manifests (for the tag latest and 0.2.7-SNAPSHOT). These manifest push can start only after all other HTTP requests/responses (e.g., uploading layer blobs) completed, so I'm fairly certain the error is happening when the server is supposed to accept scheme v2-2 manifests. You will be able to verify this with -DjibSerialize=true for < 1.6.0 or -Djib.serialize=true for >= 1.6.0.
Now, I don't immediately find anything particularly wrong with the manifest being uploaded (note you upload the exact same manifest JSON for the two tags):

manifest1 (click to expand)
{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
  "config": {
    "mediaType": "application/vnd.docker.container.image.v1+json",
    "digest": "sha256:716c75ad66f56d3d4d9bc8c60c9e98e672e86604bf74b41002ef0b748cc10363",
    "size": 6394
  },
  "layers": [
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "digest": "sha256:dc4e07da33bca48edefbcba8dadefa8e7ffc6fe3e8ee4db140600a62862a16ac",
      "size": 75838348
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "digest": "sha256:5c2598df456066d90ae3ed81592c54247800071c7ee8845985a93db7e95e936f",
      "size": 1318
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "digest": "sha256:50408d34b7db1a7cac449215c8bf82b020a4e61bd542f66a8766b4804f3882fe",
      "size": 107047961
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "digest": "sha256:4ba3169fe2368e12f3c389fcbb4a50b5de415158498523d4de8fc9a26b222c86",
      "size": 73145
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "digest": "sha256:c0c6d1b7edbf7547f7097c8f5526df037f79ac8ec4d19bc1837111002f691a13",
      "size": 201442152
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "digest": "sha256:39695cdcbd9269bf29fd1c1cfc51059b8015f157efeaabfc461b82f069663a4e",
      "size": 68161562
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "digest": "sha256:68c6c0f7af33cdc5751c57a2395c557471fe8228946456b91ce8e46bcb66a113",
      "size": 2057357
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "digest": "sha256:1fc1bfa6e7965b4df5526e5b61e308223301cf1d336994c6bb3dcecc3303c4ac",
      "size": 23282
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "digest": "sha256:046e7a6c5df301fd2c1a1615b4712bd733ea3d7a38813c09d550aa48d7c9137a",
      "size": 124861
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "digest": "sha256:539a556737849eab550afdd62d11bbe72faa16642c0f2419d1ed25ec36e04243",
      "size": 1483
    }
  ]
}

I wonder if it is the -SNOPSHOT string that's causing an issue, but I think that's somewhat unlikely, honestly. Maybe -Djib.serialize may give you some consistency in reproducing the image.

Yes, I don't think it's the SNAPSHOT-version, cause we have the same problem also with non-SNAPSHOT versions.
I have now upgraded to 1.6.1 (we're trying to keep up with new releases).
Funnily, at first run I got another error:
[2019-09-18T05:42:43.863Z] [ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:1.6.1:build (build_docker_image) on project app-backend: Tried to push BLOB for QUAY-REGISTRY/group/app with digest sha256:2a4b9f7f0b931a97e88abd05a50deae12969986e6aa66c9975c9305997a7e141 but failed because: other: blob upload invalid | If this is a bug, please file an issue at https://github.com/GoogleContainerTools/jib/issues/new: 400 BAD REQUEST
[2019-09-18T05:42:43.863Z] [ERROR] {"errors":[{"code":"BLOB_UPLOAD_INVALID","detail":{},"message":"blob upload invalid"}]}
But also, now with 1.6.1, I made 50 runs with the helloworld project without a single error. So I will do some more testing and get back to you.

Was that with jib.serialize?  Does the original error re-occur if jib.serialize is removed?

After working a full day with 1.6.1, we have not seen the 500 error occur a single time. Let's give it some more time before reaching conclusions, but if 1.6.1 has not removed the error it is at least happening far less frequently.
The 400 error above has also not happened again, so I guess that was a one off.
We have been running both with and without jib.serialize, I will remove it and see if that makes a difference.

We also observe this random 500 Internal Server Error with Quay 3.0.4. Version 1.6.1 still fails similar to 1.4 or 1.5. The error rate remains the same: 25% (100 sequential runs), errors are equally distributed. Usage of -Djib.serialize fixes the issue.

Hi @sergue1, it's good to hear someone else is also experiencing this problem. Today we are also experiencing the problem again with 1.6.1, after removing -Djib.serialize
So it seems like -Djib.serialize is a workaround for this apparent bug in Quay.
Can we please get serialize as a config parameter in the plugin configuration in the pom.xml, so that we can avoid including it on the command line everywhere?

I believe you can use something like: https://stackoverflow.com/questions/3231797/specify-system-property-to-maven-project/13159023#13159023 to set the system property. We don't really have plans to expose it as a direct config option.
As for the root cause of the issue, one possible theory is too many simultaneous connections to a local quay server are causing issues. It's just a guess, would be interesting if someone could confirm this.

As for the root cause of the issue, one possible theory is too many simultaneous connections to a local quay server are causing issues.

Yeah, maybe the server is a bit slow to finalize all the individual layers blobs uploaded concurrently, and by the time the server were asked to accept the manifest JSON that references these blobs via digests to stitch all of them, the server fails somehow as the internal server state is not stabilized. (I assume the error always occurs when uploading a manifest JSON as the final operation as evident in https://github.com/GoogleContainerTools/jib/issues/1986#issuecomment-532356864.) But this is my pure speculation as well.
Just remember that using jib.serialize will make the build super slow. No concurrency at all. Basically, no one should be using it (no reason to use). In general, I mean.
@sergue1 are you using a on-prem registry too? Regardless, is it possible to obtain and look into the server log and see if there's anything useful? (Might need to increase logging level, but I think usually servers will log at least something for errors like 500.) You can do the same analysis (without jib.serialize, of course) in https://github.com/GoogleContainerTools/jib/issues/1986#issuecomment-532304825 to roughly narrow down for which endpoint URLs this error happens. Then I supposed you could work with RH support presenting what you've got so far and press them for help. The same applies to you, @hbjastad.

Also, docker has --max-concurrent-uploads int which is set to 5 by default, so you can also try increasing the number to push an image with many layers (preferably of similar sizes) to see if the error is reproducible with docker push too.

Quay developer here; I just wanted to take a moment to chime in.
@jonjohnsonjr

Probably because jib creates schema 2 images? Has quay rolled out schema 2 support fully yet?

Great catch! The https://quay.io service does not (yet) support Schema 2 images, yet. To the best of my knowledge, some on-premise installations may have this enabled depending on their configuration.
Our initial struggle was being able to reproduce this issue locally. There's a ton of really great information in here that will get us one step closer. I, personally, have never heard of jib until this issue popped up so it's all new ground for me.
The HTTP 500 response sounds like an issue on our end. I can't promise when it will be fixed, but regardless of the payload received by Quay, it should respond with an appropriate status. I will do my best to provide updates if anyone is interested.
Please don't hesitate to @ me if anyone has questions I might be able to answer.

@kurtismullins I can't seem to find a quay github repo, so just posting this here as motivation for quay.io to move to support v2.2 soon: https://docs.docker.com/engine/deprecated/#pushing-and-pulling-with-image-manifest-v2-schema-1

@kurtismullins, it's great to see you picking up this thread, now I can sit back and relax until the problem is solved :-) I believe you have all the information you need in this thread, and you can use the helloworld example from this repo to reproduce it.
In the mean time we will use jib.serialize so that we can get back to focusing on our real job of delivering functionality to our users.

Please have a look at https://github.com/GoogleContainerTools/jib/issues/2013 also, which is not the same as this issue, but very much related.

Update:
I've been able to create the "Hello World" example using jib and push it to my local (development) Quay environment. Thanks to all for the reproduction steps!
Here's some initial observations:

If Schema 2_2 is not enabled, I always get the (expected) "Manifest Invalid" error
On a new/fresh image build+push using jib, I am seeing an exception related to a chunk missing a newline terminator.

It's still pretty premature but I believe that exception is not caught and handled correctly (hence the 5xx) and I'm not sure which chunk (if any?) is malformed. On my local system and example, the request which generates this error is:
PATCH /v2/devtable/image-built-with-jib-test/blobs/uploads/bcab81cf-b0d9-4972-b4a6-63ba87d13da5 HTTP/1.1

Moving forward, I'm digging through the raw requests using Wireshark to see if I can find a malformed chunk. My goal is to produce a testable scenario to trigger this exception so that we can at least get it handled properly on Quay's end. If I find a malformed request being generated by jib and am able to reproduce it, I'll share that information as well.
For reference purposes, here's essentially my current test-case:

Clone jib (working directly out of master)
Point the helloWorld example to my Quay instance
Execute mvn -Djib.console=plain -Djava.util.logging.config.file=./logging.properties -DsendCredentialsOverHttp=true compile jib:build
Modify HelloWorld.java and the repository's name in pom.xml for each fresh run.

Note: After encountering the HTTP 500 error initially for a given image, a subsequent retry succeeds. Hence the purpose of my changes to pom.xml and HelloWorld.java in my test-case.
I am far from a Java, maven, or jib expert so please don't hesitate to share suggestions if you have them. I had hoped I could use mitmproxy but neither the command-line arguments (e.g. -Dhttp.proxyHost [...]) or the maven settings file seemed to have worked. It is probably related to my local configuration and not using TLS/HTTPs.

@kurtismullins thanks for taking a look.
All the layers jib generates are cached so you can take a look them if you want to inspect them.
Default base layer cache locations:
windows: %LOCALAPPDATA%/google-cloud-tools-java/jib
linux: <user-home>/.cache/google-cloud-tools-java/jib
macos: <user-home>/Library/Application Support/google-cloud-tools-java/jib
Default application Layer cache:
maven: <project>/target/jib-cache
gradle: <project>/build/jib-cache

The proxy should work. For example, if I do
mvn \
    -Dhttp.proxyHost=localhost -Dhttp.proxyPort=8085 \
    -Dhttps.proxyHost=localhost -Dhttps.proxyPort=8085 \
    jib:build

and do nc -l 8085 on a different terminal, I see Jib trying to connect to my GCR repo:
$ nc -l 8085
CONNECT gcr.io:443 HTTP/1.1
Host: gcr.io:443
Proxy-Connection: Keep-Alive

And what do you mean exactly by a "chunk"? If you are talking about the "Docker chunked upload", Jib doesn't do it but always does "monolithic" uploads.

@kurtismullins if your mitmproxy is on the localhost, I think you'll also need to specify -Dhttp.nonProxyHosts="" to force proxy access for the local machine too.

@chanseokoh & @briandealwis
Thank you! That seemed to work during the pull from gcr.io but doesn't seem to affect the push to my localhost:5000. It's as-if it's ignoring the proxy all-together for localhost. I'll see if I can make it work later on -- perhaps by using a fake hostname in my /etc/hosts (Linux).
@chanseokoh

And what do you mean exactly by a "chunk"? If you are talking about the "Docker chunked upload", Jib doesn't do it but always does "monolithic" uploads.

Great question. I actually don't have more context on that Exception at the moment. My assumption was Chunked Encoding but you just mentioned that it's always "monolithic" so maybe that's not the case. I'm going to continue digging in.

@kurtismullins thanks for the update. To clarify, Jib always does monolithic uploads instead of chunked uploads (consisting of multiple HTTP PATCH requests). Here, "chunked" in this context refers to the the "monolithic" vs "chunked" in the Docker API spec for pushing an image.
Now, for the chunked HTTP transfer encoding, Jib doesn't explicitly craft chunked bodies. If the message is being chunked, it may be the HTTP client library that we use that automatically does the chunking for some unknown reason. But I've not really seen this happening from our logs. From your comment, it looks like you already know how to log detailed HTTP requests/responses from Jib. Do you actually see Transfer-Encoding: chunked from the Jib log? I wonder if your server mistakenly assumes Transfer-Encoding: chunked when Content-Length is missing.

But I've not really seen this happening from our logs.

Sorry, I'll take that back. I've monitored HTTP headers using mitimdump, and we end up setting Transfer-Encoding: chunked. I think it is our HTTP library that does this. I'll look into the content body to see if it is well-formed.

@kurtismullins I think our HTTP library (Google HTTP Client for Java) is working fine and the chunked body is well-formed. The library is being used extensively by the public too. Do you see a specific body that is missing a newline termination?
PATCH / HTTP/1.1
Accept:
Accept-Encoding: gzip
Authorization: Bearer ...
User-Agent: jib 1.6.2-SNAPSHOT jib-maven-plugin Google-HTTP-Java-Client/1.27.0 (gzip)
Transfer-Encoding: chunked
Content-Type: application/octet-stream
Host: localhost:8085
Connection: Keep-Alive

70d
{"created":"1970-01-01T00:00:00Z","architecture":"amd64","os":"linux", ... }
0

Thank you for checking @chanseokoh! From a quick glance, it looks good to me. I would also assume that Google HTTP Client for Java would work well and is pretty heavily tested. It does seem to work most of the time with Quay, as well.
Quay also relies on a mainstream (Python) HTTP library/framework. I also imagine it's been pretty well tested by the public.
I'm going to try to put together a minimal example to see if I can reproduce the issue while eliminating jib. I don't believe that Quay is doing anything that would affect this "low-level" portion of the stack but I could be wrong.
I am curious why configuring jib to run in serial would eliminate the issue. It would make it a lot easier to isolate the problem!

I am curious why configuring jib to run in serial would eliminate the issue. It would make it a lot easier to isolate the problem!

No idea here too. But in case you missed it, our theory is that too many simultaneous connections causes the issue somehow. Related, you can increase the number of concurrent uploads with docker push, and I am also curious if this is reproducible by docker push after increasing it.

I just wanted to chime back in. I have setup a simple environment using Docker to run three services. My intention is to replicate a sample user environment. These containers are running on a public cloud instance and I am running jib locally.
Containers:

Quay v3.0.5
Postgres 9.6
Redis (latest)

Unfortunately I am unable to replicate the issue under these circumstances. I can tell there is a significant difference in performance and making these requests in parallel, quickly.
I am not sure why I was running into the chunk encoding issue previously but it could be a number of factors in my environment so I don't want to point a firm finger at that issue. My development environment is significantly different than any user-facing environment.
If someone else can help me setup a test scenario to reliably reproduce this issue, that would help tremendously. My ideal goal would be to have verbose logs on quay and on jib's end. On Quay, I am providing the environment variable DEBUGLOG=true and in Jib I am providing multiple options:
mvn -Djib.console=plain -Djava.util.logging.config.file=./logging.properties compile jib:build 2>&1 | tee jib-log.txt

Seeing as the performance is significantly different in this scenario, I am also curious if your theory about the connections is related @chanseokoh. As soon as I have time, I'll try to run Jib on the same instance that's running Quay to see if I can reproduce with the lower latency.
I did quickly test pushing a large image with "high concurrency" using Docker to the same Quay instance. It appears that Docker v18.06.3 actually retries pushing a layer upon failure. Modifying the file /etc/docker/daemon.json on Fedora 30, I have set the max upload count to 1,000 although it looks to be using only ~13 in parallel. In this quick test, I was able to reproduce the retry scenario a few times but have not gathered any data which indicates why there are failures.
@hbjastad Would you be able to attempt a similar test -- running a highly parallelized Docker push to your Quay environment? That might shed some light on to whether this is related to Jib or not, as suggested by @chanseokoh.

Using helloworld I tried running mvn compile jib:build 10 times,
with our local Quay installation, which is now on v3.1.0
I got this error once, which is strange:
[ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:1.6.1:build (default-cli) on project helloworld: com.google.cloud.tools.jib.api.RegistryUnauthorizedException: Unauthorized for QUAY-REGISTRY/r2d2/distroless_java: 401 Unauthorized
[ERROR]
[ERROR] <title>401 Authorization Required</title>
[ERROR]
[ERROR]
401 Authorization Required

[ERROR]
nginx/1.12.1
[ERROR]
[ERROR]

@kurtismullins, any idea why this would happen randomly?
The 500 error did not show up at all.
I updated the version to 1a and tried another 10 runs, with the exact same result
(401 error once, no other errors).
I then tried another 10 runs, this time I got the 401 error twice, and still no
500 error.
Is it possible that v3.1.0 of Quay has fixed the 500 error and instead introduced
this new, infrequent, 401 error?

@hbjastad That's interesting. I'm glad the 500s have cleared up for you! I am not sure about the 401. There were some auth-related changes between those two versions so it is possible although our test coverage is pretty extensive so I wouldn't expect to see any authentication errors unless Jib is first making an unauthenticated request.
It may be helpful to add the -X flag to your mvn command to see which request is unauthenticated.
Until we can pinpoint that Jib, specifically, has an issue, I'd like to invite anyone interested over to discuss this in our Google Group. I have created a thread related to this Github issue. My hope is that this will get more visibility by other members in the Quay team/community and avoid producing more notifications than necessary for the folks behind Jib.
In the mean-time, I'll try to reproduce the HTTP 401 response in Jib to see if I can track down what's going on there.

Re: the random 401 errors (https://github.com/GoogleContainerTools/jib/issues/1986#issuecomment-536905823), I've analyzed the log and showed here that it is most likely Quay that sometimes misbehaves.

There has been a development in the thread re: 401 errors, and looks like the cause is identified.
The 401 situation is a bit similar to #1914. In #1914, the Location: value returned by the Microsoft server had two consecutive slashes (//) in the path component and various non-alphabet characters encoded in the query string part, and the Apache library was normalizing and decoding them. Here with Quay, the Location: had %2F in a query string value that is being normalized to /. We disabled normalizing double slashes, which Microsoft seemed to have trouble, but not disabling decoding query string values. Apparently, Microsoft has no problem dealing with decoded string values, but Quay doesn't seem to, so that is probably why this is still problematic with Quay. It is probably the best that Quay fixes its behavior to conform to the standard in handling query string values. We could also try to find a way to disable decoding query string values, but this query string handling seems so basic, and I'm not sure if there's an API for that.

Still in a deadlock: https://groups.google.com/forum/#!topic/quay-sig/2y7tMP0h0g0

In https://github.com/GoogleContainerTools/jib/issues/2106#issuecomment-547593721, I've identified it is GenericUrl that does escaping query strings. (But it is still possible that Apache HttpClient may do a similar escaping.)
from: exp=1572285389~hmac=f0a387f...     --> OpenShift says OK
to  : exp%3D1572285389~hmac%3Df0a387f... --> confuses OpenShift

So in #2106, escaping some characters confuses the OpenShift registry. However, this issue is the opposite. The query string value is being unescaped:
from: Signature=2wYOD0a%2BDAkK%2F9lQ... --> Quay says OK
to  : Signature=2wYOD0a%2BDAkK/9lQ...   --> confuses Quay

Worse, I realized this decoding happens on a different execution path than the path that encodes query strings.

@sergue1 @hbjastad
#2201 only resolves the random 401 errors,. But it was reported at some point that 500 errors are no longer returned. (Maybe Quay fixed it?) I'm closing it now, but if you still need assistance in having Quay folks fix internal server errors, feel free to re-open.


Dark mode support

Hello!

Vote on this issue by adding a 👍 reaction
If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details
When I am browsing the API docs for a package and even simply browsing around in the registry the white background is tough on my eyes. Adding dark mode support would help immensely for late-night hackers like me and also for those who prefer a dark theme at all times.
Affected area/feature
The whole registry site

plllleeeeease <3

Agreed, went to look for it today and was disappointed when I discovered no such option exists. I would be very grateful for this addition :)

we are working on this right now!! you should see this available by the end of the month if not earlier ❤

Rad!!

Middle of May bump ;)

sry yall, this was delayed to prioritize our may 4th launch. we ar hoping to pick it back up soon.
https://www.pulumi.com/blog/pulumi-universal-iac/

Hello platypuddians,
I would also like dark theme. Godspeed.

any update on this @susanev ?

@twoTimesAgnew I've had pretty good luck using the Dark Reader extension to view their site in a dark mode. However, native support is always better.

hi! we are doing q4 planning, and this is on my list, so we will be trying super hard to make this happen before the end of the year. 🤞🏻

hi all, the ux team would love to make a dark theme available for pulumi's marketing website, docs, and registry sometime before the year wraps. the design work has been ready for awhile now, so we're hopeful to make space for development soon! leaving a small preview of the homepage with the dark theme enabled.

a few other things to expect:

the current light theme will remain default, but you'll be able to turn on dark mode from any page on our marketing website, docs, or registry
we'll remember your selection so you'll only have to toggle the theme once
if you have any feedback, please don't hesitate to reach out to us!

@anita-trimbur Woo hoo! Could you share an example dark-modized paragraph and code block, please? :)

@Wittionary absolutely! here's a preview of the dark theme applied to a package page in the registry

Waiting for you guys!

Guessing there are a lot of busy devops folk like myself Pulumi as an extracurricular activity given current industry trends. Dark mode docs would be excellent!

:+1:

Please? The light burns my eyes :(


Fix -proto artifact publishing

In Gradle v5.6 the behaviour of publication config has been changed. Now it is impossible to have more than one publication with the same group ID, artifact name, and version. This breaks the mechanism of publishing -proto artifacts in core-java.
In order to work this around, we now publish all the artifacts in a single publication. The artifacts are collected through the archives configuration.
This is also more pluggable and helps configure to publish more artifacts in separate projects without changing the config.

@armiol, PTAL.


How to get --watch working?

Can't seem to get the --watch feature to work and I've tried the following on macOS 10.12 using 0.7.0 with Firefox:

apiary preview --watch and opens a  new browser tab and nothing happens when I save changes to the original file

apiary preview --server --watch and endlessly complains about the following with different directories
 ** ERROR: directory is already being watched! **

  Directory: /Users/cloud_171/Library/Containers/com.apple.iPhoto/Data/Desktop

  is already begin watched through: /Users/cloud_171/Desktop

  MORE INFO: https://github.com/guard/listen/wiki/Duplicate-directory-errors

--server is needed for the watch functionality as the output needs to be served dynamically - i'll mention it in readme/help
it is a limitation of the 'listen' lib used for detecting ADD changes - we'll try to solve it in near future

@tu1ly Thanks! Should've actually read the duplicate directory error link and the workaround would be obvious.

I've come across this error but it seems that the wiki for the duplicate directory error is nowhere to be found. Could you point me to another resource? Thanks!


Intellisense suggestions cannot ignore case issues

1
The same function, if I start with a capital letter I can't get intelisense suggestion.
I think is good to  add a ferature like pycharm about code completion :

2
Please add support for pyqt5 module, I can't get intelisense  suggestions.

Hey @CatNofishing
Thanks for the suggestion. We are currently investigating this request and will update with details soon.

@savannahostrowski   Thank you for your reply 😁

This issue stiil exist

Unless I'm mistaken, this has been working since 2020.12.0, which introduced fuzzy matching for completion items.


Neon crashes when uploading new files

It has happened several times that neon crashes when uploading new files.

Unassigning myself because I can't manage to replicate this.


Files resolved via paths confg don't get source maps.

I'm migrating a project that was using the require optimizer to amd-optimize. I've been struggling with a build that wasn't getting sourcemaps output and have tracked the problem down to files which get resolved via paths configuration.
My config looks something like this:
var amdConfig = {
    "baseUrl": "./target/js",
    "preserveFiles": true,
    "paths": {
        "class": "/lib/class-amd",
        "passwordstrength": "/lib/passwordstrength-amd",
        "jquery": "empty:",
    }
};

And my task looks more or less like this:
return gulp.src('target/js/**/*.js', { base: amdConfig.baseUrl })
    .pipe(sourcemaps.init())
    .pipe(amdOptimize("project-name/bootstrap", amdConfig))
    .pipe(concat('bootstrap.js'))
    .pipe(sourcemaps.write())
    .pipe(gulp.dest('./target/js/built'));

I found the problem by removing the concat line and noting that all files appeared to have sourcemaps. This lead me to thinking that perhaps a few files didn't so I inserted a debug log into gulp-sourcemaps to let me know if this was the case. It turns out that both class and password strength don't have sourcemaps associated. This leads to no files having sourcemaps after concat.
If I write a fix I'll PR it here. Just raising the bug here now in case you're more prepared to fix since you are more familiar with the code.
Thanks for the great project :).

mm, upon reading the code
# TODO: Handle shimmed, mapped and relative deps

Is probably relevant.

I tracked down the culprit. When index's module.exports.loader get's used instead of the other methods of loading a file, source maps don't exist on the loaded files as they haven't gone through sourcemaps.init(). Removing the leading / from my paths declarations resolved the issue.
Seem like an issue with my configuration. Primarily that paths wasn't being used as expected. I believe I had changed them to use a leading slash because using a leading ./ causes problems in how the file is looked up inside trace. If a path starts with a dot, it ends up assuming the path is relative to the module that depends on it.
I'll close this issue now.


riot-web: mention incompatible config change in release notes

Motivation for this change
Mention the changes introduced in commit c9e5cca.
GitHub: closes #81416
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@rnhmjoj PR amended to mention builtins.fromJSON and add an example.

Backported to release-20.03 in 61cc1f0dc07c2f786e0acfd07444548486f4153b.


Add Autobahn test suite for websockets

We're using the existing test suite for websocket servers from the
Autobahn project to verify that out websockets implementation is
sane. A CT test suite and python module wrapping the test suite has
been added. The test suite is run when the 'make inttests' target
is executed.
We're awaiting the inclusion of these changes to rebar: https://github.com/basho/rebar/pull/166

Awesome. Can't wait!

The python script doesn't seem to run on python 3.2.2. Also tried on the last python2 and it doesn't work there either. For what version did you make it work? Or do I miss a python related package maybe?

Is there a stacktrace or error message in the CT logs? It would help a little.

Nothing interesting in the ct log (badmatch in suite's init), but I had something a little better running it by hand (syntax error though), I'll try to run it again soon.

essen@alice (0) % python test.py
File "test.py", line 67
print 'AB-TESTS-SETUP-OK'
^
SyntaxError: invalid syntax

Python 3.2.2 from the current Arch Linux.

Ok, so python 3 has removed the print statement from the language, I tested using the print function that replaced it on 2.7.2 and it works as well. Lets fix this and hope that this is the only issue.

Ping. ;)

So, trying to get this running on Python3 is not going to happen until Twisted has added support for it. Do you think there's any way to work around it on your end?

Thanks!


Fix for comparison issue in columns_equal when ignore_case=True (Generated by Ana - AI SDE)

Description
This PR addresses an issue in the columns_equal function where comparing datetime.date columns incorrectly returns false differences when ignore_case=True. The patch ensures that string operations are only performed on appropriate types, resolving this issue.
This patch was generated by Ana - AI SDE, an AI-powered software development assistant.
This is a fix for Issue 327

@ana-ai-sde There seem to be some issues with the code. Also there are no new unit tests included in the PR.

Hi @fdosani
For the test cases. We will add the ones that Ana used internally in the same PR.
BR,
Team Ana

@ana-ai-sde There seem to be some issues with the code. Also there are no new unit tests included in the PR.

Hi @fdosani
For the test cases, we will incorporate the ones that Ana utilized internally within the same pull request after ensuring compatibility with the repository guidelines.
BR,
Team Ana

Thanks for the PR, at this time the SDE contributions don't meet our contributor guidelines. Closing this for as of now.


unable to find out ruby.h

https://travis-ci.org/ruby/ruby/jobs/78775640
33)

An exception occurred during: loading /Users/travis/build/ruby/ruby/spec/rubyspec/optional/capi/typed_data_spec.rb ERROR

RuntimeError: Unable to compile "/Users/travis/build/ruby/ruby/spec/rubyspec/optional/capi/ext/typed_data_spec.c"

/Users/travis/build/ruby/ruby/spec/rubyspec/optional/capi/spec_helper.rb:79:in `compile_extension'

/Users/travis/build/ruby/ruby/spec/rubyspec/optional/capi/spec_helper.rb:108:in `load_extension'

/Users/travis/build/ruby/ruby/spec/rubyspec/optional/capi/typed_data_spec.rb:3:in `<top (required)>'

/Users/travis/build/ruby/ruby/spec/rubyspec/optional/capi/ext/util_spec.c:1:18: fatal error: ruby.h: No such file or directory

 #include "ruby.h"

                  ^

compilation terminated.

ERROR:

incflags=-I/Users/travis/build/ruby/ruby/spec/rubyspec/optional/capi/ext -I/./include -I/.ext/include/x86_64-darwin13 -I/./include/ruby

cflags= -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Werror=pointer-arith -Werror=write-strings -Werror=declaration-after-statement -Werror=implicit-function-declaration -Werror=deprecated-declarations -Wno-packed-bitfield-compat  -pipe  -fPIC

It seems due to a bug of the recent changes to fake.rb.
@nobu Can you fix in fake.rb and/or in rubyspec if the logic is incorrect?

Seems to work now, but the generated config does not seem optimal, in particular:
RbConfig::CONFIG["rubyhdrdir"]
# on the failing commit: "/./include"
# on recent commits: "././include"

Thank you!


main attribute in bower.json

Hi,
Would you please add "./d3plus.js" into "main" attribute in the bower.json file in order to allow something like wiredep to inject d3plus script file into html?
Thanks.

@chocstarfish, let me know if this works!


Is it possible to back mobx keystone?

Hi,
mobx keystone is awesome. Is it possible to support it financially? For example through Patreon or something similar.

Duplicate of #137.


Cmd-P/Ctrl-P hotkey of google saved brew loads hb print url

From here:
https://www.reddit.com/r/homebrewery/comments/qgh7br/homebrewery_export_issue/hk077vf/

I clicked thru to here:
https://homebrewery.naturalcrit.com/share/1Bi_Y3ZIDi2Wsf96kE6edbqm6vAY-XE4bBYkH_7v0-Mau

I hit cmd-P to print, landed here:
https://homebrewery.naturalcrit.com/print/BYkH_7v0-Mau?dialog=true

Which says
Can not find brew

Back to the brew, clicked the Get PDF button:
https://homebrewery.naturalcrit.com/print/1Bi_Y3ZIDi2Wsf96kE6edbqm6vAY-XE4bBYkH_7v0-Mau?dialog=true

Error is here:
https://github.com/naturalcrit/homebrewery/blob/fb52618ce95ae25a33edeb7fea64c9d08b420288/client/homebrew/pages/sharePage/sharePage.jsx#L44
Needs to be run through the processShareId() function same as https://github.com/naturalcrit/homebrewery/blob/fb52618ce95ae25a33edeb7fea64c9d08b420288/client/homebrew/pages/sharePage/sharePage.jsx#L66


Remove hacking protections from atmos and sec airlocks

About the PR
Removes hacking protections from atmos and sec airlocks that were introduced by https://github.com/space-wizards/space-station-14/pull/18894.
Why / Balance
After a discussion with the author, we agreed to drop hacking protections from atmos and security. Some relevant points from the discussion:

Hacking protections make hacking way to difficult, requiring effectively a full engineering belt, goggles, and insulated gloves, and takes a significantly longer amount of time.
It is more fun to extend an existing mechanic, for example, by adding the number of wires, instead of adding an additional orthogonal mechanic.
Others have expressed that only emagging is worthwhile. It has to be a plausible, roughly equally balanced difficulty/outcome in order for something to be considered a "good" tradeoff, and right now hacking is leaning more strongly towards the "too difficult" side of balance.

Media

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

Breaking changes

Changelog

Honestly think it should be removed from command doors too. Just keep it on the high security doors since they’re, yknow, high security, but it should be possible to hack onto the bridge or someone’s office if you want to.

i concur

Superseded by https://github.com/space-wizards/space-station-14/pull/20171


Fix settings documentation

README says:

Settings
Note Directory: The directory to archive notes.

… except, a quick peek at note.coffee says it's notational-velocity.directory.

Next time, I'll just write a pull request to avoid the issue noise. Sorry about that; this is my first pull request since becoming able to. Long story.


Program running issues

Hi, I am a newbies in machine learning and interested in your Fundus-Image-Classification. Want to learn your code, quoted from one of my work.I have some questions about the data processing part of the code. Can you provide me with the data of your code? Thank you.

Hi,
The link to the dataset is right there in the documentation.
Have fun reading.
Greetings
Daimon
DeFi13 @.***> schrieb am Mi. 27. Dez. 2023 um 03:44:

Hi, I am a newbies in machine learning and interested in your
Fundus-Image-Classification. Want to learn your code, quoted from one of my
work.I have some questions about the data processing part of the code. Can
you provide me with the data of your code? Thank you.
—
Reply to this email directly, view it on GitHub
https://github.com/daimonae/Fundus-Image-Classification/issues/1, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AT6RMK2JNRP7TDRJFUCCPLLYLODQLAVCNFSM6AAAAABBD25NJ6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2TMOBUG44TSOA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


fix: move peerDependencies to dependencies

Current dependencies on/for this PR:

main

PR #9   👈

This comment was auto-generated by Graphite.


Added hashtags highlighting to Tweet card body

This PR resolves the following issue: https://github.com/mikaelacaron/brain-marks/issues/82

I just tested this and it seems to be missing some hashtags here and there.

Can I work on this?


Update dependencies, Move to pnpm

@jwm0 are you OK with moving to pnpm so we standarize across different repos (cli, app-template, react-storefront, checkout)?

The NodeJS problem on GitHub Actions comes from bumping TypeScript to 4.7.2, but locally it works just fine.


Update UVR model 20181213

From comment on #39:
@BenjaminPelletier, we have updated UVR model
https://github.com/nasa/utm-apis/blob/v4-draft/utm-domains/utm-domain-commons.yaml
This is usually announced in the uss_implementor's channel.
Going forward, we will give you advance notice that will allow our models to be in sync before the announcement goes out.
Can you please update your model based on this?
We have been trying to codegen from your version and have encountered a problem with "allOf" attribute. We are currently blocked. I believe the v4-draft does not include this attribute.
Hopefully, this problem will go away after you sync up with our version.
Originally posted by @myspri in https://github.com/wing-aviation/InterUSS-Platform/issues/39#issuecomment-446751872

Made redundant by #67


[Dashboard] Remove TableContainer from tw-components

DASH-417

#5338  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @kien-ngo and the rest of your teammates on  Graphite


Update cy file

Make sure code coverage considers branch master coverage.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@fe2b381). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #20   +/-   ##
=========================================
  Coverage          ?   86.20%
=========================================
  Files             ?       18
  Lines             ?      174
  Branches          ?       50
=========================================
  Hits              ?      150
  Misses            ?       24
  Partials          ?        0

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 fe2b381...b36b437. Read the comment docs.


Hide Keypad when EditText out of focus

In order to increase the user experience the keypad should be hidden each time the editText is out of focus.
Activity and fragment that include this feature:

fragment_single_upload

Activities or fragments that need this change:

activity_login
fragment_categorization
fragment_multiple_upload_lists

I start working on this :)

Hi, Is @liormic still working on this issue? If not, Can I please start working on this?
Thanks

@gupta-meghna64 : No news from @liormic since a week, so yes you can take it! Be sure to report your progress every few days at least. Thanks! :-)

Sorry guys .Yes gupta been working on another thing...Better if you take it
Tnx

Cool! I'll start working on it :)

Awesome @gupta-meghna64. Am marking this task as assigned.