Zerotier OPNSense interface binding

Continuing from https://github.com/opnsense/core/issues/1775.
Per @dharrigan :

Let me do some more testing on binding to interfaces (I may need some help from the OPNsense core team on this one).

My eventual goal is to use BGP or OSPF over a Zerotier "virtual switch" between a bunch of OPNSense routers.
@dharrigan I'm no core team (or even peripheral team) member, but I'm happy to test and debug!

FWIW, there is a new "lock interface" feature since 17.7.1 as well, maybe that's already enough. It's untested with zerotier, so "don't do this at home" (yet).

Will investigate! :-)
-=david=-

Another note, it seems when I bind ZT to an interface in OPNSense and enable DHCP for IPv4 (wasn't sure what auto-assign in ZT uses), a few things happened:

My system lost its default gateway, and had to be rebooted to regain it
The interface didn't get an IP via auto-assign (though the ZT interface showed the IP in a shell session)

Let me know how I can help! I'm a fairly experienced linux sysad, and semi-know my way around nets.

+1, lost my gateway as well when trying out Zerotier with DHCPv4 as IP scheme.

Hi,
Thank you for the feedback. I hope to look into this over the course of this weekend. :-)
-=david=-

@StrikerTwo can you clarify please - are you attempting to use DHCPv4 on the Zerotier interface within OPNsense, or have you defined the auto-assigned IP address range in my.zerotier.com? Thank you.

@dharrigan to speak for myself, I set that on the ZT interface in OPNSense, but also set auto-assigned IPs in my.zerotier.com (thinking ZT central would use DHCP as a protocol for ipv4, but that's probably naive).

@dharrigan I tried to use DHCPv4 on the Zerotier interface. My gateway was gone immediately, so I don't think it even had time to connect to Zerotier and get an IP.

Hi,
I've been doing some investigation. More to do, but this works for me:
I created a new network on zerotier WITHOUT enabling autoassign of IP addresses (I believe it's best, otherwise OPNsense will get confused when it brings up/down interfaces - more investigation required). In effect, you are saying that you will assign the IP addresses to each node, either statically or via DHCP.
I can confirm that if you do that, then you can enable DHCP on the zerotier interface (after assignment) within OPNsense then other nodes joining the network will be issued DHCP addresses from the pool you specify.
I chose a subnet of <IP_ADDRESS>/16 (others will work too) on my.zerotier.com.
I installed the plugin on OPNsense and enabled the service (so that the green play button shows).
I then added the network id I created above to the VPN...Zerotier form and enabled the network (from OPNsense's point of view).
I checked that the node (running opnsense) showed up on my.zerotier.com and authorized it to connect.
On OPNsense, I then when to interface assignments and assigned the new zerotier interface to a new interface (OPT1). I went into OPT1 and gave the interface a static IP address of <IP_ADDRESS>/16.
On a completely separate computer in another country I installed zerotier one, joined the network created above, went into my.zerotier.com and authorized the node, then on the node I did:
ip addr add <IP_ADDRESS>/16 dev zt0
I confirmed that the zt0 interface was assigned the IP address and that the route for <IP_ADDRESS>/16 was set to go out via zt0.
Back on OPNsense, I went into the firewall rules configuration, selected OPT1 and allowed all traffic to pass (don't forget, that as soon as you assign an interface, that interface falls under the same firewall rules as other interfaces, so you have to allow IPV4/6 to flow as suitable for your requirements).
I was then able to ping (and ssh) from the remote node to the OPNsense box via <IP_ADDRESS> and vice-versa, I was able to ssh (and ping) to the remote node of <IP_ADDRESS> from OPNsense.
Further, I removed the IP from the remote node, then after configuring DHCP (with a pool of <IP_ADDRESS> to <IP_ADDRESS>) on OPNsense on the OPT1 interface, I was able to do dhclient -v zt0 on the remote node and I was assigned an appropriate IP and was able to still ssh/ping to and from remote node and OPNsense node, and the DHCP lease showed up on OPNsense for the remote node.
So, right now, I have a bi-directional secure VPN network between two different nodes witin the zerotier network, with one of those nodes being OPNsense and allowing me to do all the interface things I would expect.
I believe, given this configuration so far, things like Quagga, or any other services that can bind to interfaces would work as expected.
I'm still doing some investigation on a few things, but let me know if you can replicate this.
I didn't observe my gateway go down. If it goes down, can you provide me some more details please?
Hope this helps!
-=david=-

I do not doubt that you can get it to work. Still, (maybe naively) selecting DHCPv4 on the Zerotier interface should not leave the system without a working gateway.
Maybe the problem is that my WAN address gets assigned via DHCPv4 as well?

Hi,
Thank you for the reply. My WAN interface is assigned via DHCP too
(although I connect my OPNsense router to the modem via PPPoE). In my test
rig, I configured my WAN interface to use DHCP too and I was unable to
reproduce the issue you have observed, but let me do some more testing. Can
you let me know if, by following my previous post, it works for you? If it
still fails, please do let me know what your route table is like (netstat
-nr) and perhaps logging what the system log shows (clog -f
/var/log/system.log) would be helpful too.
In all my previous experiences of Zerotier, it has never replaced the
default gateway (as you should be using a different subnet from your own
LAN network, i.e., if you LAN subnet is <IP_ADDRESS>/24 you should create a
Zerotier network like <IP_ADDRESS>/24 or <IP_ADDRESS>/16 - something like
that - otherwise, yes, Zerotier would assume control of your LAN as the IP
addresses are the same!) Can you confirm your LAN is different from the
network subnet you are using on Zerotier?
Thank you.
Let me know how you get along!
-=david=-
On 3 September 2017 at 08:46, StrikerTwo<EMAIL_ADDRESS>wrote:

I do not doubt that you can get it to work. Still, (maybe naively)
selecting DHCPv4 on the Zerotier interface should not leave the system
without a working gateway.
Maybe the problem is that my WAN address gets assigned via DHCPv4 as well?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opnsense/plugins/issues/239#issuecomment-326789690,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAaEji70qf1IOuiSaUPgiz0KcMRR9nrOks5selk7gaJpZM4PJSB8
.

--
I prefer encrypted and signed messages.
Fingerprint: 110A F423 3647 54E2 880F ADAD 1C52 85BF B20A 22F9
No trees were harmed in the sending of this message, however, a number of
electrons were inconvenienced.

Yes, my LAN network (<IP_ADDRESS>/8) is quite different from the Zerotier range.
But again, I think the problem is that I selected DHCPv4 as IP method on the Zerotier interface. According to your description, you always used static IPs in OPNsense on the Zerotier interface (OPT1 in your post).
It would be okay if that didn't work and I had to assign IPs manually. But with the default gateway gone it didn't even connect to Zerotier. And Zerotier should never be the default gateway, anyway.
I can do some more testing myself next week to see if I can isolate the problem and/or provide you with logs.

Hi,
Thank you. Do let me know how it goes. You can chat to me on freenode (#opnsense) if you want.
-=david=-

Okay, I tried again, on a fresh OPNsense VM.
zerotier-cli join worked, the device showed up on my.zerotier.com.
I then assigned the ZT interface to OPT1, activated it and set it to DHCP. And now my box is offline because it expects ZT to provide the default gateway:

Although my real gateway is still the default set in the GUI:

Hi,
Did you try to set the interface to a static IP as discussed above, rather than DHCP?

Yes, I did. That works. But
a) I would like to use the ZT auto-assign method, and
b) the system shouldn't do something I didn't tell it to ;)
Are you saying DHCP is generally unsupported with the ZT plugin? Because I could live with that, but it should be documented somewhere.

Hi,
That's great news that it works with a static IP, I'm very happy to hear
that. With regards the other points:

I'll do some testing with the auto-assign on the ZT network, although I
do believe you still need your interface IP to be statically assigned.
I firmly agree and I'll see if this is a problem that is because of some
assumptions that the zerotier service does, or something that is inherent
within OPNsense.

DHCP does work with the zerotier plugin, as shown above. Once you've
assigned your interface a static IP (and your zerotier network has
auto-assigned turned off) then you can enable the OPNsense DHCP server for
the zerotier interface and any other node joining your network will have IP
addresses handed out to it by the DHCP server. I've got this to work
successfully for me (as shown above). If, on the otherhand you are asking
if auto-assign of IP addresses is unsupported, then as we have discovered
together, it does seem to be problematic - but perhaps it's just a gap in
my understanding that can be fixed with some more investigation.
I'm putting together some documentation for how to do the basic's with the
plugin - just waiting on the appropriate privileges to push this document
up to the OPNsense documentation repo.
I've really appreciated your comments and feedback on the plugin and I do
hope you find it useful and I thank you for your patience whilst it
improves.
If you're happy with this, I'll close the ticket and raise a ticket for
myself to put in some documentation on getting it to work.
-=david=-
On 4 September 2017 at 12:18, StrikerTwo<EMAIL_ADDRESS>wrote:

Yes, I did. That works. But
a) I would like to use the ZT auto-assign method, and
b) the system shouldn't do something I didn't tell it to ;)
Are you saying DHCP is generally unsupported with the ZT plugin? Because I
could live with that, but it should be documented somewhere.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opnsense/plugins/issues/239#issuecomment-326937485,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAaEjsWQVJVDLtaQPwlxxnNBrwJG3s_Uks5se9yFgaJpZM4PJSB8
.

