Dead "microsoft" link

Under Supported Devices and drivers the link for "Microsoft" is dead.  It should link to https://support.microsoft.com/en-us/help/4094045/surface-devices-that-work-with-windows-10-s

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

ID: 6ce6147b-57c3-b40d-2d1e-3aa04a3d5606
Version Independent ID: c453ea14-6842-4af7-42c0-6ef8e2336c6c
Content: Test Windows 10 S on existing Windows 10 education devices
Content Source: education/windows/test-windows10s-for-edu.md
Service: unspecified
GitHub Login: @CelesteDG
Microsoft Alias: celested

@Scottmca - Thank you very much for the feedback. I've made this change today and pushed the PR. Hopefully the change goes live this afternoon.


Do not include whitespace when applying inline markdown styles

If you test out markdown on a gist, markdown like this:
**Test **

(with trailing or leading whitespace) is not properly parsed. (examples here: https://gist.github.com/Rosey/3f848d77b46f7ab337a53211117acd87)
This change only surrounds the text with markdown inline styles and preserves
the whitespace, but doesn't attempt to style it, fixing the issue of
incompatibility with markdown parsers.

I'm not super confident about the efficiency of my regular expression here. It works, but I am worried that it is not optimal. Perhaps someone with better regex-fu will know if it can be improved performance-wise.

@Rosey are you planning to fix the conflicts? Your PR most probably also solved https://github.com/sstur/react-rte/issues/127


TabBarIOS tintColor for unselected items

Nice to have

Hey @ecesena! Closing this since it's a duplicate of #3083.

Ops, sorry... I searched for unselected, didn't think to inactive... :)

:+1: No worries :)


long duration timeouts can cause loss of time

Multiple timer drivers work by recording a counter value at the point ticks were last announced, and tracking elapsed time since that event to get the current time.  Deadlines for new events are calculated by adding the requested duration to the elapsed time and setting a compare event at the last announce time plus this offset.  (With rounding/conversion from ticks to cycles.)
Several driver implementations try to avoid counter overflows by limiting the maximum number of ticks to a value that can be represented without overflowing the cycle counter span.  This worked in pre-tickless builds because the elapsed time was always less than one tick.
It fails in tickless because when the elapsed time is added to the converted maximum ticks it can cause a counter wrap.
This is the problem underlying #20892.  It's also present in hpet and systick, and probably multiple other drivers.

Here's the deep analysis for the problem.  The background is for Nordic; the problem is cross-platform.
Background
The Nordic timer infrastructure uses a 24-bit cycle counter that increments at 32 KiHz.  The counter has a compare interrupt; when the interrupt fires the difference in ticks between the previous fire and the current fire is added to a counter and the ticks are announced.
The implementation maintains a 32-bit value that represents the low 32 bits of an extended cycle counter that advances by a multiple of cycles-per-tick to track the cycle count corresponding to the most recently announced tick.
The elapsed time since the last announced tick is calculated by a 24-bit unsigned subtraction of the extended cycle counter.
The current time is the sum of the extended cycle counter plus the elapsed time.
Analysis
Let T be the elapsed time since system start measured in cycles, measured objectively.
Since we're in a tickless system we actually track L (number of announced ticks) and need to measure E (number of ticks since the last announcement).  When the system is correct T=L+E.
Let C be the counter span; i.e. to the counter X == (X+C) for X in [0, C).
Let M be the maximum duration that can be accommodated when scheduling a timeout (M < C).  In a timer driver where cycle rate is equal to tick rate M = C-2.
Any duration greater than M must be reached in steps that do not exceed M cycles so we avoid losing track of a cycle counter wrap.
Let D be the desired duration of an alarm measured in cycles.
So an alarm D cycles after T should be scheduled at A = T+R, where:

R = D if D <= M; otherwise
R = M.

We shall see that this rule is incorrect because it does not take into account a wrap event in cases where E>0.
Let's run an example where the user wants a relative alarm to occur in D = C+1000 ticks at a point where the last tick event was at time L = 1 and there have been E = 663 unannounced ticks since that event.
The desired absolute time for the alarm is 664+C+1000 = 1664+C.  This is too long, so the first step is to delay M=C-2 ticks:
L     E     T         D        R       A
1     663   664       C+1000   C-2     C+662

The counter will lap and read 662 in C-2 cycles.  The interrupt handler will determine that 662-L = 661 cycles have passed.  This adjustment added to L and subtracted from D so the new D is C+339.  In this case there are no unaccounted-for ticks.
Note that at this point L undercounts T by C ticks, which is an error. What follows
L     E     T         D        R       A
662   0     C+662     C+339    C-2     C+660

The counter will lap and read 660 in C-2 cycles.  The interrupt handler will determine that 660-L = -2 so C-2 cycles have passed. This adjustment added to L and subtracted from D so the new D is 337.
L     E     T         D        R       A
C+660 0     2*C+660   337      337     997

The counter will not lap, and will read 997 in 337 cycles.  The interrupt will determine that 997-660 = 337 so 337 cycles have passed. This adjustment is added to L and subtracted from D so the new D is zero.
L     E     T          D
C+997 0     2*C+997    0

The alarm that was requested to fire in C+1000 ticks (C+1664 absolute) will have instead fired in 2*C-333 ticks (2*C+997 absolute).
Root Cause
The implementation is expected to avoid lost overflow events by this rule:

So an alarm D cycles after T should be scheduled at A = T+R, where:

R = D if D <= M; otherwise
R = M.

The rule is correct, but for cases where E is not zero must be stated as:
So an alarm D cycles after T=L+E should be scheduled at A = L+R, where:

R = E+D if E+D <= M; otherwise
R = M.

In implementations the incoming duration is measured in ticks.  The maximum number of ticks that can be supported is whatever produces M cycles (M = ticks * cycles/tick). The original implementation assumed that capping the duration at that maximum number of ticks was sufficient to guarantee that D would not exceed M, so only the first case needed to be handled.
Instead, when E is non-zero the actual upper bound is M-E, which can't be satisfied simply by adjusting ticks on entry.  Consequently the bound must be validated against E+D.

@pabigot thanks a lot for your explanation, now i understand the issue.


Tests: using platform-dependent crypto

Describe the bug
Tests.Kerberos.NET runs a few tests using unsupported crypto. The problem is that this makes the tests platform-dependent. This issue documents problematic operations.
To Reproduce
Please watch #334. Ported tests dropping soon-ish(tm).
Expected behavior
Varies. I expect a perfectly fine test to succeed. Some tests are supposed to fail but aren't covered.
Additional context
Bug found in the course of porting the tests to Linux.

