Output only blank

Hi, I tried to training from scratch using minimal english. The output quickly converged to underscore, so all the predicted transcripts are just empty strings. Any suggestions? Thank you.

How many epochs did you wait for? For me the first one or two epochs were gibberish, the next couple were empty, and only after then the model started outputting something sensible.


Replace KILL signal with TERM for :restart option

I don't see needing for KILL signal, also we're waiting for termination.
Resolve #106

Closing in favor of #132, where the actual option for signal.


Test 2

[x] Add new new feature
[x] Fixed a bug
[x] Remove un-used code

Text with a highlight

Closing

One more comment

You can use scale.pink.2


Guide message for admin who first time use machine update.

If kubernetes is deployed by the new paictl, the node configuration will be created after the deploymend.
But for the cluster deployed by the old version paictl, the node configuration may be missed. So add this messge to help admin to operate the cluster.

Coverage decreased (-0.01%) to 51.62% when pulling dfa6b0fef8ba47f587c53f6b99ec83289a2b23d0 on yuye/machine-update-fix into 647b93fb8983b7dff0b14562456b1c3386ba894f on master.

Coverage decreased (-0.01%) to 51.62% when pulling dfa6b0fef8ba47f587c53f6b99ec83289a2b23d0 on yuye/machine-update-fix into 647b93fb8983b7dff0b14562456b1c3386ba894f on master.

Coverage decreased (-0.01%) to 51.62% when pulling dfa6b0fef8ba47f587c53f6b99ec83289a2b23d0 on yuye/machine-update-fix into 647b93fb8983b7dff0b14562456b1c3386ba894f on master.

Coverage decreased (-0.01%) to 51.62% when pulling dfa6b0fef8ba47f587c53f6b99ec83289a2b23d0 on yuye/machine-update-fix into 647b93fb8983b7dff0b14562456b1c3386ba894f on master.


opentelemetry-collector: 0.64.1 -> 0.66.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/open-telemetry/opentelemetry-collector/releases.
meta.description for opentelemetry-collector is: "OpenTelemetry Collector offers a vendor-agnostic implementation on how to receive, process and export telemetry data"
meta.homepage for opentelemetry-collector is: "https://github.com/open-telemetry/opentelemetry-collector"
meta.changelog for opentelemetry-collector is: "https://github.com/open-telemetry/opentelemetry-collector/blob/v0.65.0/CHANGELOG.md"
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.65.0 with grep in /nix/store/7iqs8ifxrq6a4yc3ir9rj9ippr8iblkr-opentelemetry-collector-0.65.0
found 0.65.0 in filename of file in /nix/store/7iqs8ifxrq6a4yc3ir9rj9ippr8iblkr-opentelemetry-collector-0.65.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
opentelemetry-collector

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/7iqs8ifxrq6a4yc3ir9rj9ippr8iblkr-opentelemetry-collector-0.65.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A opentelemetry-collector https://github.com/r-ryantm/nixpkgs/archive/39e6fc9af869eacabf5472ff1d6507b918ba555b.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/7iqs8ifxrq6a4yc3ir9rj9ippr8iblkr-opentelemetry-collector-0.65.0
ls -la /nix/store/7iqs8ifxrq6a4yc3ir9rj9ippr8iblkr-opentelemetry-collector-0.65.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

opentelemetry-collector

Maintainer pings
cc @uri-canva @06kellyjac for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/open-telemetry/opentelemetry-collector/releases.
meta.description for opentelemetry-collector is: "OpenTelemetry Collector offers a vendor-agnostic implementation on how to receive, process and export telemetry data"
meta.homepage for opentelemetry-collector is: "https://github.com/open-telemetry/opentelemetry-collector"
meta.changelog for opentelemetry-collector is: "https://github.com/open-telemetry/opentelemetry-collector/blob/v0.66.0/CHANGELOG.md"
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.66.0 with grep in /nix/store/v4nwyis7v6hzxrg5h1hhz0xa2ibalrqn-opentelemetry-collector-0.66.0
found 0.66.0 in filename of file in /nix/store/v4nwyis7v6hzxrg5h1hhz0xa2ibalrqn-opentelemetry-collector-0.66.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
opentelemetry-collector

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/v4nwyis7v6hzxrg5h1hhz0xa2ibalrqn-opentelemetry-collector-0.66.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A opentelemetry-collector https://github.com/r-ryantm/nixpkgs/archive/32bbf73f49d6504196468691d2f33a3ef71273e9.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/v4nwyis7v6hzxrg5h1hhz0xa2ibalrqn-opentelemetry-collector-0.66.0
ls -la /nix/store/v4nwyis7v6hzxrg5h1hhz0xa2ibalrqn-opentelemetry-collector-0.66.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

opentelemetry-collector

Maintainer pings
cc @uri-canva @06kellyjac for testing.


displaying image result outside of jupyter

Hi !
sorry if my question is quite silly, I'm quite new to python and image handling, However I've been messing around with Deep Dream and Neural-Transfer previously and I recently found Lucid, and I'm completly amazed by what it does, so thanks for sharing your work and knowledge !!
however I tried to play with the code directly on python (outside of jupyter) and I've come across a problem :
the render.render_vis command output a list of values and then when I convert it to an array with numpy, I get a 5 dimensional array (which is not convertible into an image in this state) but I see that in the notebook file you provide, this array is displayed as an image, so basicly how can I manually convert it to an image directly in a .py file ?
(in an other way, how can I display or save the result of render.render_vis as an image, using PIL, pyplot or numpy for example ?)
another subplot :
i'm working on python 2.7 and to get it working on it I modified the vision_base.py file on line 75 to :
class Model(object):
  __metaclass__ = ModelPropertiesMetaClass

before building and installing it, as the metaclass syntax changed on python 3, a small modification but if it can help for some python 2 users :)

The result of render_vis should be a (Python) array of the optimization result at each step specified in thresholds. If you didn't specify them, you'll get a list with just one entry. That entry is a numpy array of shape Batch x Width x Height x Channels. If your batch dimension is just 1—which it is by default—then you can simply index into that numpy array and use the save helper to save it as a file which you can then view outside of python.
Writing this from memory, so it may have syntax issues:
from lucid.optvis.render import render_vis
from lucid.misc.io import save

results_at_thresholds = render_vis(…)
last_result = results_at_thresholds[-1] # gets result at last threshhold
image = last_result[0] # gets first image from batch
save(image, "path/to/result.jpg")

Closing in the hopes this helps, but let me know if you need more assistance!
Re subplot: unfortunate timing; this will be fixed today.

perfect !! thanks for the assistance, that works !
I think I didn't read carefully enough all the documents you provided about your method, I will re read them to understand Lucid better ;)


[BUG] Xiaomi Aqara LLKZMK11LM 2nd channel not working

Describe the bug
I got a load of these sensors and the pair great and the first channel works fine, but the second channel never switches.
Physical hardware is fine as the switch lines on the device seem to be all good
To Reproduce
Steps to reproduce the behavior:

Add device to ZHA devices
Toggle channel 1 it works
Toggle channel 2 it doesn't works, sends command but then fails and switches back
See errors in logs

[homeassistant.components.zha.entity] light.lumi_lumi_relay_c2acn01_on_off_2: turned on: {'on_off': TimeoutError()}
Expected behavior
Both channels should work

I read the packet from the logs and resent it, it works fine.
echo -en "\xfe\r$\x01\x16\xdf\x01\x01\x06\x00'\x00\x1e\x03\x01'\x01\xfa" > /dev/ttyACM0
So I decided to use zigpy-cc  to generate the binary frame and then push it down to the router so I can test some changes.
After adjusting the src and destination points from 1,1 to 1,2 respectively I managed to get the second channel to switch.
payload2_on = {'dstaddr': 57110, 'destendpoint': 2, 'srcendpoint': 1, 'clusterid': 6, 'transid': 39, 'options': 0, 'radius': 30, 'len': 3, 'data': b"\x01t\x01"}
I believe this should just be a change in the device quirks? Not sure what the process is to make this change or where is should be done.
If you need more info please ask, i really want to help get this alive.

it is a bug in zigpy-cc https://github.com/zigpy/zigpy-cc/issues/57 https://github.com/zigpy/zigpy-cc/issues/57
the 0.116 beta which will be released tomorrow would contain zigpy-znp switch your integration to use zigpy-znp radio type instead  and the problem should be solved.

Duplicate of https://github.com/zigpy/zigpy-cc/issues/56
Closing this one to keep everything in one place.

@Adminiuga You are the best, thanks!


String format method flagged incorrect syntax in voice.py

Modified the voice.py script to use %s string formatting instead of calling the format method.
Currently running version Python 3.5.0 and the build script failed to compile the voice.py binary with the previous code.

Neat


Rename :java-language-extensions => :stdlib-java-extensions

For consistency with :stdlib-kotlin-extensions and the <module>-<language>-extensions convention.
Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

WARN: The milestone of this PR is 8.10 RC1, but the base branch version is 8.9


Resolution registry does not invalidate all claims of request

This is a bug. The resolution registry maps from fill hash to filler. That implies that an attacker who presents a false claim with a random fill id will not be invalidated by the fill proof of the real filler. This attack only happens if the real filler hasn't withdrawn yet. But it is possible that this happens.
We have two options to fix it:
a) Send a Non-fill proof for each false claim. Same as for non filled requests, there is always the option to invalidate any fill hash. This has the disadvantage that for any challenge, the challenger must call invalidateFillHash on L2 to have its proof in case of L1 resolution. This means one transaction more per challenged claim. To recover the cost for this it could be incorporated into the claimStake. The advantage is, that it is just a minor change in the agent to work.
b) Refactor the resolution registry. Initially the mapping fillers (fillHash -> filler) was chosen to incorporate the fill id and prevent an attack vector that an attacker could claim and only fill after he was challenged. This leads to the fact that we have inefficiency in mapping itself. There can only ever be one fill per request but we do not know from the fill hash which request it corresponds to. When checking the registry upon withdraw, we automatically check the fill id by recreating the fill hash from the claim's information. But if the mapping is empty we would never know if there is another fill hash with the real filler corresponding to the potentially false claim's request.
We have to separate the information (request hash and fill id) and store them separately. But it is crucial that we also pass the fill id. The filler mapping would look like request hash => struct(filler, fill id). If we have that then there is a direct assignment from request hash to the real filler. Every claim for that request would look up the same entry and evaluate based on the information found.
The advantage would be that a challenger would not need calling its own L1 resolution. Only one L1 resolution per request.
The disadvantage is the amount of work to fix that now.