--
I prefer encrypted and signed messages.
Fingerprint: 110A F423 3647 54E2 880F ADAD 1C52 85BF B20A 22F9
No trees were harmed in the sending of this message, however, a number of
electrons were inconvenienced.

Thank you for your work and your comments.
Are there any drawbacks in running your own DHCP server on the ZT network instead of using the ZT assignment functionality? (Other than it being a SPOF, so it HAS to be online in order for the network to work)

Hi,
I haven't observed any drawbacks from running DHCP on Zerotier - in fact, they support this model, although there is some discussion on the merits of DHCP on Zerotier (see https://github.com/zerotier/ZeroTierOne/issues/322). However, my view at the moment is that since you trust OPNsense (so to speak) and are configuring DHCP on OPNsense, then handing out IP addresses to hosts on your Zerotier network is okay :)
-=david=-

@fichtner Can you close this ticket please and raise a new one to provide Zerotier plugin how-to documentation. Thank you.

Sure, done. :)


Unable to build for Android: Your project requires a newer version of the Kotlin Gradle plugin.

When I try to build my Flutter application get the following error:
Launching lib/host/main.dart on sdk gphone64 arm64 in debug mode...
Running Gradle task 'assembleDebug'...
e: Incompatible classes were found in dependencies. Remove them from the classpath or use '-Xskip-metadata-version-check' to suppress errors
e: /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/META-INF/kotlin-stdlib-jdk7.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
e: /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/META-INF/kotlin-stdlib-jdk8.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
e: /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/META-INF/kotlin-stdlib.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
e: /Users/roygroothulze/.gradle/caches/transforms-3/ffa7656cc9dfa379ef973b2265defda8/transformed/jetified-kotlin-stdlib-common-1.9.10.jar!/META-INF/kotlin-stdlib-common.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (27, 32): Class 'kotlin.coroutines.CoroutineContext' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/coroutines/CoroutineContext.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (30, 5): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (31, 5): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (32, 13): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (36, 5): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (37, 7): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (38, 12): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (39, 7): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (40, 12): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (42, 7): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (43, 12): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (44, 24): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (45, 14): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (46, 12): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (47, 7): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (49, 14): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (54, 20): Class 'kotlin.coroutines.CoroutineContext' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/coroutines/CoroutineContext.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (55, 24): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (56, 7): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (56, 7): Class 'kotlin.coroutines.CoroutineContext' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/coroutines/CoroutineContext.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (57, 16): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (66, 20): Class 'kotlin.coroutines.CoroutineContext' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/coroutines/CoroutineContext.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (67, 24): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (68, 7): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (68, 7): Class 'kotlin.coroutines.CoroutineContext' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/coroutines/CoroutineContext.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (69, 16): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (83, 22): Class 'kotlin.coroutines.CoroutineContext' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/coroutines/CoroutineContext.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (84, 26): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (84, 74): Unresolved reference: orEmpty
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (86, 9): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (86, 9): Class 'kotlin.coroutines.CoroutineContext' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/coroutines/CoroutineContext.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (87, 18): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (95, 5): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (98, 29): Type mismatch: inferred type is String but Nothing was expected
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (100, 16): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (105, 34): Type mismatch: inferred type is String but Nothing was expected
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (106, 35): Type mismatch: inferred type is String but Nothing was expected
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (107, 29): Type mismatch: inferred type is String but Nothing was expected
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (108, 32): Type mismatch: inferred type is String but Nothing was expected
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (115, 20): Unresolved reference: listOf
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (117, 19): Unresolved reference: let
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (118, 25): Unresolved reference: it
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (120, 20): Unresolved reference: let
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (121, 29): Unresolved reference: it
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (123, 14): Unresolved reference: let
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (124, 31): Unresolved reference: it
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (126, 17): Unresolved reference: let
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (127, 26): Unresolved reference: it
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (132, 14): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (134, 14): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class
e: /Users/roygroothulze/.pub-cache/hosted/pub.dev/telemetrydecksdk-0.4.0/android/src/main/kotlin/com/telemetrydeck/telemetrydecksdk/TelemetrydecksdkPlugin.kt: (139, 13): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.
The class is loaded from /Users/roygroothulze/.gradle/caches/transforms-3/f23e86226710681f60594812ddc3fe6d/transformed/jetified-kotlin-stdlib-1.9.10.jar!/kotlin/Unit.class

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':telemetrydecksdk:compileDebugKotlin'.
> A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction
   > Compilation error. See log for more details

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 5s

┌─ Flutter Fix ──────────────────────────────────────────────────────────────────────────────┐
│ [!] Your project requires a newer version of the Kotlin Gradle plugin.                     │
│ Find the latest version on https://kotlinlang.org/docs/releases.html#release-details, then │
│ update /Volumes/FileContainer/Softwareprojecten/bookgrinder/android/build.gradle:          │
│ ext.kotlin_version = '<latest-version>'                                                    │
└────────────────────────────────────────────────────────────────────────────────────────────┘
Error: Gradle task assembleDebug failed with exit code 1

When I remove the TelementryDesk SDK the issue is gone. After adding it again the issue is back

Hi @roygroothulze, could you please try updating the Kotlin version in your project as indicated by the message and set it to ext.kotlin_version = '1.9.25'

Thank you! The issue is fixed


add all errors to js CompositeParserException so it can be inspected later

useful when plugging into an ace editor worker

Thanks!


Client hangs forever when engine crashes

Describe the bug
When the engine crashes or hangs, the client will wait at the semaphore forever. This will make automated testing infeasible.
Expected behavior
When the engine crashes, the client should crash too.

We could make a watchdog thread on the client. Whenever the engine signals the client, feed the watchdog. The watchdog checks every 1s, if it hasn't been fed in the meantime, then abort the python process.
We would need to implement some debug=True flag so that when we are developing Holodeck it doesn't kill the client when we are stepping through the engine.

Done in #272


Periodic merge of main with vkp

Merged main with vkp
re-created manifests

Testing:

make all should generate the binary without errors

This change is

no longer needed


unexcepted args

main_attack.py line 550
builder.build_sound  builder.build_frame
fc_dim is unexcepted args, i delete and it worked well ,should i delete it?

Yes, it should be deleted. Please check the latest code and new readme in the repo. I have fixed the issues in the previous version.

For re-producing defense results on the MUSIC dataset, please follow the suggestion in the readme: first combine the MinSim loss to train the av event recognition model (uncomment the loss term in the L468 of main_attack.py ) and then train the defense model.
Please let me know if you have any questions.

Thank you. I'm sorry. I didn't see the new version just now. I still use the previous version just now.

No problem. I should fix these problems earlier. I tried to clean the previous dirty code but forgot to fix the issues.


Missing container image for arm64 architecture

Is your feature request related to a problem? Please describe.

Yes! There's no image to arm64 (raspberry) so when trying to pull lightninglabs/lightning-terminal it fails.
$ docker-compose up litd
Pulling litd (lightninglabs/lightning-terminal:)...
ERROR: manifest for lightninglabs/lightning-terminal:latest not found: manifest unknown: manifest unknown

I know that lnd builds images for arm64 arch. Are there any plans to support it in this project as well?

There is no latest build. You need to specify a version. There is an ARM64 build of v0.6.4-alpha: https://hub.docker.com/layers/lightninglabs/lightning-terminal/v0.6.4-alpha/images/sha256-5dc063001add6bcd54d9b1acbe03c72580517e71afbc55b626d971fc6c4a1d8c?context=explore


Remove Deprecated Builder Classes

Describe the proposal
Remove builder classes that were deprecated in v1.3.0 of Java SDK. To be done in Milestone v1.5 of Java SDK.

duplicate of #601


Best practice installing extra modules

Is there any way to have extra modules installed in this image. E.g. my tests require bcmath module.
How I normally should handle this case? Custom image?

@fatganz, @up9cloud I change the based image for two reasons:

lighter image
flexible image

@fatganz in the new image (avail. soon), the bcmath was enabled.
@up9cloud in the new image (avail. soon), the pdo_* was enabled.

See #39.

@JulienBreux thanks for your time and great job man!


App Configuration Spring Geo Replication - Draft

Description
Adds Geo Replication support to the App Configuration Spring Library

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-spring-cloud-appconfiguration-config

