testcase for broken Header\AbstractAddressList::fromString

Problem:

GenericHeader loads the header in file, decodes it to utf-8
the Headers::get attempts to Lazy-Load "To" header class

Lazyload does stringify and load in from string
$encoding = $current->getEncoding();
$headers  = $class::fromString($current->toString());

However, toString does not encode comma
AND To header class does split on comma!
see \Zend\Mail\Header\AbstractAddressList::fromString
this PR shows only the problem.

toString invocation path:

GenericHeader::toString
GenericHeader::getFieldValue
HeaderWrap::wrap
HeaderWrap::wrapUnstructuredHeader
HeaderWrap::mimeEncodeValue
[Mime::encodeQuotedPrintableHeader]
[Mime::_encodeQuotedPrintable]
... it got scary here

perhaps the fix is in zend-mime project:
https://github.com/zendframework/zend-mime/pull/26
if it gets accepted!

after https://github.com/zendframework/zend-mime/pull/26 being applied,
such code with Zend\Mail:
$headerLine = 'To: "=?iso-8859-1?Q?W=2C_bj=F8rn?="<EMAIL_ADDRESS>echo Mail\Header\GenericHeader::fromString($headerLine)->toString();

before:
To: =?UTF-8?Q?"W,=20bj=C3=B8rn"=20<user@example.org>?=

now:
To: =?UTF-8?Q?"W=2C=20bj=C3=B8rn"=20<user@example.org>?=

and
// with headerline without comma:
$headerLine = 'To: =?UTF-8?Q?"W=2C=20bj=C3=B8rn"=20<user@example.org>?=';
echo Mail\Header\To::fromString($headerLine)->toString();

To: =?UTF-8?Q?"W=2C=20bj=C3=B8rn"?=<EMAIL_ADDRESS>

@weierophinney closed this in zendframework/zend-mime@73e6d05 15 days ago
this is not correct. reopen please.

@glensc I think I'm not understanding something.
The original string includes an encoded comma (=2c).
Why should the comma NOT be encoded when the To header is cast to a string? Is it because of the different encodings (iso-8859-1 vs UTF-8)?
(I need to understand why your expectation should be the expected behavior, basically.)

@weierophinney it's combination of these two statements from Pull Description:

However, toString does not encode comma
AND To header class does split on comma!

so, this seemed the simplest way to solve the problem. it's not forbidden to zealously encode
as https://github.com/zendframework/zend-mime/commit/73e6d05 was accepted in https://github.com/zendframework/zend-mime/pull/26
this just updates unit test data.

This repository has been moved to laminas/laminas-mail. If you feel that this patch is still relevant, please re-open against that repository, and reference this issue. To re-open, we suggest the following workflow:

Squash all commits in your branch (git rebase -i origin/{branch})
Make a note of all changed files (`git diff --name-only origin/{branch}...HEAD
Run the laminas/laminas-migration tool on the code.
Clone laminas/laminas-mail to another directory.
Copy the files from the second bullet point to the clone of laminas/laminas-mail.
In your clone of laminas/laminas-mail, commit the files, push to your fork, and open the new PR.
We will be providing tooling via laminas/laminas-migration soon to help  automate the process.


Avoid pattern matching in multiple inheritance

Hi,
is there a way to avoid these pattern matching ?
the code that will be used to adapt :
public bool MapToDto(TEntity input, out TDto output)
{
    output = input.Adapt<TEntity, TDto>();
    return true;
}

By default, I don't want it to be mapped to Dtos directly.

I think you can remove ConstructUsing.
You can also generate Include from types;
var config = TypeAdapterConfig<ItemInstance, ItemInstanceDTO>.NewConfig();
var models = typeof(ItemInstance).Assembly.GetTypes().Where(it => it.Namespace == "Your.Domains");
var dtoDict = typeof(ItemInstanceDTO).Assembly.GetTypes().Where(it => it.Namespace == "Your.DTOs").ToDictionary(it => it.Name);
foreach (var model in models) {
    var dto = dtoDict.GetValueOrDefault(model.Name + "DTO");
    if (dto != null) {
        config.Settings.Includes.Add(new TypeTuple(model, dto));
    }
}

var mappedDto = entity.Adapt<ItemInstance, ItemInstanceDTO>();

var gameObj = (Game.Items.Instance.ItemInstance)mappedDto;

Without the ConstructUsing, this code would end up in a throw, safe cast would end up in a null returned value
Also, using .Include<> work, but by default, except for the class "ItemInstance" which is the one I expect instead of ItemInstanceDTO
TypeAdapterConfig<ItemInstance, ItemInstanceDTO>.NewConfig()
    .Include<ItemInstance, Game.Items.Instance.ItemInstance>()
    .Include<WearableInstance, Game.Items.Instance.WearableInstance>()
    .Include<SpecialistInstance, Game.Items.Instance.SpecialistInstance>()
    .Include<BoxInstance, Game.Items.Instance.BoxInstance>();

All this is to prevent adding hard dependency to my game logic assembly inside my DataAccessLayer assemblies.

There are 2 ways.

Change ItemInstanceDTO to Game.Items.Instance.ItemInstance and remove Include.

TypeAdapterConfig<ItemInstance, Game.Items.Instance.ItemInstance>.NewConfig()
    //.Include<ItemInstance, Game.Items.Instance.ItemInstance>()
    .Include<WearableInstance, Game.Items.Instance.WearableInstance>()
    .Include<SpecialistInstance, Game.Items.Instance.SpecialistInstance>()
    .Include<BoxInstance, Game.Items.Instance.BoxInstance>();

Move ItemInstance to last item.

TypeAdapterConfig<ItemInstance, ItemInstanceDTO>.NewConfig()
    .Include<WearableInstance, Game.Items.Instance.WearableInstance>()
    .Include<SpecialistInstance, Game.Items.Instance.SpecialistInstance>()
    .Include<BoxInstance, Game.Items.Instance.BoxInstance>()
    .Include<ItemInstance, Game.Items.Instance.ItemInstance>();


Transfer rules_go to bazel-contrib

Description:
This issue proposes transferring the rules_go repository from the bazelbuild GitHub organization to the bazel-contrib GitHub organization, which is owned by the Community for Bazel project under the Linux Foundation.
GitHub Discussion: https://github.com/orgs/bazelbuild/discussions/2
Impacts:

GitHub issues & PRs will be transferred to the new repository.
Branch protection rules will need to be transferred to the new repository.
Individual maintainers will be transferred to the new repository.
GitHub teams will NOT be transferred to the new repository and will need to be re-created.
Bazel CI configurations will need to be updated to point to the new repository.

Read more on Transferring a repository from GitHub documentation.
Checklist:

[x] Obtain approval from the current project maintainers (@bazelbuild/go-maintainers).
[x] Obtain approval from the bazel-contrib SIG (@alexeagle).
[x] Initiate the transfer process on GitHub (@meteorcloudy).
[x] Update Bazel CI settings and confirm presubmit & postsubmit work (@meteorcloudy).

Notes from SIG meeting: this transfer was unanimously approved by a thumbs-up vote.

I approve for @bazelbuild/go-maintainers

Do we need approvals from other go maintainers? I'll first create a @bazel-contrib/go-maintainers team and invite the same members.

@bazel-contrib/go-maintainers is now created and I granted @fmeum maintainer role.

Transfert this repository to another org will change the import path of the Go library github.com/bazelbuild/rules_go/go/runfiles.
Will this module rename in the go.mod be made at the same time?

Assuming that the redirect remains in place, we should be able to make it after the transfer, before the next release.

It's perfect. Thanks

Transfer is done, Bazel CI has been updated, let me know if there is any problem.


run task returns as soon as the main thread of your app exits

problem
From discord thread https://discord.com/channels/632150470000902164/922600050989875282/925483273419890789

SBT 1.6.0 (which I upgraded to to stop getting the annoying TrapExit deprecation warnings on Java 17) seems to return from the run task as soon as the main thread of your app exits. Which seems potentially a bit weird when running e.g. an akka-http app that starts up an http server in the background threadpool, and exits the main thread...
Wondering if there's a workaround for this, or other suggestions? I was thinking we could block the main thread on the lifetime of the actor system with a Await.ready(system.whenTerminated, Duration.Inf) at its end?

expectation

The run task should only return when all the threads from created from the app end. This was the behavior in sbt 1.5.6
notes
Looks like the removal of TrapExit introduced this regression, because TrapExit besides trapping the exit signal was also handling the waiting of threads ending (see deleted method waitForExit in https://github.com/sbt/sbt/pull/6665/files#diff-f6dd9c717690ab2adbd6b977d576e8ce45db4a51ba2dfcf66610774dd30fa5f7L200-L215)

@eed3si9n do you think this should be fixed by reverting the removal of TrapExit and just get rid of the SecurityManager usage? Or should we instruct users to use fork or make the main thread wait?

I think trapping exit should go away (since it's not possible afaik), but we can resurrect waiting for thread part as some function that gets called.

Perhaps related to this: I get sporadic dots before getting to the sbt shell after trying exit the REPL started via console, requiring an inconvenient extra press on Enter before getting the sbt promp. This is in sbt 1.6.1:
sbt:gist> console
Welcome to Scala 3.1.0 (11.0.13, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
scala> :quit
[success] Total time: 7 s, completed Dec 30, 2021, 11:27:34 AM
…   // these three dots shown sometimes; must press Enter to exit to sbt shell
sbt:gist>

we can resurrect waiting for thread part as some function that gets called.

That sounds good, since it makes the behavior of run more similar to running your application as a separate JVM process.
I wonder if it is possible, though - it looks like we're also using the SecurityManager to track which threads belong to the application (https://github.com/sbt/sbt/pull/6665/files#diff-f6dd9c717690ab2adbd6b977d576e8ce45db4a51ba2dfcf66610774dd30fa5f7L461-L472 in TrapExit.scala), and I suspect we don't want to go back to that - is there another way to achieve the same?

At least for run an easy (but slow) workaround would be to fork.

I don't know if it's related to this issue but when I update sbt to v1.6.1 from v.1.5.8, my CI (Github Action) doesn't fail anymore when my tests fail. The CI is green but the tests inside failed.

@guizmaii That does not sound good. Could you file a separate issue for that with repro steps please?

@eed3si9n My issue might be related to a combination of changes in sbt 1.6+ and how the "compile time" sbt plugin implemented for Caliban works.
A fix has just been merged in the plugin (see: https://github.com/ghostdogpr/caliban/issues/1240 and https://github.com/ghostdogpr/caliban/pull/1236).
A version of Caliban containing the fix will be released soon, so I'll be able to test again with the fix to see if I still have the issue.


Change the way suggestions are displayed

As suggested in issue #31 I think we should move away from a popup and instead expand out the warnings that appear to show more information on the warning.

I might just try to take a quick look at this as part of a 24 Pull Requests event! First time looking at an issue on an open source project... :)

@piperhaywood Welcome to open source! And great, go for it. If you wanna discuss anything lengthy or overly technical feel free to do so here, its good to have a paper trail - for more quick questions which maybe don't need to be on github https://gitter.im/basicallydan/forkability is better :) me and @m-zuber often hang out there.
Also, thanks for showing an interest in contributing!

I second @basicallydan.
Welcome to the wonderful world of open source.
Happy to help out with anything you need.
p.s. feel free to ping me if you are interested in help on other projects as well

@basicallydan @M-Zuber Thanks very much! Got a little ways with it yesterday, I'm hoping to take a further look at it shortly and submit a PR later this week :)

Great! Thank you for the update.
If you want any feedback on the code,  even if you think it is not ready to merge,  just open a PR with [WIP] in the title

:+1: to @M-Zuber's comment.

Hello @piperhaywood,
Just checking in. I am aware that there is such a thing as life, so please do not feel pressured.

Thanks for checking in! I've been visiting my folks in the states for
the holidays and have been pretty lax with projects and such. Will try
to take a look when I'm back!

Piper Haywood
+44 (0)7522 542616
piperhaywood.com
sbphstudio.com
On 27/12/2015 09:17, Mordechai Zuber wrote:

Hello @piperhaywood https://github.com/piperhaywood,
Just checking in. I am aware that there is such a thing as life, so
please do not feel pressured.
—
Reply to this email directly or view it on GitHub
https://github.com/basicallydan/forkability/issues/32#issuecomment-167419763.

@piperhaywood No problem, I've been in almost exactly the same position. Hope you had a good break :+1:

Have fun!!


Made 1.20 possible

Tryna' help, and need friendz so this is a 2 in 1

I've already done this, but for me everything is currently having graphical issues, can you replicate?

I'll merge, but #34  is needed to make 1.20 work


Jupyter-scala kernel does not work

It seems that jupyter-scala does not work in hydrogen.
I installed the jupyer-scala as described on its github site and verified it works with ipython.
In hydrogen settings I tried to map the scala language to scala211: {"Scala":"scala211"}
But then I get the following error:
[Enter steps to reproduce below:]
**Atom Version**: 1.0.19
**System**: Mac OS X 10.10.5
**Thrown From**: [hydrogen](https://github.com/willwhitney/hydrogen) package, vundefined

### Stack Trace

Uncaught TypeError: Cannot read property 'name' of undefined

At /Users/krikava/.atom/packages/hydrogen/lib/watch-sidebar.coffee:10

TypeError: Cannot read property 'name' of undefined
  at new WatchSidebar (/Users/krikava/.atom/packages/Hydrogen/lib/watch-sidebar.coffee:10:59)
  at new Kernel (/Users/krikava/.atom/packages/Hydrogen/lib/kernel.coffee:23:29)
  at Object.module.exports.KernelManager.startKernel (/Users/krikava/.atom/packages/Hydrogen/lib/kernel-manager.coffee:121:22)
  at /Users/krikava/.atom/packages/Hydrogen/lib/main.coffee:255:44
  at /Users/krikava/.atom/packages/Hydrogen/lib/config-manager.coffee:23:13
  at Object.module.exports.portfinder.findManyHelper (/Users/krikava/.atom/packages/Hydrogen/lib/find-port.coffee:21:13)
  at /Users/krikava/.atom/packages/Hydrogen/lib/find-port.coffee:26:18
  at Server.<anonymous> (/Users/krikava/.atom/packages/Hydrogen/lib/find-port.coffee:14:21)
  at Server.g (events.js:260:16)
  at emitNone (events.js:67:13)
  at Server.emit (events.js:166:7)
  at emitCloseNT (net.js:1495:8)
  at doNTCallback1 (node.js:427:9)
  at process._tickCallback (node.js:349:17)

### Commands

     -0:39 application:new-file (ol.tree-view.full-menu.list-tree.has-collapsable-children.focusable-panel)
     -0:30.8.0 settings-view:open (atom-text-editor.editor.is-focused)
  2x -0:17.8.0 core:move-left (atom-text-editor#Hydrogen.languageMappings.editor.mini.is-focused)
     -0:15.1.0 core:move-right (atom-text-editor#Hydrogen.languageMappings.editor.mini.is-focused)
     -0:13.9.0 core:move-left (atom-text-editor#Hydrogen.languageMappings.editor.mini.is-focused)
     -0:11.6.0 core:move-right (atom-text-editor#Hydrogen.languageMappings.editor.mini.is-focused)
     -0:10.8.0 core:save (atom-text-editor#Hydrogen.languageMappings.editor.mini.is-focused)
     -0:07.7.0 command-palette:toggle (atom-text-editor.editor.is-focused)
     -0:06.1.0 core:confirm (atom-text-editor.editor.mini.is-focused)
     -0:06.1.0 set-syntax:Scala (atom-text-editor.editor)
     -0:03.8.0 core:paste (atom-text-editor.editor.is-focused)
     -0:02.5.0 hydrogen:run (atom-text-editor.editor.is-focused)

### Config

{
  "core": {
    "themes": [
      "one-dark-ui",
      "solarized-dark-syntax"
    ]
  }
}

### Installed Packages

# User
Hydrogen, v0.6.3
autocomplete-paths, v1.0.2
ever-notedown, v0.2.11
file-type-icons, v0.7.3
language-latex, v0.6.1
language-scala, v1.1.3
latex, v0.26.0
open-recent, v2.3.0
set-syntax, v0.3.0

# Dev
No dev packages

Then I just changed the kernel settings and retied, This time it hangs while Atom is eating all the CPU.
I see "scala kernel: starting", but nothing happens. Neither seems to do any interrupt and restart actions.

On 15/10/15 21:39, Filip Krikava wrote:

I installed the jupyer-scala as described on its github site and verified it works with ipython.
In hydrogen settings I tried to map the scala language to scala211: |{"Scala":"scala211"}|

I think it should be the other way around: |{"scala211":"scala"}|
I don't know why Hydrogen doesn't complain it can't find a kernel.

look to kernel errors in developer console, it should help

OK, I figured out what's going on. The end result is that Hydrogen is asking Atom for a grammar named "scala211", and of course there isn't one. This is my bad. 20265df2619dfd3a354be52b8652431637bd5ae7 fixes this problem.
However, I'm trying to get the Scala kernel running in Hydrogen right now, and it seems to really not ever send a message beyond saying it's starting. It works in the notebook, though. I'm not sure what difference between Hydrogen and the notebook causes this. Perhaps the kernel is sending information on the wrong channel?

[14:12:35] will@MacBook-Pro /Users/will/code/hydrogen/ (master|✔ ) $ apm publish patch
Preparing and tagging a new version ✓
Pushing v0.6.4 tag ✓
Publishing<EMAIL_ADDRESS>✓

@willwhitney were you able to resolve this?

I'd love to get this working as well, but developer console just shows kernel starting, and that's it. Any update?

@sbromberger @tylerprete even if hydrogen is patched to find scala211 kernel didn't answer after starting event as was mentioned here: https://github.com/willwhitney/hydrogen/issues/121#issuecomment-148939094. You can test this behavior — just change your kernel json to
 "language" : "scala",
  "display_name" : "Scala 2.11",
...

So this is kernel specific bug, try to creating issue on it's own page.

@terraqout I got the kernel association working by putting {"scala211": "scala"} in the Hydrogen Language Mappings. That's not the issue. The issue is https://github.com/willwhitney/hydrogen/issues/121#issuecomment-148939094 - are you suggesting that this is a kernel issue and not a Hydrogen issue?

yes its kernel specific

Closing this as an issue with the kernel.

Just a note that I was able to use jupyter-scala with Hydrogen. One extra thing you need to do is install the language-scala package.


after load files the window grays out

HI Sebastian:
Thank you for showing me this nice software. I tried it on my laptop. But once I uploaded required report.tsv and the metadata file, it grays out. Please see this screen shot.

Hi, thanks for the feedback. Would it be possible to share the file with me so I can test it?


Create 2D editing space

Create the space to edit blueprint graphs. This should include the basic ability to add a blueprint


Forwarder sometimes crashes with segmentation fault after restart

I tested several forwarder restarts sequentially and sometimes it thrown panic on a segmentation fault:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xf23672]

goroutine 276 [running]:
github.com/networkservicemesh/sdk-vpp/pkg/networkservice/pinhole.tunnelIPSwIfIndex({0x147caf0, 0xc000986b10}, {0x7f7d585f7c18?, 0xc0000bf120}, {0xc00028bb00, 0x10, 0x10})
	/root/go/pkg/mod/github.com/networkservicemesh/sdk-vpp@v0.0.0-20231002104338-c5aa8c256465/pkg/networkservice/pinhole/common.go:210 +0x3d2
github.com/networkservicemesh/sdk-vpp/pkg/networkservice/pinhole.create({0x147caf0, 0xc000986b10}, {0x7f7d585f7c18, 0xc0000bf120}, {0xc00028bb00, 0x10, 0x10}, 0x12b5, {0xc00002a8a0, 0x15})

See the logs attached: forwarder-restart-segfault.log

@szvincze Nice catch!
The panic should be fixed and now we need to check what happens next with the forwawrder.
Could you please re-test with the latest forwarder?

Latest forwarder image is https://github.com/networkservicemesh/cmd-forwarder-vpp/pkgs/container/ci%2Fcmd-forwarder-vpp/133810960?tag=9d48b78

I need some time to reconfigure my environment to use the latest image but will test it.

I have been testing this image for a while. The panic haven't happened so far but haven't even seen the corresponding error message in the logs.

That's good news. Could we close the ticket?

I close it now. If something happen during the coming tests I can open another one.


Clusterfuzz Jazzer builds fail in v0.3.0

Error log:
libc++abi: terminating with uncaught exception of type std::runtime_error: JNI_CreateJavaVM returned code -1
AddressSanitizer:DEADLYSIGNAL
=================================================================
==263==ERROR: AddressSanitizer: ABRT on unknown address 0x000000000107 (pc 0x7fdccbf0218b bp 0x7ffc3acdb3f0 sp 0x7ffc3acdaac0 T0)
SCARINESS: 10 (signal)
==263==WARNING: invalid path to external symbolizer!
==263==WARNING: Failed to use and restart external symbolizer!
    #0 0x7fdccbf0218b  (/lib/x86_64-linux-gnu/libc.so.6+0x4618b)
    #1 0x7fdccbee1858  (/lib/x86_64-linux-gnu/libc.so.6+0x25858)
    #2 0x484695  (/tmp/not-out/tmpzrlj_s8f/NativeUbsanFuncPtrFuzzTest.runfiles/rules_fuzzing_oss_fuzz/jazzer_driver_with_sanitizer+0x484695)
    #3 0x46e31e  (/tmp/not-out/tmpzrlj_s8f/NativeUbsanFuncPtrFuzzTest.runfiles/rules_fuzzing_oss_fuzz/jazzer_driver_with_sanitizer+0x46e31e)
    #4 0x46e1e2  (/tmp/not-out/tmpzrlj_s8f/NativeUbsanFuncPtrFuzzTest.runfiles/rules_fuzzing_oss_fuzz/jazzer_driver_with_sanitizer+0x46e1e2)
    #5 0x486455  (/tmp/not-out/tmpzrlj_s8f/NativeUbsanFuncPtrFuzzTest.runfiles/rules_fuzzing_oss_fuzz/jazzer_driver_with_sanitizer+0x486455)
    #6 0x4863ef  (/tmp/not-out/tmpzrlj_s8f/NativeUbsanFuncPtrFuzzTest.runfiles/rules_fuzzing_oss_fuzz/jazzer_driver_with_sanitizer+0x4863ef)
    #7 0x39b715  (/tmp/not-out/tmpzrlj_s8f/NativeUbsanFuncPtrFuzzTest.runfiles/rules_fuzzing_oss_fuzz/jazzer_driver_with_sanitizer+0x39b715)
    #8 0x390dfe  (/tmp/not-out/tmpzrlj_s8f/NativeUbsanFuncPtrFuzzTest.runfiles/rules_fuzzing_oss_fuzz/jazzer_driver_with_sanitizer+0x390dfe)
    #9 0x39148e  (/tmp/not-out/tmpzrlj_s8f/NativeUbsanFuncPtrFuzzTest.runfiles/rules_fuzzing_oss_fuzz/jazzer_driver_with_sanitizer+0x39148e)
    #10 0x38fed0  (/tmp/not-out/tmpzrlj_s8f/NativeUbsanFuncPtrFuzzTest.runfiles/rules_fuzzing_oss_fuzz/jazzer_driver_with_sanitizer+0x38fed0)
    #11 0x3e73e6  (/tmp/not-out/tmpzrlj_s8f/NativeUbsanFuncPtrFuzzTest.runfiles/rules_fuzzing_oss_fuzz/jazzer_driver_with_sanitizer+0x3e73e6)
    #12 0x3fe7c0  (/tmp/not-out/tmpzrlj_s8f/NativeUbsanFuncPtrFuzzTest.runfiles/rules_fuzzing_oss_fuzz/jazzer_driver_with_sanitizer+0x3fe7c0)
    #13 0x7fdccbee30b2  (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #14 0x2e294d  (/tmp/not-out/tmpzrlj_s8f/NativeUbsanFuncPtrFuzzTest.runfiles/rules_fuzzing_oss_fuzz/jazzer_driver_with_sanitizer+0x2e294d)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: ABRT (/lib/x86_64-linux-gnu/libc.so.6+0x4618b)
==263==ABORTING

@fmeum can you look into it? I can release a v0.3.1 with the fix.

Also see for example: https://github.com/bazelbuild/rules_fuzzing/runs/4870312891?check_suite_focus=true

On it, see also https://github.com/bazelbuild/rules_fuzzing/pull/192#issuecomment-1016633152.

The build broke because Bazel 5.0.0 got released a few hours ago and we neither pin a Bazel version in rules_fuzzing nor run CI checks against something like last_green.
My guess is that https://github.com/bazelbuild/bazel/commit/20061f8fb7ed95924c6cdbaaaf3d06a64edf974e is causing issues with the native library needed as runfiles. I will see whether I can fix the logic.


Error when running the rng example on stm32l476rg

When I try to run the rng example on my stm32l476rg I get the following error:
ERROR probe_rs::util::rtt:
Error reading from RTT: Control block corrupted: write pointer is<PHONE_NUMBER> while buffer size is 1024 for "up" channel 0 (defmt)
Frame 0: "HardFault handler. Cause: Escalated BusFault (Precise data access error) at location: 0xffffffff." @ 0x0800f552
Frame 1: "External interrupt #495." @ 0xffffffff
Error: CPU halted unexpectedly.

I have identified that it is the line let mut rng = Rng::new(p.RNG, Irqs); that cause the issue.
I have adapted the chip feature of embassy-stm32 in examples/stm32l4/Cargo.toml and the chip argument to probe-rs in
examples/stm32l4/.cargo/config.toml.
Other examples work without any issue.

I was able to use git bisect to identify the commit where it starts to fail: 5c5e6818195b364199e583eb559b0042d392b3e7

set config.rcc.clk48_src = Clk48Src::PLL1_Q. The default is HSI48, which that chip doesn't have.
(the reason that commit breaks it is it now requires specifying clk48_src explicitly, vs before it would try to guess it based on the enabled clocks)


Copy paste bug

Hello, first of all, thank you very much for the package you developed. The package is preventing me from copy-pasting my project. Can you help me?

Same issue

I have tried creating an empty project, and adding mobile scanner as a dependency, however i am not able to reproduce this behavior. Can you provide an example? Also, when you are copying you seem to get a notification. I have tried it on a simulator with ios 15.5 but i don't get any notification and can copy/paste without any issues.

I created a new flutter project. I have added a textformfield inside the container as a widget. I can't paste. This issue exists in versions above iOS 13.5. Xcode is up to date
mobile_scanner: ^2.0.0

Can you help me? @juliansteenbakker

The problem persists and I ran the app in Xcode. When I copy-paste, I get an error like this. @juliansteenbakker

It would be great to create a simple example repo
@gizemgizg

Built without errors, had to pod repo update inside of the ios folder

Same issue here.

Can you please try again with version 3.0.0?


Rename err_load_xxx_strings_int

Use the already-existing prefix ERR_load_xxx_strings_int.
Also fix a confusing comment in the Unix makefile, that specified the
wrong flag to force a rebuild.
This is a partial fix for #15344

Use the already-existing prefix ERR_load_xxx_strings_int.

Uhm, haven't you noticed the pattern, public symbols get uppercase prefix, while private symbols get lowercase prefix?

Yes, I noticed the pattern.  Thanks for the reminder.
If you have a better way to keep those symbols inside the library, when they're not static, please close this.

Uhmmmmm, making them uppercase doesn't change anything other than making them uppercase, does it?
So yeah, our private non-static symbols are exposed in the static library, there's not very much we can do about that.

I just discovered that we have one err-related internal symbol exposed in the shared libcrypto: err_free_strings_int
I haven't looked at it (for long enough that I've forgotten, at the very least).  Someone else might be able to fill us in on that one.

Making them uppercase moves them into the public namespace.  And yes, that's all it does.  And yes, it goes against the convention of using lower-case prefix, and/or and _int suffix for internal and private symbols. If you have another way to have symbols not exposed, great. Perhaps @paulidale's original issue, #15344, is doing something wrong. I think you should (re-)read it and comment there.
If he's doing something wrong, then close this; I'll open a new PR for just the Makefile comment fix.
If he's right, and there's a better way to fix the issue then renaming things -- which is what was done in addressing #12694 -- then close this and I look forward to learning the better way.

The right fix is to add the ossl_ prefix.

2021 19:47, 19:47, Rich Salz @.***> napsal/a:

Making them uppercase moves them into the public namespace.  And yes,
that's all it does.  And yes, it goes against the convention of using
lower-case prefix, and/or and _int suffix for internal and private
symbols. If you have another way to have symbols not exposed, great.
Perhaps @paulidale's original issue, #15344, is doing something wrong.
I think you should (re-)read it and comment there.
If he's doing something wrong, then close this; I'll open a new PR for
just the Makefile comment fix.
If he's right, and there's a better way to fix the issue then renaming
things -- which is what was done in addressing #12694 -- then close
this and I look forward to learning the better way.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openssl/openssl/pull/15408#issuecomment-846131226

Replaced the prefix with ossl_

I'm sorry if I didn't make it clear. I didn't mean replacing err_ prefix with ossl_ but rather adding it. And to keep the name length reasonable you can drop the _int suffix as it is unnecessary.

2021 21:55, 21:55, Rich Salz @.***> napsal/a:

Replaced the prefix with ossl_
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/openssl/openssl/pull/15408#issuecomment-846219618

I think ossl_load_XXX_strings_int is fine and am not going to change it again.

I think ossl_load_XXX_strings_int is fine and am not going to change it again.

Then I am sorry, but I am not going to approve it. But I won't block it either.

Closing in favour of #15446


{'data': {'data': ... }} ???

This call:
jsonApi.update('case', {id: 100, side: 'top'})
will post this payload:
{'data': {'data': {'attributes': {'side': 'top'}, 'id': 100, 'type': 'case'}, 'meta': {}},
That.... is not correct.
Am I doing something wrong? Or am I looking at a serialisation bug?

Can you please share with us some reproducible code? It's hard to see why this happens from the data provided.

Oh wow.  Turns out I was looking at the logging output of the server which wrapped the payload in another {data: ... }.
Please ignore yesterday-me :) Thanks.


fix:Parse custom routes defined by Pod annotation panic

Signed-off-by: iiiceoo<EMAIL_ADDRESS>

需要在描述中 关联解决的issue


Change extension name to Zicfisslp

Name change suggested by ARC:
https://lists.riscv.org/g/tech-ss-lp-cfi/message/50

PR #102 to address this issue.


HDDS-1424. Support multi-container robot test execution

The ./smoketest folder in the distribution package contains robotframework based test scripts to test the main behaviour of Ozone.
The tests have two layers:

robot test definitions to execute commands and assert the results (on a given host machine)
./smoketest/test.sh which starts/stops the docker-compose based environments AND execute the selected robot tests inside the right hosts

The second one (test.sh) has some serious limitations:

all the tests are executed inside the same container (om):

https://github.com/apache/hadoop/blob/5f951ea2e39ae4dfe554942baeec05849cd7d3c2/hadoop-ozone/dist/src/main/smoketest/test.sh#L89
Some of the tests (ozonesecure-mr, ozonefs) may require the flexibility to execute different robot tests in different containers.

The definition of the global test set is complex and hard to understood.

The current code is:
{code}
TESTS=("basic")
execute_tests ozone "${TESTS[@]}"
TESTS=("auditparser")
execute_tests ozone "${TESTS[@]}"
TESTS=("ozonefs")
execute_tests ozonefs "${TESTS[@]}"
TESTS=("basic")
execute_tests ozone-hdfs "${TESTS[@]}"
TESTS=("s3")
execute_tests ozones3 "${TESTS[@]}"
TESTS=("security")
execute_tests ozonesecure .
{code}
For example for ozonesecure the TESTS is not used. And the usage of bash lists require additional complexity in the execute_tests function.
I propose here a very lightweight refactor. Instead of including both the test definitions AND the helper methods in test.sh I would separate them.
Let's put a test.sh to each of the compose directories. The separated test.sh can include common methods from a main shell script. For example:
{code}
source "$COMPOSE_DIR/../testlib.sh"
start_docker_env
execute_robot_test scm basic/basic.robot
execute_robot_test scm s3
stop_docker_env
generate_report
{code}
This is a more clean and more flexible definition. It's easy to execute just this test (as it's saved to the compose/ozones3 directory. And it's more flexible.
Other example, where multiple containers are used to execute tests:
{code}
source "$COMPOSE_DIR/../testlib.sh"
start_docker_env
execute_robot_test scm ozonefs/ozonefs.robot
export OZONE_HOME=/opt/ozone
execute_robot_test hadoop32 ozonefs/hadoopo3fs.robot
execute_robot_test hadoop31 ozonefs/hadoopo3fs.robot
stop_docker_env
generate_report
{code}
With this separation the definition of the helper methods (eg. execute_robot_test or stop_docker_env) would also be simplified.
See: https://issues.apache.org/jira/browse/HDDS-1424

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
32
Docker mode activated.

_ Prechecks _

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1
mvninstall
1071
trunk passed

+1
compile
48
trunk passed

+1
mvnsite
29
trunk passed

+1
shadedclient
638
branch has no errors when building and testing our client artifacts.

+1
javadoc
25
trunk passed

_ Patch Compile Tests _

-1
mvninstall
18
dist in the patch failed.

+1
compile
18
the patch passed

+1
javac
18
the patch passed

+1
mvnsite
22
the patch passed

-1
shellcheck
2
The patch generated 11 new + 0 unchanged - 1 fixed = 11 total (was 1)

+1
shelldocs
15
The patch generated 0 new + 104 unchanged - 132 fixed = 104 total (was 236)

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
2
The patch has no ill-formed XML file.

+1
shadedclient
762
patch has no errors when building and testing our client artifacts.

+1
javadoc
20
the patch passed

_ Other Tests _

+1
unit
26
dist in the patch passed.

+1
asflicense
32
The patch does not generate ASF License warnings.

2907

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-726/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/726

Optional Tests
dupname  asflicense  shellcheck  shelldocs  compile  javac  javadoc  mvninstall  mvnsite  unit  shadedclient  xml

uname
Linux c5c992ae7d7c 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / bdbca0e

maven
version: Apache Maven 3.3.9

Default Java
1.8.0_191

shellcheck
v0.4.6

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/1/artifact/out/patch-mvninstall-hadoop-ozone_dist.txt

shellcheck
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/1/artifact/out/diff-patch-shellcheck.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/1/testReport/

Max. process+thread count
445 (vs. ulimit of 5500)

modules
C: hadoop-ozone/dist U: hadoop-ozone/dist

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/1/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
24
Docker mode activated.

_ Prechecks _

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1
mvninstall
1035
trunk passed

+1
compile
28
trunk passed

+1
mvnsite
27
trunk passed

+1
shadedclient
650
branch has no errors when building and testing our client artifacts.

+1
javadoc
17
trunk passed

_ Patch Compile Tests _

-1
mvninstall
22
dist in the patch failed.

+1
compile
18
the patch passed

+1
javac
18
the patch passed

+1
mvnsite
21
the patch passed

-1
shellcheck
2
The patch generated 2 new + 0 unchanged - 1 fixed = 2 total (was 1)

+1
shelldocs
14
The patch generated 0 new + 104 unchanged - 132 fixed = 104 total (was 236)

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
1
The patch has no ill-formed XML file.

+1
shadedclient
697
patch has no errors when building and testing our client artifacts.

+1
javadoc
16
the patch passed

_ Other Tests _

+1
unit
21
dist in the patch passed.

+1
asflicense
27
The patch does not generate ASF License warnings.

2753

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-726/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/726

Optional Tests
dupname  asflicense  shellcheck  shelldocs  compile  javac  javadoc  mvninstall  mvnsite  unit  shadedclient  xml

uname
Linux 3ac617fd7f4f 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / abace70

maven
version: Apache Maven 3.3.9

Default Java
1.8.0_191

shellcheck
v0.4.6

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/2/artifact/out/patch-mvninstall-hadoop-ozone_dist.txt

shellcheck
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/2/artifact/out/diff-patch-shellcheck.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/2/testReport/

Max. process+thread count
440 (vs. ulimit of 5500)

modules
C: hadoop-ozone/dist U: hadoop-ozone/dist

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/2/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
25
Docker mode activated.

_ Prechecks _

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1
mvninstall
1024
trunk passed

+1
compile
78
trunk passed

+1
mvnsite
31
trunk passed

+1
shadedclient
669
branch has no errors when building and testing our client artifacts.

+1
javadoc
21
trunk passed

_ Patch Compile Tests _

-1
mvninstall
20
dist in the patch failed.

+1
compile
20
the patch passed

+1
javac
20
the patch passed

+1
mvnsite
20
the patch passed

-1
shellcheck
0
The patch generated 2 new + 0 unchanged - 1 fixed = 2 total (was 1)

+1
shelldocs
16
The patch generated 0 new + 104 unchanged - 132 fixed = 104 total (was 236)

+1
whitespace
1
The patch has no whitespace issues.

+1
xml
1
The patch has no ill-formed XML file.

+1
shadedclient
735
patch has no errors when building and testing our client artifacts.

+1
javadoc
21
the patch passed

_ Other Tests _

+1
unit
23
dist in the patch passed.

+1
asflicense
29
The patch does not generate ASF License warnings.

2866

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-726/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/726

Optional Tests
dupname  asflicense  shellcheck  shelldocs  compile  javac  javadoc  mvninstall  mvnsite  unit  shadedclient  xml

uname
Linux 3ed4e60f0ff4 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / d608be6

maven
version: Apache Maven 3.3.9

Default Java
1.8.0_191

shellcheck
v0.4.6

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/4/artifact/out/patch-mvninstall-hadoop-ozone_dist.txt

shellcheck
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/4/artifact/out/diff-patch-shellcheck.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/4/testReport/

Max. process+thread count
410 (vs. ulimit of 5500)

modules
C: hadoop-ozone/dist U: hadoop-ozone/dist

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/4/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
24
Docker mode activated.

_ Prechecks _

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1
mvninstall
1254
trunk passed

+1
compile
129
trunk passed

+1
mvnsite
35
trunk passed

+1
shadedclient
654
branch has no errors when building and testing our client artifacts.

+1
javadoc
26
trunk passed

_ Patch Compile Tests _

-1
mvninstall
24
dist in the patch failed.

+1
compile
22
the patch passed

+1
javac
22
the patch passed

+1
mvnsite
23
the patch passed

-1
shellcheck
2
The patch generated 2 new + 0 unchanged - 1 fixed = 2 total (was 1)

+1
shelldocs
22
The patch generated 0 new + 104 unchanged - 132 fixed = 104 total (was 236)

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
1
The patch has no ill-formed XML file.

+1
shadedclient
743
patch has no errors when building and testing our client artifacts.

+1
javadoc
16
the patch passed

_ Other Tests _

+1
unit
19
dist in the patch passed.

+1
asflicense
30
The patch does not generate ASF License warnings.

3139

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-726/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/726

Optional Tests
dupname  asflicense  shellcheck  shelldocs  compile  javac  javadoc  mvninstall  mvnsite  unit  shadedclient  xml

uname
Linux 8006a03f0cac 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 0b3d41b

maven
version: Apache Maven 3.3.9

Default Java
1.8.0_191

shellcheck
v0.4.6

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/5/artifact/out/patch-mvninstall-hadoop-ozone_dist.txt

shellcheck
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/5/artifact/out/diff-patch-shellcheck.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/5/testReport/

Max. process+thread count
446 (vs. ulimit of 5500)

modules
C: hadoop-ozone/dist U: hadoop-ozone/dist

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/5/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
80
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

0
shelldocs
2
Shelldocs was not available.

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1
mvninstall
613
trunk passed

+1
compile
263
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
977
branch has no errors when building and testing our client artifacts.

+1
javadoc
180
trunk passed

_ Patch Compile Tests _

+1
mvninstall
565
the patch passed

+1
compile
276
the patch passed

+1
javac
276
the patch passed

+1
mvnsite
0
the patch passed

-1
shellcheck
4
The patch generated 2 new + 0 unchanged - 1 fixed = 2 total (was 1)

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
2
The patch has no ill-formed XML file.

+1
shadedclient
760
patch has no errors when building and testing our client artifacts.

+1
javadoc
174
the patch passed

_ Other Tests _

-1
unit
238
hadoop-hdds in the patch failed.

-1
unit
1206
hadoop-ozone in the patch failed.

+1
asflicense
45
The patch does not generate ASF License warnings.

5635

Reason
Tests

Failed junit tests
hadoop.ozone.client.rpc.TestCloseContainerHandlingByClient

hadoop.ozone.web.client.TestKeysRatis

hadoop.ozone.ozShell.TestOzoneShell

hadoop.ozone.web.client.TestOzoneClient

hadoop.ozone.om.TestOmMetrics

hadoop.ozone.container.ozoneimpl.TestOzoneContainer

hadoop.hdds.scm.pipeline.TestPipelineClose

hadoop.ozone.om.TestOzoneManagerConfiguration

hadoop.ozone.om.TestOmBlockVersioning

hadoop.hdds.scm.pipeline.TestNode2PipelineMap

hadoop.ozone.container.common.statemachine.commandhandler.TestCloseContainerByPipeline

hadoop.ozone.scm.TestXceiverClientManager

hadoop.ozone.web.TestOzoneVolumes

hadoop.ozone.scm.pipeline.TestPipelineManagerMXBean

hadoop.ozone.client.rpc.TestBlockOutputStreamWithFailures

hadoop.ozone.client.rpc.TestReadRetries

hadoop.ozone.web.TestOzoneRestWithMiniCluster

hadoop.ozone.TestMiniOzoneCluster

hadoop.ozone.scm.TestSCMNodeManagerMXBean

hadoop.ozone.client.rpc.TestCommitWatcher

hadoop.ozone.client.rpc.TestOzoneClientRetriesOnException

hadoop.ozone.om.TestOzoneManager

hadoop.ozone.web.client.TestBuckets

hadoop.ozone.om.TestOzoneManagerHA

hadoop.ozone.TestMiniChaosOzoneCluster

hadoop.ozone.scm.TestGetCommittedBlockLengthAndPutKey

hadoop.ozone.scm.TestContainerSmallFile

hadoop.ozone.web.client.TestKeys

hadoop.ozone.TestStorageContainerManager

hadoop.ozone.scm.node.TestSCMNodeMetrics

hadoop.ozone.scm.TestAllocateContainer

hadoop.ozone.web.client.TestVolume

hadoop.ozone.client.rpc.TestSecureOzoneRpcClient

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-726/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/726

Optional Tests
dupname asflicense shellcheck shelldocs compile javac javadoc mvninstall mvnsite unit shadedclient xml

uname
Linux 6f224256abb3 3.13.0-153-generic #203-Ubuntu SMP Thu Jun 14 08:52:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 6a42745

Default Java
1.8.0_191

shellcheck
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/6/artifact/out/diff-patch-shellcheck.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/6/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/6/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/6/testReport/

Max. process+thread count
3313 (vs. ulimit of 5500)

modules
C: hadoop-ozone/dist U: hadoop-ozone/dist

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/6/console

versions
git=2.7.4 maven=3.3.9 shellcheck=0.4.6

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

/retest

+1 from me too. This will allow more acceptance tests to be added easily.

Thanks @arp7 and @xiaoyuyao the review. I will merge it with the fixed type.
And this is just the improvement for the framework. As a next step, I would like to :

Remove the intermittency from the acceptance test runs (now it's easier as it's very easy to find the report for a specific test).

Fix ozonefs with hdfs dfs command and enable the unit test

Enable test for ozone + mapreduce (now, it should be easy based on the README)

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
30
Docker mode activated.

-1
patch
14
https://github.com/apache/hadoop/pull/726 does not apply to trunk. Rebase required? Wrong Branch? See https://wiki.apache.org/hadoop/HowToContribute for help.

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-726/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/726

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-726/7/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.


feat: update advice notes content and url

Describe your changes
APPLICS 795: Update advice notes content and URL

Replaced 'advice notes' with 'advice pages'
Replaced 'nodiadau cyngor’ with ‘tudalennau cyngor’
Updated URL for advice pages
Changed config variable adviceNotes to advicePages
Updated unit tests

Type of change 🧩

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update
[ ] Other (please explain in the description section above)

Checklist before requesting a review

[x] I have performed a self-review of my own code
[x] I have double checked this work does not include any hardcoded secrets or passwords
[ ] I have made corresponding changes to the documentation
[x] I have provided details on how I have tested my code
[x] I have referenced the ticket number above
[x] I have provided a description of the ticket
[ ] I have included unit tests to cover any testable code changes

:tada: This PR is included in version 1.14.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.29.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


SERVO_OUTPUT_RAW only display the first 8 channels

This should be fixed in rust-mavlink: https://github.com/mavlink/rust-mavlink/issues/57

Moving to emit-extension feature fix the problem: dc88d4ae259bd3c9366a592bae7b351d5ec88d4e

It appears to be a problem with rust-mavlink: https://github.com/mavlink/rust-mavlink/issues/61

Fixed with  71fb896


POST body not parsed on POST requests

Usually, a  POST requests has a POST body containing the data, either x-www-form-urlencoded or json. But in the SmartEVSE API you need to do a POST request but provide data using GET parameters (in the URL). This is kind of awkward.
The issue is request->getParam() is called in POST requests, without setting the 2nd parameter (post) to true.
I'd like to fix this.
Would a PR be accepted if the behavior is not backward-compatible?

I was not aware of this "awkwardness", as were the original authors of the API, Im sure.
Since backward incompatibility would hit al lot of users, including the ones using the homeassistant integration, I wouldnt accept such a PR.
Is there  no way compatibility could be warranteed, e.g. autodetecting which of both methods is used?

That'll be a couple lines extra code, I'll see if I can get to it


Track replica mode transition times with replicaTransitionTimeMap

Which issue(s) this PR fixes:
longhorn/longhorn#8114
What this PR does / why we need it:
Adds the CRD field required by https://github.com/longhorn/longhorn-manager/pull/2685.

@mergify backport v1.6.x v1.5.x


transforms.Pad doc broken

https://pytorch.org/docs/master/torchvision/transforms.html#torchvision.transforms.Pad

Fixed via #511


Add a note for filtering

I recently tried to filter for mother's own milk but it kept failing. Yoshiki and I tried it on Qiime2 and the command --p-where "type_of_feed_7_d = "mother's own milk"" worked. Add a note that to filter samples with an apostrophe in it you must write the command like type_of_feed_7_d = "mother's own milk". Not sure if you want me to add this in the help or tutorial or if you want to add this to the actual Qiita filtering command page but we should document it somewhere.

That command is no longer working but it did work maybe a month ago.
Error in filtering samples in biom Std out: Std err: /bin/sh: -c: line 0: unexpected EOF while looking for matching `"' /bin/sh: -c: line 1: syntax error: unexpected end of file

This is still an issue. I can't figure out how to filter for samples that contain metadata with an apostrophe in it.

@stephanieorch, in your original post, you said:
"""Add a note that to filter samples with an apostrophe in it you must write the command like type_of_feed_7_d = "mother's own milk". Not sure if you want me to add this in the help or tutorial or if you want to add this to the actual Qiita filtering command page but we should document it somewhere."""
So, is that the solution or you are not sure?
Now, the problem with this issue is that this is a comment specific to a command so the best place to add it: the tutorials.

It worked at one point but now it doesn't work. Not sure what happened... So there is currently no solution to this.

That's weird, when was the last time you checked? Is that analysis still avaialble?

I checked it today and it didn't work. I keep getting the error that I posted above on May 17th... I can't find the original job that worked.

Just added this to the CMI tutorial under filtering

@stephanieorch, can we close?

Yes. But remember that it's not in the help documentation, only in the tutorial


docs updates

parallelism spec
get rid of /prev (when it's merged and update for appropriate version)
reorganize reference docs (PFS, PPS, FAQ)
Add readme's for each directory the point people to RTD
update instances of v1.2.0 to v1.2.1
remove bad benchmark - already outdated

@JoeyZwicker don't get rid of /prev while the behavior is still present in master. We're trying to get in the habit of updating docs as patches that change behavior are merged in so you shouldn't have to worry about that one. Whoever removes /prev will update the docs too.

I didn't actually check yet to see if the /prev PR landed and what release it's under, 1.2.1 or 1.2.2(e.g. HEAD right now, or not at all yet), but I won't change the docs until it is. It's on this list as something to check on.

Now being tracked here: https://github.com/pachyderm/pachyderm/issues/1869


How to deal with float vs complex data types?

What is the expected enhancement?
On various occasions the topic has come up, how to deal with float vs complex data types consistently across the entire stack. Some examples are:

#455
#72
#830
https://github.com/Qiskit/qiskit-nature/pull/921#discussion_r1010755662

Most of these cases above actually want to deal with other aspects/features/etc. but will rely on the ability to consistently treat complex vs. real values across the stack.

The main problem here is, that we do not want to cast everything always to be complex as this would significantly increase the memory requirements when dealing with larger systems. Furthermore, this may in fact not be desirable when certain values can physically not become complex but will/should always remain real.
I do not yet have a very good answer on how to solve this, but one idea that keeps coming up would be a configurable datatype setting as part of qiskit_nature.settings which could consistently handle "casting" to complex/float values across the stack. Just to put this out here as an initial idea...

Quoting from https://github.com/Qiskit/qiskit-nature/pull/1144

Complexity should not pose a real problem any longer because we do not do any explicit down- or up-conversions in the stack any longer. This can be seen since Tensor and PolynomialTensor explicitly allow complex values.


SVG support

I hope you like it.

Thanks a lot!

Thank you for this awesome project! I love it..


Implement url / word whitelist

I wonder if para will even accept this :thinking:

We'll leave this on that separate branch until we can do some staged testing.


Video starts playing on recyclerview scroll

I am using this library in horizontal recyclerview. The issue is that video starts playing if I am scrolling recyclerview. I only want to play the video when it is clicked not on scrolling. How can I achieve this?

Hi, we are a recycler view example in the sample app. Please take a look.


Prefix per server

[x] I have tested my changes against the dev branch (the latest developmental version), and this pull request is targeting that branch as a base
[x] I have tested my changes on Python 3.10.12
[x] I have ensured my code is formatted using Black

Description
This PR adds support for setting a command prefix per guild/server.  It adds one new option EnableOptionsPerGuild and a new command setprefix to manage the feature.
This feature allows just about anything without spaces to be set as a command prefix, including Emoji.  Only one verb cannot be set, as setprefix clear is used to clear any currently set prefix.
The default prefix in options.ini is used when no server-specific prefix is set.  If per-guild options are not enabled the setprefix command will raise an error.
Additionally, this feature will remember a limited number of prefix changes so the clean command can take care of messages prior to a prefix change.   This history of prefixes does not persist through restarts.
Related issues (if applicable)
#2288

This should be fully ready to go now. :+1:


Documentation

Is it just me or the code is un-understandable for a person who hasn't wrote this.
If you could just provide an advance documentation of how it works, I would personally give you some chocolate. :chocolate_bar:

Hey @steelbrain, thanks for the feedback.
I'm not sure the code is so unreadable because @sandropaganotti contributed to it without asking but I understand that documentation is important (http://thisisnotdocumentation.tumblr.com) and I love chocolate :D
Is there anything in particular that you found hard to read?

Nevermind, this morning I tried reading it again and it was much more readable than before. My Bad.
Here you go :chocolate_bar:


Parser.parse Does not preserve iconSet element.

In lib/rubyXL/objects/worksheet.rb, definition of iconSet element has attribute's name 'type'.
It should be 'iconSet'.
So Paser.parse does not preserve original iconSet.

Thanks, great bugreport. Should go out with next release.


IndexError: tuple index out of range with stripe_webhooks

When I create a user on the Django admin panel the following way, I get the following error
class CustomUser(AbstractUser):
    username = None
    email = models.EmailField(_('email address'), unique=True)
    name = models.CharField(verbose_name=_("first name"), max_length=50)
    stripe_customer_id = models.CharField(max_length=120)

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = ['name']

    objects = CustomUserManager()

    def __str__(self):
        return self.name

@receiver(post_save, sender=CustomUser)
def _on_update_user(sender, instance, created, **extra_fields):
    print(f"HERE {instance.is_superuser}")

    if created and not instance.is_superuser:

        # Create Stripe user
        customer = stripe.Customer.create(
            email=instance.email,
            name=instance.name,
        )

        User = get_user_model()

        # Create profile
        user = User.objects.get(id=instance.id)
        user.email = instance.email
        user.name=instance.name
        user.stripe_customer_id=customer.id

        user.save()

The error occurs when the following is running
 stripe listen --forward-to <IP_ADDRESS>:8000/stripe/webhook/
2022-06-17 13:07:51   --> customer.created [evt_1LBd1nCiNWlPNf1Rnx6rsetb]
2022-06-17 13:07:51  <--  [500] POST http://<IP_ADDRESS>:8000/stripe/webhook/ [evt_1LBd1nCiNWlPNf1Rnx6rsetb]

Here is the error I get
Traceback (most recent call last):
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/drf_stripe/stripe_webhooks/handler.py", line 53, in handle_webhook_event
    e = StripeEvent(event=event)
  File "pydantic/main.py", line 341, in pydantic.main.BaseModel.__init__
pydantic.error_wrappers.ValidationError: 1 validation error for StripeEvent
event
  No match for discriminator 'type' and value 'customer.created' (allowed values: <EventType.CUSTOMER_SUBSCRIPTION_DELETED: 'customer.subscription.deleted'>, <EventType.CUSTOMER_SUBSCRIPTION_UPDATED: 'customer.subscription.updated'>, <EventType.CUSTOMER_SUBSCRIPTION_CREATED: 'customer.subscription.created'>, <EventType.INVOICE_PAID: 'invoice.paid'>, <EventType.INVOICE_CREATED: 'invoice.created'>, <EventType.INVOICE_PAYMENT_FAILED: 'invoice.payment_failed'>, <EventType.PRODUCT_UPDATED: 'product.updated'>, <EventType.PRODUCT_CREATED: 'product.created'>, <EventType.PRODUCT_DELETED: 'product.deleted'>, <EventType.PRICE_CREATED: 'price.created'>, <EventType.PRICE_UPDATED: 'price.updated'>, <EventType.PRICE_DELETED: 'price.deleted'>, <class 'str'>) (type=value_error.discriminated_union.invalid_discriminator; discriminator_key=type; discriminator_value=customer.created; allowed_values=<EventType.CUSTOMER_SUBSCRIPTION_DELETED: 'customer.subscription.deleted'>, <EventType.CUSTOMER_SUBSCRIPTION_UPDATED: 'customer.subscription.updated'>, <EventType.CUSTOMER_SUBSCRIPTION_CREATED: 'customer.subscription.created'>, <EventType.INVOICE_PAID: 'invoice.paid'>, <EventType.INVOICE_CREATED: 'invoice.created'>, <EventType.INVOICE_PAYMENT_FAILED: 'invoice.payment_failed'>, <EventType.PRODUCT_UPDATED: 'product.updated'>, <EventType.PRODUCT_CREATED: 'product.created'>, <EventType.PRODUCT_DELETED: 'product.deleted'>, <EventType.PRICE_CREATED: 'price.created'>, <EventType.PRICE_UPDATED: 'price.updated'>, <EventType.PRICE_DELETED: 'price.deleted'>, <class 'str'>)

During the handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 47, in inner
    response = get_response(request)
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/django/core/handlers/base.py", line 181, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
    return view_func(*args, **kwargs)
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/django/views/generic/base.py", line 70, in view
    return self.dispatch(request, *args, **kwargs)
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/rest_framework/views.py", line 509, in dispatch
    response = self.handle_exception(exc)
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/rest_framework/views.py", line 469, in handle_exception
    self.raise_uncaught_exception(exc)
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/rest_framework/views.py", line 480, in raise_uncaught_exception
    raise exc
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/rest_framework/views.py", line 506, in dispatch
    response = handler(request, *args, **kwargs)
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/drf_stripe/views.py", line 69, in post
    handle_stripe_webhook_request(request)
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/drf_stripe/stripe_webhooks/handler.py", line 15, in handle_stripe_webhook_request
    handle_webhook_event(event)
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/drf_stripe/stripe_webhooks/handler.py", line 55, in handle_webhook_event
    _handle_event_type_validation_error(err)
  File "/Users/magedhelmy/Desktop/VS_Code/licensingDemo4/.venv/lib/python3.10/site-packages/drf_stripe/stripe_webhooks/handler.py", line 41, in _handle_event_type_validation_error
    if error_loc[0] == 'event' and error_loc[1] == 'type':
IndexError: tuple index out of range

I do not understand the error and I am not sure how to proceed from here.

Hi @magedhelmy1, I think your Stripe web hook is configured to send more events than our package currently supports and thus you are seeing the error. The Stripe web hook events that are supported are listed here: https://github.com/oscarychen/drf-stripe-subscription#stripe-webhook
Essentially, your Stripe account is sending an event customer.created to your Django server, but this package currently only deals with the following events as outlined in the README:
product.created
product.updated
product.deleted
price.created
price.updated
price.deleted
customer.subscription.created
customer.subscription.updated
customer.subscription.deleted


feat: add /api/v1/alerts endpoint

Adding a prometheus-compatible API endpoint to rule-evaluator: /api/v1/alerts

Excellent @yama6a
Would this finally be enough to pull the rules into Grafana (from the evaluator), like it is with vanilla prometheus?

Excellent @yama6a
Would this finally be enough to pull the rules into Grafana (from the evaluator), like it is with vanilla prometheus?

Probably yes-ish.
For now, the endpoints will only be available on the rules-evaluator pod, not the prometheus-frontend pod, the latter of which you will probably use as a Prometheus-Datasource at the moment (running promQL queries, and fetching metrics/labels, etc).
A temporary hack could be to add the rule-evaluator pod as a separate Prometheus-Datasource in Grafana (once this is released), but I hope to make a PR for a proper solution soon-ish.
Currently, the frontend will blindly proxy all calls to /api/* to Google-Monitoring's prometheus endpoint, which doesn't work for these two new endpoints. I'm working on fixing that, and hope to have a solution soon. Ideally before the next release, if possible.

Excellent @yama6a
Would this finally be enough to pull the rules into Grafana (from the evaluator), like it is possible with vanilla prometheus?

@penekk
Probably yes-ish.
For now, the endpoints will only be available on the rules-evaluator pod, not the prometheus-frontend pod, the latter of which you will probably use as a Prometheus-Datasource at the moment (running promQL queries, and fetching metrics/labels, etc).
A temporary hack could be to add the rule-evaluator pod as a separate Prometheus-Datasource in Grafana (once this is released), but I hope to make a PR for a proper solution soon-ish.
Currently, the frontend will blindly proxy all calls to /api/* to Google-Monitoring's prometheus endpoint, which doesn't work for these two new endpoints. I'm working on fixing that, and hope to have a solution soon. Ideally before the next release, if possible.

Excellent @yama6a
Would this finally be enough to pull the rules into Grafana (from the evaluator), like it is possible with vanilla prometheus?

@penekk Probably yes-ish.
For now, the endpoints will only be available on the rules-evaluator pod, not the prometheus-frontend pod, the latter of which you will probably use as a Prometheus-Datasource at the moment (running promQL queries, and fetching metrics/labels, etc).

@yama6a
Actually the frontend is sort of 'out of the picture' because of datasyncer setup but I get your point.

A temporary hack could be to add the rule-evaluator pod as a separate Prometheus-Datasource in Grafana (once this is released), but I hope to make a PR for a proper solution soon.

That's what I was planning to do anyway :)

Currently, the frontend will blindly proxy all calls to /api/* to Google-Monitoring's prometheus endpoint (https://monitoring.googleapis.com/v1/projects/PROJECT_ID/location/global/prometheus), which doesn't work for these two new endpoints. I'm working on fixing that, and hope to have a solution soon. Hopefully before the next release.
Good to know. If there is any way I can help with the whole thing (testing and what not, not that versed with go yet) just let me know.

And thank you a lot for working on this.

Currently, the frontend will blindly proxy all calls to /api/* to Google-Monitoring's prometheus endpoint (https://monitoring.googleapis.com/v1/projects/PROJECT_ID/location/global/prometheus), which doesn't work for these two new endpoints. I'm working on fixing that, and hope to have a solution soon. Hopefully before the next release.

Nice! Yea, perhaps it's a good feature for frontend proxy or some separate proxy like thanos-querier or promxy. One day in Cloud Alerting too? 🤞🏽

Presubmit error is cryptic but it's detecting files without license:
#30 DONE 21.4s
/home/runner/go/bin/addlicense-v1.1.1 -check -ignore 'third_party/**' -ignore 'vendor/**' .
cmd/rule-evaluator/internal/alerts.go
cmd/rule-evaluator/internal/alerts_test.go
cmd/rule-evaluator/internal/api_test.go
make: *** [Makefile:144: regen] Error 1

@penekk

@yama6a Actually the frontend is sort of 'out of the picture' because of datasyncer setup but I get your point.

A temporary hack could be to add the rule-evaluator pod as a separate Prometheus-Datasource in Grafana (once this is released), but I hope to make a PR for a proper solution soon.

That's what I was planning to do anyway :) (after seeing your previous contribution from a while back)

If you add the rule-evaluator as a data-source I would expect a bunch of UI and log errors, due to the fact that Grafana is going to try to use this as a query-datasource (which of course won't work). and Grafana-users can pick it as a datasource for their Dashboards and in the Metrics-Explorer and such. Not the end of the world of course, and perhaps the lesser evil in your case, just a fair warning.

Thank you for the contribution!! Should be a nice addition for debugging and general visibility.
Question for you - given that managed collection deploys one rule evaluator per cluster, there's no way to get a global view of your rules with this endpoint. You could only get a global view if there was only one rule evaluator, such as if you are using self-deployed evaluation or if you only use GlobalRules.
Cloud Alerting's promql alerts work the same way as global rules but they can give you a better view in a centralized place. Have you looked into that? Is there some sort of feature deficit there that is stopping you from using it?

@lyanco

Question for you - given that managed collection deploys one rule evaluator per cluster, there's no way to get a global view of your rules with this endpoint. You could only get a global view if there was only one rule evaluator, such as if you are using self-deployed evaluation or if you only use GlobalRules.

I see what you mean; I suppose it depends on the individual setup and use-case.
In our case, we have one cluster (and hence one rule-evaluator) with one Grafana, per project. So, the global view is no problem if we pipe the rules via rule-evaluator into Grafana as a datasource. If there would be multiple clusters with one rule-evaluator respectively, we could still opt for adding all of those as datasources to a central Grafana, and use that as a place of consolidation to achieve a global view, or something else that ingests multiple rule-evaluator endpoints.
I'm not sure how using only GlobalRules would help, as you mentioned. Could you elaborate how this would affect a setup with multiple clusters? Wouldn't we still have multiple rule-evaluators which ingest the GlobalRules from the different clusters?

Cloud Alerting's promql alerts work the same way as global rules but they can give you a better view in a centralized place. Have you looked into that? Is there some sort of feature deficit there that is stopping you from using it?

We did look into it, and it essentially boils down to developer experience, with GlobalRules adhering to the per-se industry standard of PrometheusRule resources (=> familiarity + ease of migration), and a IaC-decision of Terraform vs. Kubernetes or Atlantis vs ArgoCD. The full answer here is a bit more involved.
Do you guys have a Slack or a similar communications channel? Would be happy to run it by you if you want, as well as see what architectural solution could be beneficial to everyone using GMP (With reference to https://github.com/GoogleCloudPlatform/prometheus-engine/pull/1162). Would be happy to contribute more to this project.

@yama6a
Got it, thanks for the explanation. If you have 1:1:1 cluster:project:grafana then yes this should work for you. If you have more than one cluster, you'd have to have multiple datasources in Grafana connecting to multiple rule-evaluators to show you all your rules, and it wouldn't be a single pane of glass (you'd have to tab between datasources).
In this scenario, designating one cluster as your Rules cluster and only using GlobalRules would allow you to connect Grafana to that rule-evaluator only and get a single pane of glass that way. But then you lose the tenancy benefits of Rules/ClusterRules resources. It wouldn't be recommended. FWIW if you use GlobalRules we recommend only putting them in one rule-evaluator, otherwise you end up getting collisions.
Noted on the cloud alerting experience, that makes sense. We're not getting rid of the cluster-local rule path, although we are investing in it less.
We made a chat room in Google Chat for you... I think bartek might have invited you?


running out of buffers with recvmsg-multishot since 6.1.7

Here are the settings:
8192 provided buffers
[2023-01-20 11:14:28] INFO WSCONT/initGroupBuffer Provide 8192 16724 bytes buffers to gid 1 from address 0x0x7f710bd57000 (137003008)
to serve 48 sockets recvmsg multishots.
I configure my ring with twice as much cqe (16K) to avoid cq overflows if all buffers get used.
I do use the buffer rings to return back buffers to io_uring.
Very shortly after the connections are initiated, data is exchanged back and forth, I see the HTTP handshake but in less than a minute, the program start to experience a non stop flow of recvmsg errors. ENOBUF (105).
If I rollback the kernel to 6.1.6, I have stable connections with no errors at all for hours.
Prior to 6.1.7, I may have seen 1 or 2 ENOBUF errors once or twice with this number of buffers (8192) after running the application non-stop for weeks. Now, I have a spurious flow of them. Hundreds of them in few minutes...
I suspect something broke with 6.1.7

Hmm interesting - looking at the log, these are the changes between 6.1.6 and 6.1.7:
Jens Axboe (5):
      io_uring/poll: add hash if ready poll request can't complete inline
      io_uring/fdinfo: include locked hash table in fdinfo output
      io_uring/poll: attempt request issue after racy poll wakeup
      io_uring/io-wq: free worker if task_work creation is canceled
      io_uring/io-wq: only free worker if it was allocated for creation

Pavel Begunkov (1):
      io_uring: lock overflowing for IOPOLL

Are you compiling your own kernels? If so, I'd probably just bisect around io_uring/ between those two commits. The two poll related changes would be primary candidates. Really don't see how that can be right now, but that doesn't mean there isn't an issue.
I'm assuming you don't have a test case for this that I can run...?

it makes sense that 2 of the poll commits are primary candidates. Sure, I'll try bisect to pinpoint what is causing my issue.
No, I do not have a test case at this point and I have barely started to look at the problem...
it is not impossible too that a fix is now breaking my app. The fixed bug maybe had the effect of throttling down the incoming flow.
A feature of the flow is that despite providing very large buffers, the sending server do send very small segments most of the time (100-200) bytes on average.
Initially, my number of buffers was set to 512 but with multishot, it was depleted too fast. I had to double the size until I reach 8192.
I am going isolate the issue. With that result in hand maybe things will get clearer...

You could try this...
diff --git a/io_uring/poll.c b/io_uring/poll.c
index f2f9f174fc62..ab5ae475840f 100644
--- a/io_uring/poll.c
+++ b/io_uring/poll.c
@@ -281,8 +281,12 @@ static int io_poll_check_events(struct io_kiocb *req, bool *locked)
 			 * to the waitqueue, so if we get nothing back, we
 			 * should be safe and attempt a reissue.
 			 */
-			if (unlikely(!req->cqe.res))
+			if (unlikely(!req->cqe.res)) {
+				/* Multishot armed need not reissue */
+				if (!(req->apoll_events & EPOLLONESHOT))
+					continue;
 				return IOU_POLL_REISSUE;
+			}
 		}
 		if (req->apoll_events & EPOLLONESHOT)
 			return IOU_POLL_DONE;

I suspect that:
commit c06015ebc4367be38904b88582e13cc079672075
Author: Jens Axboe<EMAIL_ADDRESS>Date:   Sat Jan 14 08:46:14 2023 -0700

    io_uring/poll: attempt request issue after racy poll wakeup

seems like the most likely culprit.

thx... I am giving this potential fix a shot. I'll you know ASAP how it went

Wrote a test case (https://git.kernel.dk/cgit/liburing/commit/?id=15de013e2456dae5fce9c7bcb6711fd563d656a9) and verified it works with 6.1.6, and break miserably with 6.1.7. With the above mentioned fix, it works again as expected.
We might have another issue here with leaks of ring provided buffers, which is just apparent with the above bug. But that's for a separate investigation, I'll do that next.

I confirm too that your patch did fix the behavior that I was observing with 6.1.7
I don't know if I'll run out of provided buffers. I'll let you know if I see something in that regard.
Something that I wish I had is access to is the buffer ring tail and head indexes for easier debug on the client side.
I think that I might have created some debug code having a bitmap to track down the bids returned by io_uring to figure out if I was mishandling the buffers...
this might be handy to reactivate that code to detect a potential leak...

Great, thanks for reporting and testing. I'll send out a patch for this.
I'm looking into any potential leaks now. Multishot should not leak with the fix, it definitely did before the fix on 6.1.7 (or current -git). Separate investigation... I'll close this one up.


Platform.script.path issue on Windows

On Windows Platform.script.path returns value like /D:/dart/tmp/tst.dart. Please note '/' at the beginning of the path. On Windows absolute path should not be started with '/'
tested on Dart VM version: 2.0.0-dev.10.0 (Mon Dec 4 17:07:49 2017 +0100) on "windows_x64"

Platform.script is returning a URL.  URL.path returns the path part of the URL.  What you want is the native file path from a file:// URL, which is URL.toFilePath.  So you should call Platform.script.toFilePath().


[FEATURE] - Allow daemon mode to search for torrents via hash

Ready State: Yes
This pull request is related to the following Github issue:

#118

Requirements & Dependencies

None

Deployment Instructions

Merge code

Usage/Test Instructions

[ ] Run the daemon mode
[ ] Make a curl request to the daemon passing a hash property in the JSON. eg: curl -XPOST http://$CROSS_SEED_HOST:2468/api/webhook -H 'Content-Type: application/json' --data '{"hash": "$INFO_HASH"}' - where $CROSS_SEED_HOST is the domain of cross seed and $INFO_HASH is the hash of the torrent.

Thanks for your work here! I'll make a couple changes, test it, and ship it later today.

Thanks for your work here! I'll make a couple changes, test it, and ship it later today.

Glad I could help. Looking forward to it. Thanks again!

Made a couple changes

all references to hash are now infoHash. This includes the webhook payload
we convert infoHashes to lowercase during parsing so it can accept case-insensitively
changed 422 unprocessable entity to 400 bad request, to keep things simple
changed some naming and logging

Thanks for your implementing this feature!

v2.6.0. Docker auto builds may not be working atm, they decided to shut down free autobuilds due to bitcoin mining abuse. So make sure to check the version if it doesn't work. I've got some planned work to migrate off Docker Hub auto builds in favor of GH Actions, but haven't gotten around to it yet.


Question: Can I integrate the built framework and still have access to it's code?

When jumping to some method definition I only have access to the header file, is there a way to have access to the full code?
Cheers!

Can't do that right now. And there's no plan for this feature yet.
You could set the pod to :binary => false and pod install to transform it to source code version, although it's not the same thing.


Build Badge display issues

Describe the problem
Build badge isn't being displayed correctly.

For anyone who isn't signed into the chef buildkite, the badge isn't being displayed correctly.
When visiting the link, getting prompted with the buildkite chef okta login.

FYI: While I think your theory about buildkite auth is a good one, this is just the result of me not knowing how badges should actually be linked. Doh!

Been there for sure! Looks good in the PR btw. 😄


Bugfix iOS multitouch

For handling input in native on iOS we used addTarget:action:forEvent to listen for all touch events. During multitouch it looks like there is unexpected semantics or a bug here since all touch events stops when a finger is lifted.
This PR introduces a new way to handle touch events where the case above is not present. It also add the option to opt-out of automatic handling of touch events. Allowing the user to deal with the native-fuselibs interop if needed.
This PR contains:

[x] Changelog
[ ] Documentation
[ ] Tests

Added a test page @mortoray

Fixes https://github.com/fusetools/fuselibs/issues/4220


Double arrows

Keeping the scope (as in double-arrows) is Haxe's default behaviour so you don't need to create a local __this var for that.
I may say the problem is the opposite.

Interesting. I will look into it when I have some time for it. Thanks for the info!


Issue uploading to pypi with supplied versioning scheme

Hi zsimic, I love using your setupmeta package, but I think the verioning system is out of date. I am getting errors uploading to Pypi. while deploying to travis using post, build-id or '{major}.{minor}.{patch}' I get an error that says "400 Client Error: version: Cannot use PEP 440 local versions. for url: https://upload.pypi.org/legacy/" Is there anything that I can do to keep using the code that already exists?

Can you point me to your project? I wonder if it's a versioning strategy choice, as I don't have any trouble publishing to pypi or elsewhere.
I'll gladly take a look, point me to your repo if you can, or send me the relevant part of your setup.py

https://github.com/jtmorrisbytes/pyjtmorrisbytes
I want to try to use src/pyjtmorrisbytes/init.py to store the pertinant info

The setup() call in setup.py has no name= specified, that's the starting point usually.
Also, you are specifying version='0.1.5'  explicitly and no versioning=... (for setupmeta), which means that setupmeta will not try and determine the version of this project (as a rule, setupmeta will never touch anything you explicitly state in setup() call).
I'd say you're not really using setupmeta here, it is part of your setup_requires list, but it won't get to do much, especially since you seem to also specify your own cmdclass... and a setuptools.installations :)
I would start from an as-simple-as-possible setup.py first, current one seems to mix a lot of stuff.
One simple thing you could try is replace temporarily your setup.py with this:
from setuptools import setup

setup(
    name="pyjtmorrisbytes",
    versioning="dev",
    setup_requires=['setupmeta'],
)

And, delete (or empty out) setup.cfg.
Now, try running python setup.py explain, and you should get something like this:
                       author: (src/pyjtmorrisbytes/__init__.py:13) Jordan Taylor Morris
                  description: (README.md:1                       ) flask-pyjtmorrisbytes-api
                       email*: (src/pyjtmorrisbytes/__init__.py:14<EMAIL_ADDRESS>...
             long_description: (README.md                         ) # flask-pyjtmorrisbytes-api the flask version of my api
long_description_content_type: (README.md                         ) text/markdown
                         name: (explicit                          ) pyjtmorrisbytes
                  package_dir: (auto-fill                         ) {: src}
                     packages: (auto-fill                         ) 6 items: ["pyjtmorrisbytes", "pyjtmorrisbytes.config", ...
...
                      version: (git                               ) 0.1.1.dev6+g44cfe56
                           \_: (src/pyjtmorrisbytes/__init__.py:7 ) 0.1.5
                   versioning: (explicit                          ) dev
                           \_: (src/pyjtmorrisbytes/__init__.py:8 ) branch(dev,master):{major}.{minor}.{patch}

This would show you what setupmeta managed to find from your project.
From there, you could start adding stuff and see which parts become incompatible.
setupmeta was designed for very simple setup.py-s, not complex ones.
It should be able to handle stuff like .pyx extensions etc without issue, but I don't think having a lot of setup_requires will be a good use-case for setupmeta, like this line:
 setup_requires=['pytest-runner', 'cython', 'setupmeta', 'tox-setuptools', 'sphinx'],

That is mixing quite a few things:

usually you don't want to require pytest-runner, tox-setuptools and sphinx at setup time, that's much too early, you want that much later, during test runs and doc generation
don't know what cython does at setup time

Ill give your suggestion a try. My project is a cython based project that uses compiled pyx files. I need to either call Cython.Build.Cythonize with a list of pyx files or use the command line with a list of files to compile.
I am also having trouble figuring out how to prepare such a project for distribution. In its current state, It could compile files and upload them to travis, which then could upload a tar.gz file, but then all installations fail.  Im afraid that I am severely misunderstanding the packaging and setup process, and have had to mangle a bunch of different tutorials together to get anything to work

After testing your suggestion, I can confirm setup.py version --bump patch --commit works as expected. I have also confrmed that setupmeta detects package information correctly. I Think I have to add a MANIFEST.in file to include .pyx, .c, .so, and .pyd files. does setupmeta detect those files for sdist, bdist, and bdist_wheel? it would be greate if they could so I didn't have to use the manifest file.
Just tried to run tests, and pytest isnt picking up any tests without specifying anything in setup.py

MANIFEST.in is not necessary / out of scope of setupmeta. However, you will find this app pretty helpful: https://pypi.org/project/check-manifest/

Packaging is hard indeed :) setupmeta tries to help with the metadata part, making it less repetitive to have most of the common things auto-populated from other parts that you supposedly already have in your project (like long description from README, which is very standard practice)
I am not very familiar with pyx nor MANIFEST.in I must admit.

Regarding tests, note that setupmeta will declare them properly if you do this:
mv tests/jtmorrisbytes/* tests/
rm -r tests/jtmorrisbytes
cat << EOF > tests/requirements.txt
pytest
pytest-cython
EOF

Now run python setup.py explain, and you should see this line:
  tests_require: (tests/requirements.txt ) ["pytest", "pytest-cython"]

(make sure to NOT declare tests_require explicitly in your setup.py in this case, to let setupmeta find it).
Basically you have your tests in non-standard location tests/jtmorrisbytes, which setupmeta does not look at.
See for example this: https://github.com/requests/requests/tree/master/tests (pretty standard: tests are all right under tests/ folder)

Regarding author, setuptools has that weird historical thing where they want 2 fields... setupmeta is trying to let you do just one (and it will try and reasonably make the expected 2 appropriately).
In your __init__.py, try changing the 2 corresponding lines to this (there was a typo in license):
__license__ = 'MIT'
__author__ = "Jordan Taylor Morris<EMAIL_ADDRESS>
With this, you should see python setup.py explain now show:
       author: (auto-adjust                       ) Jordan Taylor Morris
           \_: (src/pyjtmorrisbytes/__init__.py:13) Jordan Taylor Morris<EMAIL_ADDRESS> author_email: (auto-adjust<EMAIL_ADDRESS>      license: (src/pyjtmorrisbytes/__init__.py:9 ) MIT

This should allow you to simplify the from src.pyjtmorrisbytes import __email__ from your setup.py.
Note that once everything is configured properly, you should never have to mention src from any import.
Using src/ subfolder is usually good practice (but debated amongst pythonistas...), I find it the more powerful way to go.
It tucks all your code neatly under one folder, but it does make it an extra challenge to package your project correctly for it to work. Usually people against src/ folder don't want to bother making their package 100% correct (or they have a reason to want "shortcuts" for certain local iterations...)
The src/ thing would be a long topic, but in general, if packaged right, you never ever mention src in any import, yet your packaging setup is such that import <mylibname> works correctly.
Using src/ also forces you to always run your code from a venv (except setup.py), which is usually very good practice.

MANIFEST.in is not necessary / out of scope of setupmeta. However, you will find this app pretty helpful: https://pypi.org/project/check-manifest/

Yup, setupmeta doesn't look or know much about MANIFEST.in yet (probably because I am also not familiar with it :) so no one taught it yet about that file)
Note you can run a tool such as check-manifest from tox, a little bit like this https://github.com/zsimic/setupmeta/blob/master/tox.ini#L30-L36 (readme_renderer in that example, but same idea)

Got it. I employed your sugestions without a problem. Im just waiting on a stable build process before attempting to upload to pypi again

I can successfully upload to pypi using setuptools and setupmeta, so I will consider this issue closed


#52 Fixed aggregated javadocs; improved package naming

Closes #52.

Appveyor builds take longer due to android docs component. I suppose this is not needed as I'm planning to generate Javadocs with Travis.


Console optionAliases() using hyphen (-) mark on alias

I running console using options that I set on optionAliases() and assume I can using hyphen (-) mark. Example: ['start-date' => 'startDate'].
So I set with -start-date="2017-01-01"
I check yii\console\Request only ^-(\w+) allowed.
Since its name changed from shortCuts to optionAliases, I think using hyphen (-) should included.

Q
A

Yii version
2.0.10

PHP version
7.0.1

@neotrouz @samdark check my pr please
https://github.com/yiisoft/yii2/pull/13678

👍
Thanks :)


Use after free in PreviousLoopbackCalculator

https://github.com/google/mediapipe/blob/bdfdaef30585719ed2cd1bc598a3e9879bcc4a1c/mediapipe/calculators/core/previous_loopback_calculator.cc#L137
main_spec is a const reference to main_packet_specs_.front(), which could be released in line 116 (main_packet_specs_.pop_front()).
This can be fixed by copy the struct in line 109.

Thanks for the fix!  The suggested change has been applied upstream in the google repository.  It should appear in the next MediaPipe release.

Thanks for the fix!  The suggested change has been applied upstream in the google repository.  It should appear in the next MediaPipe release.


intgrate new zebrunner insights (zafira) into the infra

need redesign zafira integration parameters and inject it into the infra using modular approach

qps-infra: 5.0-beta3
@okamara, you can test it on your env to make sure everything can be started and registered as usual

Close this ticket and will be created a new for test launcher


Page needs updating...

It has been a while since this was published\updated.  Need to review and update networking section to include Global Peering functionality.
Just my $0.02.
Thanks.

Chuck

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

ID: 88e51bc6-b077-a976-c890-a02e7d71b88e
Version Independent ID: f3af0a93-edc2-fddf-8690-d70ac22f8a2b
Content: Configure a SQL Server Always On availability group across different regions - SQL Server on Azure VM
Content Source: articles/azure-sql/virtual-machines/windows/availability-group-manually-configure-multiple-regions.md
Service: virtual-machines-sql
GitHub Login: @MashaMSFT
Microsoft Alias: mathoma

Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

Hi @ctimon , thanks for reaching out! I agree, this page could use a refresher, and we can look into adding global peering.
Thank you so much for your feedback! I've created an internal work item (1779886) and added it to our backlog.
Thanks again for helping improve our docs! I'm going to close out this Git Issue, but please feel free to comment should you need anything further.
Thanks!
Masha from the SQL Docs team
#please-close


[mini.test] some way to update screenshots

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md

Module(s)
mini.test
Description
At the moment, updating screenshots is somewhat painful.
My workaround is to add the following to my Makefile:
update-screenshots:
	rm -rf tests/screenshots/*
	make test

Maybe one way would be to set some env var that expect.reference_screenshot() checks and would force re-write if true?
So you would call it like:
make test-file test/test_something.lua UPDATE_SCREENSHOTS=true

Thanks for the suggestion (and actually writing tests for the plugin)!
There is a force option in expect.reference_screenshot which you can utilize in helper. I use this one and usually manually set { force = true }, but you can set its default to use UPDATE_SCREENSHOTS environment variable.
All in all, I think this one is in a territory of taste and adaptability to specific plugin needs. So closing as not planned.


Updated examples with code highlight

Added notation to example code blocks. Now the example codes are highlighted as the Language that they are written in.

@furoTmark : Thanks for your contribution! The author, @stevestein, has been notified to review your proposed change.


XOutput emulates HID-compliant game controller instead of xBox 360 Game Controller =(

XOutput emulates HID-compliant game controller instead of xBox 360 Game Controller =(
I did all steps with instructions, already have install ViGEmBus Setup 1.16.116 (as admin), all DirectX and Visual C+ libraries i have too, and no errors, no warnings appear when i start XOutput...

How can i emulate my old gamepad as xBox 360 Gamepad, please?

HID means Human interface device, that does not say it cannot be XInput device. Open File/Game Controllers and see there if the device is named Controller (XBOX 360 For Windows). If it is not, try to install XBox 360 drivers as well.

yes, there i have "Controller (xbox360 for windows)". it is good? i thought it has to have a different name.
i have Win10x64 (NTSC) so i cant install legacy driver from download installator. but i can try to install it as windows 7 driver.

If you have Controller (xbox360 for windows) it should be good.


Builder json to xml : how to merge sub level node ?

Hi,
When I try this code :
const xml2js = require('xml2js');
const builder = new xml2js.Builder({
});
const sampleObject1 = {
    "Lines": [
      {
        "Line": {
          "bar": "bazline1",
          "Sublines" : [
            {"Subline": {"sublinecontent" :  1}},
            {"Subline": {"sublinecontent" :  2}},
          ]
        }
      },
      {
        "Line": {
          "bar": "bazline2",
        }
      },
      {
        "Line": {
          "bar": "bazline3",
        }
      }
    ]
}

console.log(`Sample : \n${builder.buildObject(sampleObject1)}\n`);

the output result is
Sample :
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Lines>
  <Line>
    <bar>bazline1</bar>
    <Sublines>
      <Subline>
        <sublinecontent>1</sublinecontent>
      </Subline>
    </Sublines>
    <Sublines>
      <Subline>
        <sublinecontent>2</sublinecontent>
      </Subline>
    </Sublines>
  </Line>
  <Line>
    <bar>bazline2</bar>
  </Line>
  <Line>
    <bar>bazline3</bar>
  </Line>
</Lines>

As you can see, there is only one node Lines which contains 3 children nodes Line : this is what I expected because Lines is an array of Line in the initial json.
BUT : there are multiple (2) nodes Sublines where I was expecting something like :
<Sublines>
      <Subline>
        <sublinecontent>1</sublinecontent>
      </Subline>
      <Subline>
        <sublinecontent>2</sublinecontent>
      </Subline>
</Sublines>

Indeed, Sublines is an array of Subline in the initial json : so I was expecting Subline nodes to be children of a unique Sublines node.
Well, is there a way to get the result I want ?

I found a solution, so I will close this.
Using this code :
const xml2js = require('xml2js');
const builder = new xml2js.Builder({
});
const sampleObject1 = {
  "Lines": {
      "Line": [
          {
              "bar": [
                  "bazline1"
              ],
              "Sublines":
                  {
                      "Subline": [
                          {
                              "sublinecontent": [
                                  "1"
                              ]
                          },
                          {
                              "sublinecontent": [
                                  "2"
                              ]
                          }
                      ]
                  }

          },
          {
              "bar": [
                  "bazline2"
              ]
          },
          {
              "bar": [
                  "bazline3"
              ]
          }
      ]
  }
}

console.log(`Sample : \n${builder.buildObject(sampleObject1)}\n`);

the output result is as expected :
Sample :
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Lines>
  <Line>
    <bar>bazline1</bar>
    <Sublines>
      <Subline>
        <sublinecontent>1</sublinecontent>
      </Subline>
      <Subline>
        <sublinecontent>2</sublinecontent>
      </Subline>
    </Sublines>
  </Line>
  <Line>
    <bar>bazline2</bar>
  </Line>
  <Line>
    <bar>bazline3</bar>
  </Line>
</Lines>


speed up reading ascii tile files

read ascii tile file in 2d by reading the line into the first dimension. The changes speed up the reading by about 100 times for a 200M tile file in openmpi.

not necessary. changes were transferred to the dev/fix_tests branch


usb sniffer not working in VM

I want to use usb-sniffer under my Qubes OS system. So I tried to run it in the debian vm with usb passthrough. The result of the test command is:
data error during the speed test on count 6144000
I'm also not getting any packets in Wireshark.
Qubes OS using Xen hypervisor. Most of the passedthrough usb devices I used work normally.

The pass-though is not reliable for large amounts of data. There is nothing I can do here.
The speed test uses a pseudo-random sequence generated in the FPGA and on the PC and those sequences are compared. Something went wrong and the data is mismatched at the specified packet count. Given that it uses bulk transfers, the connection should be reliable, so it looks like some issue with the pass-though implementation.