decided on b)
we need to separate fillhash to tuple(request_hash, fill id) both in fillers and invalidFillHashes


feat: add @Path.get, @Path.put, etc. decorators to Path

Background: https://github.com/encode/starlette/pull/704
There are pros and cons to the decorator / list of routes approach.
I think the big pro of the decorator approach is having the path parameters close to the endpoint function.
The main con is that it introduces a lot of code paths, for example with App.add_middleware() and the relationship between App and App.router.
A good compromise may be to add decorators only for Path.
This gives us the best of both worlds:

Path parameter declarations are close to where they are used
There is no complicated state management (Path is pretty simple)
Other classes are boilerplate free and have simple declarative constructor composability

The main issue is how to deal with Operation.
I guess we'd have to make the decorators accept all of the parameters of Operation, which I don't like.

Hmm realizing we would have to add these to Router, not Path.
It gets super tricky then because you'd have to be able to pass parameters 2 levels deep (e.g. to get something to Operation). Or you mash up all parameters into one. But I feel like this really deteriorates what are now clearly delineated concepts of Path and Operation which map 1:1 with OpenAPI and make it super clear what's going on.
So maybe this isn't such a good idea after all. If it was simpler, I would like to have the path parameter template closer to the endpoint that uses them. But not if it introduces a lot of rough edges and makes it harder to grasp the concepts of the framework.

Two counterarguments to the arguments for having the decorators are:

You should be able to catch name discrepancies in tests, unless you literally don't have any tests calling that endpoint.
Both in Xpresso and FastAPI you can have a dependency that uses a path parameter. And at that point all bets are off the table since that dependency could be in a different file and whatnot.

This is going to have to be a punt. There are other priorities, like figuring out the Security story


Fix revision solver for branch and tag

Branch and tag revision are properly parsed by revision lexer but not properly solved into references.
#599

@mcuadros can you review this PR pls ?

@antham ping

@mcuadros you can come back, AppVeyor crashs but it doesn't seem related to my tests

Now AppVeyor works but there is an error with one of the build with travis....

@mcuadros did you see my last comments in this PR about RefRevParseRules and the tag on basic repository ?


toybox: enable use of libsmack on toybox.