@saragluna Do you know why the listing is failing on spring-cloud-azure-autoconfiguration? It isn't something I changed and I have updated to main.

@saragluna Do you know why the listing is failing on spring-cloud-azure-autoconfiguration? It isn't something I changed and I have updated to main.

Seems like it wasn't caused by the appconfig libs


✨ Add support for ICU locales in InitDB flags

Postgres 15 introduced support for ICU locales.
This PR makes it possible to configure such locales via the initdb field of the cluster spec.

Superseded by #6220


[WIP] initial edit user

Still need to verify that everything is working:

[ ] Add post and delete actions
[ ] Add creation of a new user
[ ] Add offsprings when available (or when they are defined)
[ ] Copy RSPEC for all actions

Coverage decreased (-0.2%) to 75.697% when pulling 9d9db2873f1966c8f671cf923b150460553a6106 on add_user_view_to_admin into ef8b6b844bff5833248f2cde20f2d28033fa6dd8 on master.

Coverage increased (+4.2%) to 80.08% when pulling 8e6e4fee3690c62461a2938e73efd97943db39af on add_user_view_to_admin into ef8b6b844bff5833248f2cde20f2d28033fa6dd8 on master.

Coverage increased (+4.2%) to 80.08% when pulling 53871d700e4173bc9483473e1e86b66ae4081914 on add_user_view_to_admin into ef8b6b844bff5833248f2cde20f2d28033fa6dd8 on master.

Coverage decreased (-1.4%) to 74.545% when pulling 979cd849ccdd029c5aefb31b0528e2c5d504f67d on add_user_view_to_admin into ef8b6b844bff5833248f2cde20f2d28033fa6dd8 on master.

Coverage decreased (-0.4%) to 75.458% when pulling 28db0ee037c4030d6d5d51783f198709f598a787 on add_user_view_to_admin into e488108c37a926d7800d05bdb51a7a3fc65592bf on master.


Usage

Hi there, how do you use this library?

Follow: https://github.com/leeeboo/stryd/blob/main/Client_test.go


QR not working when Android device activate Darkmode

Hi @rosskhanas
Thank you for your hard work in making this awesome package. I'm already used this package for more than 6 months now.
But, I have some reports from my users about this QR. This QR Not work as usual when user activates dark mode in several android devices.
I'm already changed the fgColor, try to revert the other color but still same.  You can see the result like image below:

I'm use this device:

Xiaomi Redmi Note 8
Google Chrome

How are you activating dark mode @idindrakusuma ?
I think this issue is caused by Chrome's dark mode implementation, which is still behind an experimental flag. It seems that if you don't have a dark mode style-sheet, it uses a custom shader. Does it still happen in the latest version of chrome? If so, it would be worth looking at the Chromium bug tracker and maybe reporting it there.

@idindrakusuma I have faced the same problem, and find out that it can be solver by the adding additional setting "bgColor". The most interesting thing that it does not work with black color, but works with others

Looks like not a bug on this lib? Can be closed?


Model compare Sugon

Implemented US10, add select farmbot model to users, display detail and feature of each model and make recommendations

Functionality: Achieved
Readability: Resonable naming. Not enough comments
Structure: Follows existing architecture design
Code Reuse: Correct import
Coding Standards: Reasonable branch name. Unclear commit messages


q filter - full text search on a field

In gitlab by @MohamedHamouGisaia on May 4, 2017, 11:04

In gitlab by @MohamedHamouGisaia on May 4, 2017, 11:04
changed milestone to %4

In gitlab by @MohamedHamouGisaia on May 12, 2017, 11:42
added ~1918368 and removed ~1918367 labels

In gitlab by @sfalquier on May 9, 2017, 09:13
added ~1918367 and removed ~1918909 labels

In gitlab by @MohamedHamouGisaia on May 12, 2017, 11:42
assigned to @MohamedHamouGisaia

In gitlab by @MohamedHamouGisaia on May 17, 2017, 10:09
closed

In gitlab by @MohamedHamouGisaia on May 17, 2017, 10:09
removed ~1918368 label


Investigate the differences between cached and normal icons in the Component Browser.

The PR #5779 introduced cached icon feature on Component Browser icons, as a step in improving its performance. During QA, some differences were spotted, which were small enough to unblock this important feature. Still, we should investigate the issue at some point.
From QA report:

Develop:

Latest commit:

(I judge by the letter "A" in the text input icon.

Not related to GUI2.


[New Feature]Add an in-app Language Translator in Utilities section

In most cases, travelers are not too familiar with a regional language and suffer while trying to communicate in a broken manner. So since the backend is in python we can start some work on this Feature.

Why are you creating this issue here? This is a backend issue.

We can actually directly use this api - https://cloud.google.com/translate/docs/reference/libraries#client-libraries-install-java


Bringing isochrone_open_source branch up-to-date

Re #1237, this:

Brings the PR branch up-to-date with current master and its changes to versioning since Dec
Checks off the first of the five todos, renaming the 'reach' packages to 'isochrone'

Thanks, LGTM. Do you think we should rename Reachability into Isochrone(Algorithm)?

Any preferences here @willcohen?

I think the renames make sense. Apologies for the delay -- as I was giving the refactor a shot I also noticed that the ContourBuilder says it's an adaptation of org.opentripplanner.common.geometry.DelaunayIsolineBuilder, which is LGPL, which means that even if JTS and the other pieces get their license issues resolved, the broader issue will still remain once isochrones get merged in. Does it make sense to try to base this feature off of a different algorithm instead? Sextante is a little old but has a bunch of MIT-licensed GIS algorithms, including some Isolines from TIN. The canonical home for Sextante is here, but I just haven't gotten through adapting this to JTS's object types yet.

LGPL is not a huge problem for now if we document which parts are which license in the NOTICE file. We can solve this later step by step. E.g. in 0.8 we were free of LGPL and we might be free of LGPL in 0.11 again, but this is not a big problem on the server side and on mobile only Android is affected due to the "merging".

Does it make sense to try to base this feature off of a different algorithm instead?

This would be really cool, also to see other advantages (and also disadvantages). Still I would prefer this in a separate PR to avoid further delay.

Okay -- I think I got the rest of the reach -> isochrone renames with this latest commit

Thanks!


Draft the November newsletter

Here are a list of topics https://docs.google.com/document/d/1BvSo7QRHvwLGQ1dsMoFOnlTbvh2IASQ8Kw69wQ5ht1o/edit#


Add generic save_device function

Change panda_utils -> utils.py only, as it already resides in a panda submodule, and have this define the sorting function needed to save a generic device.

Going to reword some of the docstrings, but this effectively solves the use cases both for i22 (from i22-bluesky) and fits nicely into the existing PR on save loading.


GH919: Feature/parse solutionfolder from sln

Refers to #919

@endrton PR can't be merged with current develop, please rebase and ping us when you think it's ready for review.

@devlead I did the rebase, so i think it's ready for review.
It's my first PR, so be frank about it, no sugarcoating. :)

@endrton seems it's merged and not rebased, in it's current state it can't be merged automatically, I'll see if I can take a closer look in a couple of hours and provide some feedback.

Interesting, i've followed this document: about-git-rebase.
Not sure if it matters, but I squashed the commits, thou.

@endrton There's still 9 commits including a merge commit in this PR so something didn't go as planned 😉 I'm not at computer now, but no worries I'll check more closely ounce I'm at the keyboard.

@endrton it might help if you step through the instructions here:
https://github.com/cake-build/cake/blob/develop/CONTRIBUTING.md#respond-to-feedback-on-pull-request
If those steps aren't clear, then we really need to get them updated, so would be interested in your feedback here.

@gep13: Thanks, will do.
Does this also means that this guide is outdated?

@endrton yes, I think you are right, we need to update that page.  Could I get you to create an issue on the website repository to get that path synced with the contributing.md from the GitHub repo?  Thanks!

@gep13 done: #92

@endrton thank you for taking the time to make this contribution to Cake.  I have taken the liberty to rebase and merge this PR here: https://github.com/cake-build/cake/commit/23e44cd89788124c992591fe51e87a9f5d25454c As a result, I am going to manually close this PR, however, your work has been correctly attributed.
Thanks!


BUG: benchmarks: don't hardcode errno constant

The value of ENOENT is architecture-dependent, so don't assume it's always 2.
Found using pydiatra.

Test failure is unrelated, merging.


Create / Edit Page - Unable to save Listing if only one Screenshot image (of 2) is added

In List Management, add a screenshot and click save. A red bar is displayed under Screenshot and the listing in not save.  Also unable to submit listing because Screenshot is a required field.

This bug is a result of there being 2 required parts to the one field; @stephanieerin is going to have a look and see if she can separate them out for save

The second part of this isn't a bug, you won't be able to submit without a screenshot.

Can we improve the wording to make it clear that a preview and a screenshot are both required?
We had an outside user complain about this as well during testing.  The words say you have to add 1 screenshot, which is true, but you have to add two images (preview + screenshot).

Wording updated - the messages sit in the React-Commons repo, so in order to get the new message, you will need to delete the node modules and reinstall them

I can create this error with one or both images.
On Tue, Apr 21, 2015 at 10:13 AM, Stephanie Schneider <
<EMAIL_ADDRESS>wrote:

The second part of this isn't a bug, you won't be able to submit without a
screenshot.
—
Reply to this email directly or view it on GitHub
https://github.com/ozone-development/ozp-center/issues/205#issuecomment-94810231
.

I take it back.  I can now save with both images.  Yesterday I could not.
On Tue, Apr 21, 2015 at 10:52 AM, Karen Gordon<EMAIL_ADDRESS>wrote:

I can create this error with one or both images.
On Tue, Apr 21, 2015 at 10:13 AM, Stephanie Schneider <
<EMAIL_ADDRESS>wrote:

The second part of this isn't a bug, you won't be able to submit without
a screenshot.
—
Reply to this email directly or view it on GitHub
https://github.com/ozone-development/ozp-center/issues/205#issuecomment-94810231
.

You can now save a listing with any combination of screenshots. You will still see the error when trying to submit without screenshots.

This required a back end change, make sure you have the latest develop in ozp-rest as well

All Browsers
I was able to save screenshot images with only one screenshot for draft listings.  Submitted listings throw errors.  There were some outstanding issues found with screenshots for IE11 that have been put in a separate ticket #227.

Tested in Staging 0.7.6
All Browsers
I was able to save screenshot images with only one screenshot for draft listings.


Discrepancy in predicted probability using caret xgboost model and xgboost native model.

I used exact same prameters and training dataset to build two classification models:

caret's xgbDART
xgboost with dart booster
After I scored the new data, the predicted probabilties are very different from two models.
Since caret is just a wrapper my understanding is it uses the same xgboost model. I am not understanding why the outputs are so different. Am I missing something?
Any insight would be appreciated.
Thanks

I'm not familiar with

Thank you. xgboost version that I have been using is <IP_ADDRESS>

Could you upgrade to1.1?

just did it to xgboost_<IP_ADDRESS>
re-ran the model. still newly scored output is very different compared to caret xgbDART generated. Please let me know if providing my set up helps better.

Can you post your script?

Closing this for now. Feel free to open another issue if you have an example you can share.


Docs links are broken on github

It seems our docs links generally point at the HTML version of the file (eg the link to create-pipeline docs here, or this). I'm assuming that is needed for these links to work on ReadTheDocs, but that causes them to be broken on github. It seems like there must be some way to make docs usable in both places, no?

This is a known issue that we've tried to figure out a fix for about 5 times and have not figured out a solution. When we migrate off of ReadtheDocs in Q3, this will stop being a problem.


TWO plus signs should not be there

The last two entries here should not have a + at the beginning.
Thanks

This has been updated on dev1.cs

I verified that no more occurrences of this issue exist


Add coveralls and scripts to travis yml for code coverage reporting.

I would like to add Badge and Code Coverage Reporting for Open Source Modules to get better visibility of code coverage.

Changes Unknown when pulling 88db733b7e490bc9b82303e6ef4be3cdea5c1791 on Add-Coveralls-And-Badge into ** on master**.

Works for me. Does it put the badge in the readme?

No I will have to add Link to README

I just added badge to README.md

Changes Unknown when pulling 3b76bc4e9482edde68b250ba47b3e76674a84932 on Add-Coveralls-And-Badge into ** on master**.


Implement LZ4 decompression for 1.20.5+

Close #101
At first I tried using lz4_flex directly, but that doesn't work because java uses a different format. Then I searched "lz4 java" in crates.io and I found this nice crate that implements exactly what we need.
We need a Lz4DecoderWrapper because the API of that crate is not the same as the gzip crates. This introduces an additional copy but I believe the only way to avoid that would be to change the interface of the read_compressed_chunk function.
Tested by generating a world using a server with region-file-compression=lz4, and using the region-dump binary to test decompressing it.

Sorry I've not gotten around to looking at this yet.
From a brief look, my gut says I'd rather depend only on the lz4 dep directly and implement the layers on top directly. Mainly just to reduce dependencies. But that depends just how complex that would be.

Well I have no interest in learning about the implementation details of lz4, and copying that dependency as a new module would be pointless, so if you or someone else wants to work on that then nice, and if not then you can always use this pull request :)
No rush on my side as most worlds will not use this compression format yet.