This is the stacktrace for RestrictionType_ApOptions
System.PlatformNotSupportedException: A crypto implementation of MD4 does not exist for Unix
    at Kerberos.NET.Crypto.CryptoPal.PlatformNotSupported(String algorithm) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/Pal/CryptoPal.cs:line 95
   at Kerberos.NET.Crypto.LinuxCryptoPal.Md4() in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/Pal/Linux/LinuxCryptoPal.cs:line 22
   at Kerberos.NET.Crypto.RC4Transformer.MD4(ReadOnlyMemory`1 key) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/RC4/RC4Transformer.cs:line 168
   at Kerberos.NET.Crypto.RC4Transformer.String2Key(KerberosKey key) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/RC4/RC4Transformer.cs:line 38
   at Kerberos.NET.Crypto.KerberosKey.<>c__DisplayClass45_0.<GetKey>b__0(EncryptionType etype) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/KerberosKey.cs:line 224
   at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
   at Kerberos.NET.Crypto.KerberosKey.GetKey(KerberosCryptoTransformer transformer) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/KerberosKey.cs:line 224
   at Kerberos.NET.Crypto.RC4Transformer.Decrypt(ReadOnlyMemory`1 ciphertext, KerberosKey key, KeyUsage usage) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/RC4/RC4Transformer.cs:line 82
   at Kerberos.NET.Entities.KrbEncryptedData.Decrypt[T](KerberosKey key, KeyUsage usage, Func`2 func) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Entities/Krb/KrbEncryptedData.cs:line 37
   at Kerberos.NET.Crypto.DecryptedKrbApReq.Decrypt(KerberosKey ticketEncryptingKey) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/DecryptedKrbApReq.cs:line 75
   at Kerberos.NET.Crypto.DecryptedKrbApReq.Decrypt(KeyTable keytab) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/DecryptedKrbApReq.cs:line 70
   at Kerberos.NET.Entities.ContextToken.DecryptApReq(KrbApReq token, KeyTable keytab) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Entities/SpNego/ContextToken.cs:line 35
   at Kerberos.NET.Entities.KerberosContextToken.DecryptApReq(KeyTable keys) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Entities/SpNego/KerberosContextToken.cs:line 26
   at Kerberos.NET.Entities.NegotiateContextToken.DecryptApReq(KeyTable keys) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Entities/SpNego/NegotiateContextToken.cs:line 42
   at Kerberos.NET.KerberosValidator.Validate(ReadOnlyMemory`1 requestBytes) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/KerberosValidator.cs:line 70
   at Kerberos.NET.KerberosAuthenticator.Authenticate(ReadOnlyMemory`1 token) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/KerberosAuthenticator.cs:line 73
   at Kerberos.NET.KerberosAuthenticator.Authenticate(Byte[] token) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/KerberosAuthenticator.cs:line 69
   at Tests.Kerberos.NET.AuthorizationsTests.GenerateAuthZ() in /home/.../RiderProjects/Kerberos.NET/Tests/Tests.Kerberos.NET/KrbApReq/AuthorizationsTests.cs:line 27
   at Tests.Kerberos.NET.AuthorizationsTests.RestrictionType_ApOptions() in /home/.../RiderProjects/Kerberos.NET/Tests/Tests.Kerberos.NET/KrbApReq/AuthorizationsTests.cs:line 113

Inside the testdata there is a certificate called testuser.pfx. This test should not fail on a system that doesn't support the used crypto.
System.PlatformNotSupportedException: A crypto implementation of DH-MODP-14 does not exist for Unix
    at Kerberos.NET.Crypto.CryptoPal.PlatformNotSupported(String algorithm) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/Pal/CryptoPal.cs:line 95
   at Kerberos.NET.Crypto.LinuxCryptoPal.DiffieHellmanModp14() in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/Pal/Linux/LinuxCryptoPal.cs:line 55
   at Kerberos.NET.Credentials.KerberosAsymmetricCredential.StartKeyAgreement() in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Credentials/KerberosAsymmetricCredential.cs:line 131
   at Kerberos.NET.Credentials.KerberosAsymmetricCredential.TransformKdcReq(KrbKdcReq req) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Credentials/KerberosAsymmetricCredential.cs:line 203
   at Kerberos.NET.Entities.KrbAsReq.CreateAsReq(KerberosCredential credential, AuthenticationOptions options) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Entities/Krb/KrbAsReq.cs:line 78
   at Kerberos.NET.Client.KerberosClient.RequestTgt(KerberosCredential credential) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Client/KerberosClient.cs:line 1194
   at Kerberos.NET.Client.KerberosClient.AuthenticateCredential(KerberosCredential credential) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Client/KerberosClient.cs:line 374
   at Kerberos.NET.Client.KerberosClient.Authenticate(KerberosCredential credential) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Client/KerberosClient.cs:line 357
   at Tests.Kerberos.NET.KdcListenerTestBase.RequestAndValidateTicketsWithCaches(KdcListener listener, String user, String password, String overrideKdc, KeyTable keytab, String s4u, Boolean encodeNego, Boolean caching, Boolean includePac, X509Certificate2 cert, String spn, KeyAgreementAlgorithm keyAgreement, Boolean allowWeakCrypto, Boolean useWeakCrypto, Boolean mutualAuth, KrbTicket s4uTicket, Boolean useKrb5TicketCache) in /home/.../RiderProjects/Kerberos.NET/Tests/Tests.Kerberos.NET/End2End/KdcListenerTestBase.cs:line 229
   at Tests.Kerberos.NET.KdcListenerTestBase.RequestAndValidateTickets(KdcListener listener, String user, String password, String overrideKdc, KeyTable keytab, String s4u, Boolean encodeNego, Boolean caching, Boolean includePac, X509Certificate2 cert, String spn, KeyAgreementAlgorithm keyAgreement, Boolean allowWeakCrypto, Boolean useWeakCrypto, Boolean mutualAuth, KrbTicket s4uTicket) in /home/.../RiderProjects/Kerberos.NET/Tests/Tests.Kerberos.NET/End2End/KdcListenerTestBase.cs:line 134
   at Tests.Kerberos.NET.ClientToKdcE2ETests.E2E_PKINIT() in /home/.../RiderProjects/Kerberos.NET/Tests/Tests.Kerberos.NET/End2End/ClientToKdcE2ETests.cs:line 106

Another location is in NdrTests.cs, where tests using either GeneratePacContainingClaims or GeneratePacWithoutClaims through GeneratePac fail. Here is an example stacktrace for NdrLogonInfoRoundtrip:
System.PlatformNotSupportedException: A crypto implementation of MD4 does not exist for Unix
    at Kerberos.NET.Crypto.CryptoPal.PlatformNotSupported(String algorithm) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/Pal/CryptoPal.cs:line 95
   at Kerberos.NET.Crypto.LinuxCryptoPal.Md4() in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/Pal/Linux/LinuxCryptoPal.cs:line 22
   at Kerberos.NET.Crypto.RC4Transformer.MD4(ReadOnlyMemory`1 key) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/RC4/RC4Transformer.cs:line 168
   at Kerberos.NET.Crypto.RC4Transformer.String2Key(KerberosKey key) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/RC4/RC4Transformer.cs:line 38
   at Kerberos.NET.Crypto.KerberosKey.<>c__DisplayClass45_0.<GetKey>b__0(EncryptionType etype) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/KerberosKey.cs:line 224
   at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
   at Kerberos.NET.Crypto.KerberosKey.GetKey(KerberosCryptoTransformer transformer) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/KerberosKey.cs:line 224
   at Kerberos.NET.Crypto.RC4Transformer.Decrypt(ReadOnlyMemory`1 ciphertext, KerberosKey key, KeyUsage usage) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/RC4/RC4Transformer.cs:line 82
   at Kerberos.NET.Entities.KrbEncryptedData.Decrypt[T](KerberosKey key, KeyUsage usage, Func`2 func) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Entities/Krb/KrbEncryptedData.cs:line 37
   at Kerberos.NET.Crypto.DecryptedKrbApReq.Decrypt(KerberosKey ticketEncryptingKey) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/DecryptedKrbApReq.cs:line 75
   at Kerberos.NET.Crypto.DecryptedKrbApReq.Decrypt(KeyTable keytab) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Crypto/DecryptedKrbApReq.cs:line 70
   at Kerberos.NET.Entities.ContextToken.DecryptApReq(KrbApReq token, KeyTable keytab) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Entities/SpNego/ContextToken.cs:line 35
   at Kerberos.NET.Entities.KerberosContextToken.DecryptApReq(KeyTable keys) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Entities/SpNego/KerberosContextToken.cs:line 26
   at Kerberos.NET.Entities.NegotiateContextToken.DecryptApReq(KeyTable keys) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/Entities/SpNego/NegotiateContextToken.cs:line 42
   at Kerberos.NET.KerberosValidator.Validate(ReadOnlyMemory`1 requestBytes) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/KerberosValidator.cs:line 70
   at Kerberos.NET.KerberosValidator.Validate(Byte[] requestBytes) in /home/.../RiderProjects/Kerberos.NET/Kerberos.NET/KerberosValidator.cs:line 58
   at Tests.Kerberos.NET.NdrTests.GeneratePacContainingClaims() in /home/.../RiderProjects/Kerberos.NET/Tests/Tests.Kerberos.NET/Pac/NdrTests.cs:line 66
   at Tests.Kerberos.NET.NdrTests.GeneratePac(Boolean includeClaims) in /home/.../RiderProjects/Kerberos.NET/Tests/Tests.Kerberos.NET/Pac/NdrTests.cs:line 42
   at Tests.Kerberos.NET.NdrTests.NdrLogonInfoRoundtrip() in /home/.../RiderProjects/Kerberos.NET/Tests/Tests.Kerberos.NET/Pac/NdrTests.cs:line 197

We have a bug tracking the request to change these values. It hasn't been a high priority unfortunately. https://github.com/dotnet/Kerberos.NET/issues/148

Is it okay to keep this issue open to document the creds in question?

Oh, yes, definitely.

There is no Linux implementation of MD4. It pinvokes Windows APIs only. You shouldn't be using the RC4/MD4 suite for anything anyway. Your app should be configured to use AES instead.

From: Ivan @.>
Sent: Wednesday, April 3, 2024 10:18:33 PM
To: dotnet/Kerberos.NET @.>
Cc: Comment @.>; Subscribed @.>
Subject: Re: [dotnet/Kerberos.NET] Tests: using platform-dependent crypto (Issue #335)
I'll join the problem. KerberosKey generation also does not work for me in Linux.
Framework: .Net 8
OS: Alpine 3.19 in Container
I'm trying to generate a key using:
        var keys = new[] {
              new KerberosKey(
<EMAIL_ADDRESS>         new PrincipalName(PrincipalNameType.NT_PRINCIPAL, "DOMAIN.SRV", new[] { "HTTP/SERVER.domain.srv" }),
         host: "SERVER.domain.srv",
         etype: EncryptionType.AES128_CTS_HMAC_SHA1_96)};
         var krb = new KerberosAuthenticator(new KerberosValidator(keys[0]));
         var identity = krb.Authenticate(authHeader[0].Replace("Negotiate ", ""));

Then I get the same error:
{System.PlatformNotSupportedException: A crypto implementation of MD4 does not exist for Unix
at Kerberos.NET.Crypto.CryptoPal.PlatformNotSupported(String algorithm) in D:\a\1\s\Kerberos.NET\Crypto\Pal\CryptoPal.cs:line 95
at Kerberos.NET.Crypto.LinuxCryptoPal.Md4() in D:\a\1\s\Kerberos.NET\Crypto\Pal\Linux\LinuxCryptoPal.cs:line 22
at Kerberos.NET.Crypto.RC4Transformer.MD4(ReadOnlyMemory1 key) in D:\a\1\s\Kerberos.NET\Crypto\RC4\RC4Transformer.cs:line 168    at Kerberos.NET.Crypto.RC4Transformer.String2Key(KerberosKey key) in D:\a\1\s\Kerberos.NET\Crypto\RC4\RC4Transformer.cs:line 38    at Kerberos.NET.Crypto.KerberosKey.<>c__DisplayClass45_0.<GetKey>b__0(EncryptionType etype) in D:\a\1\s\Kerberos.NET\Crypto\KerberosKey.cs:line 224    at System.Collections.Concurrent.ConcurrentDictionary2.GetOrAdd(TKey key, Func2 valueFactory)    at Kerberos.NET.Crypto.KerberosKey.GetKey(KerberosCryptoTransformer transformer) in D:\a\1\s\Kerberos.NET\Crypto\KerberosKey.cs:line 224    at Kerberos.NET.Crypto.RC4Transformer.Decrypt(ReadOnlyMemory1 ciphertext, KerberosKey key, KeyUsage usage) in D:\a\1\s\Kerberos.NET\Crypto\RC4\RC4Transformer.cs:line 82
at Kerberos.NET.Entities.KrbEncryptedData.Decrypt[T](KerberosKey key, KeyUsage usage, Func2 func) in D:\a\1\s\Kerberos.NET\Entities\Krb\KrbEncryptedData.cs:line 34    at Kerberos.NET.Crypto.DecryptedKrbApReq.Decrypt(KerberosKey ticketEncryptingKey) in D:\a\1\s\Kerberos.NET\Crypto\DecryptedKrbApReq.cs:line 75    at Kerberos.NET.Crypto.DecryptedKrbApReq.Decrypt(KeyTable keytab) in D:\a\1\s\Kerberos.NET\Crypto\DecryptedKrbApReq.cs:line 70    at Kerberos.NET.Entities.ContextToken.DecryptApReq(KrbApReq token, KeyTable keytab) in D:\a\1\s\Kerberos.NET\Entities\SpNego\ContextToken.cs:line 43    at Kerberos.NET.Entities.KerberosContextToken.DecryptApReq(KeyTable keys) in D:\a\1\s\Kerberos.NET\Entities\SpNego\KerberosContextToken.cs:line 38    at Kerberos.NET.Entities.NegotiateContextToken.DecryptApReq(KeyTable keys) in D:\a\1\s\Kerberos.NET\Entities\SpNego\NegotiateContextToken.cs:line 38    at Kerberos.NET.KerberosValidator.Validate(ReadOnlyMemory1 requestBytes) in D:\a\1\s\Kerberos.NET\KerberosValidator.cs:line 70
at Kerberos.NET.KerberosAuthenticator.Authenticate(ReadOnlyMemory`1 token) in D:\a\1\s\Kerberos.NET\KerberosAuthenticator.cs:line 73
at Kerberos.NET.KerberosAuthenticator.Authenticate(Byte[] token) in D:\a\1\s\Kerberos.NET\KerberosAuthenticator.cs:line 69
at Kerberos.NET.KerberosAuthenticator.Authenticate(String token) in D:\a\1\s\Kerberos.NET\KerberosAuthenticator.cs:line 65
at TestKerberos2.MiddleWare.Invoke(HttpContext context) in C:\Users\user\source\repos\TestKerberos2\TestKerberos2\MiddleWare.cs:line 45}
In this case, decryption of tickets using keytab is successful.
I tried to revert MD4 to Unix myself, but it didn't help:

Installed the openssl package
Applied the fix from the article dotnet/runtime#67353 (comment)https://github.com/dotnet/runtime/issues/67353#issuecomment-1085003764

If my problem is not related to the current one, I can create a separate issuse.
—
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/Kerberos.NET/issues/335#issuecomment-2036494345 or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAJHTYJLS4A47H3NK2CKXMDY3UEFVBFKMF2HI4TJMJ2XIZLTSSBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVE2TMNBSG4ZDGNJVURXGC3LFVFUGC427NRQWEZLMVRZXKYTKMVRXIX3UPFYGLLCJONZXKZKDN5WW2ZLOOSTHI33QNFRXHE4CUR2HS4DFVJZGK4DPONUXI33SPGSXMYLMOVS2QOBVGQ4DSMJTHCBKI5DZOBS2K2LTON2WLJLWMFWHKZNKGE3DAMJYG44TGOJRQKSHI6LQMWSWYYLCMVWKK5TBNR2WLKJVGY2DENZSGM2TLJ3UOJUWOZ3FOKTGG4TFMF2GK.
You are receiving this email because you commented on the thread.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Gradients cause banding in SRP and Direct3D11

Gradients in a riv file cause banding when using SRP and Direct3D11.

Use this riv file with the repo below:
banding.zip
https://github.com/rive-app/rive-unity/files/14911845/URPOffsetIssue.zip

I'm also having this issue, and found a discussion on Discord with others having this issue: https://discord.com/channels/532365473602600965/1215855416043503627
I also linked the Discord thread back to this issue. Fixing this issue would help at least four Unity developers using the Rive Unity runtime!