It patch to toybox to use a default libraries environment used on yocto.
Also config toybox to be compiled using libsmack.h
Upstream-Status: Submitted(https://github.com/landley/toybox/pull/15)
Signed-off-by: Alejandro Joya<EMAIL_ADDRESS>

Shouldn't the toybox patch go into the main toybox recipe? Why does it compile without it?
Regarding the .bbappend itself: this layer does not depend on meta-oe and we shouldn't add a dependency on it just for fixing toybox when it is used. Let's close this and move it to the distro-specific fixes area.


Role in User Schema

The role of a user can be multiple. As of now, it only stores a single role. Needs to be changed to an array.

Will work on this. Need to change token middleware for verifyUser, requireRole.


Update busuanzi-counter.swig

不蒜子公告：需要修改该js域名，其他均未改变

PR Checklist
Please check if your PR fulfills the following requirements:

[ ] The commit message follows our guidelines.
[ ] Tests for the changes have been added (for bug fixes / features).

[ ] Muse | Mist have been tested.
[ ] Pisces | Gemini have been tested.

[ ] Docs have been added / updated (for bug fixes / features).

PR Type
What kind of change does this PR introduce?

[ ] Bugfix.
[ ] Feature.
[ ] Code style update (formatting, local variables).
[ ] Refactoring (no functional changes, no api changes).
[ ] Build related changes.
[ ] CI related changes.
[ ] Documentation content changes.
[ ] Other... Please describe:

What is the current behavior?

Issue Number(s): N/A
What is the new behavior?
Description about this pull, in several words...

Screens with this changes: N/A
Link to demo site with this changes: N/A

How to use?
In NexT _config.yml:
...

Does this PR introduce a breaking change?

[ ] Yes.
[ ] No.

This changes already added in NexT v6.x.x

NexT is rebased into organization repo.
If you want new feature, please, create pull in NexT v6.x repo.
There is instructions on English or Chinese how to update from v5.1.x to v 6.x
You also may read this for details.


Remove test buttons on the top of the NMRium component

Two possible solutions we can adapt

Display the buttons only on the development instance. The production version should have this automatically hidden (subdomain check or via build process). Make sure this doesn't add up to the loading time of the application.

Totally hide this and register keyboard shortcuts to trigger these events. For example

Shft+Ctrl+1 => Test load custom event
Shft+ctrl+2 => Test load observable
Shft+ctrl+2 => Test load via URLS

@CS76
I will use playwright for testing and remove the buttons completely

closed by https://github.com/NFDI4Chem/nmrium-react-wrapper/commit/4e0848f93e26955507ff1c57da6dd0aa1a5cc947


fix(sherif): remove unnecessary option and ignore directory

@TkDodo I saw your feature request in https://github.com/QuiiBz/sherif/issues/41 and feature is added in v7.0.0 of sherif
Thanks to request feature to sherif. I am using this tool and this I needed this feature too.
To resolve your comment in https://github.com/TanStack/query/pull/6686 I updated script for sherif. from now we don't have to use unnecessary option(-i react-scripts -i typescript) So cool👍

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (3a127bf) 41.71% compared to head (9d71384) 41.71%.
Report is 2 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #6701   +/-   ##
=======================================
  Coverage   41.71%   41.71%
=======================================
  Files         179      179
  Lines        7007     7007
  Branches     1416     1416
=======================================
  Hits         2923     2923
  Misses       3713     3713
  Partials      371      371

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

not sure how but this is failing on main:
https://cloud.nx.app/runs/oblIhu1Dfj
> query@ test:sherif /home/runner/work/query/query
> sherif --ignore-package ./integrations/*

error: unexpected argument './integrations/react-cra5' found

Usage: sherif [OPTIONS] [PATH]

Can you please investigate and fix it, or I need to revert. Thanks

not sure how but this is failing on main:
https://cloud.nx.app/runs/oblIhu1Dfj
> query@ test:sherif /home/runner/work/query/query
> sherif --ignore-package ./integrations/*

error: unexpected argument './integrations/react-cra5' found

Usage: sherif [OPTIONS] [PATH]

Can you please investigate and fix it, or I need to revert. Thanks

@TkDodo Revert first please not to affect other branches working, I will investigate it soon

@TkDodo, I started to investigate this issue in https://github.com/QuiiBz/sherif/issues/51

Hi, seems like your shell automatically interprets and expand *, so the resulting command is indeed incorrect. In that case, you have to wrap the argument in quotes: sherif --ignore-package "./integrations/*"
Note that this isn't related to Sherif directly, but I'll update the documentation to include these quotes.


added two programs based on sorting

Added following programs

Union of two sorted arrays
Intersection of two sorted arrays

#1


Exception thrown when ICONDIRENTRY has zero bit depth

The exception was added to help identify a test case for a fragment of code with no coverage. It's when a BMP image in the icon specifies a bit depth which is different the bit depth given in the ICONDIRENTRY
An example which causes this failure is http://www.nejm.org/favicon.ico

Fixed in master, will be released in 1.0.1


sveltekit d3 problems / shows unexpected behavior for  bind:clientWidth and bind:clientHeight compared to a normal svelte project

Describe the bug
Trying to use d3 with sveltekit I stumbled upon unexpected behavior.
For demo purposes I took the svelte project simple-svelt-chart and migrated it into a simple sveltekit project  simple-svelt-chart-kit.
Doing so it shows strange behaviors regarding the calculated width and height.
Contrary to a simple svelte project it won't get calculated at render time but later.
I created 2 branches with partly solutions that are still faulty / defective.
In the branch "solution/unconditionalRendering" it renders the graph (unconditionally if width and height are available yet) including some NaN errors in the browser console (SVG translate)
In the branch "solution/presetingWidthAndHeight" I simply did preset a value for the width and height property, resulting in a rendered and secondly adjusted graph.
What is really weird with both "solutions" is the behavior when changing the window size. It results in an graph enlarging itself in height endlessly.
Reproduction
Try the sveltekit demo project I created for this purpose  simple-svelt-chart-kit ... I used the svelte project simple-svelt-chart as a simple comparable base.
Don't forget to switch into the solution ( attempt ) branches to see the weird behaviors described previously
Logs
No response
System Info
System:
    OS: Linux 5.13 KDE neon 5.24
    CPU: (8) x64 Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
    Memory: 2.11 GB / 15.44 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 16.14.2 - ~/.nvm/versions/node/v16.14.2/bin/node
    Yarn: 1.22.19 - /usr/bin/yarn
    npm: 8.5.0 - ~/.nvm/versions/node/v16.14.2/bin/npm
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Chrome: 102.0.5005.61
    Chromium: 102.0.5005.61
    Firefox: 100.0.2
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.50
    @sveltejs/kit: next => 1.0.0-next.347
    svelte: ^3.44.0 => 3.48.0

Severity
blocking all usage of SvelteKit with d3
Additional Information
I'm still rather new to sveltekit - hopefully I didn't overlook anything obvious. Researching it didn't pop up any solutions.

@delight I didn't have time to fully look into your issue, but could this be a SSR issue? When the component is created on the server, obviously there's no applicable clientWidth or clientHeight. You could test this by temporarily disabling SSR using handle: https://kit.svelte.dev/docs/hooks#handle. I'll see if I can look into it further later in the day. 😄

I just added the global.css file of the original project into the master branch - doesn't make a difference ... I can rebase the "solution" branches on top of that ... but a quick try out of one of them resulted in the same behavior

crated a stackblitz from the project

created also a stackblitz to the working svelte (not-sveltekit) project

Pretty sure the difference has to do with where you're mounting your app. In the Svelte-only stackblitz it's getting mounted to the body which is occupying the full height of the viewport (from the global css). In the SvelteKit one it is getting mounted to a div inside which is only as big as its contents need to be i.e. big enough for the selectors.
I added style="height: 100%;" to the div in app.html and the chart is rendering properly. Haven't checked on other browsers but pretty sure that's what's happening, @delight I'd be delighted (lol) if you could confirm.

@gtm-nayan to your delight ;-) I can confirm that the problem indeed was the additional div (I guess the outer div limiting the space of the inner div.wrapper - css some(often)times behavior confuses me. style="height: 100%;" wasn't needed as it was set already in the global.css
Thnx so much for point this out ... closing the ticket


Error on Connect: FileNotFoundError: [WinError 2] The system cannot find the file specified

I'm using python 3.6.6 on windows 64bit and just used pip to install pyarrow. But when I'm trying to connect I get this error while it does not look like an credential issue:
Traceback (most recent call last):
  File "hdfs.py", line 3, in <module>
    fs = pa.hdfs.connect(host='localhost', port=9000, user='dr.who')
  File "C:\Program Files\Python36\lib\site-packages\pyarrow\hdfs.py", line 183,
in connect
    extra_conf=extra_conf)
  File "C:\Program Files\Python36\lib\site-packages\pyarrow\hdfs.py", line 35, i
n __init__
    _maybe_set_hadoop_classpath()
  File "C:\Program Files\Python36\lib\site-packages\pyarrow\hdfs.py", line 135,
in _maybe_set_hadoop_classpath
    classpath = subprocess.check_output([hadoop_bin, 'classpath', '--glob'])
  File "C:\Program Files\Python36\lib\subprocess.py", line 336, in check_output
    **kwargs).stdout
  File "C:\Program Files\Python36\lib\subprocess.py", line 403, in run
    with Popen(*popenargs, **kwargs) as process:
  File "C:\Program Files\Python36\lib\subprocess.py", line 709, in __init__
    restore_signals, start_new_session)
  File "C:\Program Files\Python36\lib\subprocess.py", line 997, in _execute_chil
d
    startupinfo)
FileNotFoundError: [WinError 2] The system cannot find the file specified

I installed Hadoop locally on my windows machine by the way. Any idea?

I changed hdfs.py file this way and it passed that issue:
def _maybe_set_hadoop_classpath():
    import subprocess

    if 'hadoop' in os.environ.get('CLASSPATH', ''):
        return

    if 'HADOOP_HOME' in os.environ:
        hadoop_bin = os.path.normpath(os.environ['HADOOP_HOME']) #'{0}/bin/hadoop'.format(os.environ['HADOOP_HOME'])
    else:
        hadoop_bin = 'hadoop'

    os.chdir(hadoop_bin)
    hadoop_bin_exe = os.path.join(hadoop_bin, 'hadoop.cmd')
    classpath = subprocess.check_output([hadoop_bin_exe, 'classpath', '--glob'])
    os.environ['CLASSPATH'] = classpath.decode('utf-8')

PS: my HADOOP_HOME env already was the bin folder of hadoop.


Revamp azure-core-javadocs

Revamps JavaDocs for some key package and classes at both package and class level.

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


Add support for a horizontal rule in Markdown. The Markdown --- should get converted to an  tag.

The Markdown --- should get converted to an  tag.

closed by e59061b15158983b56827e086e573fe3f2a7c5c3


[REEF-946] Implement YARN REST submission command builder for REEF .NET

client
JIRA:
REEF-946

@anupam128 Looks good in general, just a few minor comments. Thanks!

@anupam128 I've done a pass.

Doing another pass.

I'm done with my pass.

I completed my pass.

Thanks all! I have responded to comments and made changes.

@anupam128 One final nitpick from me. I'm +1 after. Thanks!

@afchung thanks! Made the change.

I'm +1 merging it.

+1 for merge

OK, I'll test and merge tomorrow.


Make content item factory stricter

What / Why
Previously we would look up our content item model class based solely on its document type, and ignore schema name. If there was a matching model name which extended ContentItem, we'd use that.
Since we only have a LandingPage model, and there are no actual landing_page content items, you'd think this was fine.
Unfortunately, as soon as we tried to add the landing_page document type in publishing-api, we ran into a problem. Some of the tests generate "random" content items:
https://github.com/alphagov/govuk_schemas/blob/c0d74240bafcd2d4ebcf3e8550071028fc6fbbde/lib/govuk_schemas/random_example.rb#L6-L18
By default, they use the "generic" schema, which can have any document type. This means there's a chance that a random example will have schema_name: generic, document_type: landing_page.
In that situation, the ContentItemFactory will instantiate the LandingPage model instead of the ContentItem model, and we end up with a confusing situation where a controller that isn't expecting it gets a LandingPage model instead of a ContentItem model.
This is only a problem for tests, but I think in general it's better to be specific about both the schema and the document type.
This does mean we lose out on Keith's nice convention-over-configuration approach. Adding new ContentItem subclasses won't be enough to get the factory to instantiate them with this pattern, we'll also need to add them to the if statement. Short term, I think this is fine, but it might get annoying to have to manage a giant case statement later.
⚠ This repo is Continuously Deployed: make sure you follow the guidance ⚠

Superseded by #4267


update change log for version 1.0.1

Current coverage is 97.07% (diff: 100%)

Merging #30 into master will not change coverage

@@             master        #30   diff @@
==========================================
  Files             8          8
  Lines           753        753
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits            731        731
  Misses           22         22
  Partials          0          0

Powered by Codecov. Last update d08567e...0f69d70


Customization options for Containers

Clear and concise description of the problem
Currently the usage of images is very limited, which requires one to implement some workarounds like using custom images/plugins to play along with woodpecker and sometimes existing infrastructure requirements.
Therefore I would like to suggest to add support for the following options to not have to re-invent the weel every time when one wants to integrate a new tool/image which does not match the current limitations.

containerprefix
currrently the name shows up like 0_338859503931012122_step_0 and defining a name or a static prefix would make it clearer which container to look for in case of a hanging job which needs to be investigated, or for monitoring exclusion.
labels/attributes
would help in situations where external components rely on the existence of specific labels, like log collection/shipping, alerting rules, service discovery, ...
entrypoint
some containers either have default entrypoints (e.g. trivy), which can not be used in a CI context or containers built from scratch which don't have a shell available would need a way to customize the the entrypoint to work properly out of the box.

This list is only my "Top 3" with potentially more options to follow, but these would already cover more then 90% of all my use cases.
Suggested solution
The ability to define specific options for images like:
pipeline:
  test:
    image:
      name: a-container:latest
      entrypoint: [""]
      pull_policy: [always, if-not-present, never]
      labels:
        key: value

or as backend_options
    image: my-container:latest
    backend_options:
      docker:
        prefix: my_prefix_
        entrypoint: [""]
        pull_policy: [always, if-not-present, never]
        labels:
          key: value

Alternative
Currently the only alternative I see, are custom images or plugins tailered to work with woodpecker.
Additional context

As already predicted by @gapodo in https://github.com/woodpecker-ci/woodpecker/pull/1825#issuecomment-1576598884, where labels support has been removed (here we go :smirk:)
#278
GitLab Runner - Docker executor documentation
How the Testcontainers Project does it

Validations

[X] Checked that the feature isn't part of the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

if we add such docker backend options imho these should be server side configuration options not per pipeline

linking #278

I would say that's are agent backend options ...

or at least some of the proposals

@6543, @lafriks
Completely agree with your comments, some options might be better suited for backend options, while others might be a better fit for the pipeline config.
I just wanted to provide an end-user view and would leave it to the experts to decide where the implementation would fit best, as they have a better overview of all the internals.


Can't re-enter same room unless both peers leave

If I have a video call going, and one person leaves and then tries to come back, he won't be able to enter the same room the other person leaves as well, and then they both re-enter. This is also a problem because if you lose your connection or refresh, you won't be able to re-enter the room.
I'm very confused. It doesn't say the room is full when I try to re-enter so it does recognize that someone disconnected. Any ideas?

Seems to be working now, I changed two things if anyone has a similar issue.
First, in the maybeStart function, I took out the need for isInitiator to be true to be able to call doCall(). I'm still very new to webRTC and I'm not even sure what purpose isInitiator serves, but my application seems to be working fine without using it in this function. If there is a problem with doing things this way please let me know.
After I did this, I noticed I could refresh on chrome and get back into my call, but if I did it on my iPhone, I had the same issue as before. I fixed this by changing
window.onbeforeunload = function() {   sendMessage('bye'); };
to
`
var isOnIOS = navigator.userAgent.match(/iPad/i)|| navigator.userAgent.match(/iPhone/i);
var eventName = isOnIOS ? "pagehide" : "beforeunload";
window.addEventListener(eventName, function (event) {
sendMessage('bye');
} );
`
Apparently the before unload event is called pagehide now in iOS safari.


Any idea what the problem is?
Thanks in advance!

also having this issue

I have the same issue and found two workarounds, if you're depending elsewhere in your project to pdfjs-dist you can change https://github.com/vinodnimbalkar/svelte-pdf/blob/87116ace904234c14bbf715bb45ecbfa9fb9306e/src/lib/PdfViewer.svelte#L26 to: pdf.worker.entry.js, OR fork the project and update the pdfjs-dist dependency to ^3.8.162 (latest version for me at the time of testing) and the error will go away.

just ran into the same issue, added the specified version to my package json and it would work !, thanks for the tipp

I found I was able to modify svelte-pdf/src/lib/PdfViewer.svelte with the following to get workers to work
-  import * as pdfWorker from 'pdfjs-dist/build/pdf.worker.mjs'
+  import pdfWorker from 'pdfjs-dist/build/pdf.worker.mjs?worker&url'

As per
https://vitejs.dev/guide/features#web-workers
https://github.com/mozilla/pdf.js/issues/8305
https://github.com/mozilla/pdf.js/pull/17504

to: pdf.worker.entry.js

got mine to work instead by changing it to pdf.worker.min.js


[deliver] Check if each non-framed screenshot has a framed counterpart

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Motivation and Context

It solves an open issue where if there is a single framed screenshot, all non-framed screenshots are skipped.

Resolves #15366
Description

When framed screenshots are detected and the current file is not framed, check to see if it has a framed counterpart. If it does, skip this unframed version. Otherwise, add this unframed version.

I created a new directory with framed and unframed files and tested just this feature.
Testing Steps

I made a folder with a few .txt files that did and did not have the "_framed". Then, I tested my if statement like so:
files = Dir.glob('/Users/jess/testruby/thefiles/*.txt')
extensions = '{png,jpg,jpeg,txt}'
framed_screenshots_found = Dir.glob("/Users/jess/testruby/thefiles/*_framed.#{extensions}").count > 0

if framed_screenshots_found
  puts "Framed screenshots are detected! 🖼 Non-framed screenshot files may be skipped. 🏃"
end

files.each do |file_path|
  puts "working on: #{file_path}..."
  is_framed = file_path.downcase.include?("_framed.")

  if framed_screenshots_found && !is_framed
    # check to see if there is a framed version of this file
    fext = File.extname(file_path)
    puts file_path.gsub("#{fext}","_framed#{fext}")
    if Dir.glob(file_path.gsub("#{fext}", "_framed#{fext}")).any?
      puts "🏃 Skipping screenshot file: #{file_path} because this file has a framed version"
      next
    end
  end

  # still here then have the file_path
  puts "i am keeping #{file_path}"
end

The result here shows that the statement works - it skips bob.txt because there is a bob_framed.txt, but it keeps test.txt because there is no test_framed.txt:
jess:testruby/ $ ruby test_file.rb                                    [5:56:43]
Framed screenshots are detected! 🖼 Non-framed screenshot files may be skipped. 🏃
working on: /Users/jess/testruby/thefiles/bob.txt...
/Users/jess/testruby/thefiles/bob_framed.txt
🏃 Skipping screenshot file: /Users/jess/testruby/thefiles/bob.txt because this file has a framed version
working on: /Users/jess/testruby/thefiles/bob_framed.txt...
i am keeping /Users/jess/testruby/thefiles/bob_framed.txt
working on: /Users/jess/testruby/thefiles/test.txt...
/Users/jess/testruby/thefiles/test_framed.txt
i am keeping /Users/jess/testruby/thefiles/test.txt

Please note that for the test to work with minimal setup, its code is slightly different than the version in the fastlane deliver file, which includes the watch and bold:
if framed_screenshots_found && !is_framed && !is_watch
            # check to see if there is a framed version of this file
            fext = File.extname(file_path)
            if Dir.glob(file_path.gsub("#{fext}", "_framed#{fext}")).any?
              UI.important("🏃 Skipping screenshot file: #{file_path} because this file has a framed version")
              next
            end
          end

I'm looking at the circleci tests, and I think the details show failure because the screenshot count is higher than expected. It is 2 instead of 1 (excluding watch) and 3 instead of 2 (including watch). However, this is what I expect for this change.

What do I need to do to have this PR considered @janpio ? Is the behavior undesired?

Hey @monkeywithacupcake, the tests would need to be adapted to pass again of course. Additionally this lint failure needs to be fixed:
deliver/lib/deliver/upload_screenshots.rb:125:40: C: Style/UnneededInterpolation: Prefer to_s over string interpolation.

            if Dir.glob(file_path.gsub("#{fext}", "_framed#{fext}")).any?

                                       ^^^^^^^^^

@monkeywithacupcake
Hi, thank you for taking the time to contribute to fastlane and I am sorry that your change is now unacceptable as is since I significantly updated deliver/lib/deliver/upload_screenshots.rb and your change is recognised as conflicts now.
https://github.com/fastlane/fastlane/blob/15093fc8213dcfe8982ab0e07dc8a59388c6ee92/deliver/lib/deliver/loader.rb#L88-L93
As @janpio mentioned I feel like this original change had a side effect that may cause issues to existing projects. For example, frameit would name a "_framed" screenshot from non-suffixed filename; e.g. yourapp6.5_1.png vs yourapp6.5_1_framed.png. In that case,   non-suffixed screenshots will also be uploaded, which is a breaking change.
Let's continue this in https://github.com/fastlane/fastlane/issues/15366
I'll leave my idea to the issue, which is less likely to have breaks to and probably work on it at some point.

@monkeywithacupcake
Hi, thank you for taking the time to contribute to fastlane and I am sorry that your change is now unacceptable as is since I significantly updated deliver/lib/deliver/upload_screenshots.rb and your change is recognised as conflicts now.
https://github.com/fastlane/fastlane/blob/15093fc8213dcfe8982ab0e07dc8a59388c6ee92/deliver/lib/deliver/loader.rb#L88-L93
As @janpio mentioned I feel like this original change had a side effect that may cause issues to existing projects. For example, frameit would name a "_framed" screenshot from non-suffixed filename; e.g. yourapp6.5_1.png vs yourapp6.5_1_framed.png. In that case,   non-suffixed screenshots will also be uploaded, which is a breaking change.
Let's continue this in https://github.com/fastlane/fastlane/issues/15366
I'll leave my idea to the issue, which is less likely to have breaks to and probably work on it at some point.


Alt tag description

issue #742

Also, I'm curious, why just this one image in this blog post?  is the plan to do other PRs for the other images?

Made a few tweaks, mainly the remaining images' alt text.

Fixes #742


Namespace core plugin type IDs

This commit also centralizes pluginName + rawTypeID.
Resolves #436

How should analytics handle shared entries like volume.file, volume.dir? With the changes here, they'd be <plugin_name>::volume.file, <plugin_name>::volume.dir. Is that OK? Should we fine-grain them more to <plugin_name>::fs::volume.file, <plugin_name>::fs::volume.dir`?
I think it makes sense to treat volume.file/volume.dir as a single resource within the plugin (so am leaning towards <plugin_name>::volume.file, <plugin_name>::volume.dir).

Updated.


Sensorts auto-complete

Issue related to the Python sunsynk library
Describe the issue/bug
For the sensors section in config i would imagine this to be autocomplete? I cant seem to get any values to display here. Even if i remove an existing sensor and try to add it back again i cant find it.
A clear and concise description of what the bug is.
Expected behavior
I expect all available sensors to be displayed for selection.
A clear and concise description of what you expected to happen.
Logs (if applicable)
paste logs in 3x backticks...

Sorry, there are no plans to do this. Unfortunately you'll have to read the docs.
But since it's open source you are welcome to add it yourself


Add an option to ignore newer major version

For people who rely on packages that are semantically versioned, it would be nice to have an option to only upgrade to the newest version that does not have breaking changes. So, if we are using v2.2.1 and v3.0.0 becomes available, do not upgrade to it. Perhaps there could be an extra parameter called :semantic to enable this functionality, or maybe something else like :only-minor and :only-patch.

My use case is
[org.eclipse.jetty/jetty-server "11.0.6"] is available but we use "9.4.43.v20210629"
I cant upgrade because ring-adapter doenst support jetty 9+ - https://github.com/ring-clojure/ring/issues/439

FYI, Jetty 9.x Community support ended on 6/1/22, but security updates will continue probably until 2025.  See more at https://github.com/eclipse/jetty.project/issues/7958


Please

Hi, sorry for writing here.
Please write the instructions in more detail how to run this app
Thnx

Hi there,
You could see that guideline for running on local on readme file https://github.com/jellydn/dapp-token-ico#hardhat-guideline Let me know if that works for you.

I also record a video about this repo on my channel https://www.youtube.com/watch?v=9fmViThaMGk&list=PLOdXIcVPTyB-jyB4UmrwncHDK0mgl-Ex-&index=4


Onboard SecOps team so they can run forwarder/proxy components to on-prem SIEM in their own AWS accounts.

Describe the issue
We have created aggregation/forwarding configuration for SEA logs to be sent to on-prem SIEM, but we would like to have a simple, stable, agreed-upon interface to send to, and like the SecOps team to be able to control more specifics of how data is ingested into their systems.  As a way of enabling that, we want to establish/onboard the SecOps team as a tenant, with their own account set so they can manage deployment and configuration of the elements to complete the integration, as well as evolving it over time if/when it changes.
Which Sprint Goal is this issue related to?

Note: 'Milestone' is a ZenHub term that we use synonymously with 'Sprint'.

The 'Milestone' description (created in ZenHub) should clearly list Sprint Goals. This section should indicate which 'goal' this issue is related to.
Additional context
The current SIEM integration has progressed, but the "last mile" has not been completed.  This ticket is an approach towards getting through that last mile, and setting things up for a sustainable model with clear responsibilities as well as technical interfaces.
Definition of done

Coordinate with Stu and get his help to add the teams to funnel
concept socialized with SecOps team
account set created
team onboarded

We may not do this if the outcome of #894 goes sideways.


SHA224 is not supported with clear Sign - getting unspported hash algorithm

Hi,
I am using ClearSignedFiledProcessor class to sign a file using Hash Algorithm  SHA224  ( HashAlgorithmTags.SHA224: ),  and getting the following  error.
java.io.IOException: unknown hash algorithm tag in beginClearText: 11
at org.bouncycastle.bcpg.ArmoredOutputStream.beginClearText(Unknown Source)
at com.b2b.pgp.security.ClearSignedFileProcessor.signFile(ClearSignedFileProcessor.java:285)
Looking at the ArmoredOutputStream  source,  I don't see support for SHA224.  Any reasons?
*/
public void beginClearText(
int    hashAlgorithm)
throws IOException
{
String    hash;
    switch (hashAlgorithm)
    {
    case HashAlgorithmTags.SHA1:
        hash = "SHA1";
        break;
    case HashAlgorithmTags.SHA256:
        hash = "SHA256";
        break;
    case HashAlgorithmTags.SHA384:
        hash = "SHA384";
        break;
    case HashAlgorithmTags.SHA512:
        hash = "SHA512";
        break;
    case HashAlgorithmTags.MD2:
        hash = "MD2";
        break;
    case HashAlgorithmTags.MD5:
        hash = "MD5";
        break;
    case HashAlgorithmTags.RIPEMD160:
        hash = "RIPEMD160";
        break;
    default:
        throw new IOException("unknown hash algorithm tag in beginClearText: " + hashAlgorithm);
    }

It wasn't part of the original standard. This has been merged and will be in 167b06 on https://www.bouncycastle.org/betas


[FEATURE REQ] Expose refresh interval in AzureKeyVaultConfigurationProvider

Azure.Extensions.AspNetCore.Configuration.Secrets
The internals of AzureKeyVaultConfigurationProvider support a refresh interval for polling against KeyVault, yet there's no way to actually set that value from the public API, due to the provider being internal and it seems the value is null by default (don't reload).
https://github.com/Azure/azure-sdk-for-net/blob/766d3c354ce4b35e4086be90cf9167f21f4062d1/sdk/extensions/Azure.Extensions.AspNetCore.Configuration.Secrets/src/AzureKeyVaultConfigurationProvider.cs#L33
Our use case is that we store a token in KeyVault that is used by our web app and that needs refreshing once a day. I have built a Azure function that refreshes this token well before the expiration. I would like this updated token to be available to my web app, using the AzureKeyVaultConfigurationProvider. This won't work if the provider doesn't fetch the newly updated secret from KeyVault though.
Am I missing something or is this not possible yet?

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

Thank you for the report. Seems we have missed this API when migrating the library.

Fixed in https://github.com/Azure/azure-sdk-for-net/pull/16254

Thanks!


Invalid date in traces generated by the plugin

The traces generated by the plugin has Last date as invalid, Please refer to the below screenshot:

It's difficult to figure traces based on timestamp, We need to manually choose each of them to find the relevant trace. It would be good to get the Correct Last Updated value

hi @gopalanand333
i can't reproduce this behavior (see below). please instruct how.

@sjvans

I have followed these steps: https://github.com/SAP-samples/btp-developer-guide-cap/blob/main/documentation/observability/3-implement-traces.md  to enable tracing.
These are the steps used for accessing the traces:  https://github.com/SAP-samples/btp-developer-guide-cap/blob/main/documentation/observability/4-deploy-to-cf.md


How do I know image finished loading?

How do I know image finished loading? You said directive have ability to know when all pre-loaded images have finished loading within the page

Hi Asimkt, I think you are referring to the comment in the README "Ability to know when all pre-loaded images have finished loading within the page". This is under TODO and not currently implemented.


helm chart is not available => 404

Bug Report
Helm chart releases in https://kubeovn.github.io/kube-ovn/index.yaml are pointing to https://github.com/kubeovn/kube-ovn/kube-ovn-1.12.4.tgz artifact instead of https://github.com/kubeovn/kube-ovn/blob/gh-pages/kube-ovn-1.12.4.tgz , this causes 404.

@lukasmrtvy Thanks for the report, the maintainer is still on vocation and we will try to fix it soon.

@lukasmrtvy Thanks. The index.yaml has beed updated.


When moving a run to a new project, its logged artifacts stay in the previous project

Describe the bug
When moving a run to a new project, its logged artifacts stay in the previous project.
To Reproduce
Steps to reproduce the behavior:

Log an artifact:

import wandb
wandb.init(project='test-project0')

artifact = wandb.Artifact('cities-names', 'cities')
with artifact.new_file('names.txt', 'w') as f:
    f.write('Moscow;Amsterdam;New York;')
wandb.log_artifact(artifact)

wandb.finish()

Then go to the project dashboard and move this run to another project, e.g. "test-project1".
Try to use the artifact in Colab (first, copy the run path and replace with variable run_path below):

past_run = wandb.Api().run(run_path)
logged_artifact = list(past_run.logged_artifacts())[0]
print('artifact project:', logged_artifact.project)
print('artifact name:', logged_artifact.name)

artifact project: test-project1
artifact name: cities-names:v0

then run
wandb.use_artifact(logged_artifact.project + '/' + logged_artifact.name)

Raises exception:
...
<lots of traceback>
...
CommError: Project sobir/test-project1 does not contain artifact: "cities-names:v0"

Expected behavior
I should be able to use the artifact

Hey @sobir-git
Thanks for the ticket and the repro steps!
Will help flag this internally :smile:

Hey @sobir-git
Thanks for the ticket and the repro steps!
Will help flag this internally :smile:

This is a good point, thanks for reporting this. I'm thinking this is a little complicated for us, because if you have a large project that relies on a set of artifacts, you might not expect an artifact to get moved/deleted with its parent run. I'll need to think more about the behavior here — we might need to add another feature to let you move artifacts between projects, and an option when moving runs to do that for all output artifacts.

This is a good point, thanks for reporting this. I'm thinking this is a little complicated for us, because if you have a large project that relies on a set of artifacts, you might not expect an artifact to get moved/deleted with its parent run. I'll need to think more about the behavior here — we might need to add another feature to let you move artifacts between projects, and an option when moving runs to do that for all output artifacts.

Hi @sobir-git, following up on this conversation. Could you tell us a little more about why you're moving runs between projects? Is this an organization issue that could perhaps be addressed by adding tags instead of moving runs?
For the moment we are sticking with the existing functionality — move a run, and any output artifacts stay in the original project.

Hi @sobir-git, following up on this conversation. Could you tell us a little more about why you're moving runs between projects? Is this an organization issue that could perhaps be addressed by adding tags instead of moving runs?
For the moment we are sticking with the existing functionality — move a run, and any output artifacts stay in the original project.

Hi @cvphelps, thanks the reply. The reason for moving runs was that I wanted to split a project into two. I had two slightly different kinds of runs that were making the dashboard complicated. So, actually the reason was to get separate dashboards for each kinds of runs. I think it's not an issue for me now, since I learned to use reports for this purpose.

Hi @cvphelps, thanks the reply. The reason for moving runs was that I wanted to split a project into two. I had two slightly different kinds of runs that were making the dashboard complicated. So, actually the reason was to get separate dashboards for each kinds of runs. I think it's not an issue for me now, since I learned to use reports for this purpose.

Bump
It would be nice for the artifacts to move to, or at least to have a way to move them. This has made it difficult for me because now when I want to collect runs and associated artifacts with the API I need to pull from two separate projects.

Could this be reopened?

Could this issue be reopened and can i know if this is on track to be fixed in the future versions? I think the behavior for artifacts should be similar to when we use wandb.save(), in which case the media and files are moved along with the run.

@dmitryduev Could you reopen this? I think this issue should not have been closed as stale. Having the ability to migrate artifacts together with their runs is an essential feature.

@cvphelps Here is my use-case:

Early in development, I tend to kick off a lot of short-lived jobs.
When a project is reaching maturity, I do a few long runs that I want to save.
It would be easiest just to move the good runs to another project and delete the entire old project, with the dev runs.

If there is a good workaround, let me know.

+1

+1

Also +1 to this. I think when you are moving a run to a new project it is logical behaviour that it's artifacts would move along with it, and dangerous it is not mentioned anywhere.
I think a prompt should be added to the "move run" action in the UI to inform the user of this, as I am currently facing a critical issue because of this unclear behaviour where runs were moved to a new project and the project was deleted, but it wasnt clear that the artifacts didnt move along with it and so were erroneously deleted.
Or if this behaviour could be added as a warning to the "move run" documentation (unless its already there and I missed it!) that would be great, can open a PR for it if needed. 🙏


Request path segments are potentially not percent-encoded

Percent decoding is done manually in deserialization, but in serialization the percent encoding is not done (manually). We should investigate whether percent encoding is ever done twice (once manually, once automatically) or left out completely (more likely I think), both of which would be bugs.

The reason serialization is different from deserialization is that for deserialization we are using Url from the url crate and then converting that to http::Uri, while for deserialization, we are using http::Uri directly. We are handling percent-encoding correctly though.


Project root directory settings for git_hook

When using the git_hook, it searches the settings on every base folder path of the files commited instead of keeping the settings of the root folder.
This fix provides a way that during a git commit, the git_hook search only in the root folder where the command has been run.
Let me know if I'm doing something wrong.

Hi @aRkadeFR,
Thanks for looking into how to improve the git_hook, the suggested solution can't be accepted simply because it will break existing isort plugins (specifically ones for text-editors) as it removes the ability to run isort from a plugin, and load the settings file the same as it would be if ran from the command line at the path of that file. I would however be open to an alternative solution, especially if it was limitted in scope to the git_hook itself. Or one that added an explicit option not to look up the settings path chain.
Thanks!
~Timothy

ok, thanks


Merge currently deployed changes

2023-06-21: devDeploy is live on mainnet
If roll-back is needed, deploy mainnet-deployed

Mainnet tests were successful


Update text extraction method and config parameters

Coverage remained the same at 36.63% when pulling 8502efe0d101bd25edf408cca6ddb868b60b03d5 on AlexMathew:scrapple into 62273a66db4842b6c1d9a9a531853f5c301b1980 on scrappleapp:master.


Remove tstypes dependency

tstypes is not on npm and adding types to mylas would make mylas smaller in devdependencies

fixed in 724c8e7f5e9998e1844ec4780b67780bebf6f02f
ready for next release


fix(app): Android deep link support for auth code ui

Signed-off-by: Talwinder kaur<EMAIL_ADDRESS>

Need to rebase this pr with the #429 support

Codecov Report
Patch and project coverage have no change.

Comparison is base (5ee15ba) 89.78% compared to head (88c123c) 89.78%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #430   +/-   ##
=======================================
  Coverage   89.78%   89.78%
=======================================
  Files          79       79
  Lines        2947     2947
=======================================
  Hits         2646     2646
  Misses        199      199
  Partials      102      102

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


Initial revision

Commenting here before I forget it, will include these changes later:
Typos in PWNJUTSU entry:

Overview:

which requires suitable datasets appropriate attacks
which requires suitable datasets containing appropriate attacks

Contained Data:

23
23rd


KAFKA-1834: No Response when handle LeaderAndIsrRequest some case

PR for KAFKA-1834
When a replica become leader or follower, if this broker no exist in assigned replicas, there are no response.

@tedxia, can you please close this PR since a patch was attached to JIRA (we can't do it ourselves without asking Apache Infra via a ticket)?


Date form type shows format instead of value

Laravel Version: 5.5.20
Voyager Version: 1.0.7
PHP Version: 7.1.10
Database Driver & Version: MySQL 5.7.19

Description:
Date form type shows the format instead of the value.
Screenshots:

Voyager uses the formatLocalized method from Carbon.
You need to use a different format as described here and in detail here

Thanks @emptynick !
But in the date picker's format does not follow the set format:

Maybe this can be added as a feature in the future.

Thanks @emptynick !
But in the date picker's format does not follow the set format:

Maybe this can be added as a feature in the future.

Thanks @emptynick !
But in the date picker's format does not follow the set format:

Maybe this can be added as a feature in the future.

Sounds like a documentation change is needed.


Can i set circle background for events ?

Can i set circle background for events ?
I want to set circle background instead of dot (event indicator style).

I was searching the same question and it appears that's possible!
Use the following code snippet:
calendarView.setEventIndicatorStyle(FILL_LARGE_INDICATOR);
You can choose between those 3 options:
 public static final int FILL_LARGE_INDICATOR = 1;     public static final int NO_FILL_LARGE_INDICATOR = 2;     public static final int SMALL_INDICATOR = 3;
FILL_LARGE_INDICATOR it's like today date selection, NO_FILL_LARGE_INDICATOR it's just a circle around the day and SMALL_INDICATOR it's de default one.
Hope it helps!


Release Google.Apps.Chat.V1 version 1.0.0-beta04

Changes in this release:
New features

Add doc for Discoverable Space support for GA launch (commit 53f49ef)

Documentation improvements

Update resource naming formats (commit 53f49ef)
Update doc for SetUpSpace in service ChatService to support group members (commit 7adcc7f)
Update doc for CreateMembership in service ChatService to support group members (commit 7adcc7f)
Update doc for field group_member in message google.chat.v1.Membership (commit 7adcc7f)
Update Chat API comments (commit 7e918d2)

Created release for Google.Apps.Chat.V1-1.0.0-beta04


Image as footer

Hi,
I tried to put an image as footer, but I only see the white space.
This is my code where I set footer:
page.property( 'paperSize', {               format:'A4',               footer:{                 height:"1cm",                 contents: ph.callback(function(pageNum, numPages) {                         if(pageNum != 1){                         return '';                         }                         return "

";                     })                 }             })
If I set label works, but with image doesn't.
Is there a way to do that?
Thanks.

I set img display none on my body and now work.


Fix recent changes error for incomplete data week comparisons

Closing this as revised requirements will be done in a separate pr.


Full support of custom keywords that mutate data

At the moment it requires too much effort. See https://github.com/epoberezkin/ajv/issues/141#issuecomment-270777250
There should be property "mutating: true" in custom keyword definition to make them work in all cases.

In 4.11.0 and 5.0.1-beta.1


Set up an s3 lake

[x] Set up an s3 bucket
[x] Organise sync between repo and s3

Checked that make inputs-pull and make inputs-push appear to work.


web submission temporary scripts get placed in the job's working directory

When I select a file for input to a simulation in web-based job submission, SOCA creates a temporary script in the same directory as that file.
This creates a lot of cruft that I have to clean up. Can SOCA put those scripts in a tmp location, maybe $HOME/soca_job_output/tmp?
I suppose there's a school of thought that the PBS script needs to be in $PBS_O_WORKDIR, but there isn't anything that requires that nor any benefit that I can think of. The primary requirement is that the script is accessible from rank 0. The PBS script will need to use $PBS_O_WORKDIR instead of dirname $0 to locate the working directory, which is what it should be doing anyway.

While I find the temp scripts in the working directory kind of annoying, my use case may be different and I can understand why somebody would desire the current behavior. Maybe add a form variable use_soca_tmp? When its value is 1 that tells SOCA that it should use $HOME/soca_job_output/tmp for temp files?

More thoughts on this.... it would be advantageous to put the tmp script under a timestamp directory, indicating the day it was created.
e.g.  $HOME/soca_job_output/tmp/job-scripts/2020-09-02 etc.

Hey Brian -
This creates a lot of cruft that I have to clean up. Can SOCA put those scripts in a tmp location, maybe $HOME/soca_job_output/tmp?
Definitely, but let me bring this idea to the internal community. I think it also make sense to keep the qsub file within the PBS_O_WORKDIR (for troubleshooting procedure).
With that said, you can definitely implement your custom path on your own clusters by editing https://github.com/awslabs/scale-out-computing-on-aws/blob/master/source/soca/cluster_web_ui/api/v1/scheduler/pbspro/job.py#L145


ng build writes to stderr on successful build causing automated build to fail

Please provide us with the following information:

OS?

Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)

Windows 10
Versions.

Please run ng --version. If there's nothing outputted, please run in a Terminal: node --version and paste the result here:

ng --version
                         _                           _  _

__ _  _ __    __ _  _   _ | |  __ _  _ __         ___ | |()
/  || '_ \  / _ || | | || | / ` || '|_  / __|| || |
| (| || | | || (| || || || || (| || |  |___|| ( | || |
_,||| || _, | _,||| _,|||          _|||||
|_/
angular-cli: 1.0.0-beta.25.5
node: 7.2.1
os: win32 x64
@angular/common: 2.4.3
@angular/compiler: 2.4.3
@angular/core: 2.4.3
@angular/forms: 2.4.3
@angular/http: 2.4.3
@angular/platform-browser: 2.4.3
@angular/platform-browser-dynamic: 2.4.3
@angular/router: 3.4.3
@angular/compiler-cli: 2.4.3
Repro steps.

Was this an app that wasn't created using the CLI? What change did you do on your code? etc.

Execute a powershell script remotely or from within Powershell ISE.
script contents:
Invoke-Expression "ng build"
The log given by the failure.

Normally this include a stack trace and some more information.

PS C:\development\somark\redeacted\client\redactedt> C:\Users\redacted\Documents\ngbuild.ps1
Hash: cbdcda25faeca314ca8a
Time: 6925ms
chunk    {0} main.bundle.js, main.bundle.map (main) 4.67 kB {2[22
m} [initial] [rendered]
chunk    {1} styles.bundle.css, styles.bundle.map, styles.bundle.map (styles) 1.
77 kB {3} [initial] [rendered]
chunk    {2} vendor.bundle.js, vendor.bundle.map (vendor) 2.61 MB [init
ial] [rendered]
chunk    {3} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entr
y] [rendered]
ng :   0% compiling 10% building modules 0/1 modules 1 active multi main
  10% building modules 1/1 modules 0
active 10% building modules 1/2 modules 1 active multi styles
         10% building modules 2/2 modules 0
active 10% building modules 2/3 modules 1 active
... removed for brevity
basic chunk optimization pass 3              77% chunk optimization 78% advanced chunk optimization 69% building modules 622/623 modules 1 active
...trident\client\trident\src\styles.css                                          70% building modules 623/623 modules 0 active
       79% module and chunk tree optimization                    80% module reviving 81% module order optimization
 82% module id optimization         83% chunk reviving 84% chunk order optimization    85% chunk id optimization
     86% hashing 87% module assets processing  88% chunk assets processing 89% additional chunk assets processing
        90% recording 91% additional asset processing    92% chunk asset optimization       94% asset optimization
 95% emitting
At line:1 char:1

ng build

  + CategoryInfo          : NotSpecified: (  0% compiling...     :String) [], RemoteException
  + FullyQualifiedErrorId : NativeCommandError

Mention any other details that might be useful.
It seems that successful builds are writing info to stderr.  This gets ignored from the command line and from powershell but not when running powershell script remotely or from within the Powershell ISE.
This has the result of breaking my CI build.
I get this error from a fresh install of angular-cli with a fresh new project using ng new.
I don't want to ignore errors within my script because when a real build error occurs it will be ignored.
NB:  the project builds and creates the dist folder and that blank app works.  This is just a problem for my automated build.

Thanks! We'll be in touch soon.

I don't know if it is related or not. I usually execute code like ng lint > lint.log and ng --version > version.log. Until day before yesterday, i was using ng serve to develop my application and from yesterday started using ng build --watch. When i was trying to report an issue related to ng build for beta25 i found that ng build > build-error.log was not working as indented. the output was always getting emitted in the terminal and the generated file content was always empty.

Would still be worthwhile investigating though.

having the same issue now using a bamboo build with the frontend-maven-plugin. ng build writes to stderr causing maven to generate an "[ERROR]" causing Bamboo Build to fail. i think this should be looked into. a build tool should not write to stderr on success.

Heya can you test this again with the latest build? I could output ng build > log.txt.
I did notice that progress logging still appeared on screen though... but for CI environments in general it's a good idea to turn it off via --no-progress.

angular-cli: 1.0.0-beta.26
node: 7.2.1
os: win32 x64
@angular/common: 2.4.4
@angular/compiler: 2.4.4
@angular/core: 2.4.4
@angular/forms: 2.4.4
@angular/http: 2.4.4
@angular/platform-browser: 2.4.4
@angular/platform-browser-dynamic: 2.4.4
@angular/router: 3.4.4
@angular/compiler-cli: 2.4.4
Tested with latest build
running ng build > log.txt still results in stuff being shown on the screen and failing the build with errors.  Running with the --no-progress switch turns this off and the build succeeds.

Hi, this is still an issue with RC 2 for Windows machines. Can you please update when this issue will be fixed?

Thanks for reporting this issue. This issue is now obsolete due to changes in the recent releases. Please update to the most recent Angular CLI version.
If the problem persists after upgrading, please open a new issue, provide a simple repository reproducing the problem, and describe the difference between the expected and current behavior.

running ng build via spawn process resulted in stdout being piped to stderr during automated build
adding --no-progress parameter resolved the issue for us
ng v1.4.1


Handling a BOM with .json()

Anybody know how I should be handling a BOM with a returned json payload? Right now i'm getting this error when calling res.json()
Exception: FetchError: invalid json response body at https://api_that_returns_json_with_bom reason: Unexpected token ? in JSON at position 0
I tried adding an Accept header of application/json; charset=utf-8 but that didn't resolve the issue.

Maybe something like this:
let text = await res.text()
if (text.charCodeAt(0) === 0xFEFF) {
  text = text.substr(1)
}
const json = JSON.stringify(text)

Just a quick question: is native browser fetch able to handle it?

I don't think BOM in JSON is valid, even if browsers might handles it. Going to label this as won't fix.
ref: https://stackoverflow.com/questions/4990095/json-specification-and-usage-of-bom-charset-encoding

let text = await res.text()
try {
return JSON.parse(text)
} catch(error) {
console.error("Error:", err);
}

How about this solution @jimmywarting

Hmm, chrome seems to be able to decode BOM
await new Response(String.fromCharCode(0xFEFF) + '1').json() // 1

What we are essentially doing is:
const buffer = Buffer.from(String.fromCharCode(0xFEFF) + '1'
JSON.parse(buffer.toString()) // Error

We should stop using buffer and turn towards using TextDecoder instead, this removes the BOM
JSON.parse(new TextDecoder().decode((Buffer.from(String.fromCharCode(0xFEFF) + '1'))))

While we are at it:
text() {
  let text = ''
  const decoder = new TextDecoder()
  for await (const uint8 of this.body) {
    text += decoder.decode(uint8, { stream: true })
  }
  text += decoder.decode() // flush
  return text
}

json() {
  return this.text().then(JSON.parse)
}

A more terse workaround:
const json = JSON.parse((await res.text()).trim());

I think calling trim() on a String of JSON should always be safe.

Actually i think using textencoder is the right way to handle it.

THis fixes it for me. was getting a BOM with authorize.net api and cloudflare workers:
		const data = JSON.parse((await res.text()).trim());


NFS Provisioner chart direction

There are several competing chart PRs for this, which take different approaches:

#3870
#2779
#2559

Let's discuss and choose the direction.

@kingdonb https://github.com/kubernetes/charts/pull/2559#issuecomment-371982949 seems to  support favoring #3870

I'll try summarise some differences, I'm going to refer to each PR by the number, and the authors name, in an attempt to make it easier to follow.
Automated vs Manual Provisioning

#2559 (@kingdonb) is manual provisioning of the NFS exports for use by volumes
#3870 (@kiall - aka me) and #2779 (@nbyl) are automated based on PVC creation / StorageClasses.

Based on $what container

#2559 (@kingdonb) is based on gcr.io/google-containers/volume-nfs
#2779 (@nbyl) is based on quay.io/external_storage/nfs-client-provisioner
#3870 (@kiall) is based on quay.io/kubernetes_incubator/nfs-provisioner

Honestly. I have no idea what the differences between each are.
Helm "Standards Compliance" / "Best Practice"

#2559 (@kingdonb) and #3870 (@kiall) appear to closely follow the current Helm Best Practice's
#2779 (@nbyl) is behind, and would need updating.

Deployment vs StatefulSet

#2559 (@kingdonb) and #2779 (@nbyl) both use a Deployment resource to deploy the NFS server.
#3870 (@kiall) uses a StatefulSet to deploy the NFS server.

Creating of matching StorageClass object to consume the NFS volumes

#3870 (@kiall) and #2779 (@nbyl) both will create the StorageClass by default (And, this creation is optional in #3870 (@kiall))
#2559 (@kingdonb) will not create the StorageClass resource..

I'm sure there are more differences. But this is probably a reasonable start.

Hi @kiall,
thanks for starting this thread to unify the existing proposals. Some thoughts on my behalf regarding the PRs.
NFS-Server

#2559 (@kingdonb) and #3870 (@kiall) both deploy a NFS server inside the cluster to be consumed by Pods.
#2779 (@nbyl) only deploys a provisioner for external NFS Shares like AWS EFS or some on-premise storage solution.

Deployment

As #2779 only the deploy the provisioner part, IMHO only a single instance inside the cluster is needed, because storage is provided externally.
If th NFS-Server is provided inside the cluster a highly available mechanism like in #3870 is a much better way.

StorageClass

Providing the optional creation of a storageclass seems like a better user experience to me.

So what would be way forward? I would currently prefer #3870 as it is more feature complete and uses the "official" image. But currently my main use case is not covered.
Maybe we can join forces. An idea would be to make the NFS server optional. In this case the user could provide some external NFS storage himself and only use the provisioning part.

So what would be way forward? I would currently prefer #3870 as it is more feature complete and uses the "official" image. But currently my main use case is not covered.

Is it the official image? I wasn't aware of the other 2 images when I wrote it, so, no idea :)

Maybe we can join forces. An idea would be to make the NFS server optional. In this case the user could provide some external NFS storage himself and only use the provisioning part.

If the general sentiment is to keep #3870 (@kiall) - then - lets see if we can make the NFS server optional, so it covers your use case. I can look at that late next week, but, if others get to it first - great. We can either just sync here until we get everything in order, or a PR could be sent to the branch #3870 is sourced from (https://github.com/kiall/kubernetes-charts/tree/add-nfs-provisioner-chart )
If the general sentiment is NOT to keep #3870 (@kiall) - then - I'm happy to collaborate anywhere that works.

I went digging to see what the differences are between the different images:

#2559 (@kingdonb) - gcr.io/google-containers/volume-nfs

Based on: https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs
Designed as a sample, not really intended  to be used as is - the NFS server container appears to put together purely to demonstrate how NFS PVs work within K8S - i.e. instead of the examples starting with "Go build a NFS server somewhere else", they start with "run this container".

#3870 (@kiall) - quay.io/kubernetes_incubator/nfs-provisioner

Based on: https://github.com/kubernetes-incubator/external-storage/tree/master/nfs
Designed to run the NFS server itself
Part of the K8S external-storage project.

#2779 (@nbyl) - quay.io/external_storage/nfs-client-provisioner

Based on: https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client
Designed to tie into an external NFS server
Part of the K8S external-storage project.

So - I actually think the differences between #3870 (@kiall - quay.io/kubernetes_incubator/nfs-provisioner) and #2779 (@nbyl - quay.io/external_storage/nfs-client-provisioner) warrant two different charts. Ideally, we'd try and make sure the distinction is made clear and keep things like naming as close and clear as possible - e.g. call the charts "nfs-server-provisioner" and "nfs-client-provisioner".

I've updated #3870 (@kiall) to call the chart nfs-server-provisioner, and included a note within the README.md pointing towards the nfs-client provisioner within the external-storage project. Assuming both charts merge, the README.md's should be updated to cross-reference each other.

This discussion is awesome, I wish I got here sooner!
Can I offer to review both charts, or is there a clear winner, or ... someone mentioned that this might be warranting of two separate charts, I think I figured that out as well during my own attempt at this
it looks like one of your implementations is only a Client (expects an outside provider of the NFS resource), whereas the other one is both Client and Server (@kiall actually provisions a NFS server using StatefulSet)  Is that a valid characterization?
The amount of writeup here and discussion of the differences between all three PRs is really fantastic, I am so glad there are options now, because this has been an itch I've needed to scratch!

it looks like one of your implementations is only a Client (expects an outside provider of the NFS resource), whereas the other one is both Client and Server (@kiall actually provisions a NFS server using StatefulSet) Is that a valid characterization?

Kinda :) #2779 (@nbyl) expects an external NFS server to exist, yes. And #3870 (@kiall) expects to manage it's own NFS server inside the cluster, but it doesn't offer a clean way to tie into an existing NFS server[1].

Can I offer to review both charts, or is there a clear winner, or ... someone mentioned that this might be warranting of two separate charts, I think I figured that out as well during my own attempt at this

In my opinion, #3870 (@kiall) and #2779 (@nbyl) both serve different purposes, both use different+supported external-storage subprojects, and both should be reviewed + merged. i.e. I don't think there is as much overlap between the charts as there might seem at face value.
[1]: It looks like #3870 (@kiall) can tie into another server at face value, but in reality, it can only tie into a server that's running in the same pod (or same machine if ran outside K8S) - which isn't all that useful when running inside K8S.

The amount of writeup here and discussion of the differences between all three PRs is really fantastic, I am so glad there are options now, because this has been an itch I've needed to scratch!

Huge +1, thanks for all the discussion @kiall, @nbyl, @kingdonb & @scottrigby .
There's been some interest in an NFS provisioner to make the WordPress chart scalable in https://github.com/kubernetes/charts/pull/5009 and #5049 , so I'm interested in making a decision here.
I suggest closing out #2559 (@kingdonb) and #5049 (@vtuson) in favour of the StorageClass/provisioner approach.
I agree that both #3870 (@kiall) and #2779 (@nbyl) should exist as different options so I suggest we work on getting these reviewed and merged.

I closed #2559 because I don't think it has anything to offer that the other #3870 and #2779 don't offer

@prydonius - makes sense to me!

It looks like PR #3870 was merged, and #2779 was closed in favor of #6433 which has also been merged now.
I'm not sure there's any reason to keep this issue open anymore!  It looks like we have a chart that can be used to make PVCs against a backing ReadWriteOnce, and make them available via NFS to ReadWriteMany, ... then another chart that can take an existing NFS service and access it as a PV via PVC.
Can anyone who has used both charts comment on whether there are any gaps remaining between them?

One uses https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client - the other is for https://github.com/helm/charts/tree/master/stable/nfs-server-provisioner .
I actively use the client one myself. The main difference is that one provides a NFS server - while the client one is based on the availability of an already provided NFS server outside of Kubernetes.
Yes I think this issue should be closed.

I'm reading the READMEs now.  Trying to decide if it's possible to use them together... it seems like it should be!
The point of #2559 was originally supposed to be to provide a way for ReadWriteMany PVCs to consume a single PV block device over NFS.  It vaguely looks like stable/nfs-client-provisioner does that pretty handily.
I haven't really been following these closely, but now that they are both merged I have some issues with the documentation of at least the client chart.  But if so that is a separate issue, I'll reopen separately.  So I'll go ahead and test some more, but...
I vote in favor of closing #4142.


Integ2

Huge update. This adds sync between all goroutines. It adds a bunch of bug fixes for race conditions and some functional rough edges. This adds a new feature allowing parameter extractions and map/string lookups.

works!


"console: FileRead(): SSL error on fd 3" on Rocky Linux

On a recently fresh installation of Rocky Linux I often get disconnected like:
# console n061901
[Enter `^Ec?' for help]
console: FileRead(): SSL error on fd 3
# echo $?
0

This is both the case with 8.2.2-4 provided by EPEL as well as a self-compiled 8.2.6 from a customized SPEC file.
Currently, this version of OpenSSL is installed:
# yum list installed | grep openssl
openssl.x86_64                              1:1.1.1k-5.el8_5                       @baseos
openssl-devel.x86_64                        1:1.1.1k-5.el8_5                       @baseos-85
openssl-libs.x86_64                         1:1.1.1k-5.el8_5                       @baseos
openssl-pkcs11.x86_64                       0.4.10-2.el8                           @baseos

Disabling SSL support during compilation only removes the error message but still disconnects:
# console n061901
[Enter `^Ec?' for help]
# echo $?
0

Any thoughts where to start debugging? If necessary I can share my configuration.
conserver.spec.txt
conserver-nokrb-noopenssl.spec.txt

More information: If I run ipmiconsole -u ADMIN -p PASSWORD -h n061901 the disruption of the connection does not happen.

Well, now I also get [-- Conserver reconfigured - console has been (re)moved --] instead of console: FileRead(): SSL error on fd 3…

We have the exact same behaviour on Rocky Linux 8

@UweSauter do you still see the issue ?

@faxm0dem Yes, I do. Currently I have installed:
# yum list installed | grep -e conserver -e openssl
conserver.x86_64                            8.2.7-1.el8                              @@commandline
conserver-client.x86_64                     8.2.7-1.el8                              @@commandline
openssl.x86_64                              1:1.1.1k-9.el8_7                         @baseos-87
openssl-devel.x86_64                        1:1.1.1k-9.el8_7                         @baseos-87
openssl-libs.x86_64                         1:1.1.1k-9.el8_7                         @baseos
openssl-pkcs11.x86_64                       0.4.10-3.el8                             @baseos-88

The disconnects happen most often during the BIOS phase of a server reboot up until the login prompt is shown. Could it be that some special symbols transferred via IPMI and the sent through the conserver <-> console connection trigger this?

I get disconnects all the time, but at random times.
For instance, I just up a console and afer a few seconds I get a disconnect.

This also happens in RHEL8.
However, RHEL9 works just fine !


AWS Spring cloud map support (with AWS SDK v2)

Support for integrating with AWS Cloudmap
:loudspeaker: Type of change

[ ] Bugfix
[x] New feature
[ ] Enhancement
[ ] Refactoring

:scroll: Description

This pull request adds support for integrating spring boot application with AWS cloudmap. Here is an example of how an simple properties file integration looks like for both cloudmap registration and discovery
spring.cloud.aws.cloudmap.region=us-east-1
spring.cloud.aws.cloudmap.enabled=true
spring.application.name=cloudmap-namespace-here

# Discover existing cloudmap instances
spring.cloud.aws.cloudmap.discovery.failFast=false
spring.cloud.aws.cloudmap.discovery.discoveryList[0].service=TestService
spring.cloud.aws.cloudmap.discovery.discoveryList[0].nameSpace=ECS-CloudMap

# Register new instance
spring.cloud.aws.cloudmap.registry.description=Namespace for sample cloudmap registry service
spring.cloud.aws.cloudmap.registry.port=80
spring.cloud.aws.cloudmap.registry.service=a-service
spring.cloud.aws.cloudmap.registry.nameSpace=a-namespace

The property file is optional, any application can easily register themselves to cloudmap by adding spring-cloud-starter-aws-cloudmap dependency to pom or gradle files, here is a example:
<dependency>
  <groupId>io.awspring.cloud</groupId>
  <artifactId>spring-cloud-starter-aws-cloudmap</artifactId>
</dependency>

:bulb: Motivation and Context

Adds support for cloudmap integration with spring boot applications for both service registry and discovery #5
:green_heart: How did you test it?
I executed the following tests:

Ran unit test cases and made sure nothing failed
Deployed the sample spring boot app checked in part of this pull request in ECS, EKS fargate instances. The application could successfully discover and register the application to AWS cloudmap.

:pencil: Checklist

[x] I reviewed submitted code
[x] I added tests to verify changes
[x] I updated reference documentation to reflect the change
[x] All tests passing
[x] No breaking changes

:crystal_ball: Next steps
Code review and merging code to 3.x branch

Thanks @hariohmprasath. I'll do some polishing and very likely come back to you with some questions. In meantime, there are 3 things missing:

reference documentation
infrastructure for running a sample - or an instruction how to run the sample (I guess it's not possible to run it with Localstack)
nullability annotations & package-info.java.

There are quite a few unused fields that I am not sure if just should be deleted or some parts of implementation is still missing.
Missing integration tests stopped me from doing further refactoring. If we can't test against Localstack, we should mock AWS API and perhaps use Wiremock to stub EC2/ECS endpoints.
I feel like the CloudMapUtils class is the center of this implementation and ideally we would refactor it to avoid having so much logic in the util class - but this can or even has to wait until we have integration tests so that we can refactor safely.
@hariohmprasath would you be willing to address these issues? In case I am missing something, your opinion is appreciated.

Thanks for reviewing the code @maciejwalkowiak, let me start addressing some of the comments and we can sync up based on the changes

Reference documentation added, package-info with nullability annotation added, no infrastructure required if cloudmap namespace or service doesnt exist the cloudmap connector module will automatically create them

There are quite a few unused fields that I am not sure if just should be deleted or some parts of implementation is still missing.
Missing integration tests stopped me from doing further refactoring. If we can't test against Localstack, we should mock AWS API and perhaps use Wiremock to stub EC2/ECS endpoints.
I feel like the CloudMapUtils class is the center of this implementation and ideally we would refactor it to avoid having so much logic in the util class - but this can or even has to wait until we have integration tests so that we can refactor safely.
@hariohmprasath would you be willing to address these issues? In case I am missing something, your opinion is appreciated.

Thanks for reviewing the code @maciejwalkowiak, let me start addressing some of the comments and we can sync up based on the changes

@maciejwalkowiak, The last commit that I pushed in has code changes to mock the required HTTP responses. So we can use these tests as a reference for further refactoring. Since CloudMap is not supported in CloudMap you may need to connect with AWS using credentials to run this sample.
It just requires the following environment variables to be set before running the sample application:
AWS_ACCESS_KEY_ID=<key>
AWS_REGION=us-east1
AWS_SECRET_ACCESS_KEY=<secret>
DEPLOYMENT_PLATFORM=ECS

Update CloudMapUtils.getEcsRegistrationAttributes(), comment out line between 536 to 547 and return hard-coded ipAddress and vpcId, this is all you need to pretty much to run this sample.

@hariohmprasath thanks for an update. We still need to have an integration test that checks everything all together. Something like ParameterStoreConfigDataLoaderIntegrationTests - does not need to use SpringApplication, can just use Spring testing framework capabilities, but it has to give us confidence that when details change, the integration still works.
Considering it's not possible to use Localstack for that, either we need to mock responses from AWS or run the test against real AWS and spin up resources with Cloudformation. I can imagine this is quite a bit of work but we just cannot merge the integration lacking solid test coverage.

@hariohmprasath thanks for an update. We still need to have an integration test that checks everything all together. Something like ParameterStoreConfigDataLoaderIntegrationTests - does not need to use SpringApplication, can just use Spring testing framework capabilities, but it has to give us confidence that when details change, the integration still works.
Considering it's not possible to use Localstack for that, either we need to mock responses from AWS or run the test against real AWS and spin up resources with Cloudformation. I can imagine this is quite a bit of work but we just cannot merge the integration lacking solid test coverage.

Hi @maciejwalkowiak,
Thanks for reaching out to localstack team regarding the support. I had a chance to catch up on their response and based on that I have submitted an enhancement (https://github.com/testcontainers/testcontainers-java/issues/5838) + PR (https://github.com/testcontainers/testcontainers-java/pull/5839) to support AWS CloudMap  for localstack module in testcontainers project.
Once the enhancement and PR gets approved I can use the same to add the required integration test cases. Hope this works for you, let me know your thoughts. Thanks

@hariohmprasath sounds like the way to go!

Hi @maciejwalkowiak,
I have added integration tests to test service discovery and registration for both the platforms (ECS and EKS).

EcsCloudMapIntegrationTest.java - Integration tests for ECS platform
EksCloudMapIntegrationTest.java - Integration tests for EKS platform

Note: Since CloudMap service is only enabled for pro version of LocalStack make sure to create an API Key (either using trial mode or buying a subscription), update the key in IntegrationTestUtil.LOCAL_STACK_API_KEY variable before running the integration tests.

Hopefully this should make things easier for testing, let me know if you want me to update anything. Thanks and appreciate your support for this PR.

Hi @maciejwalkowiak, Just checking to see whether you had a chance to review the changes, let me know if you have any questions/suggestions. Thanks

@hariohmprasath not yet unfortunately but it's still high in my priority list so don't worry - it won't be ignored :-)

Hi @maciejwalkowiak,
Hope you are doing great. Any tentative timeline when this support will be released? Thanks

@hariohmprasath apologies again, but we didn't find enough time to include it in 3.0.
3.0 will be released in April, CloudMap is planned for 3.1, so Q2/Q3 2023.

Sounds good, thanks for letting me know

Hi @maciejwalkowiak, Would love to get this merged by early 2024 :)

We are interested in using this integration as well. What needs to be done to get this reviewed and merged, and how could we help with that process?

Hi @maciejwalkowiak, The PR was created on Sep 4, 2022, probably 2 years back :) Any plans to merge it part of a mainline or release?

+1

Again apologies for postponing it for so long. I'll get some support and we will get it through.


Finalize hook

Provides task to inherit from in order to provide easy hooks for additional processing after export provider tasks have run, but before run containing the providers has been finalized.
Stores any file produced in these tasks in the same location as ExportTask's results.
Added task factory create_finalize_run_task_collection() & wired into TaskFactory.parse_tasks().
Updated integration tests with timeout and additional output to help find issues when they arise.
Tasks can be hooked into finalize processing by:

Write a task with the following args:

@app.task(bind=True, base=FinalizeRunHookTask)
def my_task(self, new_zip_filepaths=[], run_uid=None):
    return [new_file_created_in_this_task]

Add my_task to create_finalize_run_task_collection's hook_tasks

Looks like one of the ExportProvider tasks is slipping through and finishing before the cancel takes effect.  Worth delaying a merge to update that test?


UnknownHostException: kubernetes.default.svc

Trying to work with DiscoveryClient i have:
1º @EnableDiscoveryClient
2º  @Autowired private DiscoveryClient discoveryClient;
3º List instances = discoveryClient.getInstances(myServiceName);
However i get UnknownHostException: kubernetes.default.svc
Otherwise if i do not @EnableDiscoveryClient then i have no errors but i get always 0 instances. While i can see my service has 1 pod associated.
Can ou give me some hints?

I solved this passing an environment variable to the pod with the name of the kubernetes service.
name: KUBERNETES_MASTER
value: kubernetes

Do you have the Kubernetes DNS addon deployed? It's a pretty essential part of any Kubernetes deployment nowadays so I'd recommend it if you don't.