Image writer options

This is a work-in-progress PR for per-format options in the ImageWriter node.
Currently, the implementation and UI are done.
Still to come:

Documentation in the UI
Tests
Compatibility conversion ('mode' (tile/scanline) has moved to be per-format)

I have a question for you all (anyone who cares!) on this:
I have two formats that aren't quite right, based on the test - OpenEXR and tiff. Obviously important ones to get right!
With OpenEXR, half and float are both fine, it's uint32 that I may need to do some special case work on. The issue is that when converting from float data to uint32 data, OIIO is remapping a 0..1 range to 0..INT_MAX. This is certainly an option. The other possible option is to round the float numbers to the nearest integer in the range 0..INT_MAX and write that instead.
Thoughts?

FYI, the other option, and this would be what Nuke has decided to do, is to not support writing of UINT EXRs.
Nuke, for reference supports half and float EXRs only, and 8-bit, 16-bit and float TIFFs. OIIO specifies that TIFF supports far more formats, although seems to have issues writing some of them (int32 and uint32 fail to write, int8 and int16 seem to remap 0..1 to -1..1. Well, this could well be Nuke reading them wrong...) Nuke is also unable to read (or OIIO has corrupted on write) double float tiffs
My proposal for a cut-down selection that will be supported straight-off would be:
OpenEXR:

half
float

Tiff:

uint8
uint16
half
float

With our own remapping, we could also support uint32 EXRs, and I'd have to do some research to figure out whether the issue with int8 and int16 tiffs is in OIIO or Nuke.

Your cut-down list sounds like a good start to me - it'll cover a whole load of scenarios we don't yet support at all, and we can then deal with the other data types when we have clear use cases for them to guide our decision making...

What're your thoughts on leaving things in the code as comments (in terms of the currently disabled presets in ImageWriterUI for now), vs completely removing all reference to them.
Currently, ImageWriterUI.py has a few things commented out:

visibility activators
EXR compressions supported from 2.2.0 upwards (we're on 2.1.0)
EXR and Tiff data types

Another question too:
OIIO considers uint8 to be the 'default' tiff data type. However, Gaffer previously forced it to float. Do you think that I should leave float as the default, or change it to uint8? (Curiously, Nuke doesn't support tiled float tiffs)

We have a "no dead code" policy, so we should remove all the commented stuff. I'm with OIIO on considering uint8 to be the default for TIFF, and personally don't have any concerns about backwards compatibility in that area unless @andrewkaufman does. Are we also making half the default for EXR?

Okay - will do then.
I've realised that I could probably do with a test case to check the default values of the image writer format plugs...

I've just pushed my last change to this, so I'm officially putting it up for review. All plugs are now documented.

The Travis tests seem to be failing - perhaps because the gaffer version number in the image metadata has changed (the version on master has moved on since you branched)? If that is the reason, then I guess we need to ignore that particular metadata when testing.

I've figured out the travis test failure - the metadata from the actual image stream was trumping the fields like Software, etc. This should have been a failure before, but there was no IPTC metadata in the original image it was pulling in.

All notes addressed apart from the extra binary data in the tests.

For some reason GitHub isn't letting me reply to the inline conversations any more, so I'll have to reply to the couple of remaining things here.
About the unnecessary #include, we quite deliberately omit includes from headers if they are not needed by those headers, to cut down on recompilation time (it's infuriating when you change one tiny thing and the whole project decides it needs to rebuild). So please limit includes to only where they're absolutely necessary, and use forward declarations where possible instead.
About the "hash all of the file format settings if the file format is empty" thing, I probably didn't explain myself well enough before. If a plug has substitutions (${something}) or an input connection, then it can yield multiple values based on the context in which it is evaluated - this is the fundamental basis for the multithreading in gaffer, and the tile-based image generation and the random-access scene generation. So, in the context of the UI, when we were trying to hide the irrelevant file format options, I was trying to say that if a plug has substitutions or an input, it might be that more than one set of options is relevant, depending on context. So I was suggesting that perhaps the UI showed all of them in this case, rather than just show the one that is relevant in the exact current UI context.
But in hash(), we're definitely only interested in one context - the one which is current when hash() is called, and we're just responsible for computing a signature for what execute() will do when performed in that very same context. So, once we've performed the substitutions using the current context in currentFileFormat(), we should know exactly what is happening, and if the file format is empty, that should mean that execute() won't be using any of the format options (it'll be erroring instead).

For some reason GitHub isn't letting me reply to the inline conversations any more, so I'll have to reply to the couple of remaining things here.
About the unnecessary #include, we quite deliberately omit includes from headers if they are not needed by those headers, to cut down on recompilation time (it's infuriating when you change one tiny thing and the whole project decides it needs to rebuild). So please limit includes to only where they're absolutely necessary, and use forward declarations where possible instead.
About the "hash all of the file format settings if the file format is empty" thing, I probably didn't explain myself well enough before. If a plug has substitutions (${something}) or an input connection, then it can yield multiple values based on the context in which it is evaluated - this is the fundamental basis for the multithreading in gaffer, and the tile-based image generation and the random-access scene generation. So, in the context of the UI, when we were trying to hide the irrelevant file format options, I was trying to say that if a plug has substitutions or an input, it might be that more than one set of options is relevant, depending on context. So I was suggesting that perhaps the UI showed all of them in this case, rather than just show the one that is relevant in the exact current UI context.
But in hash(), we're definitely only interested in one context - the one which is current when hash() is called, and we're just responsible for computing a signature for what execute() will do when performed in that very same context. So, once we've performed the substitutions using the current context in currentFileFormat(), we should know exactly what is happening, and if the file format is empty, that should mean that execute() won't be using any of the format options (it'll be erroring instead).

For some reason GitHub isn't letting me reply to the inline conversations any more, so I'll have to reply to the couple of remaining things here.
About the unnecessary #include, we quite deliberately omit includes from headers if they are not needed by those headers, to cut down on recompilation time (it's infuriating when you change one tiny thing and the whole project decides it needs to rebuild). So please limit includes to only where they're absolutely necessary, and use forward declarations where possible instead.
About the "hash all of the file format settings if the file format is empty" thing, I probably didn't explain myself well enough before. If a plug has substitutions (${something}) or an input connection, then it can yield multiple values based on the context in which it is evaluated - this is the fundamental basis for the multithreading in gaffer, and the tile-based image generation and the random-access scene generation. So, in the context of the UI, when we were trying to hide the irrelevant file format options, I was trying to say that if a plug has substitutions or an input, it might be that more than one set of options is relevant, depending on context. So I was suggesting that perhaps the UI showed all of them in this case, rather than just show the one that is relevant in the exact current UI context.
But in hash(), we're definitely only interested in one context - the one which is current when hash() is called, and we're just responsible for computing a signature for what execute() will do when performed in that very same context. So, once we've performed the substitutions using the current context in currentFileFormat(), we should know exactly what is happening, and if the file format is empty, that should mean that execute() won't be using any of the format options (it'll be erroring instead).

All sounds good to me.
I've just pushed changes that should address all notes.
I haven't shifted images over to GafferImageTest/images yet, as there's a lot of crossover with other node tests. Can I suggest that I do all of that in a separate PR? There is one additional image in this PR, as a base default DPX, but other than that, I've removed all of the excess binary data, and am checking against just a single base file per format, doing any metadata tweaks as appropriate. There's no way of checking for compression in the metadata that comes through from OIIO, it seems, but then there wasn't before, if it was lossless, as the resulting image data would have ended up the same.

Cool - moving the images in a separate PR sounds like a good plan. Because of Git's "every repository holds all the history" architecture, we'll actually be paying for those added+deleted files in every checkout still though. Could you try a rebase squashing the "add images" and the "remove images" commits together - hopefully that should mean the deleted ones disappear for real.

Like so? Done.

I've just realised I've missed a chunk of work on this.
I need to get it to shift the write mode onto the format plugs when old scripts are loaded.

Just chiming in now... yes to the cut down list, yes to sensible default format settings instead of backwards compatible ones.
About the EXR 2.2.0 compressions schemes, can we expose those in some way that still lets you use 2.1.0? We're using 2.2.0 here and there have been several requests to test out that Dreamworks compression...

There's the compatibility code. I'm only supporting w["writeMode"].setValue() here, not any other method on the (now non-existent) plug.
They will already be supported at the C++ end of things, if it's compiled with 2.2.0. However, they won't be in the presets list. If there's a way to get at the OpenEXR version from Python, then yet, the presets could be added in the UI.py file if it's using the right OpenEXR version. It feels slightly hacky to just bind a openexrVersion() or openexrSupportsDWA() method on the ImageWriter, but that would do it. Beyond that, any suggestions?

For my part, I don't mind adding another preset at IE only. We probably should ship Gaffer with the presets that make sense for whatever EXR version we're using in the public builds though... @johnhaddon what version is that?

Cool - I was going to suggest we just add an extra config with the DWA preset at Image Engine. We're using 2.1.0 in the public builds but I don't know of any reason we couldn't just move that up - it'd get us a bit closer to VFXPlatform conformance which would be no bad thing.

I think that shifting the public version up to both keep it inline with your IE end, plus to keep it up to date would be the ideal solution.

Agreed - it'll take a bit of time to get that rolled up though, so shall we go with the image-engine-specific-config in the meantime?

Sounds good. All it needs is the presets adding into the UI file - with the right defines set, the c++ will compile with support already.

Thanks Hugh!

Good stuff - thanks!

Hey guys, I just updated master, and I'm seeing all the extension plugs visible regardless of my filename. Did this PR include the visibilityActivators or did we decide to leave that for a separate PR?

We decided to leave that one for another PR.
Hugh Macdonald
Nvizible - Visual Effects
020 3167 3860
07773 764708
www.nvizible.com
On 10 Sep 2015, at 19:33, Andrew Kaufman<EMAIL_ADDRESS>wrote:
Hey guys, I just updated master, and I'm seeing all the extension plugs
visible regardless of my filename. Did this PR include the
visibilityActivators or did we decide to leave that for a separate PR?
—
Reply to this email directly or view it on GitHub
https://github.com/ImageEngine/gaffer/pull/1471#issuecomment-139337211.

I'll open an issue describing what I think would be good to have

FYI - I've just realised why jpeg writing is failing. This is because OIIO doesn't define Jpegs as supporting alphas, but we aren't checking that, and are pushing alpha data in. I'm going to look at fixing this up, so that the ImageWriter checks out->supports( "alpha" ). At the same time, I'll also check out->supports( "nchannels" ), without which, only RGB (or RGBA if it supports alpha) should be written.


Implement armstrong numbers

Hi!
Ported armstrong-numbers exercise to C++.

@patricksjackson thank you for your time! I like your proposal for make example solutions as clear as we can for future students. Note for self for my next PRs ;)


Configurable step size when using shortcuts

Using shortcuts to, for example, increase the brightness, increases it by 1% for every keypress. Having to use the shortcut a lot to get a desired level is a bit annoying, while holding it down results in a slow increase that can take several seconds to complete during which the system is not accessible.
I don't need the fine adjustments, 10% per press would probably be sufficient. So a setting to configure the step size would be great.

Will be implement on version 2.0, that will be released in the following days.

The version 2.0.0 was reverted back on the repository.
For now, if you want the latest version maintained by me you can follow these steps:

Download zip from<EMAIL_ADDRESS>Extract .zip archive to ~/.local/share/cinnamon/applets.
Enable the applet in Cinnamon settings


Query return

Hello,
When I created a query and return respective results, "date colums" aka "Closed Date", "Created Date", respectiva value is formatted to UTC, not local time.

Otto,
The fix is working correctly!
Congrats.


Updated Gui

Still incomplete but here is what I got for the GUI

Dashboard files merged manually into /gui/Dashboard folder


ONLYOFFICE Editor does not work as expected

Hi team,
I'm recently integrating this onlyoffice-strapi plugin in my own project. It seems that the editor does not work as expected.

The JWT secret validation functionality works fine, but when I try to edit files it keeps popping up 'The document cannot be saved error'. I checked the request header and the Authorization part was not found.

Hi,
A possible explanation would be connection issues: if Strapi is not reachable by the Document Server, the document can't be downloaded for editing. Could you check the connection between the servers?


What is the difference between AddKeyedSqlServerClient and AddSqlServerClient?

Describe the issue or suggestion
Is not clear What is the difference between AddKeyedSqlServerClient and AddSqlServerClient?  If documentation about it exists, I could not find it, and if it does exists, please provide link.

cc @eerhardt

Check out

https://learn.microsoft.com/dotnet/aspire/fundamentals/components-overview#keyed-services

The XML docs have something that could be improved though:
https://learn.microsoft.com/dotnet/api/microsoft.extensions.hosting.aspiresqlserversqlclientextensions.addkeyedsqlserverclient

Registers 'Scoped' SqlConnection factory for given name for connecting Azure SQL, MsSQL database using Microsoft.Data.SqlClient. Configures health check, logging and telemetry for the SqlClient.


for nomad case can we mark node as ineligible

for chaos perspective we should make node as ineligible so that workload shift to another node.

hmm, that sounds interesting. We were only thinking about bringing chaos to the workload and didn't think about the nodes and the cluster.

https://developer.hashicorp.com/nomad/api-docs/nodes#drain-node
https://developer.hashicorp.com/nomad/api-docs/nodes#purge-node

can we also test this out if you contribute I would be happy to test this out

@resmo any thoughts on this?

@thatsk let's clarify that we understand the same: chaotic should drain a node (workload gets shifted), wait some time and then marking the node as eligible for scheduling again, right?

yup exactly the same and if we can add some timing as a parameter for what we have done for a job that would be awesome. for eg. Drain the node for 5 min.

like allow_node_drainlist:  i am also assuming that we need to add skip_node_drainlist: which is like infra components which don't need to be drained but its optional.

so that workload should be shifted to another workload and once timing has been achieved it should bring back to the original one which is a feature of nomad or wait for that node to be healthy so that we can perform restart stanza and update stanza to be checked

first implementation in #16, I only implemented a skip list, but wouldn't be much work to change it to an allow/block list.

I just think now don't we drain the full node or add a parameter to tag with the system job to be drained or not via config.yaml when I am testing this I think if the node is not eligible for workload then it might be the case the node should be performing an OS upgrade might be I'm not sure.

right now it's performing serially one by one what if we want to perform 20% out of cluster clients or 30%clients to be drained at time in terms of percentage

its just an idea feel free to feedback me

because I am thinking of when autoscaling is performing it might get utilized and trigger an event for to scale up the instance until our instances are eligible for workload

I refactored a bit #16 to have it included into the nomad kind and not in a separate nomad_node kind.

I just think now don't we drain the full node or add a parameter to tag with the system job to be drained or not via config.yaml when I am testing this I think if the node is not eligible for workload then it might be the case the node should be performing an OS upgrade might be I'm not sure.

We could add a tag for also draining system jobs, however, I currently see a real usecase for it.
The implementation in #16 does filter out drained or ineligible nodes

right now it's performing serially one by one what if we want to perform 20% out of cluster clients or 30%clients to be drained at time in terms of percentage

The question is, what is our goal with these experiments, this experiment would target the capacity planning of a cluster and might result in a n-service downtime.
Currently out goal is to test randomly picked services, VMs, nodes  to test for redundancy and failure without impact a huge amount of services or the business service availability in an uncontrolled manner.
However, I think this experiment can be useful for multiple cluster failover experiments, but currently not our main focus.

because I am thinking of when autoscaling is performed it might get utilized and trigger an event to scale up the instance until our instances are eligible for workload

Not sure if I get what you are thinking. Could you describe in more detail?

yes, that is correct whatever you are saying totally makes sense. the implementation which you have done is applicable in a single cluster. But I am thinking about multi-region and multi-cluster deployment in that we can perform stress on clusters, not on the node level but it's okay whatever implementation right now totally makes sense.
regarding the draining system job I don't see any tag in the config.yaml not sure if its there in code or not.

I think, it wouldn't be too hard to implement an option and calculate the % of nodes to be drained, let me check that.
Adding a config option for system jobs draining.

also drain system job option https://github.com/ngine-io/chaotic/pull/16/commits/0f5b0966ad83045190822456bcf39d41f54fd898

drain multiple nodes in % https://github.com/ngine-io/chaotic/pull/16/commits/edf54f9558932d7208dff2e76fca19ae66a0da63


New package: ADEMCSampler v0.1.0

Registering package: ADEMCSampler
Repository: https://github.com/gboehl/ADEMCSampler.jl
Created by: @gboehl
Version: v0.1.0
Commit: 51eb9a61677543e9b0aeb7c2d68f544e7e7f27ae
Reviewed by: @gboehl
Reference: https://github.com/gboehl/ADEMCSampler.jl/commit/51eb9a61677543e9b0aeb7c2d68f544e7e7f27ae#commitcomment-85021905
Description: Adaptive Differential Evolution MCMC sampling for Julia

Wait...


HBASE-26555 Fix findbugs/spotbugs findings

Commits in the PR branch break down changes per module.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 44s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ branch-2 Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m  3s
branch-2 passed

+1 :green_heart:
compile
12m 13s
branch-2 passed

+1 :green_heart:
checkstyle
5m 33s
branch-2 passed

+1 :green_heart:
spotbugs
10m 37s
branch-2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 33s
the patch passed

+1 :green_heart:
compile
11m 55s
the patch passed

+1 :green_heart:
javac
0m 52s
hbase-common in the patch passed.

+1 :green_heart:
javac
0m 23s
hbase-metrics in the patch passed.

+1 :green_heart:
javac
1m 13s
hbase-client generated 0 new + 157 unchanged - 1 fixed = 157 total (was 158)

+1 :green_heart:
javac
0m 29s
hbase-zookeeper in the patch passed.

+1 :green_heart:
javac
0m 26s
hbase-replication in the patch passed.

+1 :green_heart:
javac
0m 34s
hbase-http in the patch passed.

+1 :green_heart:
javac
0m 30s
hbase-asyncfs in the patch passed.

+1 :green_heart:
javac
0m 35s
hbase-procedure in the patch passed.

+1 :green_heart:
javac
3m 30s
hbase-server in the patch passed.

-0 :warning:
javac
0m 51s
hbase-mapreduce generated 1 new + 197 unchanged - 1 fixed = 198 total (was 198)

+1 :green_heart:
javac
0m 58s
hbase-rsgroup generated 0 new + 190 unchanged - 1 fixed = 190 total (was 191)

-0 :warning:
javac
0m 43s
hbase-it generated 3 new + 100 unchanged - 3 fixed = 103 total (was 103)

-0 :warning:
javac
0m 51s
hbase-rest generated 1 new + 184 unchanged - 4 fixed = 185 total (was 188)

+1 :green_heart:
checkstyle
0m 25s
The patch passed checkstyle in hbase-common

+1 :green_heart:
checkstyle
0m 11s
The patch passed checkstyle in hbase-metrics

+1 :green_heart:
checkstyle
0m 37s
The patch passed checkstyle in hbase-client

+1 :green_heart:
checkstyle
0m 15s
The patch passed checkstyle in hbase-zookeeper

+1 :green_heart:
checkstyle
0m 13s
The patch passed checkstyle in hbase-replication

+1 :green_heart:
checkstyle
0m 14s
The patch passed checkstyle in hbase-http

+1 :green_heart:
checkstyle
0m 14s
The patch passed checkstyle in hbase-asyncfs

-0 :warning:
checkstyle
0m 15s
hbase-procedure: The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-0 :warning:
checkstyle
1m 32s
hbase-server: The patch generated 2 new + 763 unchanged - 10 fixed = 765 total (was 773)

+1 :green_heart:
checkstyle
0m 20s
hbase-mapreduce: The patch generated 0 new + 86 unchanged - 1 fixed = 86 total (was 87)

+1 :green_heart:
checkstyle
0m 13s
The patch passed checkstyle in hbase-rsgroup

+1 :green_heart:
checkstyle
0m 20s
The patch passed checkstyle in hbase-it

+1 :green_heart:
checkstyle
0m 16s
The patch passed checkstyle in hbase-rest

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
15m 25s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
12m 43s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
2m 29s
The patch does not generate ASF License warnings.

101m  0s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3937

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 16412fdc97c3 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / bf6f94685c

Default Java
AdoptOpenJDK-1.8.0_282-b08

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/artifact/yetus-general-check/output/diff-compile-javac-hbase-mapreduce.txt

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/artifact/yetus-general-check/output/diff-compile-javac-hbase-it.txt

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/artifact/yetus-general-check/output/diff-compile-javac-hbase-rest.txt

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-procedure.txt

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

Max. process+thread count
87 (vs. ulimit of 12500)

modules
C: hbase-common hbase-metrics hbase-client hbase-zookeeper hbase-replication hbase-http hbase-asyncfs hbase-procedure hbase-server hbase-mapreduce hbase-rsgroup hbase-it hbase-rest U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 36s
Docker mode activated.

-0 :warning:
yetus
0m  7s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 54s
branch-2 passed

+1 :green_heart:
compile
6m 29s
branch-2 passed

+1 :green_heart:
shadedjars
7m 49s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
4m 53s
branch-2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 22s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 29s
the patch passed

+1 :green_heart:
compile
6m 32s
the patch passed

+1 :green_heart:
javac
6m 32s
the patch passed

+1 :green_heart:
shadedjars
7m 44s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
5m  9s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 56s
hbase-common in the patch passed.

+1 :green_heart:
unit
0m 22s
hbase-metrics in the patch passed.

+1 :green_heart:
unit
2m 52s
hbase-client in the patch passed.

+1 :green_heart:
unit
0m 44s
hbase-zookeeper in the patch passed.

+1 :green_heart:
unit
0m 28s
hbase-replication in the patch passed.

+1 :green_heart:
unit
0m 45s
hbase-http in the patch passed.

+1 :green_heart:
unit
1m 25s
hbase-asyncfs in the patch passed.

+1 :green_heart:
unit
1m 38s
hbase-procedure in the patch passed.

-1 :x:
unit
136m  9s
hbase-server in the patch failed.

+1 :green_heart:
unit
11m 46s
hbase-mapreduce in the patch passed.

+1 :green_heart:
unit
3m 49s
hbase-rsgroup in the patch passed.

+1 :green_heart:
unit
1m 14s
hbase-it in the patch passed.

+1 :green_heart:
unit
3m 12s
hbase-rest in the patch passed.

220m 38s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3937

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 5d38b58e3ea6 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / bf6f94685c

Default Java
AdoptOpenJDK-11.0.10+9

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/testReport/

Max. process+thread count
3718 (vs. ulimit of 12500)

modules
C: hbase-common hbase-metrics hbase-client hbase-zookeeper hbase-replication hbase-http hbase-asyncfs hbase-procedure hbase-server hbase-mapreduce hbase-rsgroup hbase-it hbase-rest U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 19s
Docker mode activated.

-0 :warning:
yetus
0m  7s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 17s
branch-2 passed

+1 :green_heart:
compile
5m 24s
branch-2 passed

+1 :green_heart:
shadedjars
7m 10s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
4m 16s
branch-2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m  5s
the patch passed

+1 :green_heart:
compile
5m 23s
the patch passed

+1 :green_heart:
javac
5m 23s
the patch passed

+1 :green_heart:
shadedjars
7m  6s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
4m  5s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 36s
hbase-common in the patch passed.

+1 :green_heart:
unit
0m 19s
hbase-metrics in the patch passed.

+1 :green_heart:
unit
2m 50s
hbase-client in the patch passed.

+1 :green_heart:
unit
0m 46s
hbase-zookeeper in the patch passed.

+1 :green_heart:
unit
0m 36s
hbase-replication in the patch passed.

+1 :green_heart:
unit
1m 11s
hbase-http in the patch passed.

+1 :green_heart:
unit
2m 19s
hbase-asyncfs in the patch passed.

+1 :green_heart:
unit
2m  2s
hbase-procedure in the patch passed.

-1 :x:
unit
219m 51s
hbase-server in the patch failed.

+1 :green_heart:
unit
16m 12s
hbase-mapreduce in the patch passed.

+1 :green_heart:
unit
4m 33s
hbase-rsgroup in the patch passed.

+1 :green_heart:
unit
1m 11s
hbase-it in the patch passed.

+1 :green_heart:
unit
5m 17s
hbase-rest in the patch passed.

306m 44s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3937

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 6797908d5380 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / bf6f94685c

Default Java
AdoptOpenJDK-1.8.0_282-b08

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/artifact/yetus-jdk8-hadoop2-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/testReport/

Max. process+thread count
2984 (vs. ulimit of 12500)

modules
C: hbase-common hbase-metrics hbase-client hbase-zookeeper hbase-replication hbase-http hbase-asyncfs hbase-procedure hbase-server hbase-mapreduce hbase-rsgroup hbase-it hbase-rest U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

Fix LoadTestKVGenerator related failures.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
2m 26s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  2s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ branch-2 Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 38s
branch-2 passed

+1 :green_heart:
compile
12m 14s
branch-2 passed

+1 :green_heart:
checkstyle
4m 55s
branch-2 passed

+1 :green_heart:
spotbugs
11m 15s
branch-2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 19s
the patch passed

+1 :green_heart:
compile
12m 18s
the patch passed

+1 :green_heart:
javac
0m 52s
hbase-common in the patch passed.

+1 :green_heart:
javac
0m 22s
hbase-metrics in the patch passed.

+1 :green_heart:
javac
1m 12s
hbase-client generated 0 new + 157 unchanged - 1 fixed = 157 total (was 158)

+1 :green_heart:
javac
0m 31s
hbase-zookeeper in the patch passed.

+1 :green_heart:
javac
0m 26s
hbase-replication in the patch passed.

+1 :green_heart:
javac
0m 32s
hbase-http in the patch passed.

+1 :green_heart:
javac
0m 30s
hbase-asyncfs in the patch passed.

+1 :green_heart:
javac
0m 33s
hbase-procedure in the patch passed.

+1 :green_heart:
javac
3m 41s
hbase-server in the patch passed.

-0 :warning:
javac
0m 55s
hbase-mapreduce generated 1 new + 197 unchanged - 1 fixed = 198 total (was 198)

+1 :green_heart:
javac
1m  4s
hbase-rsgroup generated 0 new + 190 unchanged - 1 fixed = 190 total (was 191)

-0 :warning:
javac
0m 44s
hbase-it generated 3 new + 100 unchanged - 3 fixed = 103 total (was 103)

-0 :warning:
javac
0m 56s
hbase-rest generated 1 new + 184 unchanged - 4 fixed = 185 total (was 188)

+1 :green_heart:
checkstyle
0m 27s
The patch passed checkstyle in hbase-common

+1 :green_heart:
checkstyle
0m 12s
The patch passed checkstyle in hbase-metrics

+1 :green_heart:
checkstyle
0m 37s
The patch passed checkstyle in hbase-client

+1 :green_heart:
checkstyle
0m 13s
The patch passed checkstyle in hbase-zookeeper

+1 :green_heart:
checkstyle
0m 13s
The patch passed checkstyle in hbase-replication

+1 :green_heart:
checkstyle
0m 13s
The patch passed checkstyle in hbase-http

+1 :green_heart:
checkstyle
0m 12s
The patch passed checkstyle in hbase-asyncfs

-0 :warning:
checkstyle
0m 15s
hbase-procedure: The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-0 :warning:
checkstyle
1m 32s
hbase-server: The patch generated 2 new + 763 unchanged - 10 fixed = 765 total (was 773)

+1 :green_heart:
checkstyle
0m 22s
hbase-mapreduce: The patch generated 0 new + 86 unchanged - 1 fixed = 86 total (was 87)

+1 :green_heart:
checkstyle
0m 15s
The patch passed checkstyle in hbase-rsgroup

+1 :green_heart:
checkstyle
0m 18s
The patch passed checkstyle in hbase-it

+1 :green_heart:
checkstyle
0m 17s
The patch passed checkstyle in hbase-rest

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
14m 53s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
14m  9s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
2m 32s
The patch does not generate ASF License warnings.

102m 41s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3937

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 2a25e9c8f626 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / bf6f94685c

Default Java
AdoptOpenJDK-1.8.0_282-b08

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/artifact/yetus-general-check/output/diff-compile-javac-hbase-mapreduce.txt

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/artifact/yetus-general-check/output/diff-compile-javac-hbase-it.txt

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/artifact/yetus-general-check/output/diff-compile-javac-hbase-rest.txt

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/artifact/yetus-general-check/output/diff-checkstyle-hbase-procedure.txt

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

Max. process+thread count
86 (vs. ulimit of 12500)

modules
C: hbase-common hbase-metrics hbase-client hbase-zookeeper hbase-replication hbase-http hbase-asyncfs hbase-procedure hbase-server hbase-mapreduce hbase-rsgroup hbase-it hbase-rest U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 31s
Docker mode activated.

-0 :warning:
yetus
0m  6s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 44s
branch-2 passed

+1 :green_heart:
compile
5m 36s
branch-2 passed

+1 :green_heart:
shadedjars
6m 34s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
4m 26s
branch-2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 31s
the patch passed

+1 :green_heart:
compile
5m 36s
the patch passed

+1 :green_heart:
javac
5m 36s
the patch passed

+1 :green_heart:
shadedjars
6m 31s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
4m 25s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 35s
hbase-common in the patch passed.

+1 :green_heart:
unit
0m 21s
hbase-metrics in the patch passed.

+1 :green_heart:
unit
2m 49s
hbase-client in the patch passed.

+1 :green_heart:
unit
0m 46s
hbase-zookeeper in the patch passed.

+1 :green_heart:
unit
0m 26s
hbase-replication in the patch passed.

+1 :green_heart:
unit
0m 52s
hbase-http in the patch passed.

+1 :green_heart:
unit
1m 44s
hbase-asyncfs in the patch passed.

+1 :green_heart:
unit
1m 48s
hbase-procedure in the patch passed.

+1 :green_heart:
unit
145m 39s
hbase-server in the patch passed.

+1 :green_heart:
unit
11m 38s
hbase-mapreduce in the patch passed.

+1 :green_heart:
unit
3m 24s
hbase-rsgroup in the patch passed.

+1 :green_heart:
unit
1m 17s
hbase-it in the patch passed.

+1 :green_heart:
unit
4m  8s
hbase-rest in the patch passed.

223m  0s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3937

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux cfc03fbefea5 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / bf6f94685c

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/testReport/

Max. process+thread count
3997 (vs. ulimit of 12500)

modules
C: hbase-common hbase-metrics hbase-client hbase-zookeeper hbase-replication hbase-http hbase-asyncfs hbase-procedure hbase-server hbase-mapreduce hbase-rsgroup hbase-it hbase-rest U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 30s
Docker mode activated.

-0 :warning:
yetus
0m  8s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 44s
branch-2 passed

+1 :green_heart:
compile
6m 25s
branch-2 passed

+1 :green_heart:
shadedjars
7m 23s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
5m  9s
branch-2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 21s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 25s
the patch passed

+1 :green_heart:
compile
6m 32s
the patch passed

+1 :green_heart:
javac
6m 32s
the patch passed

+1 :green_heart:
shadedjars
7m 14s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
4m 56s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 49s
hbase-common in the patch passed.

+1 :green_heart:
unit
0m 25s
hbase-metrics in the patch passed.

+1 :green_heart:
unit
3m  0s
hbase-client in the patch passed.

+1 :green_heart:
unit
0m 45s
hbase-zookeeper in the patch passed.

+1 :green_heart:
unit
0m 41s
hbase-replication in the patch passed.

+1 :green_heart:
unit
0m 47s
hbase-http in the patch passed.

+1 :green_heart:
unit
1m 35s
hbase-asyncfs in the patch passed.

+1 :green_heart:
unit
1m 36s
hbase-procedure in the patch passed.

+1 :green_heart:
unit
160m 43s
hbase-server in the patch passed.

+1 :green_heart:
unit
13m 56s
hbase-mapreduce in the patch passed.

+1 :green_heart:
unit
4m 36s
hbase-rsgroup in the patch passed.

+1 :green_heart:
unit
1m 18s
hbase-it in the patch passed.

+1 :green_heart:
unit
3m 28s
hbase-rest in the patch passed.

248m 41s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3937

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 40850b82a80f 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / bf6f94685c

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/testReport/

Max. process+thread count
4472 (vs. ulimit of 12500)

modules
C: hbase-common hbase-metrics hbase-client hbase-zookeeper hbase-replication hbase-http hbase-asyncfs hbase-procedure hbase-server hbase-mapreduce hbase-rsgroup hbase-it hbase-rest U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/2/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

I am going to split the Random changes into a separate JIRA and PR because that part has taken on a life of its own.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
8m 33s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ branch-2 Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  9s
branch-2 passed

+1 :green_heart:
compile
9m 44s
branch-2 passed

+1 :green_heart:
checkstyle
3m 46s
branch-2 passed

+1 :green_heart:
spotbugs
8m 23s
branch-2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

-1 :x:
mvninstall
3m 33s
root in the patch failed.

-1 :x:
compile
0m 34s
hbase-it in the patch failed.

+1 :green_heart:
javac
0m 49s
hbase-common in the patch passed.

+1 :green_heart:
javac
1m  6s
hbase-client generated 0 new + 158 unchanged - 1 fixed = 158 total (was 159)

+1 :green_heart:
javac
0m 32s
hbase-http in the patch passed.

+1 :green_heart:
javac
0m 31s
hbase-procedure in the patch passed.

+1 :green_heart:
javac
3m 12s
hbase-server in the patch passed.

-0 :warning:
javac
0m 51s
hbase-mapreduce generated 1 new + 197 unchanged - 1 fixed = 198 total (was 198)

+1 :green_heart:
javac
0m 56s
hbase-rsgroup in the patch passed.

-0 :warning:
javac
0m 34s
hbase-it in the patch failed.

-0 :warning:
javac
0m 51s
hbase-rest generated 1 new + 184 unchanged - 4 fixed = 185 total (was 188)

+1 :green_heart:
checkstyle
0m 25s
The patch passed checkstyle in hbase-common

+1 :green_heart:
checkstyle
0m 38s
hbase-client: The patch generated 0 new + 0 unchanged - 4 fixed = 0 total (was 4)

+1 :green_heart:
checkstyle
0m 15s
The patch passed checkstyle in hbase-http

-0 :warning:
checkstyle
0m 15s
hbase-procedure: The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

+1 :green_heart:
checkstyle
1m 18s
The patch passed checkstyle in hbase-server

+1 :green_heart:
checkstyle
0m 18s
The patch passed checkstyle in hbase-mapreduce

+1 :green_heart:
checkstyle
0m 15s
The patch passed checkstyle in hbase-rsgroup

+1 :green_heart:
checkstyle
0m 18s
The patch passed checkstyle in hbase-it

+1 :green_heart:
checkstyle
0m 16s
The patch passed checkstyle in hbase-rest

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

-1 :x:
hadoopcheck
3m 30s
The patch causes 24 errors with Hadoop v3.1.2.

-1 :x:
hadoopcheck
7m 29s
The patch causes 24 errors with Hadoop v3.2.1.

-1 :x:
spotbugs
0m 31s
hbase-it in the patch failed.

_ Other Tests _

+1 :green_heart:
asflicense
1m 51s
The patch does not generate ASF License warnings.

77m 30s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3937

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 7e006f948c4d 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / c7a8e428df

Default Java
AdoptOpenJDK-1.8.0_282-b08

mvninstall
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-general-check/output/patch-mvninstall-root.txt

compile
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-general-check/output/patch-compile-hbase-it.txt

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-general-check/output/diff-compile-javac-hbase-mapreduce.txt

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-general-check/output/patch-compile-hbase-it.txt

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-general-check/output/diff-compile-javac-hbase-rest.txt

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-general-check/output/diff-checkstyle-hbase-procedure.txt

hadoopcheck
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-general-check/output/patch-javac-3.1.2.txt

hadoopcheck
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-general-check/output/patch-javac-3.2.1.txt

spotbugs
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-general-check/output/patch-spotbugs-hbase-it.txt

Max. process+thread count
96 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-http hbase-procedure hbase-server hbase-mapreduce hbase-rsgroup hbase-it hbase-rest U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
9m 34s
Docker mode activated.

-0 :warning:
yetus
0m  5s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  3s
branch-2 passed

+1 :green_heart:
compile
4m 32s
branch-2 passed

+1 :green_heart:
shadedjars
6m 42s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 23s
branch-2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for patch

-1 :x:
mvninstall
3m 31s
root in the patch failed.

-1 :x:
compile
0m 26s
hbase-it in the patch failed.

-0 :warning:
javac
0m 26s
hbase-it in the patch failed.

+1 :green_heart:
shadedjars
6m 52s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 23s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 38s
hbase-common in the patch passed.

+1 :green_heart:
unit
2m 38s
hbase-client in the patch passed.

+1 :green_heart:
unit
1m  6s
hbase-http in the patch passed.

+1 :green_heart:
unit
1m 45s
hbase-procedure in the patch passed.

+1 :green_heart:
unit
154m  1s
hbase-server in the patch passed.

+1 :green_heart:
unit
13m 28s
hbase-mapreduce in the patch passed.

+1 :green_heart:
unit
4m 42s
hbase-rsgroup in the patch passed.

-1 :x:
unit
0m 46s
hbase-it in the patch failed.

+1 :green_heart:
unit
4m 26s
hbase-rest in the patch passed.

235m 45s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3937

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 6daacbf06b36 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / c7a8e428df

Default Java
AdoptOpenJDK-1.8.0_282-b08

mvninstall
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-jdk8-hadoop2-check/output/patch-mvninstall-root.txt

compile
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-jdk8-hadoop2-check/output/patch-compile-hbase-it.txt

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-jdk8-hadoop2-check/output/patch-compile-hbase-it.txt

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-jdk8-hadoop2-check/output/patch-unit-hbase-it.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/testReport/

Max. process+thread count
3718 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-http hbase-procedure hbase-server hbase-mapreduce hbase-rsgroup hbase-it hbase-rest U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 31s
Docker mode activated.

-0 :warning:
yetus
0m  8s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+0 :ok:
mvndep
0m 42s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 35s
branch-2 passed

+1 :green_heart:
compile
5m 13s
branch-2 passed

+1 :green_heart:
shadedjars
8m 16s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 36s
branch-2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

-1 :x:
mvninstall
4m 44s
root in the patch failed.

-1 :x:
compile
0m 35s
hbase-it in the patch failed.

-0 :warning:
javac
0m 35s
hbase-it in the patch failed.

+1 :green_heart:
shadedjars
8m 30s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
4m  2s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
2m 10s
hbase-common in the patch passed.

+1 :green_heart:
unit
3m  7s
hbase-client in the patch passed.

+1 :green_heart:
unit
0m 56s
hbase-http in the patch passed.

+1 :green_heart:
unit
2m  8s
hbase-procedure in the patch passed.

+1 :green_heart:
unit
209m 41s
hbase-server in the patch passed.

+1 :green_heart:
unit
15m  5s
hbase-mapreduce in the patch passed.

+1 :green_heart:
unit
4m 20s
hbase-rsgroup in the patch passed.

-1 :x:
unit
0m 43s
hbase-it in the patch failed.

+1 :green_heart:
unit
4m 23s
hbase-rest in the patch passed.

294m 38s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3937

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 45c35bea82e8 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / c7a8e428df

Default Java
AdoptOpenJDK-11.0.10+9

mvninstall
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-jdk11-hadoop3-check/output/patch-mvninstall-root.txt

compile
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-jdk11-hadoop3-check/output/patch-compile-hbase-it.txt

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-jdk11-hadoop3-check/output/patch-compile-hbase-it.txt

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-it.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/testReport/

Max. process+thread count
3080 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-http hbase-procedure hbase-server hbase-mapreduce hbase-rsgroup hbase-it hbase-rest U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3937/3/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

Oh bother, now I see #3936 has the same changes.


chore: trim monorepo dependencies

Description

Use pnpm run instead of npm-run-all
Use eslint-plugin-i instead of eslint-plugin-import
Use is-builtin-module instead of is-core-module

Additional context

What is the purpose of this pull request?

[ ] Bug fix
[ ] New Feature
[ ] Documentation update
[x] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the PR Title Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

I did this for fun and will close it. Except the npm-run-all migration which could be useful, but maybe another time.


Libraries with MIT licence are not shown, although defined in AboutLibraries

About this issue

Briefly describe the issue

Libraries that use MIT licence are not displayed in the list.

How can the issue be reproduced / sample code

add following dependencies into your gradle file:
implementation "com.nispok:snackbar:2.11.0"
implementation "com.amulyakhare:com.amulyakhare.textdrawable:1.0.1"
implementation "com.klinkerapps:link_builder:2.0.3"

Details

[ 6.0.8 ] Used library version
[ 27+ ] Used support library version
[ Gradle 4.4 ] Used gradle build tools version
[ 3.1.1 ] Used tooling / Android Studio version
[ ] Other used libraries, potential conflicting libraries ??

Checklist

[x] Searched for similar issues
[x] Checked out the sample application
[x] Read the README
[x] Checked out the CHANGELOG
[x] -Read the MIGRATION GUIDE- Not related, first usage.

@burakozhan tested and verified that at least the snackbar one works (the others may have no definition file available) .
Be aware that the ABoutLibraries caches the libs for one version to speed up loading. if you added them without changing verison they won't show up, clear app data, or adjust the version number :)


Create a separate project in our monorepo for our Flowershow website

Acceptance

[ ] we have a project in our repo for our Flowershow website
[ ] no symlinks between our packages/template and /site needed

WONTFIX. we already have an approach where we "install" (ie. symlink) the latest "version" of flowershow to run the website on publishing or for local dev. One day we may want to publish the website more formally but this works for now.

@rufuspollock I'd reconsider creating an app for our flowershow website in flowershow/apps folder and make the flowershow/packages/template a clean template project.
Why: although we have cleaned up the template of unneeded files, there are still some (e.g. Nx's project.json, .eslintrc.json) that need to stay there if we're treating it as an app as well. They are currently being removed by the CLI but for people who'd like to use the template to jump-start their Next.js project (e.g. using npx create-next-app --example xxx), these files will be copied over as well. Another thing is that, in my opinion, the template should also include the /content dir with at least a starting index.md (now it doesn't have one, since the CLI creates a symlink to external content folder) and a config.js file with the set of all the possible config options. It could also have eslintrc.json file (but with different content, not referencing parent eslint files in our monorepo as it does now) with some basic settings.
Also: I'd even move the template to examples, as it's neither an app nor an installable package. And I think all other examples we have in there shouldn't be structured like they are now, i.e. external content folder + .flowershow, but should also be kind of like different templates, that you can select from when using our CLI, or when running npx create-next-app --example xxxx.
@rufuspollock what do you think?

Ok, we can think about this. Relative to other things it still seems a bit low priority (but it depends on the cost of doing it).

No longer relevant. A separate repository for Flowershow was created here: https://github.com/datopian/flowershow-app


Frontend exited with code 1

Hello!
I downloaded the repo locally and ran docker-compose --profile all up and am getting an exited with code 1 error on the frontend.  Please see attached images.

Thanks in advance for the help!

Hi @vdemchenko3 this issue was solved last week.


[dxvk] Add Direct3D9ForceHybridEnumeration empty export function.

The WLK tests for d3d9 call Direct3D9ForceHybridEnumeration function. When it is missing the exception is thrown and the application is terminated.
With empty stub is added the test starts the operation.

It's marked as a draft so I assume you were going to do that later but anyway: Please explain the rational behind your change, especially which game relies on this.

Who should I add as a reviewer?

You don't need to add anyone, it would just be nice to know what this fixes

You don't need to add a reviewer, looks good.


Listener receiving swapped series when drawing multi bar charts?

I'm not a JS developer and this is not my code and it's incredibly messy, so please bear with me :)
We have a react-chartist component that uses the onDraw listener to fill in some tooltip data for a multi bar chart showing age/gender demographics. The tooltips seem to have been reversed: data from series 'Man' has the label from series 'Woman' and vice versa.
When looking at the data the listener received, it looks like the two have been swapped somehow:

As you can see, data.value does not appear anywhere in data.series.data, as it is a datapoint for the 'Man' series and we've received the 'Woman' series. We get our tooltip label from data.series.name, so it appears reversed.
Am I right to assume that data.series should point to the current series being drawn? Any idea what I could be overlooking? Thanks!

Hello @RobinRamael 👋
Chartist has recently been updated to version 1.0 with some new exciting changes like ESM and TypeScript support. The migration guide can be found right here.
Please let me know if the quiestion is still relevant to you so we can further look into it!


V3 of the API is still being used. Current API version is V5

We will move to V5. I am going to take a stab at a full re-write of this gem in the coming month or two.


Adds rex_date to UIDatePicker.

This PR adds a rex_date mutable property to UIDatePicker that sends a value every time the picker is updates through a UI event and also updates the picker's date property when the mutable property is updated (this does not cause an infinite loop because I am using target/action which doesn't get called when a property is changed programmatically).
I know this works because I testes it on a project but one of the tests are not passing and I am doing exactly the same you are doing in the UIButton tests. Maybe you can help me there.

I disabled the test and merged this in. Thanks for the PR!


Unmanaged Resource leak

Ok, after learning a bit about unmanaged resource, I know that there is a lack of PROPER disposing of unmanaged resource(Example: File logging of SteamBot) which isn't good. @BlueRaja @scholtzm What you guys think?

Wasn't there already some pull request which was taking care of disposing the logger?

You mean UpdateLogCapabilties? Still not merged yet.

Yeah, I see now.

If there's anything that can be merged just let me know.  We need to clean up the PRs.  There's a bunch just sitting there with no updates for a while now.

I'm waiting for blueraja to give his opinions on the PR I sent for UpdateLogCapabilities.


Disable by default alpha/untested features ( multinetwork/cluster)

Multicluster adds "network" config to each endpoint, and processing ( filtering the endpoints) - it should be at turned off using an env variable or flag until it has sufficient testing. We need to review other parts of config generation that are different from 1.0 and make sure they're either tested ( and don't regress
performance or stability ) or off by default.
In particular the implementation is quite inefficient - filtering happens after the config is generated, and seems dependent on including the "network" attribute in the generated output ( when it can just be used locally ). For 1.1 it may be sufficient to disable the code (except when user explicitly enable the alpha feature), but ideally code should be cleaned up.

/cc @ymesika

/assign


Cannot access the Operator Hub with Basic Sample

I deployed the sample basic
https://github.com/terraform-ibm-modules/terraform-ibm-base-ocp-vpc/tree/main/examples/basic
but I cannot access the Operator Hub in the OpenShift console

Hi @lionelmace - This is happening due to the variable disable_outbound_traffic_protection taking the default value as false. If you want to have this, you can open up outbound traffic by setting this variable to true, for example as shown below:


Task6

Issue:#215

Hey @Snehalgupta-07
Thanks for opening this PR 🚀. Mentor will review your pull request soon and till then, keep contributing and stay calm.
Thanks for contributing in OpenCode'24 ✨✨!

Hey @Snehalgupta-07
Your PR has been merged 🥳🥳 and you have earned 20 points.
Thanks for contributing in OpenCode'24 ✨✨


Error setting up Hue on restart on version 101

Home Assistant release with the issue:
0.101.0 - Frontend version: 20191025.1 - latest
Last working Home Assistant release (if known):
0.100.3
Operating environment (Hass.io/Docker/Windows/etc.):
Docker on Linux
Integration:
https://www.home-assistant.io/integrations/hue
Description of problem:
I am seeing a new error after upgrading.  The error does not seem to prevent the Hue lights from working.  I have 3 Hue hubs integrated with HA and this error appears 2 times.  Seems like the error is happening only when there are more than one Hub.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
They were setup through the Frontend UI
Traceback (if applicable):
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 150, in _async_setup_platform
    await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
  File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, in wait_for
    return fut.result()
  File "/usr/src/homeassistant/homeassistant/components/hue/sensor.py", line 36, in async_setup_entry
    await shared_async_setup_entry(hass, config_entry, async_add_entities, binary=False)
  File "/usr/src/homeassistant/homeassistant/components/hue/sensor_base.py", line 44, in async_setup_entry
    await manager.start()
  File "/usr/src/homeassistant/homeassistant/components/hue/sensor_base.py", line 89, in start
    await async_update_bridge(None)
  File "/usr/src/homeassistant/homeassistant/components/hue/sensor_base.py", line 83, in async_update_bridge
    await self.async_update_items()
  File "/usr/src/homeassistant/homeassistant/components/hue/sensor_base.py", line 174, in async_update_items
    current,
  File "/usr/src/homeassistant/homeassistant/components/hue/helpers.py", line 19, in remove_devices
    await entity.async_remove()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 474, in async_remove
    self.hass.states.async_remove(self.entity_id)
AttributeError: 'NoneType' object has no attribute 'states'

I also see this error
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/hue/sensor_base.py", line 83, in async_update_bridge
    await self.async_update_items()
  File "/usr/src/homeassistant/homeassistant/components/hue/sensor_base.py", line 174, in async_update_items
    current,
  File "/usr/src/homeassistant/homeassistant/components/hue/helpers.py", line 19, in remove_devices
    await entity.async_remove()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 474, in async_remove
    self.hass.states.async_remove(self.entity_id)
AttributeError: 'NoneType' object has no attribute 'states'

Additional information:
It still seems to connect to all 3 hubs and lights work as expected but these errors did not exist until upgrading.
I restarted many times to make sure it wasn't just a one time thing.

This issue seems to be linked to a problem I saw after moving from 100.1 to 101.2 - I have two Hue bridges - 4 motion detectors on each - on one of them, although the motion detectors are fine the temp & lux level values all changed to 'Unknown'.  Revrting to 100.1 fixed it immediately.
Thanks.

I have motion sensors but they are in a box since I switched to the wyze ones.  I can control all my lights still it seems but this error does not go away.  The motion sensors are still paired to my bridges, I forgot to remove them, I can see if only the ones on one bridge work when I am home.

My hue motion sensor no longer shows the temp or light level values. (Ive just upgraded to 101.3). Numerous reboots / and Hassbian update made no difference. Please could your repair.

Should be fixed with https://github.com/home-assistant/home-assistant/pull/28679


fix: encode bytebuffer should reset everytime

Codecov Report

Merging #12 into master will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master      #12   +/-   ##
=======================================
  Coverage   96.96%   96.96%
=======================================
  Files          31       31
  Lines         792      792
=======================================
  Hits          768      768
  Misses         24       24

Impacted Files
Coverage Δ

lib/codec/hessian/index.js
96.15% <100.00%> (ø)

Continue to review full report at Codecov.

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

2.0.1


Removed dependency on glyphicons and added feathericon replacements

Make sure you have checked all steps below.
Title

[ ] My PR Title addresses the issue accurately and concisely.

Example: "Updates the version of Flask to v1.0.2"
In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

Description

[ ] Here are some details about my PR, including screenshots of any UI changes:

Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[ ] I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters (not including Jira issue reference)
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[ ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain docstrings that explain what it does

Code Quality & Coverage

[ ] Passes make test

FYI @bolkedebruin


Investigate the use of Electron Forge

Electron Forge v6 is out, and has been advertised as a "batteries included" solution for Electron
Is this a more reliable option for local dev and packaging / distribution?
https://www.electronjs.org/blog/forge-v6-release

yeah -- I don't want to try and replace one "problem" only to create 3 more

I'm thinking this approach might make it easier - but also wondering about a slight directional change. I'll create a new issue to gauge the mood.


Add embedding for media

It would be really cool if I could upload an image or video, post the link somewhere and have it embed it automatically e.g on discord.
This works if I copy the link to the exact file, but then depending on the file name this can be a large URL.
Example:

https://url.com/monkey-dog-fox has an image attached, the image is automatically embedded on discord.

To achieve this currently, it would look like:

https://url.com/monkey-dog-fox/P_20230126_123935038.jpg

Hopefully it's understandable what I meant!

This would really be useful as I myself use MicroBin over Discord a lot. The issue is that Discord uses a bot to visit the URL and takes the first image. Because there is no image displayed at https://url.com/monkey-dog-fox, it has nothing to show in the chat. What we could easily do is displaying image and video files on the pasta page instead of just making them downloadable, this would make MicroBin itself more user friendly, and it would help in use cases like this one as well.

Related: #58

I think it would be enough to set a few fields in the HTML header. There are fields that tell crawlers what to embed. A website for generating links that do something similar is stolen.shoes, if the link is pasted into discord or some other platform that looks for these fields it will embed the resource properly, but with stolen.shoes if the link is opened in the browser it will display something else (like the normal site).

Example link


Placeholder Silently Fails for non-string Options

Setting a placeholder:"<some-thing>" as a struct tag for types other than string` causes the option parsing to silently fail and omit that option:
type Config struct {
	# Included
	Start     int64  `option:"start-time" description:"The timestamp (in Unix seconds) to request logs from."`
	# Omitted (i.e. not parsed, not included in help text)
	End       int64  `option:"end-time" placeholder="<unix-timestamp>" description:"The timestamp (in Unix seconds) to request logs to."`
	# Included	Count     int    `option:"c, count" default:"1" description:"The number (count) of logs to retrieve."`
}

Is this intended? Can be useful to describe formatting.

@elithrar I think the error is actually the formatting on the struct tag.  End has placeholder= instead of placeholder:.  The struct tag parsing provided by the reflect package silently ignores/omits tags that are malformed.  It makes no attempt to recover or inform you of the issue, so on the writ side it just looks to writ like the placeholder tag doesn't exist.

Whoops—totally looked past that. Thanks for the quick response!

No problem!


Keep asking the pull secret until valid or the user wants to quit

Entering the pull secret is hard and most of the time it takes 2-3 tries to get it correct.
crc could keep asking for it instead of exiting. The user may quit this loop by typing [q]uit for example.
It will save time for the user: preflight checks run once and it will be clearer in the telemetry for us.

Included in 1.22.0


Unable to build our code after include esp_ota_ops.h file  (IDFGH-12873)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
We are using https://github.com/espressif/esp-idf/tree/release/v5.1 and branch 5.1.2. We need to use latest set ota partition related API's which are present in app_update module inside esp_ota_ops.h file. In this version we need to include app_update module. If we include this module in cmakelist and include esp_ota_ops.h file in our code, then at the time of building , we are getting error of fatal error - esp_app_desc.h No such file or directory present inside the file esp_ota_ops.h. In actual this file is present inside esp_app_format module. But still it generate error. If we copy esp_app_desc.h file to another module eg esp_partition/include then same code will build without any issue. How to resolve this issue without copying this file to esp_partition module?
Please refer the below screenshots of this issue.

Could you please also show the contents of CMakeLists.txt file of the component from which you are including esp_ota_ops.h?

Also we tried to add using REQUIRES app_update esp_app_format method also. But same error we got.

I can see that you are adding include directories of other components by extending the INCLUDE_DIRS. This is not the right approach in CMake... Instead, you need to add the libraries you depend on to the REQUIRES or PRIV_REQUIRES lists.
Please try removing all the INCLUDE_DIRS which contain ../../../esp32_common/esp-idf, then add the components you depend on into REQUIRES. Once you do this, please try to build again. If you get an error, please share the complete build log. Please upload the log as text rather than as a picture.

Please refer to this build system guide section for more information on the component requirements. Hope this helps!


Add option to show status in font without emojis

When ssh into a remote instance, system fonts don't properly render the bits for status, update, or merge. It would be great to add a config option to display bits that are supported for all fonts.
Sample output below:
> git spr status
> git rev-parse --show-toplevel
> github fetch pull requests
> git log --format=medium --no-color upstream/dev..HEAD
> git branch --no-color
[____] https://github.com/mosaicml/composer/pull/2593 : Add Rank Planners
[____] https://github.com/mosaicml/composer/pull/2584 : Update types to follow PEP 585
[____] https://github.com/mosaicml/composer/pull/2582 : Add SavePlanner and LoadPlanner support in Trainer

Use statusBitsEmojis in the User config.

I set it as false and it doesn't render properly

Gotcha, I'll add a basic status bits, these are the current set:
	asciiCrossmark = "✗"
	asciiPending   = "·"
	asciiQuerymark = "?"
	asciiEmpty     = "-"
	asciiWarning   = "!"

I think the current set is extended ASCII? I personally prefer lowercase x v, but both are fine.
https://theasciicode.com.ar/

Your change released in v0.14.4. Thank you for the contribution!


workflow after separating out Core package

when updating to the latest SymPyPythonCall unSym (and many other functions) are no longer exported. I am not sure if this is a feature and we are supposed to import the core package as well or a bug :) I would advocate for exporting the functions from the PythonCall and PyCall packages and leave the Core package invisible to the user.

Thanks. that was bad form. I'll put in proper deprecations in the next release, hopefully today. (For now, unSym is just the unicode \downarrow[tab].)

CLosed in #36. Please reopen if that didn't address the issue.


Bank Account - Plaid bank connection reverts to manual method after navigating back

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.42-0
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause Internal Team
Action Performed:

Go to https://staging.new.expensify.com/
Create a new workspace and enable workflow.
Navigate to "Workflow" and click on "Connect Bank Account."
If your account is not verified, complete the verification.
Click "Connect Online with Plaid" and follow the flow until you reach the personal information section.
Add your legal first name and last name, then go offline and come back online before clicking "Next."
Go offline again, set your date of birth, come back online, and click "Next."
Continue navigating back until the "Manually Add Your Bank Account" option appears.

Use Regions bank
Username: user_good | Password: pass_good
Account type: Plaid Saving (2nd option)
CompanyName: Alberta Bobbeth Charleson
Expected Result:
The process should not revert to the manual method, as Plaid was selected.
Actual Result:
When navigating back several times, the system incorrectly reverts to the manual method for connecting the bank account.
Workaround:
Unknown
Platforms:

[ ] Android: Native
[x] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/user-attachments/assets/398a1f29-44cc-45ef-8189-b165d8b7f26e

View all open jobs on GitHub

@CortneyOfstad  FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

Probably BE bug, when we switch offline mode, OpenReimbursementAccountPage API gets called with substep=plaid payload but returns with substep=manual.

I agree that this is a BE issue as that should not be reverting back! Getting some eyes on this!

I believe we discussed with @koko57 @nkuoch that this is expected right?

the account number should be disabled to edit in this case

yep this is expected and account numbers should be shown and non-editable once the bank account has been created in db

@mountiny yes, and  now as this PR is merged this can be retested - the fields will be disabled

So, closing


ecub joint setup configuration: increasing current and velocity limits

I further updated the current the velocity limits in the configuration file  under the 5-setup subfolder for the testing of the ecub joint motor with the hysteresis dynamometer.
The 2FOC board often reaches it's I2t limits while testing and so I would like to increase it further.
cc @ale-git

Hi @divyashah
This PR is not mergeable as it contains conflicts.
Can you please sort it out?
Ideally, it suffices to fix and push a new commit; the PR will get updated.
Don't close this PR then, to start it over.

In particular, these are the conflicts to be resolved:

Thanks @pattacini for pointing it out!
I think I might have included the previous commit by mistake which was causing the conflict. I tried to resolve it on the web. Let me know if it is mergeable now or not.

Great! Thanks @pattacini!


move categorical_cardinalities out of the schema class

Continued small-piece-at-a-time refactoring for https://github.com/NVIDIA-Merlin/Transformers4Rec/issues/566
This removes categorical_cardinalities from the Schema class, which does not exist on the merlin.schema.Schema class.
Goals :soccer:

Implementation Details :construction:

Testing Details :mag:

Oh, that's a great tip and will be helpful in the next step, which is to move from merlin_standard_lib's Tag to merlin.schema.Tags.
Right now, this version of categorical_cardinalities still depends on the older version of Tag so the version in models isn't compatible. I'll be sure to make that change and depend on the one from models in the next PR, but for now I think this one needs to stay.


Firefox does not automatically snap to the defined zone when opening it [FancyZones]

.

I see the same issue, but with Chrome and Thunderbird.

@ccxla
upload a screenshot showing the window when is snapped to the zone and one showing when it's reopened.

snapped

reopened

@ccxla
can you please provide some information?

is the display in portrait mode? What's the native resolution and the DPI scaling %?
what type of layout are you using?

is the display in portrait mode?

Yes

What's the native resolution and the DPI scaling %?

1440 x 2560 at 100%

what type of layout are you using?

Only one zone on that monitor. This is my second monitor, no other zones are configured on any other monitor.

@ccxla
can you do a test?

snap the Chrome window to the zone
quit PowerToys
close and reopen Chrome

Does the problem reproduce?

Yes, following these steps yields the same result as seen in the screenshots.

@ccxla
that means it's an application issue, some application don't respect the exact position when they reopen.
We can try to use a workaround to force the application to resize to the desired position, we already tried in the past and the results were not good at all because it can cause flickering.
I'll keep the issue open for now, but it may get closed after some investigation if we don't find a reliable way to force the app to reopen where it is supposed to open.

@JasonRichards1989
with PowerToys 0.31.2 and the latest version of Firefox I cannot reproduce the problem.
Is still reproducing for you?

Hi enricogior, the problem persists in PT 0.31.2, at least for me. Second screen, landscape, 3440x1440, every time on reopen of Firefox.
It's not a massive issue, but it does significantly impact an otherwise perfect workflow using FancyZones.

its still a problem in december 2023

The problem persists in PT v0.79.0.
Just tested it with Firefox (v124.0.0) @ 3440x1440 - 100% scaling.


syncToZustand is slow to hydrate from indexer snapshot

https://discord.com/channels/865335009915961364/1196402713341218826
I assume this is similar to what we saw a while back with RECS where the hydration step takes a while because it triggers updates for each record/value, which lead us to an option that can disable this depending on sync state: https://github.com/latticexyz/mud/blob/main/packages/store-sync/src/recs/syncToRecs.ts#L36-L37
I think what we need to do is update this: https://github.com/latticexyz/mud/blob/main/packages/store-sync/src/zustand/createStorageAdapter.ts
instead of calling store.setState for each log, we could turn all the logs into records to be set, then call store.setState once at the end of the loop with all the records

repro here: https://github.com/dudendy/mud-primodium-snapshot

@holic resolved in #2145


[Consideration] STX as Result/Error library

For me it seems like it would be useful to use STX library as Result/Error library
This library inspired by Rust Result
Also this library available in conan-center

In theory this API depends only a little bit on Result, so I'd ideally prefer to avoid taking a whole dependency just for this. Perhaps though the wasmtime::Result type could be copied over from the stx version? (or at least the most important bits)

Yeah, I agree maybe it is not necessary to bring bit dependency ...


useSelectableList Error: Uncaught TypeError: Cannot read property 'querySelector' of null

🐛 Bug Report

useSelectableList called with isVirtualized: false does not check if the ref is set and throws this error:

Error: Uncaught TypeError: Cannot read property 'querySelector' of null

https://github.com/adobe/react-spectrum/blob/abcd25984bc9cf726754e4dea9a392afdc3d8afb/packages/%40react-aria/selection/src/useSelectableList.ts#L107-L116
🤔 Expected Behavior

Refs should always be checked to be set.
😯 Current Behavior

ref.current is not checked to be set.
💁 Possible Solution

Add a check for ref.current to the if block.
if (!isVirtualized && selectionManager.focusedKey && ref.current) {}

🔦 Context

💻 Code Sample

🌍 Your Environment

Software
Version(s)

react-spectrum

Browser

Operating System

🧢 Your Company/Team

🕷 Tracking Issue (optional)

@AndyOGo Looks reasonable, thanks for the fix!


Add EF core migrations deployment

Looks like it only applies for first migration - works for now so closing


Create the docs archive for Kubeflow v0.5

I think it's time to create the v0.5 branch of the docs and hook it up to the version dropdown on the website.
This is the only outstanding issue that claims to be relevant to v0.5:
https://github.com/kubeflow/website/issues/650
Pretty soon we'll start adding v0.6 features.

/assign @abhi-g
/cc @jlewi
/cc @paveldournov
What do you folks think?

lgtm

This task is in progress. We've created the v0.5 archive and hooked it up to the version dropdown on the website. The remaining task is to get an SSL certificate.

SSL up and running. Thanks all!
/close


Transform box

This RP implements a widget wrapper which allows arbitrary transforms of the inner widget using the TransformPolicy trait and some implementations of the TransformPolicy trait.
TODO:

[ ] fix Widget::parent_window_origin. At the moment this value wrong inside of a TransformBox
[ ] calculate damaged-region correctly

I can't actually find the conversation now, but around the time that partial invalidation was first introduced, there was some discussion about allowing arbitrary transformations. My recollection was that we decided to wait and see if there was a compelling use case first, and then figure out if we can support it. Do you have some specific situations where you want, e.g., an arbitrary rotation?
The main issue is that having arbitrary transformations interacts in complicated ways with other features (such as detecting window-relative mouse position for launching pop-ups, and the fact that the current layout code that tries to align things to pixel boundaries will break if a scaling is applied).

I don't really need it. It would make some things easier, but its not that important to me. I heard other people talk about it (i also can't find the comments) and thought maybe someone else needs this, but i understand your concerns.

Yeah, it's definitely come up a couple of times. I think the closest we had to a version with a real use-case was for the Tabs widget (#1160), which was only for 90,180,270-degree rotations. But even in that case, we decided to punt...

AaTransform does exactly this. One option would be to export only AaTransform until someone needs the rest.

Thank you for the patch, but I remain reluctant here. In general, UI elements are designed with an orientation, and should not be arbitrarily transformed. The only case I can personally really think of is something like an animated transition, but that remains entirely theoretical.
If someone can demonstrate a compelling case where this is helpful then I am open to that, but in general it feels like bringing in a bunch of code that will be very rarely used, and which will have to be maintained.

Ok


chore: bump the max tx bytes in the mempool config

Codecov Report

Merging #2219 (a176976) into main (3dd1ba6) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main    #2219      +/-   ##
==========================================
- Coverage   21.54%   21.53%   -0.01%
==========================================
  Files         127      127
  Lines       14329    14335       +6
==========================================
  Hits         3087     3087
- Misses      10939    10945       +6
  Partials      303      303

Files Changed
Coverage Δ

app/default_overrides.go
16.51% <0.00%> (-0.97%)
:arrow_down:

do we need to update this branch for the backport to work?


Replacements should be able to add imports

If a replacement generates code that needs additional require statements to be added before it compiles, resyntax should be able to insert the needed imports. It should be possible to derive the necessary imports automatically by looking at the bindings of all of the identifiers in the syntax objects generated by a refactoring rule.

One tricky part here is how to display a suggested fix that adds imports. A fix on line 200 with an added import might want to insert the import on line 5. GitHub's suggestion comments in reviews would be an awful UI for that since it'd have to suggest modifying the entire span from line 5 to line 200.
One possible approach might be to gather up all added imports from all suggestions and make a single suggestion that adds all the imports. There are two downsides:

Suggestions are no longer fully independent. Some suggestions would only work correctly if the import suggestion is also accepted.
If some suggestions aren't accepted but the import adding suggestion is, unnecessary imports might be added.

Neither of these problems are that bad in my opinion. The first can be softened by including text in each suggestion warning the user when it requires adding imports. The second can be turned into less of a problem by building an analyzer that suggests removing unnecessary imports.


Discovery: Change to HTTPS DNS records

Remove the DNS URI records as a few large DNS providers does not support them (and the RFC is informational)
Clarify TLS certificate requirements (according to RFC 9640)
Fix some markdown formatting (make markdownlint happy)

Text from the RFC:  "Note that none of these forms alter the origin or authority for
validation purposes.  For example, TLS clients MUST continue to
validate TLS certificates for the original service name."
So if the URI points to "products.example.com" - this is what you use to validate the TLS cert for the first server. After 302 you got a new or the same server.

https://www.netmeister.org/blog/https-rrs.html
“Firefox has been making HTTPS lookups (albeit only over DoH) since May 2020, Apple’s iOS and Safari / macOS since September 2020, Chrome has had partial support since December 2020, and just recentlyenabled ECH by default. Various DNS service providers also offer support for HTTPS and SVCB records already.”


Fix #1321: Use hljs from CDN

[ ] Solarized dark has solarized light theme for line numbers
[ ] Line numbers broken in /developers

Fixes #1321

Hm, dark theme means Terminal so it shouldn't have line numbers at all. Probably the API for choosing line number or not changed?

Ahah, so actually the problem might be that the dark theme is always used, for both bash and vala.

It looks like the language isn't being detected correctly (it thinks it's a different language in like every snippet). I don't see a vala style upstream in hljs. Did we carry our own highlighting scheme for this?

So we basically created our own theme to highlight bash with solarized dark. We may want to keep themes hosted in the repo, especially if we want to customize it (e.g. to fix #983 which is not fixed with newer themes).

Hm I think we're missing something. I think maybe we added a custom set of highlight rules.
In this branch, on developer page it says the language is "cpp". In master it says "vala"

Okay, the problem here is that hljs from the CDN is missing vala.

Yeah so I guess this is blocked then. We need to fix #983 and upstream the vala highlight mode

No, we can upstream the vala highlight mode. hljs from the CDN is only including 22 languages, because including more would make the library too big. So we need to continue to host it.

Easy fix! Use both the highlight.js and the language file. Which do we need?
Like this: https://cdn.jsdelivr.net/g/highlight.js@9.6.0(highlight.min.js+languages/vala.min.js)

Works for me, maybe @danrabbit can just double-confirm that this works. It highlights the vala on /developer fine here though.

Yeah this is pretty much the same as master. I think there's some issues with our solarized-light styles and the vala highlighter is not 100% correct. But it's parity with master, so it works for me :)
If we're using these things from CDN, we should delete the local copies

scripts/highlight.pack.js has been deleted already.


Scrub Office 365 continued

per Elizabeth's edits

Docs Build status updates of commit afe7e50:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/design/authentication-patterns.md
:white_check_mark:Succeeded
View

docs/develop/auth-with-office-dialog-api.md
:white_check_mark:Succeeded
View

docs/develop/create-sso-office-add-ins-aspnet.md
:white_check_mark:Succeeded
View

docs/develop/create-sso-office-add-ins-nodejs.md
:white_check_mark:Succeeded
View

docs/develop/dialog-api-in-office-add-ins.md
:white_check_mark:Succeeded
View

docs/develop/overview-authn-authz.md
:white_check_mark:Succeeded
View

docs/develop/sso-in-office-add-ins.md
:white_check_mark:Succeeded
View

docs/develop/troubleshoot-sso-in-office-add-ins.md
:white_check_mark:Succeeded
View

docs/includes/sso-tutorial-prereqs.md
:white_check_mark:Succeeded
View

docs/overview/set-up-your-dev-environment.md
:white_check_mark:Succeeded
View

docs/publish/host-an-office-add-in-on-microsoft-azure.md
:white_check_mark:Succeeded
View

docs/quickstarts/sso-quickstart-customize.md
:white_check_mark:Succeeded
View

docs/quickstarts/sso-quickstart.md
:white_check_mark:Succeeded
View

docs/tutorials/migrate-vsto-to-office-add-in-shared-code-library-tutorial.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Unable to reproduce bottleneck baseline result for benchmark paper

The result I obtain from simply running the baseline for bottleck scenario in the current version of Flow does not seem to produce the same result as the benchmark paper. The result seems to be much much higher. I'm currently running it with
python -m flow.benchmarks.baselines.bottleneck0

Correct. To reproduce that result exactly you would have to roll back versions and as the version of SUMO has changed and the bottleneck curve is now different (due to SUMO handling merging differently now). We put the commit number in there if you want to reproduce exactly. Sorry for the trouble!

Correct. To reproduce that result exactly you would have to roll back versions and as the version of SUMO has changed and the bottleneck curve is now different (due to SUMO handling merging differently now). We put the commit number in there if you want to reproduce exactly. Sorry for the trouble!

We are in the process of upgrading the benchmarks but it's going to be a while.

Got it, thanks. I'll see if I can sweep the flow rate a little myself and see what happens

Closing since I think this is answered.


Handle grayscale, RGB, RGBA in im2rec and data loader

Handle grayscale, RGB, RGBA in im2rec and data loader

Modified tools im2rec.cc and im2rec.py

Add an option to choose the encoding: jpg or png; png is needed to store RGB+Alpha channel
Add an option to choose color mode: force gray, force color or use the color mode of the source images
The existing quality parameter can be used to choose the png compression
in im2rec.cc, add an option to keep the original image untouched: that speed up the creation of the dataset (don't need to decode and encode image).

Modified data loader

Add a parameter mean_a to substract the mean of the alpha channel

LGTM

I have added you to https://github.com/dmlc/mxnet/edit/master/CONTRIBUTORS.md Thanks for the contribution and making mxnet better!


Stack overflow error with Donation modal

Describe the bug
When you go to a challenge and the donation modal appears a stack overflow error occurs
To Reproduce
Steps to reproduce the behavior:

Using Chrome go to http://localhost:8000/learn
Click on Say Hello to HTML Elements
Open the dev console
See error

Screenshots

Desktop (please complete the following information):

OS: Ubuntu
Browser Chrome
Version 76.0.3809.100 (Official Build) (64-bit)

Additional context
Removing this._editor.focus() removes it, so presumably it's a clash between that and the modal.

You are correct, I think there could be a race condition between the two.