This looks related: https://rive.app/community/forums/bugs/fsLjspgTHYcR/transparency-issues-in-ue5/ftjRTvjFapi8
It looks like this was fixed in UE5/DX11! Given both runtimes use DX11, it feels plausible that the fix for UE5/DX11 runtime can probably fix Unity/DX11 runtime. :)

Also refer to: https://github.com/rive-app/rive-unreal/issues/55

Hi Jaden, thanks for detailing the issue. We're looking into a fix for this in Unity.

This should be fixed from v0.1.188. Please upgrade and let us know if you're still running into issues with banding.


How to add a format that doesn't introduce newlines?

I'm trying to create a plain format that would simply enter the label of the entry, but nothing else.
A custom plain format, cite_marker = '%s' introduces one newline. How to suppress these?
EDIT: One newline is introduced, not two. Newline + enter insert mode. Effectively, PrintLabel+ja.

When I try to do it like this:
      custom_formats = {
        {id = 'myCoolFormat', cite_marker = '%s'}
      },
      format = 'myCoolFormat',

I get only the label, no newlines. Maybe something else is responsible for the newlines in you config?

Would you dare guess what configuration options might introduce newlines?
I have no custom telescope configuration apart from configuring the bibtex extension, thus:
require('telescope').setup {
  extensions = {
    bibtex = {
      depth = 1,
      custom_formats = {
        {id = 'plain', cite_marker = '%s'}
      },
      format = 'plain',
      global_files = { "/path/to/sources.bib" },
      search_keys = { 'author', 'year', 'title' },
    }
  }
}

require('telescope').load_extension("bibtex")

When calling :Telescope bibtex<cr> at X on line 3 I get the search window. Pressing enter for selecting an entry, the label is entered on line 3 and the cursor is moved to position Y on line 4, in insert mode. Doesn't matter if I call :Telescope bibtex from normal mode or insert mode. What happens is 1) label is printed; 2) effectively "ja" (one line down and enter insert mode).
1 text
2 more text
3 text XMyCitationLabel
4. sYecond line

I am a bit lost about where the 'j' would come from. The inserting process is a bit hacky and I might look for something better in the future. Basically the label is inserted at the cursor position and then I do 'ea' to put the user in insert mode after the inserted text (thinking about it, 'Ea' may be better). But again, I do not know why it would move a line down. Is this just happening for your custom format or also for tex?

Happens for tex as well. \cite{key} is inserted and equivalent to movement ja is executed.
I call it through the following (lua) mapping; should it be done in some other fashion, perhaps?
local map = vim.api.nvim_set_keymap
local options = { silent = true, noremap = true }

map('n', '<leader>@@', '<cmd>Telescope bibtex<cr>', options)
map('i', '@@', '<cmd>Telescope bibtex<cr>', options)

The mappings look fine. I really cannot tell where this issue would come from. You can try to remove line 168 vim.api.nvim_feedkeys("ea", "n", true) and see where the cursor goes. Another thing you can try is calling vim.api.nvim_put(...) with some random stuff to see if that is done correctly. I will look for a better way to do the insertion some time in the future, but right now I do not have the time for that.

Without line 168, the cursor stops at the last character of key. That is, if bibtex key = "lorem", the cursor is at m.
It seems the behaviour I've been describing appears only if telescope-bibtex is invoked at the end of the line, not if there are trailing characters at the point where the cursor is on invocation.
Consider nvim_put({lines}, {type}, {after}, {follow}).
If I set follow = false I do not see the described behaviour regardless if I'm at the end of the line or not. That is, it seems that if the cursor was at the end of the line, follow = true led to cursor being moved to the next line.
Also, with after = true, if cursor was placed at the comma in the following setting  12,34 the key was not inserted after , but after 3. Setting after = false solved that issue.
However, with
        vim.api.nvim_put({entry}, "", false, false)
        vim.api.nvim_feedkeys("ea", "n", true)

and cursor at comma in 12,34, the key was inserted properly (12,lorem34) but the cursor was moved to 4! (It should, IMO, been moved between m and 3 --- that is, to the end of the key that was inserted.
The following lines give me the behaviour I'm personally expecting:
        vim.api.nvim_put({entry}, "", false, false)
        vim.api.nvim_feedkeys("la", "n", true)

With the above, it's working just as I'd like it to. Thanks!

Follow up. I believe the issue arose because of a different workflow. For me, I frequently cite several keys; I want to add page references, sometimes prefix text (i.e. \cite[cf.][9]{lorem} or \cite{lorem,ipsum}, etc). I've got snippets and whatnot to handle this, as well as my use of different cite-commands, such as \parencite{}, \textcite{}, \parencites{}, plain \cite and so on.
In the use-case where telescope-bibtex would insert the entire cite-command, complete with bib-key, the current setup works well (I imagine). For my use-case, I prefer handling 'the surrounding command' in other ways, and would like telescope-bibtex to merely insert the plain bib-key and nothing else (as it does with the nvim_put and nvim_feedkeys mentioned in the previous post.
I would thus suggest the addition of a new format, plain, which does only that, as described above, and that nvim_put and nvim_feedkeys would be conditional to the format used. Thus, telescope-bibtex could support both kinds of workflows.

This looks good for me as well:
vim.api.nvim_put({entry}, "", false, false)
vim.api.nvim_feedkeys("la", "n", true)

I think I didn't pay attention what nvim_put(.. true, true) does when I implemented this. Thanks for helping me with this.
Regarding the plain format, this sounds like a resonable thing to provide out of the box. But why does the cursor need to be at the beginning of the inserted text (assuming that is what you mean)? I think this is rather specific for your workflow and not something others would expect the plugin to do.

Sounds good!
Not sure what you meant by that last thing about the cursor though. I must've been unclear at some point.
I would expect the key to be inserted where the cursor is. And I would expect the cursor at the end of the inserted key, after insertion.

Yes ok, then we got the same thing in mind. I should probably implement a check whether bibtex was called from normal or insert mode to place the user in the right mode after the insertion.

Works great in current master. Thank you!

Hey @krissen I am about to revert the changes to vim.api.nvim_put(...). I hope this does not break anything for you.
I implemented a new way to specify the format which should fit your workflow.
If you have \cite[]{} with the cursor between the {} in insert mode, you can call :Telescope bibtex cite format=plain to insert the label inside the {}. Similary doing the same with the cursor on { in normal mode will paste the entry inside the brackets as well.
If you already set format='plain' in the setup-function, everything should work as well.
Please let me know if any issues arise from this.

Gotcha! Thank you for the heads up; much appreciated.


Broken method get_time_entries({start_date: @now - 1, end_date: @now + 1})

Methods, which described in specs seems to be broken (Outdated API calls?)
https://github.com/kanet77/togglv8/blob/master/spec/lib/togglv8/time_entries_spec.rb
require 'togglv8'
require 'json'

config = JSON.parse(File.read('config.json'))

toggl    = TogglV8::API.new(config['toggl_api_token'])

@now = DateTime.now
r = toggl.get_time_entries({start_date: @now - 1, end_date: @now + 1})
r.each do |e|
  p e
  p '------'
end

Gives 400 response from server:
/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/togglv8-1.0.2/lib/togglv8.rb:93:in `_call_api': HTTP Status: 400 (RuntimeError)
	from /Users/garmoshka-mo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/togglv8-1.0.2/lib/togglv8.rb:100:in `get'
	from /Users/garmoshka-mo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/togglv8-1.0.2/lib/togglv8/time_entries.rb:82:in `get_time_entries'
	from import.rb:12:in `<main>'

To be exact - same code but only without ({start_date: @now - 10, end_date: @now}) - works as expected
(though not very usable because returns tons of records)

Are you using the latest version (v1.0.2)? I'm able to run your code exactly as it's written.
$ ruby garmoshka-mo.rb
{"id"=>321144098, "guid"=>"a8cb8f08-0508-4d4b-8e19-d2a21e2bb292", "wid"=>1062195, "billable"=>false, "start"=>"2016-01-14T05:39:34+00:00", "stop"=>"2016-01-14T05:39:38+00:00", "duration"=>3, "description"=>"issue #11", "duronly"=>false, "at"=>"2016-01-14T05:39:38+00:00", "uid"=>1820939}
"------"

However, it looks like Toggl may have made an API change. I re-ran my latest Travis CI build without making any code changes and it failed.
I see 400 response codes relating to Task API calls and other errors relating to Projects. I see the same errors running tests locally. I'll take a look.

I'm wrong about the cause of my errors. My Toggl subscription ran out and I was testing Pro features without a Pro account. Everything looks good in Travis CI now.
On closer inspection I see that you do have v1.0.2 of togglv8. No guess why you're getting a 400. I'll see if there's an easy way to add better end-user debugging to the gem.

When i have:
r = toggl.get_time_entries({start_date: @now - 1, end_date: @now + 1})

Here is what full_resp have:
#<Faraday::Response:0x007fbc008df158 @on_complete_callbacks=[], @env=#<Faraday::Env @method=:get @body="Invalid start date\n" @url=#<URI::HTTPS https://www.toggl.com/api/v8/time_entries?end_date=2016-01-19T18%3A32%3A37+02%3A00&start_date=2016-01-17T18%3A32%3A37+02%3A00> @request=#<Faraday::RequestOptions (empty)> @request_headers={"Content-Type"=>"application/json", "Authorization"=>"Basic --<CUT>--", "User-Agent"=>"Faraday v0.9.2"} @ssl=#<Faraday::SSLOptions verify=true> @response=#<Faraday::Response:0x007fbc008df158 ...> @response_headers={"server"=>"nginx", "date"=>"Mon, 18 Jan 2016 16:32:24 GMT", "content-type"=>"text/plain; charset=utf-8", "content-length"=>"19", "connection"=>"close", "cache-control"=>"no-cache, private, no-store, must-revalidate, max-stale=0, post-check=0, pre-check=0", "x-content-type-options"=>"nosniff", "x-toggl-request-id"=>"8a2c9b0f-bc27-4272-7ebc-eea04c098429"} @status=400>>

So it says "Invalid start date"
And this - works:
r = toggl.get_time_entries({start_date: '2016-01-17', end_date: '2016-01-19'})

So i'll use custom formatting for my task, though probably someone else may meet same isssue

Thanks for the debug output. It helped me recognize the problem was the '+' in your ISO8601-formatted time.
end_date=2016-01-19T18%3A32%3A37+02%3A00&start_date=2016-01-17T18%3A32%3A37+02%3A00
                                ^                                          ^

I didn't see this problem because I have a negative UTC offset.
Use v1.0.4 for the fix.
Also, you can now print the Faraday debug output to STDOUT by calling toggl.debug(true) (or simply toggl.debug).

Thanx!
Yeah, that debug option would simplify understanding of issues a lot


CLOUD-53143 metadata and ssh fingerprint collection errorhandling fix on the flow

@keyki pls review

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/cloudbreak-pull-request/2145/


Sync records in sampleMetadata with those in df after possible removal

Resolves #10
Adds functionality to remove samples in the sampleMetadata that were removed during getCollectionData. Or more accurately, keeps those records that were complete in the collection data.
Regardless of annotations or anything, we need to keep sampleDetails records synced with the data's. I looked into other cases where we might have a mismatch and didn't see any issues.

so i notice you made this change in the mbio version of veupathUtils... i was expecting a resurrection of the veupath version?

I'd like to wait a bit to see what some of the plans are going to be, also the change here was small enough that it's not a bit deal to add it to the veupath one later


Hide SQL password in logs

Proposed changes:

fixes #5805

Status (please check what you already did):

[ ] added some tests for the functionality
[ ] updated the documentation
[ ] updated the changelog (please check changelog for instructions)
[ ] reformat files using black (please check Readme for instructions)

@ricwo just FYI, not sure if you saw https://github.com/RasaHQ/rasa/pull/5841

I hadn't seen this - thanks @erohmensing


NDT Rviz plugin can not display NDT map using DistributionsPublisher??

The map can be visualized using PointcloudPulisher,This is  my launch file.
velodyne.txt
I am using ubuntu 18.04 and ros melodic.

Hello @will1991
we experienced difficulties with other self-compiled RVIZ plugins as well. Is it possible, that there is a 'devel' folder inside your 'build' folder and that you need to source '/build/devel/setup.sh' before starting RVIZ? I remember that this worked for a different RVIZ plugin.
However, I would in general recommend you to use the PointcloudPublisher, since it is faster (for the DistributionsPublisher, eigenvectors etc. are calculated), and the RVIZ plugin for Distributions is also rather slow if there are loads of distributions to be rendered (I had fps drops to <1 fps with Velodyne VLP-16 outdoor data). The DistributionsPublisher was intended mainly for debugging and needs to be improved massively for online usage.
If you use the PointcloudPublisher, try setting the RVIZ parameters to render boxes of about half the resolution or 1/4 of the resolution, and color by height, then you get a reasonable visualization similar to something like OctoMap.
And please note, that the resolution you specify in your launch file will be 2x the effective resolution of your grid, e.g. for 0.5m effective resolution you need to specify 1m in your launch file. Further, the 3D ONDT version is currently undergoing a rework, since the map update is too slow; I hope there will be an update soon (hopefully in the next few weeks).
Best wishes


fix: Pinning Pydantic<2.0 as Traefik-k8s ingress lib dependency

Description
Pinning Pydantic<2.0 as Traefik-k8s ingress lib dependency to fix the integration tests
Checklist:

[ ] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that validate the behaviour of the software
[ ] I validated that new and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[ ] I have bumped the version of the library

Haha, you beat me by seconds with this PR :)

You are always quicker.  The exceptions do not break the rules :)


feat ✨: Removing a set setting

The first displayed option when setting a setting is now to remove it.
This comes at the cost of 1 autocomplete slot but I suppose most users can narrow their channels enough down by typing that this is okay

@Dragons-Dev/qm Schau einmal drüber und release danach bidde, dange 😄


better logs

minor enhancements in logging

Coverage decreased (-0.1%) to 83.129% when pulling 6361006b8db50132f8c7fdcef710b885de8be955 on matiu:feat/logs2 into a1ec4593112770a6d38e25c99cc44ca1ddc755bb on bitpay:master.

Coverage decreased (-0.1%) to 83.129% when pulling 64e5a292e445a905e39f96d881ca5e0aef2bc9c4 on matiu:feat/logs2 into a1ec4593112770a6d38e25c99cc44ca1ddc755bb on bitpay:master.


feat: adding optional ebs volume

Adds feature request from #102
Not adding it to the example because I don't expect the majority of the users wanting to deploy this by default, I can change that if wanted.

Might need to re-sign some of those  previous commits. It's blocking the merge.


Migrate documentation of Stable Diffusion and add notebooks

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


When using a SubViewport to show 2D scenes the normal map information is lost.

Tested versions
4.3.stable
System information
Windows 11 - 4.3.stable.official Vulkan 1.3.280 - Forward+ - Using Device #0: NVIDIA - NVIDIA GeForce RTX 3060 Laptop GPU
Issue description
When using a SubViewport to show 2D scenes the normal map information is lost.
SubViewport.get_texture() returns a ViewportTexture that does not contain the information regarding normal maps.
For example, if I wanted to project a scene containing some Sprite2D and related textures (CanvasTexture containing diffuse_texture and normal_texture) onto a PlaneMesh using a SubViewport, currently there is no way to make it interact properly with the light coming on the mesh in the 3D environment, because the data about the normal maps is lost.
Here I am projecting a 2D scene on a SubViewport rendered on a mesh, there is no way to retrieve the normal map informations to make it react to the light in the 3D environment (the relative Sprite2D in the 2D scene has a normal map):

On the contrary using a 3D scene it is possible to see its normal information and use it throught Rendering > Debug Draw > Normal Buffer:

I have thought of a few solutions:

Set the diffuse_texture and normal_texture properties to ViewportTexture, mimicking the behavior of CanvasTexture.
Add the get_normal() method to SubViewport.
Make the SubViewport Rendering > Debug Draw > Normal Buffer feature that already works with 3D scenes work for 2D scenes as well.

Steps to reproduce

Create a 2D scene with one or more Sprite2D with a CanvasTexture and relative diffuse_texture and normal_texture.
Create a 3D scene with a MeshInstance3D and a shape.
Add a SubViewport node to the 3D scene and instantiate the 2D scene as a child of the SubViewport.
Add a material to the mesh, and add the SubViewport as a ViewportTexture in the albedo property.
From here there is no way to retrieve the normal map from the 2D scene and use it as a normal map for the material. Did not found any workaround.

Minimal reproduction project (MRP)
Here there is a little project with a SubViewport where both 3D and 2D scenes projection can be experimented. I animated the lights so that the results can be seen easily.
bug_sub_viewport_normals.zip

I'm going to go with not a bug, but a missing or maybe underdocumented feature, actually.
The normals buffer is not even fully supported for 3D. If I try your MRP with a 3D subviewport on Compatibility, the normal buffer debug view doesn't work, because there is no normal buffer on Compatibility. The debug views mostly just work with what is easily accessible, they don't go out of their way to add new buffers (because of code complexity and performance overhead). Notably there is a "lighting info" debug view for 3D, but it's not implemented by accessing a lighting buffer, because godot uses a forward renderer and doesn't have that buffer.
Compatibility:

Forward+:

For Compatibility 3D, the engine just does not store the normal information after using it to calculate lighting. It should be the same for a 2D viewport on any renderer. In 3D, I also believe you can only get one texture worth of information out of a subviewport, so you can't make use of both the rendered color and the debug normals. So all three of your proposed solutions have some barrier to implementation, I'm not sure which would be the easiest to implement technically.
I believe all three of your solutions require the 2D pipeline to create a normals buffer in addition to whatever buffers 2D currently creates, which technically might not be simple at all. Your proposed solutions only differ in how that information would be accessed, they don't change the fact that it's not currently there to use.
Maybe someone more familiar with the internals of the renderer can confirm?

That was my fear, I'm not an expert but it seems to me too that for the solutions I proposed the only way is to have a 2D normal buffer to draw from, if it doesn't exist it's a problem.
I don't know if someone who knows the engine better can propose a more viable solution?
All the other ideas I can think of are workarounds, I don't even know how feasible, and that seems to me to be not the best from a performance point of view:

Make a duplicate of the 2D scene in the SubViewport that contains only the normals data, and generate the texture via another SubViewport. The problem with this approach besides not being clean is that the two scenes must remain synchronized, if the scene is demanding so will the duplicate.
Insert a light source into the 2D scene that is affected in real time by the way the lights hit the mesh in the 3D scene. Don't even know if this is possible, maybe I'll give it a try.


oneof float support

add support for float32
ensure support for both float32 and float64
lint fixes
add tests for float64 & add test for nil pointer

@bxcodec I got bored haha. I decided to jump in sooner rather than later with support for the float types.

@bxcodec okay I think it is now ready for review again! 👍


K3s crashes on startup on fresh installed Debian Bullseye

Environmental Info:
K3s Version:
# k3s --version
k3s version v1.22.7+k3s1 (8432d7f2)
go version go1.16.10

Node(s) CPU architecture, OS, and Version:
x86_64
Debian GNU/Linux 11 (bullseye)
# uname -a
Linux mymachine 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27) x86_64 GNU/Linux