Hey, I've still not got around to looking at this more closely. I'm going to go with this as is. I can always spend the time in future if I really care about the dependencies.
Thanks again for your contributions, it's appreciated.


Ignition solution not appearing

Ignition Version: 1.2.4
Laravel Version: 9.4.1
PHP Version: 8.1.2

Description:
I'm using the spatie/laravel-ignition package with the default configuration to include it in my Laravel application. I have also added a custom exception which implements Facade\IgnitionContracts\ProvidesSolution, but it doesn't appear on the error page.
FfprobeLengthException.php:
<?php

namespace App\Exceptions;

use Exception;
use Facade\IgnitionContracts\BaseSolution;
use Facade\IgnitionContracts\ProvidesSolution;
use Facade\IgnitionContracts\Solution;

class FfprobeLengthException extends Exception implements ProvidesSolution
{
    public function getSolution(): Solution
    {
        return BaseSolution::create('There was an error with the ffprobe command')
            ->setSolutionDescription("The video file may be invalid");
    }
}

RunCode.php
use App\Exceptions\FfprobeLengthException;

throw new FfprobeLengthException("Could not get video length");

Result:

Wrong repository


MGDSTRM-8525: add topic config policy enhancement end to end tests

Do not merge until FleetShard 0.26 is released
Draft - work in progress
@showuon this is a work in progress, but comments welcome already.

Thanks @k-wall , I'll take a look next Monday.


[bphh-844] Proof of concept generating pdf from sidekik worker and node script

Description
[bphh-844] Proof of concept generating pdf from sidekik worker and node script
This pr is only for demo purposes

closing in favour of https://github.com/bcgov/HOUS-permit-portal/pull/337


Implement the diff command (raw term with colors)

Changes Checklist

[ ] The changes were tested (manually)
[ ] The changes are tested automatically (pytest)
[ ] The changes are optimized and clean
[ ] The changes are documented:

[ ] The code is documented
[ ] The readme is up to date
[ ] The documentation (readthedocs) is up to date and tested

Codecov Report

Merging #22 into master will decrease coverage by 30.7%.
The diff coverage is 47.65%.

@@             Coverage Diff             @@
##           master      #22       +/-   ##
===========================================
- Coverage     100%   69.29%   -30.71%
===========================================
  Files           4        7        +3
  Lines         129      254      +125
  Branches       13       34       +21
===========================================
+ Hits          129      176       +47
- Misses          0       78       +78

Impacted Files
Coverage Δ

pytest_django_queries/tables.py
100% <100%> (ø)
:arrow_up:

pytest_django_queries/filters.py
100% <100%> (ø)

pytest_django_queries/diff.py
33.33% <33.33%> (ø)

pytest_django_queries/cli.py
78.33% <43.47%> (-21.67%)
:arrow_down:

pytest_django_queries/entry.py
82.75% <82.75%> (ø)

Continue to review full report at Codecov.

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


Fix the way known locations are generated on windows

Use GetAllUsersProfileDirectoryW and GetProfilesDirectoryW instead of hardcoding paths.
Previously, the known locations were treated as UNC paths, which would typically fail to be read after ~5 second timeout.
Also fixes memory leak of username string.

@swift-ci please test Linux platform

@swift-ci please test macOS platform

@swift-ci please test macOS platform

@swift-ci please test Linux platform

@swift-ci please clean test macOS platform

@swift-ci please test macOS platform

This is a windows only path change, and the failure is an infrastructure failure on the macOS side.


add Nav case study and fix Pinterest

@cody-clark  thank you for catching that! this PR is to fix the Pinterest case study (move the video to match the others) and add a new Nav Case Study
@zacharysarah @kbarnard10

/approve

/approve


chore: remove unneeded explicit lifetime

This should appease clippy and fix CI.
Signed-off-by: Joel Dice<EMAIL_ADDRESS>

This should appease clippy and fix CI.

Oh right we just got a new rust release :+1:

This should appease clippy and fix CI.

Oh right we just got a new rust release +1

What's slightly confusing is that the referenced lint was apparently added in Rust 1.29.0 or earlier.  Not sure why it's only complaining now.  Perhaps the lint level was raised or the lint was expanded to cover more cases.


Add Cone Geometry Message

Closes #46

can you sign off your commit? We are now requiring this for DCO check to pass. You can click on Details beside DCO for more info.


I am looking forward to this project very much, but I am just getting started, so when will the tutorial be released for this project?

