Nicer (alternative?) Debug implementations

Here's one simple suggestion that may increase user-friendliness of the crate by a huge margin:

Switch Debug implementations (e.g. for Date or OffsetDateTime) to user-friendly ones

Current behaviour if you ever debug-print a date or a datetime (you'll have to scroll right...):
date: Date { year: 2019, ordinal: 89 },
time: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2019, ordinal: 89 }, time: Time { hour: 0, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } } },

Proposed behaviour:
date: 2019-03-30,
time: 2019-03-30 0:00:00.0 +00:00:00,

The main point, really, is user (or rather, dev) friendliness, to aid in developing crates that depend on time. As a hypothetical example, you're using this crate for parsing some structs from some APIs and you want to quickly derive Debug on those to see what you've just parsed, you'll have a hard time (especially with dates).
A few notes and some explanation:

Whichever formatting is chosen, it has to be lossless, especially for datetimes (that is, if there are non-zero nanoseconds there, they cannot be truncated).
Date { year: 2019, ordinal: 89 } is information for computers, not for human beings. You won't be able to tell what date it is without doing a mental (or computer-aided) computation first.
OffsetDateTimes are absolutely humongous when debug-printed and will likely dwarf most structs; their readable representation is a tiny string that humans can immediately parse though.
But Debug has to represent internals since it's meant for Debug purposes? Not really - same as Vec's Debug implementation doesn't print its capacity and the pointer, it just outputs whatever likely is the most useful information to the user. If you need to print capacity and the pointer, in very rare cases, you can always do so manually.
Why not implement your own Debug? You can. But sometimes you have 20 other fields in your structs, and you'd have to manually implement Debug just to be able to see your dates and times in a readable fashion.
You can always wrap Date in a newtype? You can. But then have to do it everywhere you use it, you'll have to implement derefs and conversions and possible end up with a bunch of newtype wrappers, and all for the sake of being able to just print it?
But it already implements Display? It does. But more often than not your structs and their fields won't, so you won't be able to derive it even with helper crates like derive_more.
Performance-wise, it doesn't really matter. It's pretty-formatting, after all.
If the current debug-representation is really needed, one could add a newtype wrapper for each struct which will be accessible as e.g. struct.debug(). The chances are, it will never get used, except by the devs of this crate themselves. An alternative option, if needed for dev purposes, is having a feature flag, disabled by default, for auto-derived debug (current behaviour); but then again, would it be used at all?

I could try and help out with this if needed (although it should be pretty trivial implementation-wise).
Thanks and cheers 🖖

Thank you for the detailed and thorough issue!
I'll think about it. Ultimately a debug representation is meant for debugging, and this includes debugging the time crate. Some of the debug outputs are not even representative of the actual internal representation, such as Date (Date is internally stored as a bitpacked u32).
With regard to the comparison to Vec, it also matters how the value is semantically thought about. Aside from OffsetDateTime (which uses PrimitiveDateTime internally), this is pretty much already the case. For what it's worth OffsetDateTime will have a different output come October, as that's when the internals for OffsetDateTime and PrimitiveDateTime will be merged.
Date could be changed to be a year-month-day debug output, but that would have some cost associated with it (namely calculating the month and day). That's not the end of the world, as the debug output shouldn't be used in places where performance matters anyways.

Hey, ran into the same problem. Another inconvenience is that Rust tests output Debug print by default, so our tests look like this when they fail:

I went ahead and made PR #509, which copy the Display impls that are the same as you describe in the issue.

@xy2iii Would you mind sharing that as text? It's a decent case for me to visualize how different changes would affect the output, even if this one is on the larger-than-average end of the spectrum.

Here are the cases of before and after:

Before
Resource { id: 0, meta: Meta { object: Report, url: "https://api.wanikani.com/v2/summary", data_updated_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 11, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } } }, data: SummaryR { lessons: [AvailableLessons { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 11, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [7746, 208, 204] }], next_reviews_at: Some(OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 11, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }), reviews: [AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 11, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [776, 2937] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 12, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 13, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [7690, 3248] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 14, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 15, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [3485, 4164] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 16, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [3483] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 17, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [8939, 7745, 2778, 7687, 7689, 3310, 8801] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 18, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 19, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 20, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 21, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 22, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 267 }, time: Time { hour: 23, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 268 }, time: Time { hour: 0, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 268 }, time: Time { hour: 1, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 268 }, time: Time { hour: 2, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [3270, 2595] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 268 }, time: Time { hour: 3, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [7629, 803, 3224, 3136, 3124, 2878, 3243, 7478] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 268 }, time: Time { hour: 4, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 268 }, time: Time { hour: 5, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 268 }, time: Time { hour: 6, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 268 }, time: Time { hour: 7, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [8665, 3249, 7535, 3207, 7625] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 268 }, time: Time { hour: 8, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [3278, 3271] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 268 }, time: Time { hour: 9, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [4848] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 268 }, time: Time { hour: 10, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }, AvailableReviews { available_at: OffsetDateTime { local_datetime: PrimitiveDateTime { date: Date { year: 2022, ordinal: 268 }, time: Time { hour: 11, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, subject_ids: [] }] } }

After
Resource { id: 0, meta: Meta { object: Report, url: "https://api.wanikani.com/v2/summary", data_updated_at: 2022-09-24 11:00:00.0 +00:00:00 }, data: SummaryR { lessons: [AvailableLessons { available_at: 2022-09-24 11:00:00.0 +00:00:00, subject_ids: [7746, 208, 204] }], next_reviews_at: Some(2022-09-24 11:00:00.0 +00:00:00), reviews: [AvailableReviews { available_at: 2022-09-24 11:00:00.0 +00:00:00, subject_ids: [776, 2937] }, AvailableReviews { available_at: 2022-09-24 12:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-24 13:00:00.0 +00:00:00, subject_ids: [7690, 3248] }, AvailableReviews { available_at: 2022-09-24 14:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-24 15:00:00.0 +00:00:00, subject_ids: [3485, 4164] }, AvailableReviews { available_at: 2022-09-24 16:00:00.0 +00:00:00, subject_ids: [3483] }, AvailableReviews { available_at: 2022-09-24 17:00:00.0 +00:00:00, subject_ids: [8939, 7745, 2778, 7687, 7689, 3310, 8801] }, AvailableReviews { available_at: 2022-09-24 18:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-24 19:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-24 20:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-24 21:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-24 22:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-24 23:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-25 0:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-25 1:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-25 2:00:00.0 +00:00:00, subject_ids: [3270, 2595] }, AvailableReviews { available_at: 2022-09-25 3:00:00.0 +00:00:00, subject_ids: [7629, 803, 3224, 3136, 3124, 2878, 3243, 7478] }, AvailableReviews { available_at: 2022-09-25 4:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-25 5:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-25 6:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-25 7:00:00.0 +00:00:00, subject_ids: [8665, 3249, 7535, 3207, 7625] }, AvailableReviews { available_at: 2022-09-25 8:00:00.0 +00:00:00, subject_ids: [3278, 3271] }, AvailableReviews { available_at: 2022-09-25 9:00:00.0 +00:00:00, subject_ids: [4848] }, AvailableReviews { available_at: 2022-09-25 10:00:00.0 +00:00:00, subject_ids: [] }, AvailableReviews { available_at: 2022-09-25 11:00:00.0 +00:00:00, subject_ids: [] }] } }

Just to chime in, one of my use cases was somewhat similar to @xy2iii's.
If during testing any of the asserts failed, you'd be left with screens worth of ordinals, offsets and nanoseconds if your types had #[derive(Debug)] and contained time types within them.

@jhpratt Just a thought on this:

this includes debugging the time crate

As a middleground solution, why couldn't a feature be added (disabled by default), like "debug-internal-repr", in which case all debug implementation revert back to dumping all of their internals.
This way, time devs can trace errors if they occur, and the users are happy because they would almost never care about the internal representation when deriving Debug.

Alright…there's 28 instances of an OffsetDateTime being output there. Needless to say that's a lot. However, I can't say that having an OffsetDateTime in a Vec is an unusual situation.
I'll think about this some more and should make a decision within the coming days. One thing I will not be doing is adding a feature flag for this — that just makes it more complicated to maintain, increases CI time, and would likely be confusing to downstream users.


Cannot start container: subnet sandbox join failed for "<IP_ADDRESS>/24": error creating vxlan interface: file exists