Cluster configuration:
Single node
Describe the bug:
K3s crashes on startup on a fresh installed Debian Bullseye. It's a VM under VMware v7
Steps To Reproduce:
# apt update && apt dist-upgrade -y
# curl -sfL https://get.k3s.io | sh -s -

I'v tested several options/args but did not change anything
Expected behavior:
No crash on startup.
Actual behavior:
K3s crashes on startup
Additional context / logs:
[INFO]  Finding release for channel stable
[INFO]  Using v1.22.7+k3s1 as release
[INFO]  Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.22.7+k3s1/sha256sum-amd64.txt
[INFO]  Skipping binary downloaded, installed k3s matches hash
[INFO]  Skipping installation of SELinux RPM
[INFO]  Skipping /usr/local/bin/kubectl symlink to k3s, already exists
[INFO]  Skipping /usr/local/bin/crictl symlink to k3s, already exists
[INFO]  Skipping /usr/local/bin/ctr symlink to k3s, already exists
[INFO]  Creating killall script /usr/local/bin/k3s-killall.sh
[INFO]  Creating uninstall script /usr/local/bin/k3s-uninstall.sh
[INFO]  env: Creating environment file /etc/systemd/system/k3s.service.env
[INFO]  systemd: Creating service file /etc/systemd/system/k3s.service
[INFO]  systemd: Enabling k3s unit
Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service.
[INFO]  systemd: Starting k3s
Job for k3s.service failed because the control process exited with error code.
See "systemctl status k3s.service" and "journalctl -xe" for details.

logs.txt

mars 09 16:42:57 mymachine k3s[16279]: time="2022-03-09T16:42:57+01:00" level=fatal msg="failed to find cpuset cgroup (v2)"

You appear to be missing required cgroups, which is unusual since they are all enabled by default on most major Linux distributions. Run k3s check-config to see what all is missing.

Hello,
Thanks for your help. This is the output of the command k3s check-config :
# k3s check-config

Verifying binaries in /var/lib/rancher/k3s/data/31ff0fd447a47323a7c863dbb0a3cd452e12b45f1ec67dc55efa575503c2c3ac/bin:
- sha256sum: good
- links: good

System:
- /usr/sbin iptables v1.8.7 (nf_tables): ok
- swap: should be disabled
- routes: ok

Limits:
- /proc/sys/kernel/keys/root_maxkeys: 1000000

modprobe: FATAL: Module configs not found in directory /lib/modules/4.19.0-8-amd64
info: reading kernel config from /boot/config-4.19.0-8-amd64 ...