It will be coming soon bro

#2


Add multicast and non-confirmed message support

This patch fixes #272 and adds single-interface multicast capability to go-coap.
I pushed the unified multicast options (used by the new send-multicast function and the existing discover function) into a package of their own because they are used by two different packages and I got cyclical import problems first. I am not thrilled about the solution, so I would happily move the options somewhere else.

Hmm... I think some of these errors were already in the existing code... could it be the linter got better? Shall I try to fix them all?

Hmm... I think some of these errors were already in the existing code... could it be the linter got better? Shall I try to fix them all?

Just check if there's a problem in your newly added code, ignore the rest. We've just enabled several new linters, I'm working on cleaning it up, but it requires more work than I expected. Thanks.

I think the third commit should fix the existing errors in the changed file.

I want to suggest removing non-confirmed message support to separate PR. Because I think it is more complex.

As long as the WriteMulticast() call does not wait for a response I am okay with removing the NonConfirmable code change. I will also see what I can do about writing a few tests...

Didn't you say you removed (or wanted to remove) the "non-conformation" parts of the changes? I am looking over your merged branch now and there are some issues because (parts?) of the code is still inside.


WIP: tcp retrans ebpf tracepoint hook

Description
tcp retrans hook

To force TCP retrans

create netem to drop say 50%

sudo tc qdisc add dev enp1s0 root netem loss 50%

start a long curl for example

curl https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/30/Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-30-1.2.x86_64.vagrant-libvirt.box  --output /tmp/test

Dependencies
Checklist
If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

[x] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist.
[ ] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
[x] Does this PR require product documentation?

[ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.

[x] Does this PR require a product release notes entry?

[ ] If so, fill in "Release Note Text" in the JIRA.

[ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.

[ ] If so, make sure it is described in the JIRA ticket.

QE requirements (check 1 from the list):

[x] Standard QE validation, with pre-merge tests unless stated otherwise.
[ ] Regression tests only (e.g. refactoring with no user-facing change).
[ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test


[request] modrinth release

Hi, would be awesome if you could release on modrinth. Thanks!

Releasing on github would also help as with your license I can add the mod through github cdn which is allowed on modrnith

From what I understand from your license I can redestribute as well so for now I make a github release on a fork until you do


CAMEL-18962: encryption and signature handling with server config

Description
When the AS2 server is configured with a decryption key all received messages will require encryption, and only messages with valid encryption will be successfully processed.  Similarly, when the AS2 server is configured with a message signature validation certificate chain all received messages will require a signature.
Only messages with valid encryption or signature configured as required will be successfully processed otherwise the server will return an 'insufficient-message-security' error disposition [1].
Additionally messages that cannot be decrypted will return a 'decryption-failed' error, and messages failing signature validation will return an 'authentication-failed' error [2].
[1] https://datatracker.ietf.org/doc/html/rfc4130#section-7.4.3
[2] https://datatracker.ietf.org/doc/html/rfc4130#section-7.5.4

Target

[x] I checked that the commit is targeting the correct branch (note that Camel 3 uses camel-3.x, whereas Camel 4 uses the main branch)

Tracking

[x] If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

[x] I checked that each commit in the pull request has a meaningful subject line and body.

[x] I have run mvn clean install -DskipTests locally and I have committed all auto-generated changes

/component-test as2


Purpose of "slidesSelector" parameter?

Liking the updated version of the code. I'm curious, however, about the purposed of the "slidesSelector" parameter.
I currently use an older version of the code to make a "slide plus audio" form of presentation and hack that together using data attributes for times on slide elements and timeupdate events. The name of this parameter makes me think that I might be able to use it to my advantage, but apart from the definition of the parameter I'm not sure what it's intended for or how it would be used in practice.
So not so much an issue as a query and an offer to assist with documentation and example building if it turns out to be something I would build on.

That parameter is being referenced for tracks; some of the tracks can load slides and you can specify which is the selector for those slides. Personally, I haven't seen how they are used, since mostly the common scenarios are tracks and chapters. Hope this answers your question. I have updated a little bit the documentation in regards of that. Thanks and star both projects so we can continue supporting them


QuickFix infrastructure

I've been hesitant to add this since the TypeScript roadmap has it https://github.com/Microsoft/TypeScript/wiki/Roadmap#21 (acutally linking to the atom-typescript implementation which I did a while back https://github.com/Microsoft/TypeScript/issues/6943)
However going through the trend of being the best IDE to support JS to TypeScript migration I cannot hold off any longer. Will add / migrate what I had for atom and then plan future ones here (and expose any from Microsoft/TypeScript if / when they become available :rose:)

Released with 0.0.46 :rose:
Docs : https://basarat.gitbooks.io/alm/content/features/quickfix.html
Contributing : https://basarat.gitbooks.io/alm/content/contributing/quickfix.html
Sample Screenshots


make stem.vis part of att.extSym and att.visibility

Mensural stems were missing the possibility to be identified with a specific glyph. This PR makes stem.vis part of att.extSym to fix this.
Also this makes it part of att.visibility to be more in line with att.stems.

@annplaksin @martha-thomae May I ask you to have a look at this PR?

@martha-thomae and @annplaksin could you please add your reviews ;-)

I am very sorry for not being able to add a review without receiving a bit more context on this. Is there more information about this available?

@annplaksin
The attributes @stem.dir, @stem.len, and @stem.pos have their counterparts stem@dir, stem@len, and stem@pos for <stem> elements in mensural notation.

For most elements we have the ability to identify a symbol with a specific SMuFL glyph through @glyph.name and @glyph.num. This possibility comes with att.extSym and was missing for the <stem> element.
In CMN we have @stem.visible, so it seems logical to add a corresponding stem@visible for mensural notation.

Thanks everyone!


Allow using distinct and count as functions.

Adding group-by will be more work.

@dorukozturk This adds distinct as a function.  The CI is failing due to npm, I think.

@manthey Thanks, I will try this as soon as possible. For now distinct should be enough.


SSL_accept SSL_ERROR_WANT_READ

Windows. Non-blocking sockets, Select() method. OpenSSL 1.1.1d.
Server: The server code only. The server is at https://<IP_ADDRESS>:8887/
Client: There is no client code, I access the server using the Chrome browser.
The program works normal on the laptop in Chrome.
But on the PC, the very first call to SSL_accept() results in an infinite loop of SSL_ERROR_WANT_READ messages.
Then I try to call SSL_read() to eliminate the SSL_ERROR_WANT_READ error, it returns the "-1 bytes" value. I.e. the call to SSL_read() do not succeed either.
Can it be due to local proxy setup etc?
Question: could you write me the steps to go through to debug this issue?

A first step might be to use wireshark to have a look at how far the handshake gets before it fails. An alternative is to call SSL_set_msg_callback(con, SSL_trace) where con is your SSL object instance. Note that this requires OpenSSL to be compiled with the enable-ssl-trace Configure option.

The program accepts some connections, the program sends some messages. But then the program is locked at the SSL_accept() loop requesting SSL_ERROR_WANT_READ. Also, there is a strange non-socket error 183 ERROR_ALREADY_EXISTS after first SSL_accept().
The server debug info log:
2019-10-30 09:09:04 Server has been configured.
2019-10-30 09:09:04  ** Listening at select() **
2019-10-30 09:09:09  ** inside acceptConnection() **
2019-10-30 09:09:09 Server says: Client <IP_ADDRESS>:53811 is connected.
2019-10-30 09:09:09 before SSL_accept no errors
2019-10-30 09:09:09  ** SOCKET_ERROR after SSL_accept: (ErrorCode 183)
2019-10-30 09:09:09  ** SOCKET_ERROR: Cannot create a file when that file already exists.
2019-10-30 09:09:09 SSL/TLS connection is encripted using TLS_AES_128_GCM_SHA256
2019-10-30 09:09:09 exited acceptConnection()
2019-10-30 09:09:09  ** Listening at select() **
2019-10-30 09:09:09  ** inside acceptConnection() **
2019-10-30 09:09:09 Server says: Client <IP_ADDRESS>:53812 is connected.
2019-10-30 09:09:09 before SSL_accept no errors
2019-10-30 09:09:09  ** SOCKET_ERROR after SSL_accept: (ErrorCode 183)
2019-10-30 09:09:09  ** SOCKET_ERROR: Cannot create a file when that file already exists.
2019-10-30 09:09:09 SSL/TLS connection is encripted using TLS_AES_128_GCM_SHA256
2019-10-30 09:09:09 exited acceptConnection()
2019-10-30 09:09:09  ** inside receiveMessage() **
2019-10-30 09:09:09 exited receiveMessage()
2019-10-30 09:09:09  ** Listening at select() **
2019-10-30 09:09:09  ** inside acceptConnection() **
2019-10-30 09:09:09 Server says: Client <IP_ADDRESS>:53813 is connected.
2019-10-30 09:09:09 -->HERE THERE IS A DEADLOCK AT SSL_ACCEPT)=

The wireshark debug log for port 8887:
TCP	56	53811 → 8887 [SYN] Seq=0 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM=1
TCP	56	8887 → 53811 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM=1
TCP	44	53811 → 8887 [ACK] Seq=1 Ack=1 Win=2619648 Len=0
TCP	56	53812 → 8887 [SYN] Seq=0 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM=1
TCP	56	8887 → 53812 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM=1
TCP	44	53812 → 8887 [ACK] Seq=1 Ack=1 Win=2619648 Len=0
TLSv1.3	561	Client Hello
TCP	44	8887 → 53811 [ACK] Seq=1 Ack=518 Win=2619648 Len=0
TLSv1.3	561	Client Hello
TCP	44	8887 → 53812 [ACK] Seq=1 Ack=518 Win=2619648 Len=0
TCP	56	53813 → 8887 [SYN] Seq=0 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM=1
TCP	56	8887 → 53813 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM=1
TCP	44	53813 → 8887 [ACK] Seq=1 Ack=1 Win=2619648 Len=0
TLSv1.3	1686	Server Hello, Change Cipher Spec, Application Data, Application Data, Application Data, Application Data
TCP	44	53811 → 8887 [ACK] Seq=518 Ack=1643 Win=2618112 Len=0
TLSv1.3	108	Change Cipher Spec, Application Data
TCP	44	8887 → 53811 [ACK] Seq=1643 Ack=582 Win=2619648 Len=0
TLSv1.3	580	Application Data
TLSv1.3	267	Application Data
TCP	44	53811 → 8887 [ACK] Seq=1118 Ack=1866 Win=2617856 Len=0
TCP	44	8887 → 53811 [ACK] Seq=1866 Ack=1118 Win=2619136 Len=0
TLSv1.3	267	Application Data
TCP	44	53811 → 8887 [ACK] Seq=1118 Ack=2089 Win=2617600 Len=0
TLSv1.3	1686	Server Hello, Change Cipher Spec, Application Data, Application Data, Application Data, Application Data
TCP	44	53812 → 8887 [ACK] Seq=518 Ack=1643 Win=2618112 Len=0
TLSv1.3	108	Change Cipher Spec, Application Data
TCP	44	8887 → 53812 [ACK] Seq=1643 Ack=582 Win=2619648 Len=0
TLSv1.3	267	Application Data
TCP	44	53812 → 8887 [ACK] Seq=582 Ack=1866 Win=2617856 Len=0
TLSv1.3	267	Application Data
TCP	44	53812 → 8887 [ACK] Seq=582 Ack=2089 Win=2617600 Len=0
-->HERE THERE IS A DEADLOCK AT SSL_ACCEPT()

Hmmm...nothing obviously wrong there. Can you post the actual pcap file from wireshark?

If you could post a code sample of what your SSL_accept loop looks like it might help.

        int32 SSLacceptReturnCode;
        while(true)
        {
            SSLacceptReturnCode = SSL_accept(pSocketState->ssl);
            if(SSLacceptReturnCode == 0)
            {
                // FATAL ERROR
                InvalidCodePath;
            }
            else if(SSLacceptReturnCode == 1)
            {
                // SUCCESS
                break;
            }
            else if(SSLacceptReturnCode < 0)
            {
                int32 SSLgetErrorCode = SSL_get_error(pSocketState->ssl, SSLacceptReturnCode);
                if(SSLgetErrorCode == SSL_ERROR_WANT_READ)
                {
                    /* Wait for data to be read */
                    continue;
                }
                else
                {
                    // FATAL ERROR
                    InvalidCodePath;
                }
            }
            else
            {
                InvalidCodePath;
            }
        }

Attached is the Wireshark PCAP file for this bug.
pcap.zip

What kind of BIOs are you using in this code? Are you doing any kind of buffering anywhere that might cause messages to not be delivered to libssl?

What kind of BIOs are you using in this code? Are you doing any kind of buffering anywhere that might cause messages to not be delivered to libssl?

I don't use any BIOs. I think they are redundant since newer versions of OpenSSL. There is no message buffering. The code is simple.

There is always a BIO involved. Do you mean you used SSL_set_fd?

There is always a BIO involved. Do you mean you used SSL_set_fd?

Yes, I mean there is no explicit BIO structs. I used SSL_set_fd(). I will provide you with the SSL_state_string_long() strings tomorrow morning.

The SSL_state_string_long(pSocketState->ssl) calls before and after the SSL_accept() call show the following output.
2019-10-31 08:03:16 Server has been configured.
2019-10-31 08:03:16  ** Listening at select() **
2019-10-31 08:03:20  ** inside acceptConnection() **
    2019-10-31 08:03:20 Server says: Client <IP_ADDRESS>:54657 is connected.
    2019-10-31 08:03:21 before SSL_accept loop()

        2019-10-31 08:03:21 before SSL_accept() call
            2019-10-31 08:03:21 before SSL initialization
        2019-10-31 08:03:21 after SSL_accept() call
            2019-10-31 08:03:21 TLSv1.3 early data

        2019-10-31 08:03:21 before SSL_accept() call
            2019-10-31 08:03:21 TLSv1.3 early data
        2019-10-31 08:03:21 after SSL_accept() call
            2019-10-31 08:03:21 SSL negotiation finished successfully

    2019-10-31 08:03:21 after SSL_accept() loop
    2019-10-31 08:03:21  ** SOCKET_ERROR at Control_1_5: (ErrorCode 183)
    2019-10-31 08:03:21  ** SOCKET_ERROR: Cannot create a file when that file already exists.
2019-10-31 08:03:21 exited acceptConnection()

2019-10-31 08:03:21  ** Listening at select() **
2019-10-31 08:03:21  ** inside acceptConnection() **
    2019-10-31 08:03:21 Server says: Client <IP_ADDRESS>:54658 is connected.
    2019-10-31 08:03:21 before SSL_accept loop()

        2019-10-31 08:03:21 before SSL_accept() call
            2019-10-31 08:03:21 before SSL initialization
        2019-10-31 08:03:21 after SSL_accept() call
            2019-10-31 08:03:21 TLSv1.3 early data

        2019-10-31 08:03:21 before SSL_accept() call
            2019-10-31 08:03:21 TLSv1.3 early data
        2019-10-31 08:03:21 after SSL_accept() call
            2019-10-31 08:03:21 SSL negotiation finished successfully

    2019-10-31 08:03:21 after SSL_accept() loop
    2019-10-31 08:03:21  ** SOCKET_ERROR at Control_1_5: (ErrorCode 183)
    2019-10-31 08:03:21  ** SOCKET_ERROR: Cannot create a file when that file already exists.
2019-10-31 08:03:21 exited acceptConnection()

2019-10-31 08:03:21  ** inside receiveMessage() **
    2019-10-31 08:03:21  ** SOCKET_ERROR at SocketMethodNameNotSet: (ErrorCode 183)
    2019-10-31 08:03:21  ** SOCKET_ERROR: Cannot create a file when that file already exists.
2019-10-31 08:03:21 exited receiveMessage()

2019-10-31 08:03:21  ** Listening at select() **
2019-10-31 08:03:21  ** inside acceptConnection() **
    2019-10-31 08:03:21 Server says: Client <IP_ADDRESS>:54659 is connected.
    2019-10-31 08:03:21 before SSL_accept loop()
        2019-10-31 08:03:21 before SSL_accept() call
            2019-10-31 08:03:21 before SSL initialization
        2019-10-31 08:03:21 after SSL_accept() call
            2019-10-31 08:03:21 before SSL initialization
        2019-10-31 08:03:21 before SSL_accept() call
            2019-10-31 08:03:21 before SSL initialization
        2019-10-31 08:03:21 after SSL_accept() call
            2019-10-31 08:03:21 before SSL initialization
        2019-10-31 08:03:21 before SSL_accept() call
            2019-10-31 08:03:21 before SSL initialization
        2019-10-31 08:03:21 after SSL_accept() call
            2019-10-31 08:03:21 before SSL initialization
        2019-10-31 08:03:21 before SSL_accept() call
            2019-10-31 08:03:21 before SSL initialization
        2019-10-31 08:03:21 after SSL_accept() call
            2019-10-31 08:03:21 before SSL initialization
        2019-10-31 08:03:21 before SSL_accept() call
    ... the same pattern is repeated.. "before SSL initialization ...
    - // -

Something seems to go wrong here! We expect SSL_accept to return successfully at this point. What is the actual SSL_accept return value at this point?

If you refer to the SSL_accept() loop, the actual loop break does happen after the "SSL negotiation finished successfully" line. If SSL_accept returns 1, then break.
        while(true)
        {
            OutputDebugStringA("before SSL_accept() call");
            OutputDebugStringA((char *)SSL_state_string_long(pSocketState->ssl));
            SSLacceptReturnCode = SSL_accept(pSocketState->ssl); // SSL Handshake
            OutputDebugStringA("after SSL_accept() call");
            OutputDebugStringA((char *)SSL_state_string_long(pSocketState->ssl));
            if(SSLacceptReturnCode == 0)
            {
                InvalidCodePath;
            }
            else if(SSLacceptReturnCode == 1)
            {
                break;
            }
            else if(SSLacceptReturnCode < 0)
            {
                int32 SSLgetErrorCode = SSL_get_error(pSocketState->ssl, SSLacceptReturnCode);
                if(SSLgetErrorCode == SSL_ERROR_WANT_READ)
                {
                    /* Wait for data to be read */
                    continue;
                }
                else
                {
                    InvalidCodePath;
                }
            }
            else
            {
                InvalidCodePath;
            }
        }

If you refer to the SSL_accept() loop, the actual loop break does happen after the "SSL negotiation finished successfully" line. If SSL_accept returns 1, then break.

Right - I'm asking you to print the actual SSL_accept return value.

Right - I'm asking you to print the actual SSL_accept return value.

SSL_accept() keeps returning "-1".

Hmm. That's very strange. I can't think of a reason at the moment why it would do that. Are you able to run this in a debugger? You will need to compile openssl with debugging symbols available (--debug option to Configure). In the call to accept which results in the move to the "SSL negotiation finished successfully" line, I expect to end up in the "tls_finish_handshake" function in ssl/statem/statem_lib.c. Set a breakpoint in there and make sure the function completes successfully. From there it should be a more-or-less straight line return up the call stack back to the SSL_accept() call in your application - which is supposed to result in a 1 return. We're trying to figure out at what point in deviates from that straight line return and you get something other than 1.

I seem to be getting this issue in our environment as well. Its just busy wait looping between SSL_accept() and SSL_ERROR_WANT_READ.
Is there a remedy for this? Or should I add a work around that limits the number of attempts simply?

Similar thing happen to BIO_read and BIO_should_retry.
When client close connection at right time (after the handshaking complete but before sending request),
curl -v -L -O -k --tlsv1.2 https://server-ip/content
...
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [207 bytes data]
  0     0    0     0    0     0      0      0 --:--:--  0:00:04 --:--:--     0* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [93 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [646 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [172 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
  0     0    0     0    0     0      0      0 --:--:--  0:00:05 --:--:--     0^C

Despite the connection is closed, BIO_read is -1 but BIO_should_retry and BIO_should_read return true.
BIO_should_retry just checking the flag of BIO that translating from SSL_ERROR_WANT_READ.
OpenSSL re-compile 1.1.0f of centos 7 and system lib 1.1.0j of debian 9, re-compile 1.1.1f on debian.

Hmm. I'm having a very similar issue with DTLS. I'm just beginning to learn OpenSSL. I'm basing my code off of https://github.com/nplab/DTLS-Examples/blob/master/src/dtls_udp_echo.c
My code (sorry if it's bad):
https://github.com/RotartsiORG/StoneMason/blob/master/src/stms/net/dtls.cpp
https://github.com/RotartsiORG/StoneMason/blob/master/include/stms/net/dtls.hpp
I would create a new DTLSServer, call start(), and then call tick() in a loop.
I would then try to connect with openssl s_client -comp -dtls1_2 -timeout -async -nbio -debug -msg -verify 5 -connect *myip*:3000 -CAfile ca-pub-cert.pem -cert cli-pub-cert.pem -key cli-priv-key.pem, but in the server I would see:
[17:00:06.143] [  info  ] [10427|10427] [DTLSServer|dtls.cpp:192]: Creating new DTLS server to be hosted on *myip*:3000
[17:00:06.144] [  info  ] [10427|10427] [tryAddr|dtls.cpp:438]: Candidate 0: IPv4 *myip*:3000
[17:00:06.144] [  info  ] [10427|10427] [tryAddr|dtls.cpp:480]: Candidate 0 is viable and active. However, it is not necessarily preferred.
[17:00:06.144] [  info  ] [10427|10427] [start|dtls.cpp:225]: Using Candidate 0 because it is IPv4
[17:00:07.028] [  info  ] [10427|10427] [tick|dtls.cpp:307]: New client at *myip*:38690 is trying to connect.
[17:00:07.029] [warning ] [10427|10427] [tick|dtls.cpp:360]: Fatal DTLS Handshake error! Refusing to connect.
[17:00:07.029] [warning ] [10427|10427] [handleSslGetErr|dtls.cpp:524]: Unable to complete OpenSSL call: Want Read. Please retry. (Auto Retry is on!)

SSL_accept is returning SSL_ERROR_WANT_READ. At this point, I drop the connection because the docs say that this is a fatal error.
Hope this helps.

Interesting. If i set the client socket to blocking, the error goes away. The server socket could still be non-blocking. (I have SSL_MODE_ASYNC on too)

SSL_accept is returning SSL_ERROR_WANT_READ. At this point, I drop the connection because the docs say that this is a fatal error.

Where do they say this is a fatal error? The man page for SSL_ERROR_WANT_READ says:
The operation did not complete and can be retried later.

B<SSL_ERROR_WANT_READ> is returned when the last operation was a read
operation from a non-blocking B<BIO>.
It means that not enough data was available at this time to complete the
operation.
If at a later time the underlying B<BIO> has data available for reading the same
function can be called again.

Man pages for SSL_accept, under the return values section:
<0

    The TLS/SSL handshake was not successful because a fatal error occurred either at the protocol level or a connection failure occurred. The shutdown was not clean. It can also occur if action is needed to continue the operation for non-blocking BIOs. Call SSL_get_error() with the return value ret to find out the reason.

These are two separate things.
Reason 1)
The TLS/SSL handshake was not successful because a fatal error occurred
either at the protocol level or a connection failure occurred.
The shutdown was not clean.
Reason 2)
It can also occur if
action is needed to continue the operation for non-blocking BIOs.
Call SSL_get_error() with the return value ret to find out the reason.
So you are experiencing reason 2. This is not a fatal error and can be retried.

The manpage has been changed a long time ago to say:
The read operation was not successful, because either the
connection was closed, an error occurred or action must be taken
by the calling process.  Call SSL_get_error(3) with the return
value ret to find out the reason.

The manpage has been changed a long time ago to say

That's the SSL_read man page. The SSL_accept man page says something different. It probably should say the same thing.

Hmm. I've modified my code to call SSL_read or SSL_write if WANT_READ or WANT_WRITE are returned. It looks like everything (including SSL_accept and SSL_read) is just timing out instantly with non-blocking client sockets. If I just call SSL_accept in a loop, it works eventually.

Sorry It seems I have misunderstood the timeout mechanism in OpenSSL. I thought that it times out when a message from the client hasn't been recieved in a certain amount of time.

The WANT_READ and WANT_WRITE states indicate that you need to select(), poll(), or otherwise wait for the underlying socket to be readable (respectively, writable).  Just calling the SSL functions in a loop is not helpful.

Ok, maybe I wasnt clear enough, and now lots of time have passed since my last post
But we are calling SSL_Accept again as a result of a read event being triggered from libevent:
`static void handle_read_event(int socket, short event, void* arg)
{
http_connection_t c = (http_connection_t)arg;
int result;
if (event == EV_TIMEOUT)
{
    if (c->rendering)
    {
        http_connection_register_read_event(c);
        return;
    }
    http_connection_close(c);
    atomic_inc(&counters.timeout);
    return;
}

if (c->ssl && !c->ssl_handshake_complete)
{
    http_ssl_setup_handshake(c);`

void http_ssl_setup_handshake(http_connection_t connection) {     if (connection->ssl_retry_start == 0)     {         time(&connection->ssl_retry_start);     }     // Do the SSL handshake     int n = SSL_accept(connection->ssl);     const int success = 1;
At the moment we are remedying the issue by retrying for 2s, but its not a nice work around and it takes unecessary cpu-cycles.

Ok, maybe I wasnt clear enough, and now lots of time have passed since my last post
But we are calling SSL_Accept again as a result of a read event being triggered from libevent:
`static void handle_read_event(int socket, short event, void* arg)
{
http_connection_t c = (http_connection_t)arg;
int result;
if (event == EV_TIMEOUT)
{
    if (c->rendering)
    {
        http_connection_register_read_event(c);
        return;
    }
    http_connection_close(c);
    atomic_inc(&counters.timeout);
    return;
}

if (c->ssl && !c->ssl_handshake_complete)
{
    http_ssl_setup_handshake(c);`

void http_ssl_setup_handshake(http_connection_t connection) {     if (connection->ssl_retry_start == 0)     {         time(&connection->ssl_retry_start);     }     // Do the SSL handshake     int n = SSL_accept(connection->ssl);     const int success = 1;
At the moment we are remedying the issue by retrying for 2s, but its not a nice work around and it takes unecessary cpu-cycles.

@mattiasbarthel I suggest filing a new issue with your scenario and a complete writeup.
The post at https://github.com/openssl/openssl/issues/10279#issuecomment-608420467 suggests that you are calling SSL_accept() when libevent reports "read possible" but keep getting back SSL_ERROR_WANT_READ from SSL_accept() (which would indeed be surprising), but it's hard to be 100% certain.  If you can get a packet capture correlated with the code tracethrough that would be even better.

Hi @kaduk and thanks for your response. Packet capture will be quite difficult since it happens mostly under high load.
But I guess we can filter out TCP ports in the trace.
Regarding code tracethrough, do you then refer to turning the openssl library to a debug library? (If so how is it done?)
Or traceing our own application?

Hi @kaduk and thanks for your response. Packet capture will be quite difficult since it happens mostly under high load.
But I guess we can filter out TCP ports in the trace.
Regarding code tracethrough, do you then refer to turning the openssl library to a debug library? (If so how is it done?)
Or traceing our own application?

Understood that a packet capture is challenging and may not happen.
By "code tracethrough" I just meant something similar to what you've already done, noting the relevant codepaths in your application where it interacts with libevent and (e.g.) SSL_accept() -- what values are returned when, and the like.  There is a trace option for openssl (interestingly, for this I think it would just be enable-trace to configure, not enable-ssl-trace which is for s_client/s_server), but I think it would be more detail than is needed here.

@mattiasbarthel I suggest filing a new issue with your scenario and a complete writeup.
The post at #10279 (comment) suggests that you are calling SSL_accept() when libevent reports "read possible" but keep getting back SSL_ERROR_WANT_READ from SSL_accept() (which would indeed be surprising), but it's hard to be 100% certain. If you can get a packet capture correlated with the code tracethrough that would be even better.

I manage to reproduce the issue when continuously drop the connection from client right after the ACK of TLS client hello is received

Log at our server after retry 2s (2 is the WANT_READ, you know better than me)
http_ssl_setup_handshake: unexpected reason: 2, error message: Transport endpoint is not connected (dropping connection)

Might be this relevant https://github.com/openssl/openssl/issues/11574#issuecomment-698061774

@nvkhoi112358 it may be better to open a new github issue for your issue, as there is no guarantee that the underlying problem is the same as this one.
In particular, your packet capture seems to show the client starting the TCP 3-way handshake, sending a ClientHello, and then gracefully closing the TCP connection once the TCP segment with the ClientHello got acked.  That's pretty strange, and seems to indicate an issue in the client application rather than in openssl.


Links not opening in LibreWolf

Does this issue occur when all extensions are disabled?: Yes

VS Code Version:

1.80.0
660393deaaa6d1996740ff4880f1bad43768c814
x64

OS Version: EndeavourOS Cassini Nova R2

Steps to Reproduce:
Unsure how to reproduce, here is what I do:

Terminal: unset BROWSER
Terminal: xdg-settings set default-web-browser librewolf.desktop
Open VS Code
Help > About (does nothing)
I also have an error about an OS keyring (separate issue) and I click Open Troubleshooting Guide; it does nothing
Open terminal
echo "https://example.com/"
ctrl-click the link; it does nothing
Retry steps 3-8 with dev tools open; I see nothing in the console
Double check my default browser
Find the desktop file; it exists
Check my environment variable; it is set correctly
Open an HTML file in my explorer and it opens successfully in LibreWolf
Install any updates and reboot my computer; issue persists
Search existing issues; none are relevant

I installed VS Code Insiders and it is able to open links in my browser.

Which installation of VSCode are you using, (deb, rpm or snap) ?

Also does running xdg-open https://example.com from your system terminal open the librewolf ?

Which installation of VSCode are you using, (deb, rpm or snap) ?

I installed from AUR.
The example opens in my browser as do other links I click in different software.  Insiders is working for me rn.

Thanks for confirming, I don't see any recent fixes to link handling in core. But will wait for 1.81 stable and see if the issue still repros with stable.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


The model and raw results need permission to access.

Can you open permissions？Thank you very much.

Permission enabled


Create rpc-list.mdx

Adding draft directory page

Something went wrong with PR preview build please check

Preview is available here:http://soroban-docs-pr606.previews.kube001.services.stellar-ops.com/

Preview is available here:http://soroban-docs-pr606.previews.kube001.services.stellar-ops.com/

Preview is available here:http://soroban-docs-pr606.previews.kube001.services.stellar-ops.com/

Preview is available here:http://soroban-docs-pr606.previews.kube001.services.stellar-ops.com/

Preview is available here:http://soroban-docs-pr606.previews.kube001.services.stellar-ops.com/


docs(testnet-node): Add section on ENV vars

Description
Describe the changes that were made in this pull request. When possible start with the motivations behind the change. Be sure to also include the following information:

Motivation for change?
What was changed?
Link to relevant issues?

Checklist

[ ] Conventional commits were used
[ ] New links to files and images were verified
[ ] For fixes/refactors: all existing references were identified and replaced
[ ] Style guide was reviewed and applied
[ ] Clear code samples were provided
[ ] People were tagged for review

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@r3lik I think you need to sign the contributor license agreement before I can merge.
https://github.com/blockstack/docs/pull/1102#issuecomment-796182699


Flyway Gradle Plugin in combination with Gradle Eclipse plugin adds source folder that does not exist.

Which version and edition of Flyway are you using?
7.5.2; issue has been observed with 6.5.7 as well
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)
Gradle plugin in combination with Eclipse.
Which database are you using? (Type & version)
irrelevant
Which operating system are you using?
Mac OS 10.15.7, Java 11.0.8
What did you do? (Please include the content causing the issue, any relevant configuration settings, the SQL statement(s) that failed (if any), and the command you ran)
run gradle cleanEclipse eclipse in a shell
What did you expect to see?
We apply Flyway's Gradle plugin to one of our builds, just to get the corresponding Flyway Gradle tasks. The project neither configures the flyway plugin in any way (i.e., there is no flyway { /*...*/ } section in the build.gradle file) nor does the project contains any Java migration implementations; i.e., there is no dedicated Java source folder main-java. We do, however, have standard Java code in the project; i.e., there exists a non-empty Java source folder src/main/java that contains "normal" Java code.
What did you see instead?
A source folder main-java is added to the Eclipse configurations, see screenshot below. This source folder is correctly marked as missing by Eclipse as it does not exist. This causes Eclipse not to build the project unless the source folder is removed manually.
Is this a bug? If not, what can be done to prevent the Flyway Gradle plugin (or the Eclipse Gradle plugin?) to add this folder?

This is a known 'feature' of the eclipse gradle plugin. See this forum post: https://discuss.gradle.org/t/non-existing-directories-added-to-eclipse-classpath/1652
As such, there isn't anything Flyway can do about it

I don't understand why a non-existing directory is configured anyway. I would, if it was existing while empty.
Anyway, I'm working around this issue now in the following way:
eclipse
{
	classpath
	{
		file
		{
			whenMerged { classpath ->
				classpath.getEntries().removeAll { it.path == 'main-java' }
			}
		}
	}
}


Fix link to FAQ at bottom of English 4.0 translations

Should go to the particular FAQ, not the FAQ page generally. Please also check all of the other translations and fix where needed.

What is the particular FAQ?

https://wiki.creativecommons.org/wiki/Frequently_Asked_Questions#What_are_the_official_translations_of_the_CC_licenses_and_CC0.3F

Is this the link you're referring to?

Yes. The hyperlink for FAQ. Thx.

It seems to take me to the correct place in the FAQ. Can you double check with a fresh browser?

In Chrome, yes it brings me to the correct, specific FAQ. But in Safari, I still land at the top of the FAQ page. Why the difference?

Not sure, possibly a Safari bug, or a bug with your particular set up. Either way, I don't think it's a bug we can fix.


macOS: difference between bfs and find with primaries -ls

Hi
echo file >file
find . -ls and ls -s
Display the same values for the number of file system blocks actually used by file - 8, but bfs -ls show - 4.
Regards.

Indeed, the traditional block size is 512 bytes, but bfs follows GNU find here and uses 1KiB blocks.  GNU find's -ls will use 512B blocks if POSIXLY_CORRECT is set, even though -ls is not POSIX.  bfs doesn't listen to POSIXLY_CORRECT about this, but it probably should.


Time complexity and matching method

What is the matching method for this library? Is it the backtracking kind or a linear kind (like re2)? What is worst case time complexity for a expression?

@hanickadot

backtracking, only dfa variant is linear, but for price of missing functionality

I just learned regex, I don't actually know DFA and stuff. But basically, this engine is backtracking when it is not "DFA" variant? And linear when it is?