(Similar, but closed, issues: #562, #751)
Very occasionally, I see this error message when starting a container in my swarm:
Error response from daemon: Cannot start container <container hash>: subnet sandbox join failed for "<IP_ADDRESS>/24": error creating vxlan interface: file exists

This error persists until I reboot the docker hosts. A comment on #751 suggested that restarting iptables would suffice; I have not tried this yet. I also have tried the solution mentioned in #562 previously, and I believe that worked as well, but I cannot remember for sure.
docker version:
Client:
 Version:      1.10.0
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   590d5108
 Built:        Thu Feb  4 18:18:11 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      swarm/1.1.0
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   a0fd82b
 Built:        Thu Feb  4 08:55:18 UTC 2016
 OS/Arch:      linux/amd64

docker info:
Note: this was not captured when the error was occurring. If it happens again, I will comment with the info.
Containers: 32
 Running: 29
 Paused: 0
 Stopped: 3
Images: 222
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 4
 druid-vms.historical1: <host3>:2376
  └ Status: Healthy
  └ Containers: 4
  └ Reserved CPUs: 0 / 2
  └ Reserved Memory: 0 B / 8.188 GiB
  └ Labels: executiondriver=native-0.2, historical=yes, kernelversion=3.16.0-30-generic, operatingsystem=Ubuntu 14.04.2 LTS, provider=generic, storagedriver=aufs
  └ Error: (none)
  └ UpdatedAt: 2016-02-11T15:00:03Z
 druid-vms.historical2: <host4>:2376
  └ Status: Healthy
  └ Containers: 4
  └ Reserved CPUs: 0 / 2
  └ Reserved Memory: 0 B / 8.188 GiB
  └ Labels: executiondriver=native-0.2, historical=yes, kernelversion=3.16.0-30-generic, operatingsystem=Ubuntu 14.04.2 LTS, provider=generic, storagedriver=aufs
  └ Error: (none)
  └ UpdatedAt: 2016-02-11T15:00:24Z
 druid-vms.ingestion1: <host2>:2376
  └ Status: Healthy
  └ Containers: 5
  └ Reserved CPUs: 0 / 2
  └ Reserved Memory: 0 B / 8.188 GiB
  └ Labels: executiondriver=native-0.2, ingestion=yes, kernelversion=3.16.0-30-generic, operatingsystem=Ubuntu 14.04.2 LTS, provider=generic, storagedriver=aufs
  └ Error: (none)
  └ UpdatedAt: 2016-02-11T14:59:45Z
 druid-vms.queen: <host1>:2376
  └ Status: Healthy
  └ Containers: 19
  └ Reserved CPUs: 0 / 2
  └ Reserved Memory: 0 B / 8.188 GiB
  └ Labels: broker=yes, consul=yes, deployment-master=yes, executiondriver=native-0.2, kernelversion=3.16.0-30-generic, metadata=yes, operatingsystem=Ubuntu 14.04.2 LTS, provider=generic, storagedriver=aufs, swarm-master=yes
  └ Error: (none)
  └ UpdatedAt: 2016-02-11T15:00:22Z
Plugins:
 Volume:
 Network:
Kernel Version: 3.16.0-30-generic
Operating System: linux
Architecture: amd64
CPUs: 8
Total Memory: 32.75 GiB
Name: druid-vms.queen
Http Proxy: <snip>
Https Proxy: <snip>
No Proxy: <snip>

uname -a:

Local: Darwin <hostname> 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
Docker hosts: Linux <hostname> 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Environment details (AWS, VirtualBox, physical, etc.):

Docker Swarm, 4 pre-existing VMs, generic driver

How reproducible:

Intermittent; not reliably reproducible (and I wouldn't begin to know how to try). Seems to occur sometime after destroying and re-creating the swarm using docker-machine.

Happens to us pretty random (or not in known/reproducible way) also.

Saw this again today, after destroying and re-creating my --driver generic docker machines. No meaningful changes in the docker info output; just UpdatedAt and Containers counts.
Oh, it now says Server Version: swarm/1.1.2 (Client and server docker version still 1.10.0).
Restarting docker didn't work for me like it did for @arteal, so I ended up rebooting all the hosts again.

Happened to us again, restarting docker didn't help, stopping docker, flushing iptables and starting docker did not help. Had to reboot that machine

Same as @arteal for me
Unable to identify the root cause so unable to reproduce on purpose.
Seems to happen randomly.
I'll try to get more info next time...

docker version:
Client:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 15:54:52 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 15:54:52 2016
 OS/Arch:      linux/amd64

docker info:
Containers: 1
 Running: 1
 Paused: 0
 Stopped: 0
Images: 9
Server Version: 1.10.3
Storage Driver: aufs
 Root Dir: /data/.graph/var/lib/releases/20160316_1458121754/aufs
 Backing Filesystem: extfs
 Dirs: 210
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: overlay null host bridge
Kernel Version: 3.16.0-67-generic
Operating System: Ubuntu 14.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.421 GiB
Name: se1-test-jump
ID: YPJJ:UE7N:FYIZ:AOXA:EXVL:7B7I:67U7:YUPK:NOZB:WMLJ:J4YH:GWOV
WARNING: No swap limit support
Labels:
 project=traceone
 env=test
 type=jump
Cluster store: consul://<IP_ADDRESS>:8502/network
Cluster advertise: <IP_ADDRESS>:2375

uname -a:
Linux xxxxxxxx 3.16.0-67-generic #87~14.04.1-Ubuntu SMP Fri Mar 11 00:26:02 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Environment details (AWS, VirtualBox, physical, etc.):
Physical

I just had this issue.
First i got:
500 Internal Server Error: subnet sandbox join failed for "<IP_ADDRESS>/24": vxlan interface creation failed for subnet "<IP_ADDRESS>/24": failed in prefunc: failed to set namespace on link "vx-000104-52662": invalid argument
Then after a few tries it switched to saying:
500 Internal Server Error: subnet sandbox join failed for "<IP_ADDRESS>/24": error creating vxlan interface: file exists
Doing a "service docker stop; service docker start" helped.

I keep having this issue. Now even restarting the docker daemon doesn't help.
Please let me know what more information you need in order to find a solution for this.

@larsla invalid argument typically suggests its a kernel specific issue. I see that you are using  Kernel Version: 4.4.4-std-3. Most likely its to do with that. Please share more details on your environment.

For those hitting the file exists problem, it would be of great help if someone can share some reproduction steps.

Closed via https://github.com/docker/libnetwork/pull/1065 and is vendored into docker/docker.
Can someone try the docker/docker master and confirm the fix ?

@mavenugo Unfortunately, once the problem has manifested, it's too late. I saw this today after upgrading my swarm hosts to docker 1.10.3, and if I'm reading the PR correctly, it prevents the problem from occurring, but it won't help for me to upgrade docker and try again. So I ended up rebooting the hosts again.
I greatly look forward to the release of 1.11.0, though, so this can hopefully be in the past. :-)

@mavenugo I noticed the same. Only a reboot of the host fixes it but this is not an option for production. The process can take hours in a large enterprise IT environment where the vendor (us) have no direct control over the hypervisor.

Same here.
Linux pkb-dev 4.2.0-35-generic #40~14.04.1-Ubuntu SMP Fri Mar 18 16:37:35 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
vagrant@pkb-dev:/vagrant/deployment$ docker info
Containers: 9
 Running: 7
 Paused: 0
 Stopped: 2
Images: 8
Server Version: 1.11.0
Storage Driver: devicemapper
 Pool Name: docker-8:1-396877-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: ext4
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 3.852 GB
 Data Space Total: 107.4 GB
 Data Space Available: 35.5 GB
 Metadata Space Used: 7.029 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.14 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.77 (2012-10-15)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.2.0-35-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 15.67 GiB
Name: pkb-dev
ID: 3PLF:AJP5:WQH3:KE5L:IJYS:PHHF:7Y4M:SIWI:K7IK:OGMM:YESO:4372
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Username: mvarga
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

This is still occurring on 1.11.1.

And once again today.
ping @mavenugo

@thaJeztah  @mavenugo  This should be reopened as it can be reproduced using the below script.
The idea is to simulate ungraceful docker daemon shutdowns when there are containers connected to an overlay network having a restart policy.
#!/bin/env groovy

Thread.start {
    watchOutput("error")
}
deleteContainers()
c = "sudo docker network create -d overlay test".execute().text
print c

for (int i = 0; i < 100; i++) {
    def out = "sudo docker run -td --restart unless-stopped --net test --name t$i ubuntu:14.04.2 bash".execute().text
    print out
}
def resp = 'sudo docker ps'.execute().pipeTo("wc -l".execute()).text.trim()
assert resp == "101"

while (true) {
    killDockerDaemon()
    sleep(5000)
    resp = 'sudo docker ps'.execute().pipeTo("wc -l".execute()).text.trim()
    assert resp == "101"
}

//----------

def killDockerDaemon() {
    def c = ['bash', '-c', "sudo kill -9 \$(sudo service docker status|cut -d ' ' -f4)"].execute().text
    println c
}

def deleteContainers() {
    def c = ['bash', '-c', "sudo docker rm -f \$(sudo docker ps -a -q )"].execute().text
    println c
}

def watchOutput(text, file = "/var/log/upstart/docker.log") {
    Process p = "sudo tail -f $file".execute().pipeTo(["grep", "$text"].execute())
    p.in.eachLine { line ->
        println line
    }
}

My env is :
$ sudo docker info
Containers: 100
 Running: 0
 Paused: 0
 Stopped: 100
Images: 377
Server Version: 1.11.2
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay bridge null host
Kernel Version: 4.3.0-040300-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.16 GiB
Name: seb
ID: 3IIK:AWIX:PLOR:BPQ4:XNEL:SSXQ:2GUL:VEKX:OVCQ:SCCX:MN2U:DTWH
Docker Root Dir: /home/seb/hgdata/deployments/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Cluster store: consul://localhost:8500
Cluster advertise: <IP_ADDRESS>:2375

$ sudo docker version
Client:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:47:50 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:47:50 2016
 OS/Arch:      linux/amd64

@sebi-hgdata Can you try this same script with 1.12-rc2 because we have added fixes in it which should fix it. If it is still present then atleast there will be some opportunity to fix it completely before the 1.12 release is out.

@mrjana seems like the issue does not reproduce with 1.12-rc2 all containers restart properly during testing ... but I see a lot of errors like ```time="2016-06-23T23:06:54.858306166+03:00" level=error msg="Failed to start container c0ecaca06cb75c2ff5e0950f5554053b593752f946201a5104c2e0d6c07ba44d: could not add veth pair inside the network sandbox: error setting interface "vethc1dc8a1" master to "br": Device does not exist"
after letting the script kill the daemon a couple of times, killing the script, stopping the docker daemon and starting it up again... after this no container is restarted because they failed with the above error.
I can create another issue if it's necessary

@sebi-hgdata Thanks for testing. Yes please create another issue for the new bug you are seeing. We will make sure it is fixed before 1.12 release.

@mrjana added #1290

I've just experienced it in a Swarm cluster running 1.12.3. It has been produced when I did:
subnet sandbox join failed for \"<IP_ADDRESS>/24\": error creating vxlan interface: file exists

docker service rm logspout
docker service create --mode global --name logspout ...

Still seeing this on swarm 1.2.5 + Docker 12.2-rc1

@mavenugo we're also seeing this quite often in PWD (play-with-docker)

Had the file exists error with
Client:
 Version:      1.13.0-rc2
 API version:  1.25
 Go version:   go1.7.3
 Git commit:   1f9b3ef
 Built:        Wed Nov 23 06:17:45 2016
 OS/Arch:      linux/amd64

Server:
 Version:             1.13.0-rc2
 API version:         1.25
 Minimum API version: 1.12
 Go version:          go1.7.3
 Git commit:          1f9b3ef
 Built:               Wed Nov 23 06:17:45 2016
 OS/Arch:             linux/amd64
 Experimental:        false

with docker engine in swarm mode. After restarting docker service everything worked.

@Michael-Hamburger / all this will be fixed by https://github.com/docker/libnetwork/pull/1574
I've applied this patch manually and haven't had any issues so far.

I'm running into this problem on my 1.12.3 swarm. Is there a workaround for when it happens? I've tried removing and adding the problematic network(s) without success. Is there something short of a full restart of the swarm hosts that can alleviate this?

Is there something short of a full restart of the swarm hosts that can alleviate this?

Yes, if you restart the daemon the problem should be gone.

I saw this now.
Docker version 17.05.0-ce, build 89658be
Restarting the docker daemon is not fixing this.

@alexanderkjeldaas can you open a new issue with details, possibly it's different from the one that's resolved by https://github.com/docker/libnetwork/pull/1574

I took the liberty of opening a new thread as I, too, am encountering this issue on 17.05-ce (and have on earlier releases).
See #1765 for info.

@arteal
we rebooted our machine after that machine not booted 😆

Same issue:
subnet sandbox join failed for "<IP_ADDRESS>/16": error creating vxl...

a similar problem is reproduced now june 2019
docker info
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 18.09.6
Storage Driver: zfs
Zpool: rpool
Zpool Health: ONLINE
Parent Dataset: rpool/ROOT/pve-1
Space Used By Parent:<PHONE_NUMBER>376
Space Available:<PHONE_NUMBER>12
Parent Quota: no
Compression: on
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: active
NodeID: oo0dscwkoviwtnvocttkg9932
Is Manager: true
ClusterID: 3gfm66fjmcvn6q9k2mssqwcip
Managers: 1
Nodes: 1
Default Address Pool: <IP_ADDRESS>/8
SubnetSize: 24
Orchestration:
Task History Retention Limit: 5
Raft:
Snapshot Interval: 10000
Number of Old Snapshots to Retain: 0
Heartbeat Tick: 1
Election Tick: 10
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Force Rotate: 0
Autolock Managers: false
Root Rotation In Progress: false
Node Address: <IP_ADDRESS>
Manager Addresses:
<IP_ADDRESS>:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: bb71b10fd8f58240ca47fbb579b9d1028eea7c84
runc version: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
init version: fec3683
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.15.18-9-pve
Operating System: Debian GNU/Linux 9 (stretch)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.31GiB
Name: centroit-pve1
ID: 6INQ:DFKN:3V2I:XBIZ:VDMR:7HJH:VKEY:OMNY:7YIT:YFK7:KA74:MZLO
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
<IP_ADDRESS>/8
Live Restore Enabled: false
Product License: Community Engine

This error still occurs occasionally in Docker 20.x, VM restart typically required.


[Enhancement]Unify request handler code style of tcp and http protocol

Enhancement Request

Is your enhancement request related to a problem? Please describe
Http protocol handle with processors but Tcp protocol handle with tasks, it is needed to unify them into a same code style, it would be better for futher protocol extendtion.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Could I have a try? I'll try to refactor the TCP code to look like HTTP.
In addition, I want to optimize the programming style in the HTTP and TCP code during the unification process. For example, more detailed subcontracting and more readable naming.
I think this is appropriately modified and again abstracted in favor of both unification and later expansion.

@silentchildh Welcome, you may submit a PR.

Thanks, because I want to abstract the coupling logic that exists between HTTP and TCP, I'll open a PR in a few days.


provide PDFs of Fassungsansicht

According to our discussion in discord and via Mail with Dominique:
create action/process that is manually triggered and does the following:

[ ] GET https://parzival.unibe.ch/parzdb/parzival.php?page=pdf&dreissiger=1 to https://parzival.unibe.ch/parzdb/parzival.php?page=pdf&dreissiger=827
[ ] provide PDFs in this repository for reuse in presentation-parzival

I meant to have opened this, but never submitted…
Here's the implementation plan:

Create wrapper script
Embed existing command
Optionally fetch pdf/tex/tustep files from existing interface and make them available in appropriate directory (dist/api/pdf, dist/api/tex, dist/api/tustep)

Something went wrong with tex exports, will check later.


Bugfix 221231 draft

merge jar still have issues

it seems that merge jar is ok

merge jar still have issues

it seems that merge jar is ok


NFTx Flashloan BAYC for APE airdrop

tx: https://etherscan.io/tx/0xeb8c3bebed11e2e4fcd30cbfc2fb3c55c4ca166003c7f7d319e78eaab9747098

Analysis: https://medium.com/amber-group/reproducing-the-ape-airdrop-flash-loan-arbitrage-exploit-93f79728fcf5

Hi @greefea, thanks for your participation. The community and our team all benefit from your partaking.
You may have noticed that we are working on a complex transaction analyzer. Here is the link to the tool parsing the tx you submitted.
The analyzer link
This tool is still in the private test phase that only opens to a few users.
You are more than welcome to join the specified discord channel for it. We look forward to your suggestions on features, bugs, and improvements. C'mon in!
https://discord.gg/kmjNKFvV

Hello there, thanks for participating in our just concluded "Awesome Transactions Bounty" program. In other news, we have a great update for you! It's the new analyzing tool called "EigenTx" which you can use to analyze and dissect your submission and other transactions you deem necessary or intriguing! Follow the link below to enjoy the experience.
https://tx.eigenphi.io/


Setup Checkstyle

Copy the checkstyle config from the parent Dropwizard project and set up an integration with Code Climate to detect such issues automatically during a pull request

It probably makes sense to look to create a common configuration file that all of the dropwizard organization projects can use

Checkstyle has been configured and you can browse issues in CodeClimate (or locally with the maven-checkstyle plugin).


SampleApp not working

IMPORTANT: Before you create an issue, please take a look at our Issue Reporting Guide.
Briefly summarize your issue:
https://developer.amazon.com/en-US/docs/alexa/alexa-smart-screen-sdk/ubuntu.html
After completing step 5, sample app is not working. I tried t + enter but it  is not listening
What is the expected behavior?
The sampleApp should listen the question and answer.
What behavior are you observing?
########################################
Alexa is currently idle!
########################################
i see as below.
2021-09-11 10:08:18.585 [  1] 5 ContextManager:removeStateProvider
2021-09-11 10:08:18.585 [  1] 5 NotificationsCapabilityAgent:doShutdown
2021-09-11 10:08:18.585 [  1] 9 ThreadPool:obtainWorker:created=19,obtained=54,releasedToPool=54,releasedFromPool=0,outstanding=0
2021-09-11 10:08:18.585 [  3] 9 TaskThread:startThread:moniker=  3,duration=124
Provide the steps to reproduce the issue, if applicable:
Follow the steps from the above link until step 5
Tell us about your environment:
Ubuntu
What version of the AVS Device SDK are you using?
  1.25.0

Tell us what hardware you're using:

[ ] Desktop / Laptop
[ ] Raspberry Pi
[ ] Other - tell us more: UBUNTU

Tell us about your OS (Type & version):

[ ---yes] Linux
[ ] MacOS
[ ] Raspbian Stretch
[ ] Raspbian Jessy
[ ] Other - tell us more:

I am closing this issue due to inactivity.  If you have further questions, please open a new ticket and refer to this closed one.


try out testing on py 3.10.0

[ ] Code changes are covered by tests
[ ] New functions added to __init__.py
[ ] API.rst is up to date, along with other sphinx docs pages
[ ] Example notebooks are rerun and differences in results scrutinized
[ ] Updated changelog

python 3.10.0 was released yesterday and some packages already have compatible wheels on pypi.  May need to update our pinned versions to get it working though.

oh right, don't actually need a PR for actions to run, so closing this


Handle error issue all-or-nothing

Behat handles errors by checking the error_reporting() in a all-or-nothing way.
https://github.com/Behat/Behat/blob/a996f07b052f61cf224c4494d06c424bde1b341f/src/Behat/Testwork/Call/Handler/RuntimeCallHandler.php#L76
With the new deprecations in Symfony 2.7, this makes extremely impossible to work with it without adding the unwanted error_reporting(0).

We should check whether $level matches the binary flag returned by error_reporting() instead of checking whether the binary flag is 0.


Webpack2 - Es2015 modules not resolved

After spending over two days looking into this, following similar issues raised in this forum, Im posting my problem.
Current Behaviour:
When I run the script 'start-dev', webpack2 is  unable to resolve es2015 modules.
The error I get is:
ERROR in ./app/index.js
Module not found: Error: Can't resolve 'mod' in '/var/www/homelyfe/hl-app/app'
 @ ./app/index.js 7:11-25

ERROR in ./~/react/react.js
Module not found: Error: Can't resolve './lib/React' in '/var/www/homelyfe/hl-app/node_modules/react'
 @ ./~/react/react.js 3:17-39
 @ ./app/index.js

Webpack2 with babel seems to be unable to locate modules, be the modules in 'node_modules' or within 'app' folder.
Expected Behaviour:
I should be able to execute the ./app/index.js file & display the console.log the variable being imported from module ./app/mod.js;
Here is the link to the repo:
https://bitbucket.org/kay2dan/webpack2_setup
And here is the webpack.config.js after its built:
{
    entry: {
        app: '/var/www/homelyfe/hl-app/app/index.js'
    },
    output: {
        filename: 'run.build.js',
        path: '/var/www/homelyfe/hl-app/build'
    },
    resolve: {
        alias: {
            assets: '/var/www/homelyfe/hl-app/app/assets',
            components: '/var/www/homelyfe/hl-app/app/components'
        },
        extensions: ['js', 'jsx']
    },
    resolveLoader: {
        modules: ['./node_modules', '/var/www/homelyfe/hl-app/app']
    },
    plugins: [DefinePlugin {
            definitions: [Object]
        },
        HotModuleReplacementPlugin {
            multiStep: true,
            fullBuildTimeout: 200
        },
        HtmlWebpackPlugin {
            options: [Object]
        }
    ],
    module: {
        rules: [{
            test: /\.jsx?$/,
            include: '/var/www/homelyfe/hl-app/app',
            use: [{
                loader: 'babel-loader',
                options: {
                  presets: [ 'es2015', 'react' ]
                }
            }]
        }]
    },
    devServer: {
        historyApiFallback: true,
        hot: true,
        inline: true,
        stats: 'errors-only'
    }
}

resolve.extensions should have entries starting with .: [".js", ".jsx"].

I have the same issue, and even with the extenstions, only 2 out of 4 of my aliases are found, despite being in the same directory.
--src
----components
--------Application.jsx
--------Home.jsx
my resolve config
resolve: {
       extensions: ['.js','jsx','.scss'],
       modules: [
           './src',
           'node_modules'
       ],
       alias: {
           Application: path.resolve(__dirname,'../src/components/Application.jsx'),
           Home: path.resolve(__dirname, '..src/components/Home.jsx'),
           AppStyle: path.resolve(__dirname, '../src/styles/main.scss')
       }
   },

Home.jsx
import React from 'react';

const Home = () =>
    (

Home

    );

export default Home;

Application.jsx
import React from 'react';
import Home from 'Home';

const Application = () =>
    (

           <Home />

    );

export default Application;

entry.js
import React from 'react';
import { render } from 'react-dom';
import Application from 'Application';

require('AppStyle');

render(<Application />, document.getElementById('root'));

Application and AppStyle are resolved but Webpack cannot find Home.jsx.
Module not found: Error: Can't resolve 'Home' in '....
I'm finding Webpack 2 to be a little finicky in general, so any help would be appreciated.

I needed to add "node_modules" to resolve.modules like described here https://webpack.js.org/guides/migrating/.
  modules: [
     path.join(__dirname, "src"),
     "node_modules"
   ]


How to Download?

How i can Download this?

This plugin can be downloaded with the release: https://github.com/KCodeYT/VanillaGenerator/releases/tag/1.0-SNAPSHOT

I close this issue as I think this issue should been resolved.


Question

Hello tandasat, first of all thank you for your contribution to the community. I was experimimenting with your HyperVisor and works great hoewer and im trying to log System Drivers API calls but seems like ddimon dones't catch it, i tried hooking PsLookupProcessByProcessId and it only logs the calls from userland, is there anyway to log the ones from kernel too? thanks.

Resolved, i am getting the driver caller image name by scanning loaded module list and passing return address then getting image name.


ODC-7441: Add API for Summary data and Results Data

This PR adds API integration for the Tekton Results API for the Number ofPipeline Runs Cards and Summary API integration for the total runs and total duration card.

https://issues.redhat.com/browse/ODC-7441
https://issues.redhat.com/browse/ODC-7407

/lgtm
/approve


Taxon overview: AMR panel: add links

Add links from the chart and tabular view to corresponding list of genomes.
-Maulik

Discussed with Maulik and we would like to push back to milestone p3_web-3.2.x, since we want to add extra view for this data type.

fixed and available on beta.

Wicked awesome! I love it! ... verified on beta.


Advice on setting ContentState blockMap

I'm expanding on this example a little bit and running into an issue.
This works just fine (effectively a no-op):
onChange(editorState) {
  const contentState = editorState.getCurrentContent();
  const blockMap = contentState.getBlockMap();
  const newContentState = contentState.set('blockMap', blockMap);
  const newEditorState = EditorState.push(editorState, newContentState, 'change-inline-style');
  this.setState({
    editorState: newEditorState,
  });
}

but this produces some strange behavior (still effectively a no-op):
onChange(editorState) {
  const contentState = editorState.getCurrentContent();
  const blockMap = contentState.getBlockMap();
  const newBlockMap = blockMap.map((contentBlock) => {
    return contentBlock;
  });
  const newContentState = contentState.set('blockMap', newBlockMap);
  const newEditorState = EditorState.push(editorState, newContentState, 'change-inline-style');
  this.setState({
    editorState: newEditorState,
  });
}

More specifically – using the latter, I can type h but by the time I've typed he it appears as ehe and the cursor is after the first letter. This continues creating palindromes like so:

Typed
Displayed

h
h

he
ehe

hel
lehel

hell
llehell

hello
ollehello

FWIW, I've also tried various approaches using the static methods on Modifier, all with the same results.

This is a true no-op:
const blockMap = contentState.getBlockMap();
const newContentState = contentState.set('blockMap', blockMap);

After this point, contentState and newContentState are the same object, since blockMap is unchanged. The set operation is a no-op. This, however...
const newBlockMap = blockMap.map((contentBlock) => {
  return contentBlock;
});
const newContentState = contentState.set('blockMap', newBlockMap);

...is not a no-op, since newBlockMap is not the same object as the original blockMap. Thus, contentState and newContentState are also distinct objects.
I believe that the problem here, then, is that a new ContentState is being applied to your editorState during the onBeforeInput event loop, which will allow the DOM event to occur when characters are being typed. The native character insertion will not trigger a significant content change (https://github.com/facebook/draft-js/blob/master/src/component/handlers/edit/editOnBeforeInput.js#L152), so it will be inserted natively. The editor, however, will re-render because the ContentState has changed within onChange. The result is that the character is inserted programmatically but also inserted natively. I actually would have expected the character to render twice in succession rather than as a palindrome, but I'm guessing there's probably something wonky going on with the DOM selection state during render.
In the case where there is no new ContentState to render, the editor will not force a re-render via shouldComponentUpdate, and the native insertion occurs normally. (https://github.com/facebook/draft-js/blob/master/src/component/contents/DraftEditorContents.react.js#L74)
The inability to intercept and change EditorState for a native onBeforeInput event is a known problem, and one that I'd really like to resolve. It's a notable limit on customizable insertion behavior.
Hopefully this helps to clarify!

@hellendag thanks for the detailed reply. This does clarify things a bit although I'm not sure how to proceed.
Here's is what I was actually trying to do:
const newBlockMap = blockMap.map((contentBlock) => {
  ...

  const characterList = contentBlock.get('characterList');

  // Create a new character list with updated `CharacterMetadata`
  const newCharacterList = ...

  return contentBlock.set('characterList', List(newCharacterList));
});

If any alternatives come to mind, please share!

I read the docs and thought about this some more, and have some ideas.
Thanks again for the help!

This seems to be related to the issue I opened here: https://github.com/facebook/draft-js/issues/496 Any ideas on how to work around this?


fix non public enum deserialize error, for issue #2154

What this PR does / why we need it?
fix non public enum deserialize error, for issue #2154
Summary of your change
Please indicate you've done the following:

[ ] Made sure tests are passing and test coverage is added if needed.
[ ] Made sure commit message follow the rule of Conventional Commits specification.
[ ] Considered the docs impact and opened a new docs issue or PR with docs changes if needed.

你需要在本地执行mvn validate修复checkstyle的问题

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

Comparison is base (d3eec0b) 75.36% compared to head (ffbac75) 73.63%.

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #2156      +/-   ##
============================================
- Coverage     75.36%   73.63%   -1.73%
+ Complexity    21644    20917     -727
============================================
  Files           634      622      -12
  Lines         85390    84643     -747
  Branches      18933    18730     -203
============================================
- Hits          64352    62327    -2025
- Misses        13113    14345    +1232
- Partials       7925     7971      +46

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

你需要在本地执行mvn validate修复checkstyle的问题

你需要在本地执行mvn validate修复checkstyle的问题
好 我重新提交

你需要在本地执行mvn validate修复checkstyle的问题

好 我重新提交


chn_bits 8 bits for 9 channels?

Hi,
I noticed only 8 chn_bits are stored, but there are 9 possible streams.
Regards,
Ivo

Hi!
Sorry for the late response.

I noticed only 8 chn_bits are stored, but there are 9 possible streams.

Yes, the decoder assumes that the first channel (AUDF1) is always encoded, and the encoder warns if it detects that the first channel is empty. The assumption is that you always can reorder the channels to keep the first channel used.
Have Fun!

Thanks for the clarification.
Regards,
Ivo

You are welcome :)
Closing now.


Disable existential any build setting

Motivation:
On 5.8, if the experiment existential any setting is enabled and a consuming package holds an existential of a type from swift-log without an explicit 'any' then the build will fail.
Modifications:

Disable the setting

Result:
Users of 5.8 aren't broken

Can I suggest adding this flag to CI on these platforms?


SBOM initial

Python package reading for SBOM Topic

Merged these changes in https://github.com/siemens/continuous-clearing/pull/52


Gemspec: Drop EOL'd property rubyforge_project

The RubyGems property rubyforge_project is removed without a replacement.

Awesome, thank you 👍


OneDrive for Business<EMAIL_ADDRESS>"replace" fails with 409 on upload.createSession

"rename" works fine - so the request is certainly getting parsed. But setting it to "replace" gets a 409 error. Doesn't occur on OneDrive personal. Definitely a bug.

I've also gotten this when creating a folder in ODB:
Request:
POST /drive/items/{parent-id}/children

{"name": "folderNameThatAlreadyExists", "folder": { }<EMAIL_ADDRESS>"replace"}

Response:
HTTP/1.1 409 Conflict
Cache-Control: private, max-age=0
Transfer-Encoding: chunked
Content-Type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8
Expires: Thu, 09 Jun 2016 18:37:44 GMT
Last-Modified: Fri, 24 Jun 2016 18:37:44 GMT
Server: Microsoft-IIS/8.5
X-SharePointHealthScore: 0
X-SP-SERVERSTATE: ReadOnly=0
ODATA-VERSION: 4.0
SPClientServiceRequestDuration: 89
X-AspNet-Version: 4.0.30319
SPRequestGuid: 0e5e899d-30ab-3000-0a07-3f978916e6f9
request-id: 0e5e899d-30ab-3000-0a07-3f978916e6f9
Strict-Transport-Security: max-age=31536000
X-FRAME-OPTIONS: SAMEORIGIN
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: <IP_ADDRESS>09
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
Date: Fri, 24 Jun 2016 18:37:44 GMT

{"error":{"code":"nameAlreadyExists","message":"The specified item name already exists."}}

I keep getting the same errors also with files as well:
Request:
POST /drive/items/{parent-id}:/fileNameThatAlreadyExists:/upload.createSession

{"item": {<EMAIL_ADDRESS>"replace"} }

Response:
HTTP/1.1 409 Conflict
Cache-Control: private, max-age=0
Transfer-Encoding: chunked
Content-Type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8
Expires: Tue, 28 Jun 2016 16:33:57 GMT
Last-Modified: Wed, 13 Jul 2016 16:33:57 GMT
Server: Microsoft-IIS/8.5
X-SharePointHealthScore: 0
SP-Service-Context: GMP1:15783
X-SP-SERVERSTATE: ReadOnly=0
ODATA-VERSION: 4.0
SPClientServiceRequestDuration: 718
X-AspNet-Version: 4.0.30319
SPRequestGuid: 86748f9d-90a0-3000-0a07-36fbd39ed8a3
request-id: 86748f9d-90a0-3000-0a07-36fbd39ed8a3
Strict-Transport-Security: max-age=31536000
X-FRAME-OPTIONS: SAMEORIGIN
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: <IP_ADDRESS>23
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
Date: Wed, 13 Jul 2016 16:33:57 GMT

{"error":{"code":"nameAlreadyExists","message":"The specified item name already exists."}}

We have a fix checked prepared and will be working on deploying the fix ASAP.

@rgregg has this been deployed?

any news?

I'll take this to verify. I would hope after a year it would be fixed :)
Are you still reproing the issue?

Sorry, my mistake. It is working now.

Wiadomość napisana przez Brad Cleaver<EMAIL_ADDRESS>w dniu 09.09.2017, o godz. 19:32:
I'll take this to verify. I would hope after a year it would be fixed :)
Are you still reproing the issue?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/OneDrive/onedrive-api-docs/issues/359#issuecomment-328292062, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-zLFl2O3wdEjcmGsjCPuQF_GEHdEhtks5sgsuagaJpZM4IYGyw.

Thanks for confirming!


ObjectGroup doesn't set group at all

When used the process' group is set to root no matter what was specified in ObjectGroup.
After looking at src/parse.c I found that setgid works only when ObjectUser is used without ObjectGroup. In that case the process' group becomes user's default group.

This will be fixed in a release that's not too far off, along with some other bugs.


Do not assume webserver config

In https://github.com/openpatch/hyperbook/issues/215 we had the issue already:
The webserver config has to implicitly add the .html suffix to any requested site, which makes for nice URLs but requires custom webserver configuration. Can we have an option for it to work with a standard file-serving webserver?

I'm trying to investigate possible solutions to the problem.
One solution might be to use directories with index.html for every page. This would be an easy implementation.
├── elements
│   ├── alert
│   │   └── index.html
│   ├── archive
│   │   └── index.html
│   ├── audio
│   │   └── index.html
│   ├── bitflow
│   │   └── index.html
│   ├── bookmarks
│   │   └── index.html
│   ├── collapsible
│   │   └── index.html
│   ├── download
│   │   └── index.html
│   ├── embed
│   │   └── index.html
│   ├── emoji
│   │   └── index.html

Add an html extension to every internal link is another solution, but I am currently not sure in which places I have to make changes. So I have to look into it further.

Implemented in bd83e3a1a2bc49a6509dbdc15e085642100a55ff

just fyi, using HestiaCP I was able to configure apache2 to work with the old version through adding Options +MultiViews: https://httpd.apache.org/docs/current/content-negotiation.html#negotiation

was this reverted? getting files again


Custom Job Parameters injection if parameter in mail has prefix

We use the email plugin to provide mechanisms for our testers to approve the deployment of a new build on our test servers. basically they receive an email and have to answer to that email. In the email we put in the version which is to be deployed which we later use to kick off the deploy-jobs.
But with some email configurations the reply gets prefixes added to every line of the original message, eg FOO=bar becomes >FOO=bar.
This unfortunately does not get picked up by the plugin.
Steps to reproduce
How can we reproduce the issue

create job which polls an email inbox and injects a parameter calles "FOO"
send an email to that inbox with injects a parameter ">FOO=bar"
the parameter will not be injected

Expected behaviour
There should be some kind of mechanism where you can use a wildcard for the parameters so this would still be picked up as "FOO"
Server configuration
Jenkins Version:
2.56
Plugin Version:
1.026
Mail Server:
imap.gmail.com

Hi @huehnerlady, sounds great.

Only problem I could imagine, is inadvertently/accidentally picking up unintended properties, from with the email trail. Thoughts?

e.g.
Jenkins, please release this version:

version=1.23-RELEASE

Kind regards, Nick

> Jenkins build completed:
> version=1.23-BETA
> cleanWorkspace=false

Also, re: stripping invalid characters, is it enough to restrict to letters, digits, and underscore? (regex => [a-zA-Z_][a-zA-Z0-9_]*)

Environment variable names used by the utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 consist solely of uppercase letters, digits, and the '_' (underscore) from the characters defined in Portable Character Set and do not begin with a digit. Other characters may be permitted by an implementation; applications shall tolerate the presence of such names. Uppercase and lowercase letters shall retain their unique identities and shall not be folded together. The name space of environment variable names containing lowercase letters is reserved for applications. Applications can define any environment variables with names from this name space without modifying the behaviour of the standard utilities.

http://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html

@nickgrealy thanks for your answer.
I am not sure if it is that easy as other email programmes do not add anything in front of a reply - therefore you could end up with an email like this anyways:
Jenkins, please release this version:

version=1.23-RELEASE

Kind regards, Nick

Jenkins build completed:
version=1.23-BETA
cleanWorkspace=false

Maybe you could be able to specify a regex the emails are parsed with? But optional thing, not mandatory?

as I moved team I am not using this functionality anymore, and nobody answered me anyways


Exporting experiment on Databricks

Hi! I'm trying to export an experiment to a folder using Databricks. I've got it to work running the commands listed in the README locally, but when trying the same in my Databricks workspace I'm running into trouble. After building the wheel, pushing it to DBFS and installing it on the cluster I'm trying the following:
%sh

python -u -m mlflow_export_import.experiment.export_experiment \
  --experiment /Shared/my_experiment \
  --output-dir /dbfs/mnt/out \
  --notebook-formats SOURCE

I then get the following error:

Traceback (most recent call last):
File "/databricks/conda/envs/databricks-ml/lib/python3.8/runpy.py", line 194, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/databricks/conda/envs/databricks-ml/lib/python3.8/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/databricks/conda/envs/databricks-ml/lib/python3.8/site-packages/mlflow_export_import/experiment/export_experiment.py", line 82, in
main()
File "/databricks/conda/envs/databricks-ml/lib/python3.8/site-packages/click/core.py", line 829, in call
return self.main(*args, **kwargs)
File "/databricks/conda/envs/databricks-ml/lib/python3.8/site-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
File "/databricks/conda/envs/databricks-ml/lib/python3.8/site-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/databricks/conda/envs/databricks-ml/lib/python3.8/site-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
File "/databricks/conda/envs/databricks-ml/lib/python3.8/site-packages/mlflow_export_import/experiment/export_experiment.py", line 78, in main
exporter = ExperimentExporter(None, export_metadata_tags, utils.string_to_list(notebook_formats))
File "/databricks/conda/envs/databricks-ml/lib/python3.8/site-packages/mlflow_export_import/experiment/export_experiment.py", line 22, in init
self.fs = filesystem or _filesystem.get_filesystem()
File "/databricks/conda/envs/databricks-ml/lib/python3.8/site-packages/mlflow_export_import/common/filesystem.py", line 50, in get_filesystem
return DatabricksFileSystem() if use_databricks else LocalFileSystem()
File "/databricks/conda/envs/databricks-ml/lib/python3.8/site-packages/mlflow_export_import/common/filesystem.py", line 13, in init
self.dbutils = IPython.get_ipython().user_ns["dbutils"]
AttributeError: 'NoneType' object has no attribute 'user_ns'

Is this the right approach when running export/import on Databricks?

I am also getting same issue is there any resolution to this issue?

Try using these Databricks notebooks: https://github.com/amesar/mlflow-export-import#databricks-notebooks


feat(authn): improve jwks refresh retry mechanism

Address race conditions with fetching JWKS with backoff retry logic
Reduce concurrent calls to Refresh when multiple requests in retry logic concurrently
Improve tests to validate number of retries and latency of authentication calls
Prevent a successful KID that has not needed a refresh from resetting backoff retries

@ioneyed these are the changes we discussed related to https://github.com/Permify/permify/issues/1299

Hi @charlie-retzler, thank you for your contribution!


Fix typo upgrading build from 7.x to 8.0

Fixes:

#23021

@bot-gradle test and merge

I've triggered a build for you.


create new key container via CryptAcquireContext

CryptAcquireContext + 0x8 (CRYPT_NEWKEYSET)
From Microsoft:

Creates a new key container with the name specified by pszContainer. If pszContainer is NULL, a key container with the default name is created.

The pszContainer parameter specifies the name of the container that is used to hold the key. Each container can contain one key. If you specify the name of an existing container when creating keys, the new key will overwrite a previous one.

The combination of the CSP name and the key container name uniquely identifies a single key on the system. If one application tries to modify a key container while another application is using it, unpredictable behavior may result.

source: https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptacquirecontexta

closed in #433


CI Build improvements

Seems this patch make the Travis CI build return 1 after all test.

I have no idea why. I'm investigating...

Why is the compilation failing? I don't see an error.

·The command "make -j2" exited with 2.
0.01s$ ./ardb-test
/home/travis/build.sh: line 45: ./ardb-test: No such file or directory
The command "./ardb-test" exited with 127.
0.02s$ popd
~/build/yinqiwen/ardb
The command "popd" exited with 0.
cache.2
store build cache
0.00s
6.48schange detected (content changed, file is created, or file is deleted):
seems '-j2' is not a good options to build dependencies, some 3rd libs are not compiled success before compiling ardb's source.

Oh, so the problem is the makefile? Ok I'll revert that.

I have no idea why the build is hanging. Must be a travis bug...


More boolean operations

Codecov Report

Merging #63 (e0b0823) into main (7b561e1) will increase coverage by 0.08%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #63      +/-   ##
==========================================
+ Coverage   96.80%   96.89%   +0.08%
==========================================
  Files          72       73       +1
  Lines        3319     3381      +62
==========================================
+ Hits         3213     3276      +63
+ Misses        106      105       -1

Flag
Coverage Δ

pytest
96.89% <100.00%> (+0.08%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...nguage/operations/boolean_operation_expressions.py
100.00% <100.00%> (ø)

...egend/core/language/operations/unary_expression.py
100.00% <100.00%> (ø)

pylegend/core/language/primitives/boolean.py
100.00% <100.00%> (+5.26%)
:arrow_up:

...end/tests/core/language/primitives/test_boolean.py
100.00% <100.00%> (ø)


need support for property on Carousel to disable the swipe action

Usecase: when Carousel is being used while creating a onBoarding flow, developer doesn't want the use to just swipe through and pass the whole flow rather developer want to make user go through whole flow and let the Carousel swipe items by pressing buttons.

ticket: https://github.com/EnsembleUI/ensemble/issues/1652
there could be four possible values for scrollType which is bouncing || clamping || neverScrollable || alwaysScrollable and default for iOS is bouncing  and for other is clamping.
Example EDL:
Carousel:
  id: carousel
  styles:
    height: 100
    gap: 20
    layout: auto
    borderColor: blue
    padding: 10
    currentIndex: 0
    indicatorType: rectangle
    indicatorPosition: topCenter
    enlargeCenterPage: true
    indicatorWidth: 10
    indicatorHeight: 2
    indicatorColor: green
    autoplay: true
    autoplayInterval: 3
    scrollType: neverScrollable    # it could be bouncing || clamping || neverScrollable || alwaysScrollable

cc: @amin-nas


Add Create Database

Add the possibility to create a database with the driver ?
https://docs.arangodb.com/3.1/Manual/DataModeling/Databases/WorkingWith.html#create-database

I will be tackling this over the next week along with updates for 3.2 support.

@ronanM complete database management is now integrated.  I'll be doing a new release as soon as I finish testing with 3.2 and RocksDB.


Gitlab workspace integration broken

I have configured a gitlab workspace, it maps to a (gitlab) repository,
I can save file from stackedit and see the files being added and saved to the repo,
but as soon as the synchronization (or save) is complete, the workspace refreshes
the file that I had created disapears, and I see a new workspace with a welome.md file.
I actually never see the files from my repository, it is as if StackEdit could write to my repo
but could not read from it.

@max-l Try to refresh it (when the Welcome file is shown only) with the sync button.
Although, the welcome file is created, it isn't added to the repo, so it works.
It seems that refreshing always works, so you could change the title to something like Automatically synchronize GitLab workspace when opened

Duplicate of #1505


Why is Unicode Character U+202F in action.yml

Opening the action.yml file shows the U-202F code in various locations:

@briglx we shall investigate this and keep you posted.

Hey @briglx. It's just a NARROW NO-BREAK SPACE character and was perhaps introduced previously to prevent an automatic line break. It's just like space and shouldn't affect any functionality. If you are not comfortable with the view you can disable highlighting it and it shows up like a normal space. In vscode you can do this by moving the cursor on that character and adjusting the settings.

Hi @BALAGA-GAYATRI, thanks for the clarification.


gha: drop the GKE-based multicluster workflow from stable branches

The new kind-based clustermesh workflows ported to all stable branches in #25029 have now run for a while in parallel with the old ones, and they seems comparably stable while covering more scenarios. Hence, let's drop the old ones, as we already did in #24996 for main.

Fixes: #issue-number
Drop the GKE-based multicluster GitHub actions workflow in favor of the kind-based ones (stable branches)

Reviews are in, marking as ready to merge as gha changes only.


Packaging of puppet RPM fails due to path error in source archive

When archiving all the puppet scripts for inclusion into the tarball distribution and the geowave-puppet rpm I included the full path on disk instead of relative to the geowave directory causing a downstream packaging script to fail.

Fixed with #181


Twillo SMS Alerts

⚠ Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find similar feature request

🏷 Feature Request Type
New Notification
🔖 Feature description
Receiving notification via SMS with Twilio
✔ Solution
Add Twillo as a SMS option for Notifications
❓ Alternatives
No response
📝 Additional Context
No response

This would be awesome.

I opened a feature request for this.
If anyone else can vote on it, that would be great!!
https://feedback.userreport.com/25a3cb5f-e4bd-4470-b6f3-79fcfaa8e90f/#idea/392193

+1

Hmm... I'm on a latest Kuma and I see Twilio option so it seems it's already there?
However, I would like to add/ask option to log-in via API Key instead of using master AccountSID and AuthToken. See https://www.twilio.com/docs/usage/requests-to-twilio#creating-or-updating-resources-with-the-post-method
Basically one can either use const client = require('twilio')(accountSid, authToken); or const client = require('twilio')(apiKey, apiSecret, { accountSid: accountSid });, where the second one is more secure and thus recomended.

Any PR adding such functionality is likely to be added to master.

please also go into detail what you mean by "more secure and thus recommended"
The problem with the notification providers is, that they are for the most part untested/untestable.
=> Screenshots are needed to verify that this change works.

needed change (using curl, as imo this is more readable):

@SecureCPU  given that this is in uptime kuma since #2980 (this issue was a duplicate => was missed in the autocloing), please close this issue 😅

@CommanderStorm considering this issue got closed I went with followup: https://github.com/louislam/uptime-kuma/issues/3204


Add native wake lock API support

This PR contains a:

[ ] bugfix
[X] new feature
[ ] code refactor
[ ] test update
[ ] typo fix
[ ] metadata update

Motivation / Use-Case
See discussion in https://github.com/richtr/NoSleep.js/issues/83.
Additional Info
Currently the build is pretty wasteful, since the videos are bundled no matter what. It would probably be a good idea to switch to dynamic import()s in the future.

(Supersedes https://github.com/richtr/NoSleep.js/pull/64 by @knee-cola.)

(minor nit: I will be removing the defunct package-lock.json additions in a subsequent commit on master before releasing as 0.11.0.)

Duh, sorry! I was messing around with dependencies but in the end decided to leave it as is, and forgot to reset to the previous state.


Folds without initial acc

@arkgil I have changed the docs related to all folds so that they mention accumulator.
Hopefully it's much clearer now.


Added screenshots

Hopefully that doesn't (completely) ruin the joke

I think this big change merits a 3.0 version (so big that skips the 2.X)

I think this big change merits a 3.0 version (so big that skips the 2.X)

Genius! Working on it now


No nfs

I think I found q... now what?

Codecov Report
Base: 90.70% // Head: 90.15% // Decreases project coverage by -0.55% :warning:

Coverage data is based on head (daae6bc) compared to base (43305d6).
Patch coverage: 78.94% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #60      +/-   ##
==========================================
- Coverage   90.70%   90.15%   -0.56%
==========================================
  Files          38       38
  Lines        1011     1066      +55
==========================================
+ Hits          917      961      +44
- Misses         94      105      +11

Impacted Files
Coverage Δ

librarian/urls.py
100.00% <ø> (ø)

librarian/api/views/document_views.py
84.25% <41.17%> (-6.66%)
:arrow_down:

librarian/utils/google_cloud_vision.py
44.44% <50.00%> (+11.11%)
:arrow_up:

librarian/api/serializers.py
97.27% <100.00%> (+0.30%)
:arrow_up:

tests/api/views/test_document_views.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Fix 'i' option

It is single dash, not double dashes.
See also

https://github.com/davetcoleman/roscpp_code_format

Hmmm, seemed like the other way works too, but sure


conda: init at miniconda 4.3.11

Motivation for this change
Things done

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

[ ] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Shameless copy from https://github.com/NixOS/nixpkgs/issues/26245. Thanks @jluttine !
cc @layus

To do:

[ ] rename to miniconda?
[ ] miniconda3 (3.6) and miniconda (2.7)
[ ] darwin, though out of scope for this PR
[ ] fix meta

Works for me :-).
Strange enough, trying to run anaconda-navigator fails unless I set USER env var. Could we add this one to the environment ?

I'm not sure what exactly is meant by the suggestion "rename to miniconda" so I thought I'd give my comment: It's possible to add different installers for Miniconda vs Anaconda and Python 2 vs 3. So one could replace conda-install with four different installers miniconda-install, miniconda3-install, anaconda-install and anaconda3-install if wanted. The current conda-install is Python 3 miniconda installer. But in other places I would keep the term conda instead of renaming to miniconda because Miniconda is just a minimal installer for Conda and its dependencies. That is, I would keep the default path ~/.conda, the command load-conda-shell and the package name conda as such.

@layus

Strange enough, trying to run anaconda-navigator fails unless I set USER env var. Could we add this one to the environment ?

Maybe we can just passthru the current environment somehow? I suppose this issue didn't exist when using nix-shell.
@jluttine what I mean is to indeed add all installers. However, there would be a separate derivation for each and so we keep the name conda-install for each of them.

That is, I would keep the default path ~/.conda, the command load-conda-shell and the package name conda as such.

Definitely

@FRidh I'm not too familiar with the "derivation" term. So how would the users use the different installers?
Something like this:
nix-env -iA miniconda3
load-conda-shell
conda-install

or
nix-env -iA conda
load-miniconda3-shell
conda-install

or
nix-env -iA conda
load-conda-shell
miniconda3-install

or something else? I mean, at what point and how users choose the installer?

@jluttine
nix-env -iA conda.miniconda3
load-conda-shell
conda-install

Ok. Indeed, adding all installers inside the conda shell would cause downloading all the installers to nix store even if only one of them is used inside the conda shell. However, this could be avoided if instead of downloading the miniconda/anaconda installers to store, we would just add simple scripts (e.g., miniconda3-install) which fetch the correct installer from the Continuum repo only when called.
So, for instance, miniconda3-install would look something like:
wget https://repo.continuum.io/miniconda/Miniconda3-${version}-Linux-x86_64.sh -O /tmp/miniconda.sh
chmod +x /tmp/miniconda.sh
bash /tmp/miniconda.sh -b -p ${installationPath}

And similarly for miniconda-install, anaconda-install and anaconda3-install. Then we could have all the installers inside one derivation conda and the user can use whichever (s)he prefers without the overhead of having multiple big Anaconda installers in nix store. But is this approach bad in some other way?

@layus
Strange enough, trying to run anaconda-navigator fails unless I set USER env var. Could we add this one to the environment ?

Maybe we can just passthru the current environment somehow? I suppose this issue didn't exist when using nix-shell.

Well, I have no idea, I didn't use nix-shell. But it's not really important for the release.

Is there any hope of getting this merged any time soon?

Hello,
Is there anything happening here?

Closing in favor of https://github.com/NixOS/nixpkgs/pull/34872.


Upgrade to Hibernate ORM 6

We should at least start to have a look at this.

#1052?

My bad, I looked for it but didn't find it.


AL <IP_ADDRESS>: updater cannot upgrade any service

Describe the bug
After upgrading to <IP_ADDRESS>, AssemblyLine isn't able to upgrade any service. However, the upgrade looks successful if I tried to start a container with the new service image manually. I see a couple of errors from starting containers (about ODM schema), but I'm unable to say if they come from the update container (I guess they are not - I see errors from update and privileged services, even if I try to upgrade a regular service). My suspicious is, that for some reason the updating thread is silently failing before even starting the container.
Have you seen anything like this, or should I try to add some additional logs/try-except in the updater container?
To Reproduce
Steps to reproduce the behavior:

Upgrade AssemblyLine to v27
Try o update any service.

This is an example log from the updater, here for Swiffer (I tried with a few different services):
{"@timestamp": "2024-05-28 20:27:47,142", "event": { "module": "assemblyline", "dataset": "assemblyline.service.updater" }, "host": { "ip": "<IP_ADDRESS>", "hostname": "feade7f10c47" }, "log": { "level": "INFO", "logger": "assemblyline.service.updater" }, "process": { "pid": "1" }, "message": "[CU] Service Swiffer is being updated to version 4.5.0.stable6..."}
{"@timestamp": "2024-05-28 20:27:47,143", "event": { "module": "assemblyline", "dataset": "assemblyline.service.updater" }, "host": { "ip": "<IP_ADDRESS>", "hostname": "feade7f10c47" }, "log": { "level": "INFO", "logger": "assemblyline.service.updater" }, "process": { "pid": "1" }, "message": "[CI] Installing all services marked for install..."}
{"@timestamp": "2024-05-28 20:27:47,146", "event": { "module": "assemblyline", "dataset": "assemblyline.service.updater" }, "host": { "ip": "<IP_ADDRESS>", "hostname": "feade7f10c47" }, "log": { "level": "INFO", "logger": "assemblyline.service.updater" }, "process": { "pid": "1" }, "message": "[CI] Done installing services, waiting 60 seconds for next install..."}
{"@timestamp": "2024-05-28 20:28:03,531", "event": { "module": "assemblyline", "dataset": "assemblyline.service.updater" }, "host": { "ip": "<IP_ADDRESS>", "hostname": "feade7f10c47" }, "log": { "level": "ERROR", "logger": "assemblyline.service.updater" }, "process": { "pid": "1" }, "message": "[CU] Service Swiffer has failed to update because resulting service key (Swiffer_<IP_ADDRESS>) does not exist. Update procedure cancelled..."}

If I tried a following command (for Sigma which also couldn't be updated by AL, & I reused the network created by AL for the Safelist):
docker run --env SERVICE_API_HOST=http://service-server:5003 --env SERVICE_API_KEY=***--network assemblyline_service-net-Safelist --name test_al <registry cache>/cccs/assemblyline-service-sigma:4.5.0.stable7

It's successful and AL recognize the new version.
Expected behavior
Services are upgraded
Screenshots
Environment (please complete the following information if pertinent):

Assemblyline Version: <IP_ADDRESS>, docker compose
Browser: [e.g. chrome, safari]

Additional context
Here an example from errors I see in logs, but I think they should be gone after service upgrade and are unrelated:
May 28 20:07:01 docker2 270d7f531c45[2288004]: Traceback (most recent call last):
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "<frozen runpy>", line 198, in _run_module_as_main
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "<frozen runpy>", line 88, in _run_code
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/opt/al_service/badlist/update_server.py", line 19, in <module>
May 28 20:07:01 docker2 270d7f531c45[2288004]:     from assemblyline_v4_service.updater.updater import ServiceUpdater
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/assemblyline_v4_service/updater/updater.py", line 27, in <module>
May 28 20:07:01 docker2 270d7f531c45[2288004]:     from assemblyline_v4_service.common.base import SIGNATURES_META_FILENAME
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/assemblyline_v4_service/common/base.py", line 20, in <module>
May 28 20:07:01 docker2 270d7f531c45[2288004]:     from assemblyline_v4_service.common.api import PrivilegedServiceAPI, ServiceAPI
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/assemblyline_v4_service/common/api.py", line 5, in <module>
May 28 20:07:01 docker2 270d7f531c45[2288004]:     from assemblyline_core.badlist_client import BadlistClient
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/assemblyline_core/badlist_client.py", line 7, in <module>
May 28 20:07:01 docker2 270d7f531c45[2288004]:     from assemblyline.datastore.helper import AssemblylineDatastore
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/assemblyline/datastore/helper.py", line 29, in <module>
May 28 20:07:01 docker2 270d7f531c45[2288004]:     from assemblyline.odm.models.result import Result
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/assemblyline/odm/models/result.py", line 32, in <module>
May 28 20:07:01 docker2 270d7f531c45[2288004]:     constants = forge.get_constants()
May 28 20:07:01 docker2 270d7f531c45[2288004]:                 ^^^^^^^^^^^^^^^^^^^^^
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/assemblyline/common/forge.py", line 123, in get_constants
May 28 20:07:01 docker2 270d7f531c45[2288004]:     config = get_config()
May 28 20:07:01 docker2 270d7f531c45[2288004]:              ^^^^^^^^^^^^
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/assemblyline/common/forge.py", line 117, in get_config
May 28 20:07:01 docker2 270d7f531c45[2288004]:     config_cache[yml_config] = _get_config(yml_config=yml_config)
May 28 20:07:01 docker2 270d7f531c45[2288004]:                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/assemblyline/common/forge.py", line 94, in _get_config
May 28 20:07:01 docker2 270d7f531c45[2288004]:     yml_data = yaml.safe_load(env_substitute(yml_fh.read()))
May 28 20:07:01 docker2 270d7f531c45[2288004]:                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/yaml/__init__.py", line 125, in safe_load
May 28 20:07:01 docker2 270d7f531c45[2288004]:     return load(stream, SafeLoader)
May 28 20:07:01 docker2 270d7f531c45[2288004]:            ^^^^^^^^^^^^^^^^^^^^^^^^
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/yaml/__init__.py", line 81, in load
May 28 20:07:01 docker2 270d7f531c45[2288004]:     return loader.get_single_data()
May 28 20:07:01 docker2 270d7f531c45[2288004]:            ^^^^^^^^^^^^^^^^^^^^^^^^
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/yaml/constructor.py", line 51, in get_single_data
May 28 20:07:01 docker2 270d7f531c45[2288004]:     return self.construct_document(node)
May 28 20:07:01 docker2 270d7f531c45[2288004]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/yaml/constructor.py", line 60, in construct_document
May 28 20:07:01 docker2 270d7f531c45[2288004]:     for dummy in generator:
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/yaml/constructor.py", line 413, in construct_yaml_map
May 28 20:07:01 docker2 270d7f531c45[2288004]:     value = self.construct_mapping(node)
May 28 20:07:01 docker2 270d7f531c45[2288004]:             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/yaml/constructor.py", line 218, in construct_mapping
May 28 20:07:01 docker2 270d7f531c45[2288004]:     return super().construct_mapping(node, deep=deep)
May 28 20:07:01 docker2 270d7f531c45[2288004]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/yaml/constructor.py", line 143, in construct_mapping
May 28 20:07:01 docker2 270d7f531c45[2288004]:     value = self.construct_object(value_node, deep=deep)
May 28 20:07:01 docker2 270d7f531c45[2288004]:             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/yaml/constructor.py", line 100, in construct_object
May 28 20:07:01 docker2 270d7f531c45[2288004]:     data = constructor(self, node)
May 28 20:07:01 docker2 270d7f531c45[2288004]:            ^^^^^^^^^^^^^^^^^^^^^^^
May 28 20:07:01 docker2 270d7f531c45[2288004]:   File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/yaml/constructor.py", line 427, in construct_undefined
May 28 20:07:01 docker2 270d7f531c45[2288004]:     raise ConstructorError(None, None,
May 28 20:07:01 docker2 270d7f531c45[2288004]: yaml.constructor.ConstructorError: could not determine a constructor for the tag 'tag:yaml.org,2002:python/object:assemblyline.odm.base.TypedMapping'
May 28 20:07:01 docker2 270d7f531c45[2288004]:   in "<unicode string>", line 451, column 15:
May 28 20:07:01 docker2 270d7f531c45[2288004]:           INGEST: !!python/object:assemblyline.odm ...
May 28 20:07:01 docker2 270d7f531c45[2288004]:                   ^

Hmm... I wonder if it has anything to do with:
https://github.com/CybercentreCanada/assemblyline-base/blob/90ba51e38c3e0e3bf01c8b1f4541902a89208ed0/assemblyline/odm/models/config.py#L1903
At least based on the last line of the error and that was the only new thing added to the Config ODM in the new release. Surprised I haven't seen this..

Could it be perhaps something related to your configuration? I just checked our logging stack and found no mention of the error, so I suspect it could be a parsing error for the metadata enforcement configuration that's causing the error to be raised.
I would suspect to see this error in the other core containers as well since they should all call forge.get_config()

It may be, I have indeed tried to configure it, and for some reasons I didn't try the upgrade without configuring metadata. But the core containers didn't have any such problem, just privileged services and update containers. Anyway, I'll check it and come back, thanks for the tip

The current state of debugging:

I have removed the submission key from the config at all & re-updated AL, tried to update any service - no success.
As so, I started adding logs to the updated, and I ended up with information from the L131 (https://github.com/CybercentreCanada/assemblyline-core/blame/167dd89cbc2299321b4c3a13abde9a73823abab5/assemblyline_core/updater/run_updater.py#L131) that container excited with an unsuccessful status code.
After getting the ID of the launched container, I managed to connect issues from logs with it, and this indeed the issue from ODM.

Now I'm looking into what exactly causes the failure.

And we have the winner - what is, indeed, the default config for metadata. However, this is not what core services see. They see the original configuration I wrote, but all privileged services, including the container for updating, gets the configuration prepared by the scaler. It looks like the scaler doesn't understand the dumping it well - here is what it produces:
 max_temp_data_length: 4096
  metadata:
    archive: {}
    ingest:
      INGEST: !!python/object:assemblyline.odm.base.TypedMapping     <----- Line 451, as in the traceback
        index: false
        sanitizer: !!python/object/apply:re._compile
        - ^[A-Za-z0-9_ -.]*$
        - 32
        store: false
        type: !!python/object:assemblyline.odm.base.Compound
          ai: true
          child_type: !!python/name:assemblyline.odm.models.config.Metadata ''
          copyto: []
          default: null
          default_set: false
          deprecation: null
          description: null
          getter_function: null
          index: false
          multivalued: false
          name: null
          optional: false
          parent_name: null
          setter_function: null
          store: false
    submit: {}

I'm not entirely sure, but it looks like a dump of the TypedMapping object itself, not the data. Setting any configuration or removing the INGEST key doesn't help either. It looks like a difference between docker compose and kubernetes deployment, so you maight not see it.

It also explains why my manual update worked - I didn't mount the prepared configuration, and things necessary for the service registration are still equal to defaults (yeah, I know they shouldn't, but it's still a hobby setup ;)), so it worked without them.

Hmm... so it would stand to reason that if you were to shell into the Scaler container, then running:
from assemblyline.common import forge
forge.get_config().submission.metadata.as_primitives()

Should yield the same error/garbage output?

Not exactly, but it does not return really primitives. Let's have a look, all in the scaler container of the AL v27:
>>> c = forge.get_config().as_primitives()
>>> c["submission"]
{'default_max_extracted': 500, 'default_max_supplementary': 500, 'dtl': 30, 'emptyresult_dtl': 5, 'max_dtl': 0, 'max_extraction_depth': 6, 'max_file_size': 524288000, 'max_metadata_length': 4096, 'max_temp_data_length': 4096, 'metadata': {'archive': {}, 'submit': {}, 'ingest': {'INGEST': {}}}, 'sha256_sources': [], 'file_sources': [], 'tag_types': {'attribution': ['attribution.actor', 'attribution.campaign', 'attribution.exploit', 'attribution.implant', 'attribution.family', 'attribution.network', 'av.virus_name', 'file.config', 'technique.obfuscation'], 'behavior': ['file.behavior'], 'ioc': ['network.email.address', 'network.static.ip', 'network.static.domain', 'network.static.uri', 'network.dynamic.ip', 'network.dynamic.domain', 'network.dynamic.uri']}, 'verdicts': {'info': 0, 'suspicious': 300, 'highly_suspicious': 700, 'malicious': 1000}}
>>> # ^ Looks okay
>>> d = yaml.dump(c)
>>> "!!python/object:assemblyline.odm.base.TypedMapping" in d
True
>>> d
' ... \n  metadata:\n    archive: {}\n    ingest:\n      INGEST: !!python/object:assemblyline.odm.base.TypedMapping\n        index: false\n        sanitizer: !!python/object/apply:re._compile...'
>>> # But dumped wrongly
>>> type(c)
<class 'dict'>
>>> type(c["submission"])
<class 'dict'>
>>> type(c["submission"]["metadata"])
<class 'dict'>
>>> type(c["submission"]["metadata"]["ingest"])
<class 'dict'>
>>> type(c["submission"]["metadata"]["ingest"]["INGEST"])
<class 'assemblyline.odm.base.TypedMapping'>
>>> # ^ Because it's not a dict

I think I know a solution to fix that 😁

You can try testing with the 4.5.1.dev166 release to make sure there aren't any other issues that <IP_ADDRESS> introduced for the Docker deployments.

I confirm with this release updating works and services look like functioning as well, thanks!
BTW I love the re-design, when does it come to the stable branch?

I can include the patch in the next stable, once the PR is approved!
The update to the iconography was included in the <IP_ADDRESS> release we pushed yesterday 😁

This should be patched in the <IP_ADDRESS> release.

Thanks, I've just installed it and can confirm it works :)

Hey, I think we both didn't test the service properly... I run it with the default configuration, but not with really configured metadata. When I played with metadata, the scaler service wasn't happy again:
{"@timestamp": "2024-06-04 16:53:41,417", "event": { "module": "assemblyline", "dataset": "assemblyline.scaler" }, "host": { "ip": "x.x.x.x", "hostname": "2a55612146dd" }, "log": { "level": "INFO", "logger": "assemblyline.scaler" }, "process": { "pid": "1" }, "message": "Found the service server at: b1d0d55f6dc96d9942b27fc5dfd5060e5e5cfaca41e17b24a58faf5c425c7e84 [assemblyline-service_server-1]"}
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/assemblyline_core/scaler/run_scaler.py", line 6, in <module>
    with ScalerServer() as scaler:
         ^^^^^^^^^^^^^^
  File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/assemblyline_core/scaler/scaler_server.py", line 365, in __init__
    yaml.dump(json.loads(self.config.json()), handle)
                         ^^^^^^^^^^^^^^^^^^
  File "/var/lib/assemblyline/.local/lib/python3.11/site-packages/assemblyline/odm/base.py", line 1403, in json
    return json.dumps(self.as_primitives())
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/json/__init__.py", line 231, in dumps
    return _default_encoder.encode(obj)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/json/encoder.py", line 200, in encode
    chunks = self.iterencode(o, _one_shot=True)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/json/encoder.py", line 258, in iterencode
    return _iterencode(o, 0)
           ^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/json/encoder.py", line 180, in default
    raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type Metadata is not JSON serializable

However, it looks to be a problem with the ingest metadata declaration (which I don't need anyway, so it's not a big issue for me), because the following configuration fails:
...
submission:
  metadata:
    submit:
      python.package_name:
        validator_type: text
        required: false
      python.uploader:
        validator_type: text
        required: false
    ingest:
      INGEST:
        python.package_name:
          validator_type: text
          required: false

but when I remove the ingest key entirely, the scaler service is working again. It looks like either I misunderstood the expected config syntax, or the as_primitives does not handle the ingest definition properly


Order by best match when searching

The search option is really great, however would be nice to have a option to filter by best match.
One option would offer the possibility to enable this feature like :
class Constants:
     # ....
     enable_search_weight: bool = False

In this case, when searching, it will apply an order on the weight of the search: one example for the weight is to sort by the length of the field(s) searched : https://stackoverflow.com/questions/15471718/how-to-sort-results-by-string-length-on-mongodb

It is easy to override the Filter.sort method and apply your custom sorting. I'm not familiar with mongodb but this looks promising: https://www.mongodb.com/docs/manual/core/indexes/index-types/index-text/control-text-search-results/
Don't forget to provide a PR when your implementation is ready!


dbeaver/dbeaver#22479 Remove JNA deps from MySQL, PostgreSQL an Oracl…

…e. Win registry read moved to the registry bundle.

verified

correction confirmed. thanks !


Add getMasterCopies to IChainsRepository

Adds getMasterCopies to IChainsRepository so that routes can use it

Coverage remained the same at 90.127% when pulling 8227f982d65ac950e1302118d257ab520a26c600 on master-copies-interface-function into fa4cbcab619a30a6588c58f852c109801e18ff84 on main.


Fix two-stage runtime error when empty proposal

Motivation
Fix two-stage runtime error when empty proposal
Resolve: https://github.com/open-mmlab/mmdetection/issues/5037
Modification
All two-stage models deal with the case of empty proposal specially.

Add unitests for empty rois can be better

done


Eric filter enhancement

Note that although both dropdown menus are implemented on the frontend, only gender_filter is available on the backend currently. I'll make further changes when app.py is modified to accept both filtering factors.
For now, if you pick a race, the graph will automatically return to the no-filter state, no matter what value is in "Gender".

The race filter and gender filter should update different variables, filter_race and filter_gender respectively. I believe it would be better and cleaner if we did it through a dictionary. So pass through an empty dictionary filters = {} when there are no selected filters, or you can pass through filters = {race_filter = None, gender_filter = None), up to you which one you think is easier/better when there are no selected filters.
And when a filter is selected pass through a dictionary like filters = { race_filter: "Asian", gender_filter: "woman"}

I'll make this change after the corresponding backend is implemented (or at least a fake hardcode).

I'll make this change after the corresponding backend is implemented (or at least a fake hardcode).

The backend is implemented, if you look at DataFormatter.filter_by, it has many available filter_type inputs

For now, both filter works. When both filters are applied (especially the race filter), the prediction data may not be available. This issue is brought by the discontinuity of the pastData after applying filter. I'll create a new ticket for this.


chore: push WRK output into the bencher

Currently we run the benchmarks on main and PRs where ci: benchmark is added. The result of the benchmark is commented on the PR. We need to continue doing it but also start pushing that data into   bencher.dev
Here are some of the links to get started:

https://bencher.dev/docs/explanation/adapters/#-json
https://github.com/wg/wrk/blob/master/scripts/report.lua

/attempt #1993