Generally Necessary:
- cgroup hierarchy: cgroups V2 mounted, cpu|cpuset|memory controllers status: bad (fail)
    (for cgroups V1/Hybrid on non-Systemd init see https://github.com/tianon/cgroupfs-mount)
- /usr/sbin/apparmor_parser
apparmor: enabled and tools installed
- CONFIG_NAMESPACES: enabled
- CONFIG_NET_NS: enabled
- CONFIG_PID_NS: enabled
- CONFIG_IPC_NS: enabled
- CONFIG_UTS_NS: enabled
- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: enabled
- CONFIG_CGROUP_SCHED: enabled
- CONFIG_CPUSETS: enabled
- CONFIG_MEMCG: enabled
- CONFIG_KEYS: enabled
- CONFIG_VETH: enabled (as module)
- CONFIG_BRIDGE: enabled (as module)
- CONFIG_BRIDGE_NETFILTER: enabled (as module)
- CONFIG_IP_NF_FILTER: enabled (as module)
- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_IPVS: enabled (as module)
- CONFIG_IP_NF_NAT: enabled (as module)
- CONFIG_NF_NAT: enabled (as module)
- CONFIG_POSIX_MQUEUE: enabled

Optional Features:
- CONFIG_USER_NS: enabled
- CONFIG_SECCOMP: enabled
- CONFIG_CGROUP_PIDS: enabled
- CONFIG_BLK_CGROUP: enabled
- CONFIG_BLK_DEV_THROTTLING: enabled
- CONFIG_CGROUP_PERF: enabled
- CONFIG_CGROUP_HUGETLB: missing
- CONFIG_NET_CLS_CGROUP: enabled (as module)
- CONFIG_CGROUP_NET_PRIO: enabled
- CONFIG_CFS_BANDWIDTH: enabled
- CONFIG_FAIR_GROUP_SCHED: enabled
- CONFIG_RT_GROUP_SCHED: missing
- CONFIG_IP_NF_TARGET_REDIRECT: enabled (as module)
- CONFIG_IP_SET: enabled (as module)
- CONFIG_IP_VS: enabled (as module)
- CONFIG_IP_VS_NFCT: enabled
- CONFIG_IP_VS_PROTO_TCP: enabled
- CONFIG_IP_VS_PROTO_UDP: enabled
- CONFIG_IP_VS_RR: enabled (as module)
- CONFIG_EXT4_FS: enabled (as module)
- CONFIG_EXT4_FS_POSIX_ACL: enabled
- CONFIG_EXT4_FS_SECURITY: enabled
- Network Drivers:
  - "overlay":
    - CONFIG_VXLAN: enabled (as module)
      Optional (for encrypted networks):
      - CONFIG_CRYPTO: enabled
      - CONFIG_CRYPTO_AEAD: enabled (as module)
      - CONFIG_CRYPTO_GCM: enabled (as module)
      - CONFIG_CRYPTO_SEQIV: enabled (as module)
      - CONFIG_CRYPTO_GHASH: enabled (as module)
      - CONFIG_XFRM: enabled
      - CONFIG_XFRM_USER: enabled (as module)
      - CONFIG_XFRM_ALGO: enabled (as module)
      - CONFIG_INET_ESP: enabled (as module)
      - CONFIG_INET_XFRM_MODE_TRANSPORT: enabled (as module)
- Storage Drivers:
  - "overlay":
    - CONFIG_OVERLAY_FS: enabled (as module)

STATUS: 1 (fail)

Same here using latest Raspberry pi OS Lite image.

@m1m1s1ku have you seen the instructions at https://k3s-io.github.io/docs/advanced#additional-preparation-for-raspberry-pi-os

@brandond yep found on an issue the same to add, works great now !


Add uuid to messages sent to alerts

Hello, i linked my account, can you please verifly me?
name : BlackGonda


splitCallingCode not working while using with react-hook-form

<Controller
          name="tel"
          control={control}
          rules={{ validate: matchIsValidTel }}
          render={({ field, fieldState }) => {
            {
              console.log(field);
            }
            return (
              <MuiTelInput
                {...field}
                defaultCountry="BD"
                helperText={fieldState.invalid ? "Tel is invalid" : ""}
                error={fieldState.invalid}
                splitCallingCode
              />
            );
          }}
        />
``
The `console.log` is printing the value without country code. As a result `matchIsValidTel` can not validate the phone number.
If I remove the `splitCallingCode` props then the `field.value` has access to phone number with country code.

Hey !
Fixed in https://github.com/viclafouch/mui-tel-input/releases/tag/v3.0.0
Be careful for the breaking changes ;)
Thanks for the catch <3

hi @nhridoy , How did you get the country code disabled and with country flag?


Feature request: Method for returning time zone offset in milliseconds

Moment's utcOffset method returns the timezone offset in minutes. However, in some cases the time zone offset may not be an integral number of minutes - for example, in Chrome 68 for timezone Europe/Madrid dates before 1901-01-01 have an offset of -14 minutes 44 seconds - utcOffset returns -15, Javascript's getTimezoneOffset returns 14:.
momentjs("1900-12-31 23:45:15").utcOffset() // -15
momentjs("1900-12-31 23:45:16").utcOffset() // -0

new Date("1900-12-31 23:45:15").getTimezoneOffset() // 14
new Date("1900-12-31 23:45:16").getTimezoneOffset() // 0

As Chrome stores the dates internally with the correct offset, doing arithmetic using the rounded offsets can lead to errors (for example, sheetjs generates Excel date/times with a 44 second error using getTimezoneOffset)
Could a "utcOffsetMS" method be added to return the correct offset in milliseconds (seconds would do, but that would be one more returned unit to remember...)
Tested with Chrome 68, tz Madrid/Europe on Windows 7.

moment's utcOffset method rounds off the offset to the nearest 15 minutes (to cater for an old bug in Firefox.)
Chrome's the only browser (so far) to implement sub-minute timezone offsets, and AFAICT doesn't provide  access to read the offset from a Date.prototype method.
It might be a bit premature to add a method to support this, given it's only useful in one browser.
However, if you really need this, you could add your own implementation using the moment.fn extension point:
moment.fn.utcOffsetMS = function() {
  return this._isUTC
    ? (this._offset || 0) * 1000 * 60
    : moment.utc(this.toArray()) - this;
};

Agreed that it might be premature to implement at the moment. However, although it will only affect a few users at the moment, those it does affect are likely to have a hard time detecting the problem (I'm lucky to be working in Spain and have some knowledge of the timezone database, otherwise tracking down the problem would have been much more difficult.) A point in favor of adding a method would be that it would act as a heads up, showing users that there might be a problem in some cases. But I'm sure you guys know best, and no doubt have to be vigilant to prevent everything but the kitchen sink being added to the API!
Thanks for the fix - I had implemented something similar to solve the problem and con confirm it does the trick.

This is a great exchange. I'm going to close for now. If historical timezone offsets become more popular, we can reconsider this.


volumeName/volumeID doesn't work when creating volume from existing one

@pacoxu commented on Thu Jan 05 2017
volumeName Create from an existing volume ID.
I use docker 1.13-rc4 and rexray 0.6.2, the scaleio is 2.0.0
According to doc below, we can use volumeName to create from existing volume.

I use the below command and opts are passed to docker volume correctly.

[root@localhost ~]# docker volume create --driver rexray -o volumeName='rs1' -o volumeID='da93455600000000'  rs2
rs2
[root@localhost ~]# docker volume inspect rs2
[
{
"Driver": "rexray",
"Labels": {},
"Mountpoint": "/",
"Name": "rs2",
"Options": {
"volumeID": "da93455600000000",
"volumeName": "rs1"
},
"Scope": "global",
"Status": {
"availabilityZone": "default",
"fields": null,
"iops": 0,
"name": "rs2",
"server": "scaleio",
"service": "scaleio",
"size": 16,
"type": "defaultSP"
}
}
]

However, the volume rs2 is not a snapshot of rs1.

I looked into the code https://github.com/codedellemc/libstorage/blob/master/drivers/storage/scaleio/storage/scaleio_storage.go#L349 and the volumeName and volumeID is not used
ScaleIO snapshot create should use something like /api/instances /System::{id}/action/snapshotVolumes

@cduchesne commented on Fri Jan 06 2017
Thanks for pointing this out @pacoxu . This is a supported feature for drivers that support it. ScaleIO has no method of creating volumes from an existing snapshot. At least not that I've seen.
This does work with the Amazon EBS driver though:
[root@rexray-aws1 ~]# docker volume create --driver rexray --name vol01 --opt=snapshotID=snap-0da41ea35fe77b21a
vol01
[root@rexray-aws1 ~]# rexray volume ls
ID                     Name          Status       Size  Encrypted
vol-0d78fc2e47ded6d4a  vol01         available    16    false

@pacoxu commented on Fri Jan 06 2017
@cduchesn I realized this. ScaleIO only support  to create a snapshot for an existing volume and create a snapshot for an existing snapshot.
Can rexray just create a snapshot when snapshotID or volumeID is in the option list?
Currently, I have to remove the ancestor of snapshot to use the snapshot. [I'm not sure whether my explanation is clear.  So here is an example.]
Example: There is a volume vol1 and I created snapshot snap1 for vol1.
Then once the vol1 has some problem data, I want to revert to snap1. Firstly, at this point, I cannot use snap1 as it is not in the rexray volume list. I have to remove vol1, so that I can see snap1 from rexray.
I have another idea about it. In my opinion, snapshot is just a volume type in ScaleIO like thin provisioned or thick provisioned. Why we don't take all scaleio volumes/snapshots as volumes. And we only need one option which would be volumeName/volumeID, we don't have to support snapshot ID/name. We can just create a snapshot for the existing volume/snapshot(which are same in user's view.) This is more like copying a volume than snapshot a volume in ScaleIO.
Best regards
Paco

I think this may be able to be closed in favor or, or is at least related to, #457. Snapshot functionality with ScaleIO is coming up a lot.


Build against optparse-applicative-<IP_ADDRESS>

Tested using cabal test. This should allow turtle to get back into Stackage.

This unfortunately allows some non-working solutions:

optparse-applicative-1.8 switches to use prettyprinter on the backend
ansi-wl-pprint switches to do the same in 1.0.2
But optparse-applicative > 1.8 and ansi-wl-pprint < 1.0 and I think cabal can't know this

I think the only solution here is to require the newer versions of both, otherwise it's quite likely that if a user accidentally gets an earlier version of one of them, they'll just get a compiler error. I can make a patch if that's okay.

The alternative would be to have a version of turtle-1.6 that built with the old versions, and then one that forces the new versions. I think the simplest way to do that would be to revert the recent revisions to relax the bounds and then make an new release with higher bounds. Not sure though.

I don't understand what "But optparse-applicative > 1.8 and ansi-wl-pprint < 1.0" means? I don't understand the conflict, I assume that there are unsatisfiable constraints?

Sorry, let me be clearer.
In the past, optparse-applicative used ansi-wl-pprint for prettyprinting. Users who used both libraries could therefore interoperate between them.
Recently, optparse-applicative started using prettyprinter. Even more recently, ansi-wl-pprint was updated to also use prettyprinter. Users who use the new versions of these libraries can interoperate between them.
What does not work is e.g. a new optparse-applicative and an old ansi-wl-pprint, because they use different prettyprinting libraries and cannot interoperate. Since neither depends on the other, this incompatibilty cannot be conveyed to cabal so cabal can freely choose such a build plan, and it will just result in errors at the use site.
turtles version bounds allow this case since this revision. For me, that meant that turtle stopped compiling, since cabal picked the bad build plan. Since it's a revision, I can't pin to a working version and have to use external constraints.
Hence my suggestion:

Roll back the revision so the published version is sure to work again
Release a new version that requires new versions of o-p-a and a-w-pp that definitely work together

To me, it sounds best to just bump the lower bound of both as you previously suggested. Users with older versions can pull constraints from old Stackage snapshots.

Well, at the moment it's a landmine for cabal users. I would be fine with bumping the lower bounds again, I just think it's unfortunate to do this by revision as it potentially will break some people's build plans (as it would break mine, since I'm forced into the old ansi-wl-pprint!).

@michaelpj: Could you give me an example of the exact turtle build failure you're running into?  That would help me better understand what's going on.

In turtle: cabal build --constraint 'ansi-wl-pprint < 1. This is allowed by the solver but do not build. If you have this constraint from elsewhere in the build plan your will get a build failure.
(I thought cabal build --constraint 'optparse-applicative < 0.18 would also break but it in fact doesn't!)

Also just ran into this, reproducible example: Checkout current master (38a64c479af9ffdacb2bd6b83d2a821734918151) and run (I used GHC 9.2.8, but I think it shouldn't matter)
cabal build --index-state=2023-10-04T00:00:00Z --constraint='ansi-wl-pprint < 1'

You then get error messages like
src/Turtle/Options.hs:100:40: error:
    • Couldn't match type ‘Doc’
                     with ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc
                             prettyprinter-ansi-terminal-1.1.3:Prettyprinter.Render.Terminal.Internal.AnsiStyle’
      Expected: Options.Applicative.Help.Pretty.Doc
        Actual: Doc
      NB: ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc’
            is defined in ‘Prettyprinter.Internal’
                in package ‘prettyprinter-1.7.1’
          ‘Doc’
            is defined in ‘Text.PrettyPrint.ANSI.Leijen.Internal’
                in package ‘ansi-wl-pprint-0.6.9’
    • In the first argument of ‘Just’, namely ‘(getDescription desc)’
      In the first argument of ‘Opts.headerDoc’, namely
        ‘(Just (getDescription desc))’
      In the second argument of ‘Opts.info’, namely
        ‘(Opts.headerDoc (Just (getDescription desc)))’
    |
100 |                 (Opts.headerDoc (Just (getDescription desc)))
    |                                        ^^^^^^^^^^^^^^^^^^^

Full log
[ 1 of 10] Compiling Turtle.Internal  ( src/Turtle/Internal.hs, /tmp/tmp.3fnNRBFySY/turtle/dist-newstyle/build/x86_64-linux/ghc-9.2.8/turtle-1.6.1/build/Turtle/Internal.o, /tmp/tmp.3fnNRBFySY/turtle/dist-newstyle/build/x86_64-linux/ghc-9.2.8/turtle-1.6.1/build/Turtle/Internal.dyn_o )
[ 2 of 10] Compiling Turtle.Line      ( src/Turtle/Line.hs, /tmp/tmp.3fnNRBFySY/turtle/dist-newstyle/build/x86_64-linux/ghc-9.2.8/turtle-1.6.1/build/Turtle/Line.o, /tmp/tmp.3fnNRBFySY/turtle/dist-newstyle/build/x86_64-linux/ghc-9.2.8/turtle-1.6.1/build/Turtle/Line.dyn_o )

src/Turtle/Line.hs:67:3: warning: [-Wnoncanonical-monoid-instances]
    Noncanonical ‘(<>) = mappend’ definition detected
    in the instance declaration for ‘Semigroup Line’.
    Move definition from ‘mappend’ to ‘(<>)’
    See also: https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/semigroup-monoid
   |
67 |   (<>) = mappend
   |   ^^^^^^^^^^^^^^
[ 3 of 10] Compiling Turtle.Format    ( src/Turtle/Format.hs, /tmp/tmp.3fnNRBFySY/turtle/dist-newstyle/build/x86_64-linux/ghc-9.2.8/turtle-1.6.1/build/Turtle/Format.o, /tmp/tmp.3fnNRBFySY/turtle/dist-newstyle/build/x86_64-linux/ghc-9.2.8/turtle-1.6.1/build/Turtle/Format.dyn_o )

src/Turtle/Format.hs:72:1: warning: [-Wunused-imports]
    The import of ‘Data.Monoid’ is redundant
      except perhaps to import instances from ‘Data.Monoid’
    To import instances alone, use: import Data.Monoid()
   |
72 | import Data.Monoid ((<>))
   | ^^^^^^^^^^^^^^^^^^^^^^^^^
[ 4 of 10] Compiling Turtle.Options   ( src/Turtle/Options.hs, /tmp/tmp.3fnNRBFySY/turtle/dist-newstyle/build/x86_64-linux/ghc-9.2.8/turtle-1.6.1/build/Turtle/Options.o, /tmp/tmp.3fnNRBFySY/turtle/dist-newstyle/build/x86_64-linux/ghc-9.2.8/turtle-1.6.1/build/Turtle/Options.dyn_o )

src/Turtle/Options.hs:100:40: error:
    • Couldn't match type ‘Doc’
                     with ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc
                             prettyprinter-ansi-terminal-1.1.3:Prettyprinter.Render.Terminal.Internal.AnsiStyle’
      Expected: Options.Applicative.Help.Pretty.Doc
        Actual: Doc
      NB: ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc’
            is defined in ‘Prettyprinter.Internal’
                in package ‘prettyprinter-1.7.1’
          ‘Doc’
            is defined in ‘Text.PrettyPrint.ANSI.Leijen.Internal’
                in package ‘ansi-wl-pprint-0.6.9’
    • In the first argument of ‘Just’, namely ‘(getDescription desc)’
      In the first argument of ‘Opts.headerDoc’, namely
        ‘(Just (getDescription desc))’
      In the second argument of ‘Opts.info’, namely
        ‘(Opts.headerDoc (Just (getDescription desc)))’
    |
100 |                 (Opts.headerDoc (Just (getDescription desc)))
    |                                        ^^^^^^^^^^^^^^^^^^^

src/Turtle/Options.hs:117:40: error:
    • Couldn't match type ‘Doc’
                     with ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc
                             prettyprinter-ansi-terminal-1.1.3:Prettyprinter.Render.Terminal.Internal.AnsiStyle’
      Expected: Options.Applicative.Help.Pretty.Doc
        Actual: Doc
      NB: ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc’
            is defined in ‘Prettyprinter.Internal’
                in package ‘prettyprinter-1.7.1’
          ‘Doc’
            is defined in ‘Text.PrettyPrint.ANSI.Leijen.Internal’
                in package ‘ansi-wl-pprint-0.6.9’
    • In the first argument of ‘Just’, namely ‘(getHeader header)’
      In the first argument of ‘Opts.headerDoc’, namely
        ‘(Just (getHeader header))’
      In the first argument of ‘(<>)’, namely
        ‘Opts.headerDoc (Just (getHeader header))’
    |
117 |                 (Opts.headerDoc (Just (getHeader header)) <>
    |                                        ^^^^^^^^^^^^^^^^

src/Turtle/Options.hs:118:40: error:
    • Couldn't match type ‘Doc’
                     with ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc
                             prettyprinter-ansi-terminal-1.1.3:Prettyprinter.Render.Terminal.Internal.AnsiStyle’
      Expected: Options.Applicative.Help.Pretty.Doc
        Actual: Doc
      NB: ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc’
            is defined in ‘Prettyprinter.Internal’
                in package ‘prettyprinter-1.7.1’
          ‘Doc’
            is defined in ‘Text.PrettyPrint.ANSI.Leijen.Internal’
                in package ‘ansi-wl-pprint-0.6.9’
    • In the first argument of ‘Just’, namely ‘(getFooter footer)’
      In the first argument of ‘Opts.footerDoc’, namely
        ‘(Just (getFooter footer))’
      In the first argument of ‘(<>)’, namely
        ‘Opts.footerDoc (Just (getFooter footer))’
    |
118 |                  Opts.footerDoc (Just (getFooter footer)) <>
    |                                        ^^^^^^^^^^^^^^^^

src/Turtle/Options.hs:119:42: error:
    • Couldn't match type ‘Doc’
                     with ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc
                             prettyprinter-ansi-terminal-1.1.3:Prettyprinter.Render.Terminal.Internal.AnsiStyle’
      Expected: Options.Applicative.Help.Pretty.Doc
        Actual: Doc
      NB: ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc’
            is defined in ‘Prettyprinter.Internal’
                in package ‘prettyprinter-1.7.1’
          ‘Doc’
            is defined in ‘Text.PrettyPrint.ANSI.Leijen.Internal’
                in package ‘ansi-wl-pprint-0.6.9’
    • In the first argument of ‘Just’, namely ‘(getDescription desc)’
      In the first argument of ‘Opts.progDescDoc’, namely
        ‘(Just (getDescription desc))’
      In the second argument of ‘(<>)’, namely
        ‘Opts.progDescDoc (Just (getDescription desc))’
    |
119 |                  Opts.progDescDoc (Just (getDescription desc)))
    |                                          ^^^^^^^^^^^^^^^^^^^

src/Turtle/Options.hs:298:49: error:
    • Couldn't match type ‘Doc’
                     with ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc
                             prettyprinter-ansi-terminal-1.1.3:Prettyprinter.Render.Terminal.Internal.AnsiStyle’
      Expected: Options.Applicative.Help.Pretty.Doc
        Actual: Doc
      NB: ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc’
            is defined in ‘Prettyprinter.Internal’
                in package ‘prettyprinter-1.7.1’
          ‘Doc’
            is defined in ‘Text.PrettyPrint.ANSI.Leijen.Internal’
                in package ‘ansi-wl-pprint-0.6.9’
    • In the first argument of ‘Just’, namely ‘(getDescription desc)’
      In the first argument of ‘Opts.progDescDoc’, namely
        ‘(Just (getDescription desc))’
      In the second argument of ‘Opts.info’, namely
        ‘(Opts.progDescDoc (Just (getDescription desc)))’
    |
298 |     info = Opts.info p (Opts.progDescDoc (Just (getDescription desc)))
    |                                                 ^^^^^^^^^^^^^^^^^^^

src/Turtle/Options.hs:309:51: error:
    • Couldn't match type ‘Doc’
                     with ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc
                             prettyprinter-ansi-terminal-1.1.3:Prettyprinter.Render.Terminal.Internal.AnsiStyle’
      Expected: Options.Applicative.Help.Pretty.Doc
        Actual: Doc
      NB: ‘prettyprinter-1.7.1:Prettyprinter.Internal.Doc’
            is defined in ‘Prettyprinter.Internal’
                in package ‘prettyprinter-1.7.1’
          ‘Doc’
            is defined in ‘Text.PrettyPrint.ANSI.Leijen.Internal’
                in package ‘ansi-wl-pprint-0.6.9’
    • In the first argument of ‘Just’, namely ‘(getDescription desc)’
      In the first argument of ‘Opts.progDescDoc’, namely
        ‘(Just (getDescription desc))’
      In the second argument of ‘Opts.info’, namely
        ‘(Opts.progDescDoc (Just (getDescription desc)))’
    |
309 |             (Opts.info p (Opts.progDescDoc (Just (getDescription desc))))
    |                                                   ^^^^^^^^^^^^^^^^^^^
Error: cabal: Failed to build turtle-1.6.1.

In my case, adding --constraint='ansi-wl-pprint >= 1' did resolve the situation (note that the solver ended up chosing ansi-wl-pprint < 1 without any manual flag like in the reproducer above).

This might be a case for the Cabal team like e.g. @Mikolaj. I am not sure why Cabal tries the lower version of ansi-wl-pprint first. That seems odd when the newer version would work fine. Usually, when Cabal searches for versions, it starts with the highest one, at least judging from the error messages.

That may be related to the fact that ansi-wl-pprint is not on Hackage, perhaps?
https://hackage.haskell.org/packages/search?terms=ansi-wl-pprint
E.g., if a package version is deprecated, cabal tries not to choose it when planning, but you can force it on commandline IIRC. Are there any deprecated versions around? Also, I'm quite surprised a package not on Hackage is solved for successfully. There must be some mechanism that permits that (or is the package hidden from the UI?). If you discover what it is, I'd be glad to learn.

It is on Hackage, but as it is marked as deprecated as a whole (but all individual versions are not deprecated), it does not show up in the search: https://hackage.haskell.org/package/ansi-wl-pprint

Thanks! BTW, I now understand why this occurs: I am running a cabal script in a Nix shell where ansi-wl-pprint-0.6.9 is preinstalled, and the Cabal solver always first tries to find a plan that includes installed packages, which is possible ATM, but will no longer be with #447.


adding support for menu xml file

If somebody already have an menu xml file describing the bottom tabs (coming from BottomNavMenuView implementation) it will be useful.

Coverage remained the same at 57.172% when pulling 9fcf75db98fbecfe5eb87183b2e9152ff9a761db on anoop44:menu_xml_support into 338ee864392087f0233ef42765730e00810cd020 on roughike:master.

This won't work as is, (or maybe will), but at least the studio will show lint warnings and a red underline if you try the give the parser a menu resource instead of xml resource.

@roughike @anoop44 and also, did you test it out? cause i just refactor this parser yesterday and if i remember correctly, you should be checking for "item" isntead of "menu" because the "item" tag is the one that has the information for each tab. But, this is so simple to do, that adding it to the library makes no sense


[Type checker] Don't finalize decls from other source files after an error

Per feedback from Jordan, this avoids extra work without missing
additional diagnostics from the current source file.

@swift-ci please smoke test and merge


Segmentation fault at sub-thread exit when GLFW is initialized and terminated in a sub-thread and glfwMakeContextCurrent was used in the main thread.

Operating System: Linux Mint 19
Kernel: Linux 4.15.0-124-lowlatency
Architecture: x86-64
GLFW shared library is version 3.3.3, accessed via headers for GLFW 3.3.3.
GLFW version string: "3.3.3 X11 GLX EGL OSMesa clock_gettime evdev shared"
This is as simplest example I'm able to make:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
#include <semaphore.h>
#include <GLFW/glfw3.h>

GLFWwindow *global;
sem_t sem1, sem2;

static void *function (void *argument) {
  printf("Initializing GLFW...\n");
  glfwInit();
  global = glfwCreateWindow(64, 64, "GLFW Window", NULL, NULL);
  printf("GLFW has been initialized.\n");
  sem_post(&sem1);

  // The main thread calls glfwMakeContextCurrent here.

  sem_wait(&sem2);
  printf("Terminating GLFW...\n");
  glfwDestroyWindow(global);
  glfwTerminate();
  printf("GLFW has been terminated.\n");
};

int main (int argc, char **argv) {
  pthread_t thread;
  pthread_attr_t attr;
  sem_init(&sem1, 0, 0);
  sem_init(&sem2, 0, 0);

  printf("Spawning thread...\n");
  pthread_attr_init(&attr);
  pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_JOINABLE);
  pthread_create(&thread, &attr, function, NULL);
  pthread_attr_destroy(&attr);
  printf("Waiting for thread to initialize GLFW...\n");
  sem_wait(&sem1);

  printf("Calling glfwMakeContextCurrent()...\n");
  glfwMakeContextCurrent(global);

  // uncommenting the next line eliminates the segmentation fault
  //glfwMakeContextCurrent(NULL);

  sem_post(&sem2);
  printf("Waiting for thread to join...\n");
  pthread_join(thread, NULL);
  printf("Thread has joined.\n");
  sem_destroy(&sem1);
  sem_destroy(&sem2);

  printf("Terminating main program.\n");
  return 0;
};

It produces this output:
Spawning thread...
Waiting for thread to initialize GLFW...
Initializing GLFW...
GLFW has been initialized.
Calling glfwMakeContextCurrent()...
Waiting for thread to join...
Terminating GLFW...
GLFW has been terminated.
Segmentation fault (core dumped)

Here's what valgrind says:
==9893== Thread 2:
==9893== Jump to the invalid address stated on the next line
==9893==    at 0x999CCB0: ???
==9893==    by 0x4E44407: __nptl_deallocate_tsd.part.5 (pthread_create.c:300)
==9893==    by 0x4E4581A: __nptl_deallocate_tsd (futex-internal.h:200)
==9893==    by 0x4E4581A: start_thread (pthread_create.c:473)
==9893==    by 0x53EB71E: clone (clone.S:95)
==9893==  Address 0x999ccb0 is not stack'd, malloc'd or (recently) free'd

In one of the programs I initially encountered this issue in, the valgrind output starts out with this:
==13328== Invalid read of size 4
==13328==    at 0x9700FF0: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.450.80.02)
==13328==    by 0x9702E0A: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.450.80.02)
==13328==    by 0x9708D9D: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.450.80.02)
==13328==    by 0x9768257: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.450.80.02)
==13328==    by 0x4010D52: _dl_fini (dl-fini.c:143)
==13328==    by 0x5B3F160: __run_exit_handlers (exit.c:108)
==13328==    by 0x5B3F259: exit (exit.c:139)
==13328==    by 0x5B1DBFD: (below main) (libc-start.c:344)
==13328==  Address 0x715e454 is 228 bytes inside a block of size 4,680 free'd
==13328==    at 0x4C32D3B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13328==    by 0x610BE7E: XCloseDisplay (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==13328==    by 0x4E53D50: _glfwPlatformTerminate (in /usr/local/lib/libglfw.so.3.3)
==13328==    by 0x4E47CA0: terminate (in /usr/local/lib/libglfw.so.3.3)
==13328==    by 0x4E484A4: glfwTerminate (in /usr/local/lib/libglfw.so.3.3)
==13328==    by 0x11893E: main_thread (glfw.c:360)
==13328==    by 0x58E46DA: start_thread (pthread_create.c:463)
==13328==    by 0x5C1D71E: clone (clone.S:95)
==13328==  Block was alloc'd at
==13328==    at 0x4C33B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13328==    by 0x611EE7D: XOpenDisplay (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==13328==    by 0x4E539E2: _glfwPlatformInit (in /usr/local/lib/libglfw.so.3.3)
==13328==    by 0x4E483B0: glfwInit (in /usr/local/lib/libglfw.so.3.3)
==13328==    by 0x11800B: main_thread (glfw.c:220)
==13328==    by 0x58E46DA: start_thread (pthread_create.c:463)
==13328==    by 0x5C1D71E: clone (clone.S:95)

In this case the thread joins successful, and indeed main() is able to exit, but then there is a segmentation fault within dl_fini, which the internet tells me is responsible for calling object deconstructors at program exit.  My own program is C and as far as I know GLFW is the only C++ in it.
In both the test program above and in my full program, I can add a glfwMakeContextCurrent(NULL) to detach the context from the main thread before the sub-thread calls glfwTerminate, and then the segmentation fault does not occur.  The line is commented in the test program above, so you can uncomment it and see that the program functions fine in that case.  However, the documentation does not say that I must detach the context.  So either the documentation is in error or GLFW is.

Oh, I did not realize that the "main thread" in "this function must only be called from the main thread" was not simply whichever thread I decided was going to be my main thread.
I swapped the actions of the two threads in the example and there is no problem when glfwInit is called from the main thread, so there is indeed no bug here.


Removes all postconditions from stuffer and blob functions

Signed-off-by: Felipe R. Monteiro<EMAIL_ADDRESS>Resolved issues:
N/A.
Description of changes:
Attempt to improve performance.
Call-outs:
N/A.
Testing:
CBMC proofs still makes sure these postconditions are checked.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Would it be better to have a check in the POSTCONDITION to see if CMBC is enabled only check it at that point?

#2433 supersedes this PR.


[FATFileSystem] Disabled flush on new sector

Disabled "flush on new sector" by default for a ~2.87x write performance improvement.

As an example of the effect on performance, my SDFileSystem_HelloWorld program yielded an average write speed of 142.33KB/s with FLUSH_ON_NEW_SECTOR enabled, and 409.18KB/s with it disabled.

I'm not sure what the justification for having these enabled by default is, they're detrimental to write performance

I am neither.  @sg- Any help here?

This feature was added and enabled in commit 2251b0267dda85cf8a096031b1cd01154b567040.  Disabling it by default would make the code work as the mbed port did originally.

cc @oliviermartin

from the commit message we should look at why fflush isnt/cant be retargeted.

@oliviermartin @neilt6 any more info for this changeset?

Apparently _sys_ensure() was the function to override in order to retarget fflush(), but it's deprecated and no longer called by any library function. In my opinion, this will only be a concern to data logging applications where power might be removed before files are closed, in which case developers could enable automatic flushing on their own.

I added this feature when I wrote a basic data logger with mbed.
As I said in my patch there is no easy way to retarget fflush() for mbed. Adding this feature would allow to revert this patch and write better data logger code (ie: code that invokes fflush() only when needed).

Is this pull request still being considered, or should I withdraw it?


xgboost: 2.0.1 -> 2.0.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/dmlc/xgboost/releases.
meta.description for xgboost is: Scalable, Portable and Distributed Gradient Boosting (GBDT, GBRT or GBM) Library
meta.homepage for xgboost is: https://github.com/dmlc/xgboost
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.0.3 in filename of file in /nix/store/a4877jnc3qyrgpch1hcsnsdri61ny2zf-xgboost-2.0.3

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

7 total rebuild path(s)

7 package rebuild(s)

First fifty rebuilds by attrpath
haskellPackages.xgboost-haskell
python310Packages.shap
python310Packages.xgboost
python311Packages.shap
python311Packages.xgboost
xgboost
xgboostWithCuda

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/bb759eadc612e46d8231d6acf969b1b4e4f331cf#xgboost

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

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

2 packages failed to build:

python310Packages.shap
python311Packages.shap

4 packages built:

python310Packages.xgboost
python311Packages.xgboost
xgboost
xgboostWithCuda

Maintainer pings
cc @abbradar @nviets for testing.

The R library fails to build in xgboost 2.0.3 because cmake can't fine libR. Did anything change in the build instructions for the R package? Log below:
@nix { "action": "setPhase", "phase": "unpackPhase" }
Running phase: unpackPhase
unpacking source archive /nix/store/c7h8x8bradl902vlfgs6hlmzzg0x877p-source
source root is source
@nix { "action": "setPhase", "phase": "patchPhase" }
Running phase: patchPhase
@nix { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" }
Running phase: updateAutotoolsGnuConfigScriptsPhase
@nix { "action": "setPhase", "phase": "configurePhase" }
Running phase: configurePhase
fixing cmake files...
cmake flags: -DCMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DCMAKE_INSTALL_LOCALEDIR=/nix/store/
3gk4qija29npzvg67zg8swb2l760i4d8-r-xgboost-2.0.3/share/locale -DCMAKE_INSTALL_LIBEXECDIR=/nix/store/3gk4qija29npzvg67zg8swb2l760i4d8-r-xgboost-2.0.3/libexec -DCMAKE_INSTALL_LIBDIR=/nix/store/3gk4qija29npzvg67zg8swb2l76
0i4d8-r-xgboost-2.0.3/lib -DCMAKE_INSTALL_DOCDIR=/nix/store/3gk4qija29npzvg67zg8swb2l760i4d8-r-xgboost-2.0.3/share/doc/xgboost -DCMAKE_INSTALL_INFODIR=/nix/store/3gk4qija29npzvg67zg8swb2l760i4d8-r-xgboost-2.0.3/share/i
nfo -DCMAKE_INSTALL_MANDIR=/nix/store/3gk4qija29npzvg67zg8swb2l760i4d8-r-xgboost-2.0.3/share/man -DCMAKE_INSTALL_OLDINCLUDEDIR=/nix/store/3gk4qija29npzvg67zg8swb2l760i4d8-r-xgboost-2.0.3/include -DCMAKE_INSTALL_INCLUDE
DIR=/nix/store/3gk4qija29npzvg67zg8swb2l760i4d8-r-xgboost-2.0.3/include -DCMAKE_INSTALL_SBINDIR=/nix/store/3gk4qija29npzvg67zg8swb2l760i4d8-r-xgboost-2.0.3/sbin -DCMAKE_INSTALL_BINDIR=/nix/store/3gk4qija29npzvg67zg8swb
2l760i4d8-r-xgboost-2.0.3/bin -DCMAKE_INSTALL_NAME_DIR=/nix/store/3gk4qija29npzvg67zg8swb2l760i4d8-r-xgboost-2.0.3/lib -DCMAKE_POLICY_DEFAULT_CMP0025=NEW -DCMAKE_OSX_SYSROOT= -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_STRIP=/
nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/strip -DCMAKE_RANLIB=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/ranlib -DCMAKE_AR=/nix/store/vwh2qqal1q101wv4jy40giavp73q0ms
d-clang-wrapper-16.0.6/bin/ar -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_INSTALL_PREFIX=/nix/store/3gk4qija29npzvg67zg8swb2l760i4d8-r-xgboost-2.0.3 -DR_LIB=ON
-- The CXX compiler identification is Clang 16.0.6
-- The C compiler identification is Clang 16.0.6
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- CMake version 3.27.8
-- Performing Test XGBOOST_MM_PREFETCH_PRESENT
-- Performing Test XGBOOST_MM_PREFETCH_PRESENT - Failed
-- Performing Test XGBOOST_BUILTIN_PREFETCH_PRESENT
-- Performing Test XGBOOST_BUILTIN_PREFETCH_PRESENT - Success
-- xgboost VERSION: 2.0.3
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found OpenMP_C: -fopenmp=libomp (found version "5.0")
-- Found OpenMP_CXX: -fopenmp=libomp (found version "5.0")
-- Found OpenMP: TRUE (found version "5.0")
CMake Deprecation Warning at dmlc-core/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

-- Found OpenMP_C: -fopenmp=libomp (found version "5.0")
-- Found OpenMP_CXX: -fopenmp=libomp (found version "5.0")
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - not found
-- Looking for fopen64
-- Looking for fopen64 - not found
-- Looking for C++ include cxxabi.h
-- Looking for C++ include cxxabi.h - found
-- Looking for nanosleep
-- Looking for nanosleep - found
-- Looking for backtrace
-- Looking for backtrace - found
-- backtrace facility detected in default set of libraries
-- Found Backtrace: /nix/store/kjcaylsca1fg47cgz94079xpgdfzi8s0-libSystem-11.0.0/include
-- /tmp/nix-build-r-xgboost-2.0.3.drv-0/source/dmlc-core/cmake/build_config.h.in -> include/dmlc/build_config.h
-- Performing Test SUPPORT_MSSE2
-- Performing Test SUPPORT_MSSE2 - Success
CMake Error at /nix/store/9m0szzwibi1rwp3wvn36r7w478i753ll-cmake-3.27.8/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find LibR (missing: LIBR_HOME LIBR_CORE_LIBRARY)
Call Stack (most recent call first):
  /nix/store/9m0szzwibi1rwp3wvn36r7w478i753ll-cmake-3.27.8/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
  cmake/modules/FindLibR.cmake:183 (find_package_handle_standard_args)
  R-package/CMakeLists.txt:1 (find_package)

-- Configuring incomplete, errors occurred!

@trivialfis, @hcho3

Looking at the diff, I haven't found anything related to CMake R. The only change to CMake files is checking gcc version for filesystem support.


ZooKeeper 3.5.5: new node types

Is New node types: Container, TTL a feature that should be implemented in this client?
http://zookeeper.apache.org/releases.html#releasenotes

It would make me very happy :)

Great! Will prioritize this one.

Added in https://github.com/yfinkelstein/node-zookeeper/pull/265

Added in https://github.com/yfinkelstein/node-zookeeper/pull/265


Customization of Country

Actually, Flashlight install the shop in english 🇬🇧 with country Great-Britain 🇬🇧 .
For PS Entreprise, we need to have an install with country France 🇫🇷 .
Thanks for your help.

It exists an argument for defining the country, for the install.
Language packs needs to be installed.
May be a @PrestaShop/tech-council  can help you.


Configure / Test DB Migrations in monorepo

I recently moved everything to a monorepo, separated the packages to make them more modular.
I updated everything including the tests, however, I haven't tested the migrations.
How do they behave taking into account that the dbConfig is now passed to the client?
New method in the dbClient? or a separate client just for migrations with a max of 1 connections?
** Remember to remove the drizzle.config.ts file from the workspace root **

Added the kitledger schema separate from public.
Drizzle kit game me some problems to run the migrations.
I should try tomorrow either Kysely or Prisma and see if they work better in a lib.

Cancelled really. Kysely did not really work for me.
In reality I'm rethinking whether to do monorepo or not.


Clarify readme language on dependency direction with Dev Kit

From some feedback from non-native English speaking folks, some of the language is being misinterpreted in intro paragraph of Readme, making it seem like C# Dev Kit comes with this extension or is required.
Current language (emphasis mine)"

A Visual Studio Code extension that provides rich language support for C# and is shipped along with C# Dev Kit.

Suggested change by customer:

A Visual Studio Code extension that provides rich language support for C#. Even more language support is provided by the C# Dev Kit extension which can be installed additionally.

Or something along those lines that doesn't feel dependency related in the wrong direction.
Ref: https://github.com/microsoft/vscode-dotnettools/issues/403#issuecomment-1683501779

Even more language support is provided by the C# Dev Kit

Does this mean that the C# Dev Kit is not a required addition? I noticed that basically every useful C# support broken when I got upgraded to the C# extension version 2.0. Things like “Go to Definition” simply didn’t work and it simply didn’t recognize anything of my project structure.
I thought this was just some temporary issue but it seems that the C# extension now no longer provides this when it is not used with Omnisharp. So I had to install the C# Dev Kit extension as well to get back this functionality that was provided by the C# extension in the past.
I’m personally fine with the C# Dev Kit extension being a necessity for the new closed source language server approach but I think it’s very disruptive that when I just update the C# extension suddenly everything that I am used to breaks. There should at least be some clear messaging that one either need to install the C# Dev Kit or re-enable Omnisharp if they want to continue with the functionality that they are used to.
And if either the C# Dev Kit or Omnisharp are a real dependency, then this should be clarified very clearly on the extension’s readme. Because right now it advertises features like refactoring and navigation when neither of these appear to work without the language server backend.

Things like “Go to Definition” simply didn’t work and it simply didn’t recognize anything of my project structure.

No, these should be working.

There should at least be some clear messaging

Honestly we're looking for better ways to communicate, trying not to be notification heavy, but may go that route.  We had all these in pre-release channel for months, had a pinned issue on the repo, blogged, etc. Any additional ideas are appreciated how you would have been better alerted.

Because right now it advertises features like refactoring and navigation when neither of these appear to work without the language server backend.

These should be working, there are some known issues -- but if you are still in a situation where with just C# v2.x alone and not working, let's get a bug and look at your specific issue.  The others are not required for this core functionality.

I believe I may be seeing the same behavior as @poke.  I don't work with .NET all the time, so I have not been keeping up with the latest news on this stuff.  I did see that there is a new C# extension, and the new Dev Kit extension.  Bounced back and forth between install/uninstall the Dev Kit becuase I'm trying to get intellisense to work.  Got used to "Restart Omnisharp" and selecting which project to load, etc.  Now I can't find the trick to get the plain old C# extension (not Dev Kit) to do anything.
What's weird is when I open a file, Program.cs for example, and close VSCode, then open the application again (so it starts up looking at Program.cs), it seems like the extension works for a second then fails.  The colorization of the file is wrong initially, then correct, as if the extension took a second to activate (which is normal), but then the colorization drops off, any there's no intellisense.
Looking for a known issue... What information can I provide to be more help?
Reference:

Hâhha metoo


Update READMEs, docs, add how-tos

Address part of #606

Codecov Report

Merging #607 (f2280d0) into main (b3ad6d1) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #607   +/-   ##
=======================================
  Coverage   26.97%   26.97%
=======================================
  Files          48       48
  Lines        5860     5860
=======================================
  Hits         1581     1581
  Misses       3995     3995
  Partials      284      284

SMASH THE LIKE BUTTON SO HARD I BROKE MY KEYBOARD

@decentralgabe is this a WIP? If so, can we have a flow on the REAME with curl which issues a credential for the simplest schema? (as one block example) - that would be wonderful

@michaelneale WIP yes, will take the VC stuff in a follow up PR didn't want this to get too big!


Implicitly include values without override on update/install

This is regarding the helm library, not the command-line client.
When installing or updating a chart, values from the chart values.yaml are not included unless you pass helm.UpdateValueOverrides or helm.ValueOverrides, regardless of whether you have overrides or not.
Example:
client := helm.NewClient(...)
chart, err := chartutil.Load(<some chart file>)

// Does NOT include values
client.UpdateReleaseFromChart(
  <releaseName>,
  chart,
)

// DOES include values
client.UpdateReleaseFromChart(
  <releaseName>,
  chart,
  helm.UpdateValueOverrides([]byte{}),
)

In cases where no overrides are necessary (in my case I do automated deployment from a service), I assumed values would be included by default and overrides would only replace them when/if given.
I can provide a preliminary patch this weekend if you agree with my assessment. From what I can tell, it should not break any current use (as helm.UpdateValueOverrides is always given, making it no different). An explicit "PassNoValues()" option could be added if you wish to exclude values.
The example here uses update, but the issue is the same for fresh installs as far as I can tell.

closing as inactive.


Documentation needs an update.

Package version
1.0.0-9
Describe the bug
The documentation (https://packages.adonisjs.com/packages/inertia) still mentions the older third-party package and mentions some commands that do not exist in this package.
Can we have some good examples with React?
Reproduction repo
No response

what you have linked is not our documentation but that of the community package for V5
the documentation and an example for React will come with the official release


Compatibility with Symfony3

Works as expected. It would be great for our team if you could create a new release for that!
Thanks in advance :)

Thx. Can you please merge/rebase with master/0.13.0 so that travis can verify that everything still works with Symfony3 ?

Jup Jup :)


honor ENV no_proxy variable when http_proxy is set

Using python 2.7 grpcio==1.3.5 on ubuntu 14.04
Also tried grpcio==1.5.0, as well as tried on macos, RHEL and saw the same issue.
A simple example (such as the hello world from grpc) is sufficient to reproduce this error.

set up the environment to point to a proxy server, or even to point to an invalid server.
http_proxy=blah

set another common proxy-related variable to indicate that localhost should not be proxied
no_proxy=localhost

try to run a grpc server on localhost and connect to it
./greeter_server.py
./greeter_client.py

I get this error:
Traceback (most recent call last):
File "./greeter_client.py", line 33, in
run()
File "./greeter_client.py", line 28, in run
response = stub.SayHello(helloworld_pb2.HelloRequest(name='you'))
File "...python2.7/site-packages/grpc/_channel.py", line 492, in call
return _end_unary_response_blocking(state, call, False, deadline)
File "...python2.7/site-packages/grpc/_channel.py", line 440, in _end_unary_response_blocking
raise _Rendezvous(state, None, None, deadline)
grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with (StatusCode.UNAVAILABLE, Endpoint read failed)>
At one point I turned on grpc traces and noticed something in the client side that indicated a proxy being used, then tried
unset http_proxy
Finally, the client could connect to the server.
Ideally, if grpc honors http_proxy, it should also honor no_proxy.  It is common in such environments where a proxy is used to have certain addresses whitelisted out of being proxied.

This was fixed in master branch last week by this PR https://github.com/grpc/grpc/pull/11755

Not fixed yet:

Windows 10 x64
grpcio 1.4.0
python 3.6.2
http_proxy=http://some_proxy:111
https_proxy=https://other_proxy:111
no_proxy=localhost,<IP_ADDRESS>

Same error above.
Thanks!.

The fix mentioned above was first released in 1.6, so it's not expected to work in 1.4.
I think we should call this fixed until/unless we have a report of it not working in 1.6.


sfp container should have community plugin preinstalled

Describe the bug
Copying issue from https://github.com/dxatscale/sfpowerscripts/issues/1444
Is it possible to get the community plugin preinstalled in the next release? 😇
Slack Message
To Reproduce
Steps to reproduce the behavior:
Try to publish site using sf community publish -n [MySite] -o [target-org]
Expected behavior
sf community publish command takes 2-4 seconds to execute as sf community plugin is preinstalled
Expected behavior
sf community publish command takes 3 minutes to execute as sf community plugin is not preinstalled

Hi @petter-eikeland, we want to keep this standard docker image as lightweight as possible. That is why this plugin is not installed automatically on SF CLi either.
(https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_plugins_overview.htm)
For this case, I advice you to create a custom image.
If you need help with that, let me know!
CC: @azlam-abdulsalam


Fixed issue #10003

Issue Reference
Fixed issue #10003

Checked and found that the issue has been fixed and working fine. For reference you can check the screenshot here