pictures instead of words

Is it possible to use pictures instead of words in the pagetypes categories and timeline? We are currently creating learning objects for illiterate people which means that we have to work visually.
By Katrien

You can do this now by dragging & dropping images into the label fields in the editor.

@FayCross @torinfo can this be made to work with .svg files too? Have tested with .png and .jpg and .gif and all work but .svg doesn't.


make doc site toggle between options and composition api just like vue site

What problem is this solving
it's hard to follow pinia's document due to the mixing of options-api and composition-api, also the composition api is not vue3.2 ready(script-setup)
Proposed solution
make the doc switchable between options and composition mode
Describe alternatives you've considered
the same way vue's doc site

Added to #829 but unsure if this is feasible/worth since it's not exactly like in Vue docs.


Homepage: Prototype a "all articles" page

[ ] Improve spacing (title + metadata)
[ ] Deal with long titles: Ellipsis ? Multiples lines? Allow various height sizes for cards?
[ ] Deal with image ratio
[ ] Deal with article not having images
[ ] Color code to differentiate news and reports?


Improve key usage checks in internal_verify() and backport fix of issue 1418 to v1.1.1

@vdukhovni, this is the said backport of the core of #10587
for fixing #1418 also for OpenSSL v1.1.1.

[x] documentation is added or updated
[x] tests are added or updated

I think I'm failing to understand something.
I expect a root CA certificate to always have the keyCertSign bit
set, that without that bit, the certificate can not be used to sign
certificates. One of the certificates the root CA signs is the root CA
certificate itself. So if the X509_V_FLAG_CHECK_SS_SIGNATURE is
set, I see no reason why we can't verify that signature.
The other trust anchor we can have is a self signed certificate
that is not a CA. It should not have the keyCertSign bit set,
otherwise it would also need to be a CA. In theory you could say
that it's not allowed to sign it's own certificate, but at the
same time it needs to do it. So here I see no reason that if
someone ensist to check the self signed signature that we check
it, it just might need special code to be able to deal with it.

I think I'm failing to understand something.
I expect a root CA certificate to always have the keyCertSign bit set, that without that bit, the certificate can not be used to sign certificates. One of the certificates the root CA signs is the root CA certificate itself. So if the X509_V_FLAG_CHECK_SS_SIGNATURE is set, I see no reason why we can't verify that signature.

Sure, and this normal case is not in question.

The other trust anchor we can have is a self signed certificate that is not a CA. It should not have the keyCertSign bit set, otherwise it would also need to be a CA. In theory you could say that it's not allowed to sign it's own certificate, but at the same time it needs to do it. So here I see no reason that if someone insist to check the self signed signature that we check it, it just might need special code to be able to deal with it.

Note that not all self-issued certs are self-signed.
One such interesting examples is https://tools.ietf.org/html/draft-ietf-curdle-pkix-04#section-10.2
As I just wrote a little further up, for self-issued certs a self-signature and consequently a self-signature verification is not always technically possible.
And even if so, the creator of the cert might still want to prohibit the use of the public key for cert signature verification,
and we should and can respect this.

Note that not all self-issued certs are self-signed.
One such interesting examples is https://tools.ietf.org/html/draft-ietf-curdle-pkix-04#section-10.2

We're talking about checking the self signatures, and that doesn't
have a self signature. The EXFLAG_SS flag should not be set in that
certificate, so there is nothing to check when
X509_V_FLAG_CHECK_SS_SIGNATURE is set.
I guess we can also be in the case where an intermediate CA is in
the trust store, but the root CA is not. We can't check the
signature of the last certificate, because it's not self-signed.
The X509_V_FLAG_CHECK_SS_SIGNATURE flag also doesn't do anything in
that case.
The manual currently says:
B<X509_V_FLAG_CHECK_SS_SIGNATURE> requires verifying the signature
of the last certificate in a chain even when it is a self-signed
(root CA) certificate.
This seems to assume that only self-signed certificates are in the
trust store, so I guess that should be clarified.
PS: That has been published as RFC 8410.

Note that not all self-issued certs are self-signed.

Sure, but unless you're also enable partial chains, a chain ending in a self-issued, but not self-signed certificate is incomplete!  Self-issued certificates need to have an authority key id that makes it clear that the certificate is not self-signed:
   The keyIdentifier field of the authorityKeyIdentifier extension MUST
   be included in all certificates generated by conforming CAs to
   facilitate certification path construction.  There is one exception;
   where a CA distributes its public key in the form of a "self-signed"
   certificate, the authority key identifier MAY be omitted.  The
   signature on a self-signed certificate is generated with the private
   key associated with the certificate's subject public key.  (This
   proves that the issuer possesses both the public and private keys.)
   In this case, the subject and authority key identifiers would be
   identical, but only the subject key identifier is needed for
   certification path building.

And in any case no one compels users to use the X509_V_FLAG_CHECK_SS_SIGNATURE flag. It is off by default. But if they ask for it, then the signature should be checked.  We should not confuse the keyUsage "certSign" bit (which is a policy constraint) with whether the algorithm is suitable for signing.  Surely the certificate signature was signed by a key that does support signing, and if that's the same as the algorithm of the SPKI, then the signature can be checked...

One such interesting examples is https://tools.ietf.org/html/draft-ietf-curdle-pkix-04#section-10.2
As I just wrote a little further up, for self-issued certs a self-signature and consequently a self-signature verification is not always technically possible.
And even if so, the creator of the cert might still want to prohibit the use of the public key for cert signature verification,
and we should and can respect this.

Not if they present a single-element chain with a self-signed EE key and ask for signature verification.

Note that not all self-issued certs are self-signed.

Sure, but unless you're also enable partial chains, a chain ending in a self-issued, but not self-signed certificate is incomplete!

Yes. For such a cert directly trusting it would not be sufficient.

Self-issued certificates need to have an authority key id that makes it clear that the certificate is not self-signed:
   The keyIdentifier field of the authorityKeyIdentifier extensin MUST
   be included in all certificates generated by conforming CAs to
   facilitate certification path construction.  There is one exception;
   where a CA distributes its public key in the form of a "self-signed"
   certificate, the authority key identifier MAY be omitted.  The
   signature on a self-signed certificate is generated with the private
   key associated with the certificate's subject public key.  (This
   proves that the issuer possesses both the public and private keys.)
   In this case, the subject and authority key identifiers would be
   identical, but only the subject key identifier is needed for
   certification path building.

Indeed for certs conforming to RFC 5280 one is able to deduce from the SKID and from the AKID (or its non-presence) whether the cert is (meant to be) self-signed.
Yet there are self-issued certs that do not have an SKID (e.g., X.509v1 certs) or with misleading SKID & AKID information (like the one in https://tools.ietf.org/html/draft-ietf-curdle-pkix-04#section-10.2, which is in test/certs/ee-ed25519.pem).
So the presence and the values of SKID and AKID are in general not sufficient for deciding whether it makes sense to check for self-signature.

And in any case no one compels users to use the X509_V_FLAG_CHECK_SS_SIGNATURE flag. It is off by default.

Right.

But if they ask for it, then the signature should be checked.

Up to this point it is not really clear whether we should be able and be allowed to check the self-signature.

We should not confuse the keyUsage "certSign" bit (which is a policy constraint) with whether the algorithm is suitable for signing.

I agree that we should not confuse these two.
Yet independently of this, as mentioned, https://tools.ietf.org/html/rfc5280#section-<IP_ADDRESS> forbids verifying cert signatures if the key usage does not support keyCertSign. And this strict requirement is stated regardless of the cert type (be it CA, EE, self-issued, etc.) and of the context of the verification.

Surely the certificate signature was signed by a key that does support signing, and if that's the same as the algorithm of the SPKI, then the signature can be checked...

That's right (and I suppose we do not need to check for matching signatures beforehand because X509_verify() will give negative result on a non-match anyway).

One such interesting examples is https://tools.ietf.org/html/draft-ietf-curdle-pkix-04#section-10.2
As I just wrote a little further up, for self-issued certs a self-signature and consequently a self-signature verification is not always technically possible.
And even if so, the creator of the cert might still want to prohibit the use of the public key for cert signature verification,
and we should and can respect this.

Not if they present a single-element chain with a self-signed EE key and ask for signature verification.

Again, I see no good reason to disregard, even on user's request, to ignore the requirement
 If the keyUsage extension is present, then the subject public key
   MUST NOT be used to verify signatures on certificates or CRLs unless
   the corresponding keyCertSign or cRLSign bit is set.

at least as long we do not make this explicit.

We could explicitly state in our documentation that the (self-)signature verification may in this case be in violation of that rule.
Is this an agreeable solution?

I think we need to go over all the cases, because I'm not sure
that we understand each other.

Normal CA cert, signs an EE cert: The CA cert has a self signature.
We don't check that signature by default, but it can be checked.
The CA cert has the keyCertSign bit, because otherwise it can't
sign the EE cert.
A non-CA self-signed certificate: It has no keyCertSign, but
it falls outside the scope of RFC5280. If requested, we can check
the signature. Whatever RFC5280 says is irrelevant.
A not self-signed certificate that's placed in the trust store,
like your self-issued X25519 example. It needs the partial chain
option if it wasn't to be verified successful. It's not
self-signed, so we can't check the signature.

Is there some case I'm missing?

I'm answering now on each of @kroeckx's most recent comments; here is the first section of this:

Note that not all self-issued certs are self-signed. One such interesting examples is https://tools.ietf.org/html/draft-ietf-curdle-pkix-04#section-10.2

We're talking about checking the self signatures, and that doesn't have a self signature.

Correct. Yet when the code in the body of internal_verify() comes across a self-issued cert last in the chain (where typically a self-signed root CA cert is placed) then it can have a hard time finding out whether the self-issued cert is meant to be self-signed because there is no direct indication in any X.509 (v1 or v3) cert saying "I'm self-signed".

The EXFLAG_SS flag should not be set in that certificate, so there is nothing to check when X509_V_FLAG_CHECK_SS_SIGNATURE is set.

Indeed the EXFLAG_SS indicates that x509v3_cache_extensions() believes that it is a self-signed cert, but as I wrote yesterday, (even in its improved version with the fixes for #1418) it can go wrong due to missing or misleading SKID and/or AKID entries. In particular, the weird cert in https://tools.ietf.org/html/draft-ietf-curdle-pkix-04#section-10.2 only has an SKID, which misleads x509v3_cache_extensions() to set EXFLAG_SS.
So relying on that flag can be slippery, and internal_verify does not rely on it.

I guess we can also be in the case where an intermediate CA is in the trust store, but the root CA is not.

Yes.

We can't check the signature of the last certificate, because it's not self-signed. The X509_V_FLAG_CHECK_SS_SIGNATURE flag also doesn't do anything in that case.

Yes, because such a cert is not even self-issued (which would be required for a self-signed cert).

The manual currently says: B<X509_V_FLAG_CHECK_SS_SIGNATURE> requires verifying the signature of the last certificate in a chain even when it is a self-signed (root CA) certificate.

That sentence is really a bit strange.

This seems to assume that only self-signed certificates are in the trust store, so I guess that should be clarified.

The sentence in the manual was not meant to assume this.
How if I improve it to:
B<X509_V_FLAG_CHECK_SS_SIGNATURE> requests checking the signature of the last certificate in a chain if the certificate is supposedly self-signed ?

PS: That has been published as RFC 8410.

What did you mean here? Which information and in which section of it?

On Sun, Jul 12, 2020 at 06:47:08AM -0700, David von Oheimb wrote:

PS: That has been published as RFC 8410.

What did you mean here? Which information and in which section of it?

You keep pointing to draft-ietf-curdle-pkix-04, which has been
published as RFC 8410.

In particular, the weird cert in https://tools.ietf.org/html/draft-ietf-curdle-pkix-04#section-10.2 only has an SKID, which misleads x509v3_cache_extensions() to set EXFLAG_SS.

I would argue that that's a bug in the RFC 8410 and that you file an
errata.

I think we need to go over all the cases, because I'm not sure that we understand each other.

Maybe this is needed, but only as far as the last cert in a chain is concerned,
because for normal EE certs (at the beginning of a chain with lenght > 1) and for intermediate CA certs nothing is in question here
(and I presume this is the reason why the cases you listed do not include such certs).

Normal CA cert, signs an EE cert:

I guess you meant a root CA cert, which signs a intermediate CA cert or EE cert.

The CA cert has a self signature.

At least this is what typically can be assumed for root CA certs.
Yet maybe it is the cert of an intermediate CA that is directly trusted. In such a case the X509_V_FLAG_PARTIAL_CHAIN flag needs to be set for accepting this situation, and then there is no need to try verifying a self-signature (because the cert is not meant to be self-signed).

We don't check that signature by default, but it can be checked. The CA cert has the keyCertSign bit, because otherwise it can't sign the EE cert.

Right (assuming we are talking about a root CA cert, which could also sign an intermediate CA cert rather than an EE cert).

A non-CA self-signed certificate:

In other words, a self-signed EE cert.

It has no keyCertSign,

Well, it /must/ not have keyCertSign, according to https://tools.ietf.org/html/rfc5280#section-<IP_ADDRESS>:
      If the keyCertSign bit is asserted, then the cA bit in the basic
      constraints extension (Section <IP_ADDRESS>) MUST also be asserted.

So in case the keyCertSign bit is still set for a non-CA cert the cert is non-conforming.

but it falls outside the scope of RFC5280. If requested, we can check the signature. Whatever RFC5280 says is irrelevant.

I still do not buy these statements until I am given a compelling argument for their validity.
RFC 5280 is full of requirements etc. for any sorts of X.509 (v3) certs, and naturally you yourself take various ideas about certs, including self-signed EE certs, from that RFC.
AFAICS it does not constrain its scope to certain (sub-)types of certs. Of course, the chain validation procedure in its section 6 makes certain assumptions on which types of certs can be in which parts of a chain, but section 4 pertains to any certs - it does not say 'we are excluding self-signed non-CA certs' or anything like this.

A not self-signed certificate that's placed in the trust store, like your self-issued X25519 example. It needs the partial chain option if it wasn't to be verified successful.

I guess you mean an /EE/ cert that is not self-signed.

It's not self-signed, so we can't check the signature.

Well, right, but, as explained earlier today (https://github.com/openssl/openssl/pull/12357#issuecomment-657219345) there are various situations where the code cannot be /sure/ if a cert is meant to be self-signed (unless it does the actual verification).

Is there some case I'm missing?

Yes, even restricting ourselves to the last cert in a chain, from a logical (decision tree) perspective at least one case is missing:
A not self-signed EE certificate that's /not/ placed in the trust store.
Here (regardless whether the cert is self-issued or not) I think the verification should fail unless the cert is directly trusted and
X509_V_FLAG_PARTIAL_CHAIN is set.
In case the cert is self-issued we should consider what to do in case the X509_V_FLAG_CHECK_SS_SIGNATURE flag is set.
Also here the check will fail if the algorithms do not match or the key does not support signing.
Also in this case I'd say if the key usage does not support cert signatures we should

not attempt verifying the signature and continue
or throw a key usage error
or explicitly point out that we will do the requested SS verification although RFC 5280 forbids it.

You keep pointing to draft-ietf-curdle-pkix-04, which has been published as RFC 8410.

Ah, right, thanks for that hint!

In particular, the weird cert in https://tools.ietf.org/html/draft-ietf-curdle-pkix-04#section-10.2 only has an SKID, which misleads x509v3_cache_extensions() to set EXFLAG_SS.

I would argue that that's a bug in the RFC 8410 and that you file an errata.

Good suggestion - done at https://www.rfc-editor.org/errata/eid6229

So are we just talking about what should happen when we see such
an invalid certificate? One that is detected as self-signed, but
can't be self-signed because the the key type doesn't support
signing? The X25519 certificat being an example.
For such certicates, I think there are 3 options:

Always reject it, it's clearly an invalid certificate
Reject it when they ask for the self signature to be checked
Always accept it

I think you're arguing for 3), while I think we should do 1)

So are we just talking about what should happen when we see such an invalid certificate? One that is detected as self-signed, but can't be self-signed because the the key type doesn't support signing? The X25519 certificate being an example.

The scope of our discussion is wider, namely how to handle the case that a certificate at the end of a chain appears to be self-signed (and typically is in fact self-signed) and X509_V_FLAG_CHECK_SS_SIGNATURE is requested but its key usage does not allow verifying certificate signatures.
So the problem arises also for valid/well-formed/conforming certificates that are actually self-signed and have a keyUsage extension that does not include keyCertSign. The typical - an perfectly legitimate - use case is a directly trusted self-signed EE cert (i.e., one that is not issued by a CA) for a key that supports signing. For technical reasons it must bear a signature, and thus usually a self-signature is used, while the cA flag and the keyCertSign key usage bit is not set (in order to prevent the cert from being interpreted as a CA cert). If no key usage extension is given the problem does not arise because then implicitly all key usages are allowed. Yet the cert (self-)issuer may want to make sure that the cert key use is restricted (e.g., to digitalSignature).
As I wrote yesterday (https://github.com/openssl/openssl/pull/12357#issuecomment-657232938) in such a situation there are the following possibilities (where I added on case describing the status quo):

not attempt verifying the (self-)signature and continue, ignoring the X509_V_FLAG_CHECK_SS_SIGNATURE request. This was my original proposal in this PR.
throw a key usage error because X509_V_FLAG_CHECK_SS_SIGNATURE is requested but forbidden
attempt verifying the (self-)signature regardless, silently ignoring the key usage restriction without documenting this behavior. This is the status quo.
attempt verifying the (self-)signature regardless, ignoring the key usage restriction but explicitly pointing out in the documentation that we will do the requested SS verification although there is a rule in RFC 5280 not allowing it. This is my new proposal, given on Saturday (https://github.com/openssl/openssl/pull/12357#issuecomment-657124900).

attempt verifying the (self-)signature regardless, silently ignoring the key usage restriction without documenting this behavior. This is the status quo.

Maybe it males (some) sense to add one more flag - X509_IGNORE_SS_KU? Yes, it is over-engineering, I see...

My take is that a trusted chain consisting of exactly one self-issued certificate as its own trust-anchor that has keyUsage without certSign and yet is actually signed by the same key, is so far outside the scope of RFC5280 or any standard PKI model, that perhaps the right thing to do is what the user asked us to do, which is check the certificate signature as requested.
This supports the creation of self-signed certs in which keyUsage explicitly disavows certSign, and yet their self signature can be checked.
Ultimately however, this is rather a corner case, and we're in bikeshedding territory.  If there's some support for David's position, I can back off...

Thanks Viktor for your comment.
As I wrote I meanwhile agree with you that we should continue doing what a user requested by X509_V_FLAG_CHECK_SS_SIGNATURE.
And surely we should continue supporting the use of self-signed EE certs because they are a practically important workaround for scenarios where a CA cannot be used (for whatever reasons).
So why not simply state explicitly in the documentation that in case the key usage stands against the requested SS check, we will do it regardless, following the user's request and at his/her risk?

The GitHub web server meanwhile seems to be working/responsive again :)

@kroeckx, on the side topic of invalid certificates, like that example cert in https://tools.ietf.org/html/rfc8410#section-10.2:

The X25519 certificat being an example.
For such certicates, I think there are 3 options:

Always reject it, it's clearly an invalid certificate
Reject it when they ask for the self signature to be checked
Always accept it I think you're arguing for 3), while I think we should do 1)

Here I am also in favor of 1)
BTW, so far OpenSSL does not thoroughly check certificate conformance.
Two weeks back I've already started preparing a PR that adds various checks for not well-formed certs.

@vdukhovni and @kroeckx,
are you fine if I retract the most recent change regarding key usage checking for self-signature verification
and write the following in the documentation?
B<X509_V_FLAG_CHECK_SS_SIGNATURE> demands checking the signature of
the last certificate in a chain if the certificate is supposedly self-signed
(ignoring any key usage restrictions in the certificate that may prohibit this).

@vdukhovni and @kroeckx,
are you fine if I retract the most recent change regarding key usage checking for self-signature verification
and write the following in the documentation?
B<X509_V_FLAG_CHECK_SS_SIGNATURE> demands checking the signature of
the last certificate in a chain if the certificate is supposedly self-signed
(ignoring any key usage restrictions in the certificate that may prohibit this).

I've just done this tentatively.

@vdukhovni and @kroeckx, during a very good discussion this morning with my colleague @HBrock
I found that there is an update to RFC 5280 that explicitly states what you stated (without giving clear evidence):
https://tools.ietf.org/html/rfc6818#section-2 says

Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note
that use of self-issued certificates and self-signed certificates
issued by entities other than CAs are outside the scope of this
specification.  Thus, for example, a web server or client might
generate a self-signed certificate to identify itself.  These
certificates and how a relying party uses them to authenticate
asserted identities are both outside the scope of RFC 5280.

So you are right in the sense that for self-issued and self-signed certificates
that have not been issued by a CA we are not bound to RFC 5820 and can do whatever makes sense.
The typical use case are directly trusted 'home-grown' self-signed self-issued end-entity certs.
So for our implementation of internal_verify we need to determine somehow if we have such a cert or not.
Unfortunately this distinction cannot really be done just by having a look at the cert in question.
Yet I suppose we can assume that a cert is such a 'home-grown' one if and only if
it appears at the end of the chain and is a non-CA cert with identical subject and issuer entries?

Due to this new insight I've updated the proposed solution as follows.
In the commit message I write:
x509_vfy.c: Improve key usage checks in internal_verify() of cert chains

If a presumably self-signed cert is last in chain we verify its signature
only if X509_V_FLAG_CHECK_SS_SIGNATURE is set. Upon this request we do the
signature verification, but not in case it is a (non-conforming) self-issued
CA certificate with a key usage extension that does not include keyCertSign.

Make clear when we must verify the signature of a certificate
and when we must adhere to key usage restrictions of the 'issuing' cert.
Add some comments for making internal_verify() easier to understand.
Update the documentation of X509_V_FLAG_CHECK_SS_SIGNATURE accordingly.

The respective section in internal_verify() now reads as:
            /*
             * According to https://tools.ietf.org/html/rfc5280#section-6.1.4
             * step (n) we must check any given key usage extension in a CA cert
             * when preparing the verification of a certificate issued by it.
             * According to https://tools.ietf.org/html/rfc5280#section-<IP_ADDRESS>
             * we must not verify a certifiate signature if the key usage of the
             * CA certificate that issued the certificate prohibits signing.
             * In case the 'issuing' certificate is the last in the chain and is
             * not a CA certificate but a "self-issued" end-entity cert (i.e.,
             * xs == xi && !(xi->ex_flags & EXFLAG_CA)) RFC 5280 does not apply
             * (see https://tools.ietf.org/html/rfc6818#section-2) and thus
             * we are free to ignore any key usage restrictions on such certs.
             */
            int ret = xs == xi && (xi->ex_flags & EXFLAG_CA) == 0
                ? X509_V_OK : x509_signing_allowed(xi, xs);

            if (ret != X509_V_OK && !verify_cb_cert(ctx, xi, issuer_depth, ret))
                return 0;

and I've updated the documentation to:
B<X509_V_FLAG_CHECK_SS_SIGNATURE> demands checking the signature of
the last certificate in a chain if the certificate is supposedly self-signed.
This is prohibited and thus results in an error if it is a non-conforming CA
certificate with key usage restrictions that do not include the keyCertSign bit.

Maybe I am confused but what is the non-conforming CA case really about - such an invalid CA certificate would not be able to verify any other certificate signature anyway so failing the self-signature check with X509_V_FLAG_CHECK_SS_SIGNATURE is expected and does not warrant any special handling.

Maybe I am confused but what is the non-conforming CA case really about - such an invalid CA certificate would not be able to verify any other certificate signature anyway so failing the self-signature check with X509_V_FLAG_CHECK_SS_SIGNATURE is expected and does not warrant any special handling.

So far the implementation of internal_verify() did not pay attention to key usage restrictions (while it was done elsewhere, during chain building). This PR rectifies this including some special cases regarding directly trusted EE certs, fixing issue #1418, and we should make sure that we do it exactly where required.
Strongly connected is the topic when exactly we should attempt to verify any supposed cert self-signatures if requested.
The case that a CA cert is non-conforming because it key usage does not allow keyCertSign is of course just a corner case.
During chain validation, there are potentially two intended uses of the public key in such a cert:

Verify the signature of the cert directly preceding it in the chain (in the view that the root is at the end).
Optionally verify its own signature if X509_V_FLAG_CHECK_SS_SIGNATURE is set.
Both cases must fail if the key usage does not allow keyCertSign.

There is also the general question what to do with certs that are not RFC 5280 compliant for various reasons,
but that's a topic to be addressed in a separate PR (which as mentioned I've started preparing).

This PR has developed into two parts:

the core of #10587 backported as fix of #1418 for v1.1.1 on which users have already been waiting for long time
the further changes regarding X509_V_FLAG_CHECK_SS_SIGNATURE that we have been discussing since then

@vdukhovni, is it realistic that you can approve this PR by tomorrow, after which I'll be on vacation for two weeks?
If not, I'd suggest that we decouple part 1 such that the inclusion of the fix in v1.1.1 is not blocked longer.

I've approved the #12375 as I think that change in the end is pretty uncontroversial. For this one I'd leave the approval on Viktor.

I've approved the #12375 as I think that change in the end is pretty uncontroversial. For this one I'd leave the approval on Viktor.

Thanks Tomáš!
Actually I've kept the contents of the (last) commit under discussion here consistent with the PR #12375 you've just approved.
So in my view, after the forth and back done during the discussion here, this PR it could be approved likewise
given that the rest of this PR is just a backport of the fix of #1418 already merged to our master in #10587.

This pull request is ready to merge

Merged - glad that also this (extended) backport of the fix for #1418 is finally in.
Thanks @vdukhovni, @kroeckx, and @HBrock for the interesting discussion
and @t8m for approving this PR in the state reflecting the discussion outcome.


⚠ Fetchers has degraded performance

In 5c755df, Fetchers ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 349 ms

Resolved: Fetchers performance has improved in f99b81d.


docs(spec): remove unknown key-value pair

According to specification no name field exists within Parameter Object.

LGTM but as @magicmatatjahu pointed out, please remove this name field from both, json and yaml example. Also change PR title to docs(spec)

All done.

@magicmatatjahu once you approve and want to merge, make sure to put [skip: ci] in the commit details. You can leave it for me if you are scared 😄

I already triggered 2 releases of 2.1 by accident so we can say I'm an expert in reverting bad decisions 😅

no runs triggered https://github.com/asyncapi/spec/actions/workflows/release.yml
🚀


Problem with binding in 1.4.0

Im not sure if this is bug or something but in older version( AngularJS v1.2.24 ) this way of binding works fine and was printing

Message - AngularIndex

My code is:
'use strict';

/* Controllers */

angular.module('AngularIndex', [])
	.controller('AngularIndexController', function ($scope, $http, userService) {
		if (userService.AngularIndex === undefined) {
		    userService.AngularIndex = {
		        Text: "AngularIndex",
                ObjectText: "AngularIndex"
		    }
		}

		$scope.this = userService.AngularIndex;
});

I also have factory for that userService and its working fine im sure
.factory('userService', function () {
    var _UserService = {};

    return _UserService;
})

And the HTML is that

Message - {{this.Text}}

Like i said in the older version ( AngularJS v1.2.24 ) this code was working fine. Please let me know if im doing something wrong or it's just a bug.
Thanks.

This is a documented breaking change in 1.3.0-rc.4.

Thank u : ))


Misconfigured kubeletctl or the port config is ignored

Summary
Due to a possible misconfiguration on my side of kubeletctl or perhaps another reason, the port being used to comunicate with the kubelet API is not correct. The port being used (39261) is the cluster port specified on my kubeconfig file (see Environment setup section).
Steps to Reproduce
Steps to reproduce the behavior:

Download the precompiled kubeletctl binary with:

$ curl -LO https://github.com/cyberark/kubeletctl/releases/download/v1.6/kubeletctl_linux_amd64 && chmod a+x ./kubeletctl_linux_amd64 && mv ./kubeletctl_linux_amd64 /usr/local/bin/kubeletctl

Try to check worker node kubelet's health:

$ kubeletctl -s <IP_ADDRESS> healthz

:eyes: NOTE:
The target worker node has the IP <IP_ADDRESS>.

Expected Results
Get the proper output from the kubelet. In this case the endpoint tested was healthz. This is the output obtained using curl instead of kubeletctl:
$ curl -k https://<IP_ADDRESS>:10250/healthz
ok

Actual Results (including error logs, if applicable)
Using the default port for  kubelet (port 10250) or setting it manually both result in the wrong address being used.
With the default port:
$ kubeletctl -s <IP_ADDRESS> healthz
[*] Using KUBECONFIG environment variable
[*] You can ignore it by modifying the KUBECONFIG environment variable, file "~/.kube/config" or use the "-i" switch
[*] Failed to run HTTP request with error: Get "https://<IP_ADDRESS>:39261/healthz/": dial tcp <IP_ADDRESS>:39261: connect: connection refused

$ kubeletctl -s <IP_ADDRESS> --port 10250 healthz
[*] Using KUBECONFIG environment variable
[*] You can ignore it by modifying the KUBECONFIG environment variable, file "~/.kube/config" or use the "-i" switch
[*] The reponse failed with status: 404
[*] Message: 404 page not found

Reproducible

[x] Always
[ ] Sometimes
[ ] Non-Reproducible

Version/Tag number
Product version is the following:
$ kubeletctl version
[*] Using KUBECONFIG environment variable
[*] You can ignore it by modifying the KUBECONFIG environment variable, file "~/.kube/config" or use the "-i" switch

 _           _           _                         _
| |         | |         | |         _          _  | |
| |  _ _   _| |__  _____| | _____ _| |_ ____ _| |_| |
| |_/ ) | | |  _ \| ___ | || ___ (_   _) ___|_   _) |
|  _ (| |_| | |_) ) ____| || ____| | |( (___  | |_| |
|_| \_)____/|____/|_____)\_)_____)  \__)____)  \__)\_)

Author: Eviatar Gerzi
Version: 1.6

Environment setup
Running on local development box:
$ uname -a
Linux <box-name> 5.0.0-32-generic #34~18.04.2-Ubuntu SMP Thu Oct 10 10:36:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Kubernetes version and cluster info:
$ kubectl cluster-info
Kubernetes master is running at https://<IP_ADDRESS>:39261
KubeDNS is running at https://<IP_ADDRESS>:39261/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Config file pointed by $KUBECONFIG env var:
$ cat $KUBECONFIG
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: BASE64_CERTIFICATE_AUTHORITY_DATA
    server: https://<IP_ADDRESS>:39261
  name: kind-cluster-name
contexts:
- context:
    cluster: kind-cluster-name
    user: kind-cluster-name
  name: kind-cluster-name
current-context: kind-cluster-name
kind: Config
preferences: {}
users:
- name: kind-cluster-name
  user:
    client-certificate-data: BASE64_ENCODED_CERTIFICATE_DATA
    client-key-data: BASE64_ENCODED_KEY_DATA

Additional Information
The kubernetes flavor used for this scenario is KinD
The extra configuration for the worker nodes is the following:
- role: worker
  kubeadmConfigPatches:
  - |
    kind: JoinConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        anonymous-auth: "true"
        authorization-mode: "AlwaysAllow"

This is mainly to allow unauthenticated requests to the kubelet api.

@ryuzakyl Thank you for the informative response!
I see the problem, I will fix it. I will update you once it will be ready.

@ryuzakyl Can you running:
kubeletctl -s <IP_ADDRESS> -i healthz

There is the -i switch that ignores the config file.

I had also previously tried with the -i switch, but didn't include it on the initial bug report. I suspect the URL being queried  is not the proper one and that's why I'm getting the HTTP 404.
$ kubeletctl -s <IP_ADDRESS> -i healthz
[*] The reponse failed with status: 404
[*] Message: 404 page not found

It would be nice to have some sort of verbose mode (-v or -vv, etc.) to know which URLs are being queried and thus, having a better understanding of kubelet API.

I see what is the problem. I debugged it and if there is not input arguments it creates a url like that: https://<node_ip>:10250/healthz/ instead of https://<node_ip>:10250/healthz/ (without the last /).
Can you please try a differnt command? Like that:
kubeletctl -s <IP_ADDRESS> -i pods

Does this commands works?
Regarding the verbose, this is a great idea, I will add it to the TODO list.

You can try version 1.7:
https://github.com/cyberark/kubeletctl/releases/tag/v1.7

It works!!! :thumbsup: :ok_hand: :clap:
Healthcheck:
$ kubeletctl -s <IP_ADDRESS> -i healthz
ok

Node pods:
$ kubeletctl -s <IP_ADDRESS> -i pods
┌─────────────────────────────────────────────────────────┐
│                    Pods from Kubelet                    │
├───┬─────────────────────────┬─────────────┬─────────────┤
│   │ POD                     │ NAMESPACE   │ CONTAINERS  │
├───┼─────────────────────────┼─────────────┼─────────────┤
│ 1 │ kube-proxy-6jtcx        │ kube-system │ kube-proxy  │
│   │                         │             │             │
├───┼─────────────────────────┼─────────────┼─────────────┤
│ 2 │ kindnet-886fl           │ kube-system │ kindnet-cni │
│   │                         │             │             │
├───┼─────────────────────────┼─────────────┼─────────────┤
│ 3 │ coredns-74ff55c5b-r5llh │ kube-system │ coredns     │
│   │                         │             │             │
└───┴─────────────────────────┴─────────────┴─────────────┘

kubelet config:
$ kubeletctl -s <IP_ADDRESS> -i configz
{
  "kubeletconfig": {
    "enableServer": true,
    "staticPodPath": "/etc/kubernetes/manifests",
    "syncFrequency": "1m0s",
    "fileCheckFrequency": "20s",
    "httpCheckFrequency": "20s",
    "address": "<IP_ADDRESS>",
    "port": 10250,
    "tlsCertFile": "/var/lib/kubelet/pki/kubelet.crt",
    "tlsPrivateKeyFile": "/var/lib/kubelet/pki/kubelet.key",
    "rotateCertificates": true,
    "authentication": {
      "x509": {
        "clientCAFile": "/etc/kubernetes/pki/ca.crt"
      },
      "webhook": {
        "enabled": true,
        "cacheTTL": "2m0s"
      },
      "anonymous": {
        "enabled": true
      }
    },
    "authorization": {
      "mode": "AlwaysAllow",
      "webhook": {
        "cacheAuthorizedTTL": "5m0s",
        "cacheUnauthorizedTTL": "30s"
      }
    },
    "registryPullQPS": 5,
    "registryBurst": 10,
    "eventRecordQPS": 5,
    "eventBurst": 10,
    "enableDebuggingHandlers": true,
    "healthzPort": 10248,
    "healthzBindAddress": "<IP_ADDRESS>",
    "oomScoreAdj": -999,
    "clusterDomain": "cluster.local",
    "clusterDNS": ["<IP_ADDRESS>"],
    "streamingConnectionIdleTimeout": "4h0m0s",
    "nodeStatusUpdateFrequency": "10s",
    "nodeStatusReportFrequency": "5m0s",
    "nodeLeaseDurationSeconds": 40,
    "imageMinimumGCAge": "2m0s",
    "imageGCHighThresholdPercent": 100,
    "imageGCLowThresholdPercent": 80,
    "volumeStatsAggPeriod": "1m0s",
    "cgroupRoot": "/kubelet",
    "cgroupsPerQOS": true,
    "cgroupDriver": "cgroupfs",
    "cpuManagerPolicy": "none",
    "cpuManagerReconcilePeriod": "10s",
    "topologyManagerPolicy": "none",
    "topologyManagerScope": "container",
    "runtimeRequestTimeout": "2m0s",
    "hairpinMode": "promiscuous-bridge",
    "maxPods": 110,
    "podPidsLimit": -1,
    "resolvConf": "/etc/resolv.conf",
    "cpuCFSQuota": true,
    "cpuCFSQuotaPeriod": "100ms",
    "nodeStatusMaxImages": 50,
    "maxOpenFiles": 1000000,
    "contentType": "application/vnd.kubernetes.protobuf",
    "kubeAPIQPS": 5,
    "kubeAPIBurst": 10,
    "serializeImagePulls": true,
    "evictionHard": {
      "imagefs.available": "0%",
      "nodefs.available": "0%",
      "nodefs.inodesFree": "0%"
    },
    "evictionPressureTransitionPeriod": "5m0s",
    "enableControllerAttachDetach": true,
    "makeIPTablesUtilChains": true,
    "iptablesMasqueradeBit": 14,
    "iptablesDropBit": 15,
    "failSwapOn": false,
    "containerLogMaxSize": "10Mi",
    "containerLogMaxFiles": 5,
    "configMapAndSecretChangeDetectionStrategy": "Watch",
    "enforceNodeAllocatable": ["pods"],
    "volumePluginDir": "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/",
    "providerID": "kind://docker/tfm-k8s/tfm-k8s-worker",
    "logging": {
      "format": "text"
    },
    "enableSystemLogHandler": true,
    "shutdownGracePeriod": "0s",
    "shutdownGracePeriodCriticalPods": "0s"
  }
}


support Base.eltype for QuantumObject

This helps to directly obtain the element type in QuantumObject.data, e.g., Int64, Float64, ComplexF64 ...
I think this would be quite useful when developing new functionality in the future.

I'm didn't write a test for this feature since it's just calling the function in Base.
For the code coverage, it will be automatically covered by the tests for new developed features.

Yes this is fine. Thank you.
BTW, I'm at RIKEN right now 😄

Yes this is fine. Thank you.
BTW, I'm at RIKEN right now 😄

Nice~ I'll arrive at Sunday afternoon this week.


[Action] instcart workers in Chicago union drive

https://twitter.com/hashtagmolotov/status/1221659237115285505?s=19

Update: https://www.vice.com/en_ca/article/qjdvgm/instacart-workers-win-historic-union-election


Feature/add parameters

Add ability to set/override syncparameters
Sync parameters are used to sync the parameters on the server. However
there was no way to override those. The functionality added allows the
user to override those commands.
By using the following command in cake you can deploy to another site or
use another connection string.
setting.AddParameter("IIS Web Application Name", "another site");

Merged :+1:


FIX checking for number of arguments

FIX service script when checking the number of arguments as it expects one argument.
I guess this should apply to every tutorial

Actually that one is deliberate - see https://github.com/FIWARE/tutorials.NGSI-v2/issues/4#issuecomment-946424673
Each services script can be run using either docker-compose (the external tool with the hyphen -) or docker compose (the newer version directly bundled with Docker with a space   )
if you start up with the following command:
./services start legacy

This will force the script to use docker-compose which may be more reliable in some cases (or if an older version of Docker is being used)


Toggle component

Simple toggle, animates between states. Can be preset to be on.

or square

p.s. like the idea of squared:)


Remove uses of WindowFn.getOutputTime

This removes all use of WindowFn.getOutputTime so that we can merge and build containers and snapshots, then remove the method right afterwards.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[x] Update CHANGES.md with noteworthy changes.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Confirmed that there are no uses outside WindowFn
beam % grep -r 'getOutputTime(' *
model/pipeline/build/generated/source/proto/main/java/org/apache/beam/model/pipeline/v1/RunnerApi.java:    org.apache.beam.model.pipeline.v1.RunnerApi.OutputTime.Enum getOutputTime();
model/pipeline/build/generated/source/proto/main/java/org/apache/beam/model/pipeline/v1/RunnerApi.java:    @java.lang.Override public org.apache.beam.model.pipeline.v1.RunnerApi.OutputTime.Enum getOutputTime() {
model/pipeline/build/generated/source/proto/main/java/org/apache/beam/model/pipeline/v1/RunnerApi.java:      public org.apache.beam.model.pipeline.v1.RunnerApi.OutputTime.Enum getOutputTime() {
runners/core-construction-java/src/main/java/org/apache/beam/runners/core/construction/WindowingStrategyTranslation.java:    TimestampCombiner timestampCombiner = timestampCombinerFromProto(proto.getOutputTime());
grep: warning: sdks/go/.gogradle/project_gopath/src/github.com/apache/beam/sdks/go: recursive directory loop
sdks/java/core/src/main/java/org/apache/beam/sdk/transforms/windowing/WindowFn.java:   * then {@code getOutputTime(A, window) <= getOutputTime(B, window)}.
sdks/java/core/src/main/java/org/apache/beam/sdk/transforms/windowing/WindowFn.java:  public Instant getOutputTime(Instant inputTimestamp, W window) {
grep: warning: sdks/java/container/.gogradle/project_gopath/src/github.com/apache/beam/sdks/java/boot: recursive directory loop

The matches in the generated proto code are actually the proto name for TimestampCombiner so they are false matches.

R: @kileys


Documentation lists shiftedBy() instead of shift()

Method in documentation is mis-named https://mikemcl.github.io/bignumber.js/#shift

The documentation is correct. shift was renamed to shiftedBy in v6.0.0.
The online documentation is for the current version. I think I need to start including the version number of the library at the top of that page.


Automatically detect when the controller interfaces are running

Some times due to a low frame rate on v-rep, the controller interface will take a longer time to be loaded. This cause an unexpected behaviour, as moveit search for the controller interface but the interfaces are still waiting for v-rep to be loaded. Check it here.
To solve this we need to automatically detect when the controller interfaces are running and then we spawn moveit

Closing as wontfix; the project is finished and the repository is to be archived.


Allow seller to cancel order

Seller should be able to cancel order after payment.
Payment can put order in "processing" state.
Messages between buyer and seller should be removed.

https://github.com/yzernik/squeakroad/pull/382


btstack_config.h: No such file or directory

For some reason after building RPI with the board specified as Pico W, after attempting to compile I am getting this missing header error: btstack_config.h: No such file or directory
Any ideas?
Full trace: https://hastebin.com/share/edeqizesur.bash
Ubuntu 20

Please ask questions here https://forums.raspberrypi.com/viewforum.php?f=145
Also probably include your cmake configuration output


Scripts for automatically setting up provider and consumer fail on certain json inputs for creating a contract

Describe the bug
As the script needs two connectors, there have been set up 2 different instances of a DSC on port 8080 and 8081 respectively.
When running the provided script provider_consumer_single_artifact_single_policy.py there seem to be some issues regarding the input of the create_contract() method. When providing the create_contract() method with additional fields besides the title of the contract this will result in the contract not beeing found when performing a contract request in the later stages of the script.
If i just add the field "title":"Sample title" this works just fine.
To Reproduce
Steps to reproduce the behavior:

Do not change anything in the script besides adding:

"consumer": "TEST-Consumer",
"provider": "TEST-Provider",
"title": "Sample Contract"

to the json part inside the create_contract() method.
2. If you run the script now this should result in following Message:
('b\'{"reason":{"properties":null,"@id":"idsc:NOT_FOUND"},"payload":"Could not '
 'find any matching contract offers for your '
 'request.","type":"de.fraunhofer.iais.eis.RejectionMessageImpl"}\'')

Expected behavior
Initiating the contract agreement and succesfully sending a contract request.

Hi,
I could reproduce this behaviour. The problem here is the line
"consumer": "TEST-Consumer"

When a consumer is specified when creating a contract offer, that offer will only be available for a consumer with the same connector ID. Since "TEST-Consumer" is not a connector ID, the contract offer is not found when making the request. If you set the consumer's connector ID in the field, e.g.
"consumer": "https://w3id.org/idsa/autogen/baseConnector/7b934432-a85e-41c5-9f65-669219dde4ea"

the request should succeed.


Interactive mode with apply command by default

Is there an ability to force Helmfile to use an interactive mode with helmfile aply by default? It would be great if it could be configured at the top of helmfile.yaml.

@iamalryz Hey! Unfortunately no. Also, I dont particularly like writing any operational config/knowledge into helmfile.yaml. That can be considered very similar sentiment as you don't/can't define -auto-approve of terraform apply in a tf file.

@iamalryz I think we'd better merge this discussion into #1767


Fix for undefined index

1. Why is this change necessary?
Indexing products

Notice: Undefined index: category_id in /Users/a.wink/Code/sw56-surteco/engine/Shopware/Bundle/ESIndexingBundle/Product/ProductManualPositionLoader.php on line 52

Notice: Undefined index: position in /Users/a.wink/Code/sw56-surteco/engine/Shopware/Bundle/ESIndexingBundle/Product/ProductManualPositionLoader.php on line 53

2. What does this change do, exactly?
Fix the undefined indexes
Current:
before:
{"7":[{"category_id":"6","position":"1"}]}

after:
{"7":[{"category_id":"6","position":"1"}]}

-- With output (see above)
Fixed:
before:
{"7":[{"category_id":"6","position":"1"}]}

after:
{"7":[{"category_id":6,"position":1}]}

3. Describe each step to reproduce the issue or behaviour.
Execute
php bin/console sw:es:index:populate
or
php bin/console sw:es:index:populate --index product
4. Please link to the relevant issues (if any).
///
5. Which documentation changes (if any) need to be made because of this PR?
///
6. Checklist

[ ] I have written tests and verified that they fail without my change

Tested by my self

[X] I have squashed any insignificant commits
[x] This change has comments for package types, values, functions, and non-obvious lines of code
[X] I have read the contribution requirements and fulfil them.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/SW-24765
Please use this issue to track the state of your pull request.

Thanks for your Contribution! :blue_heart:


.delmsgoncmd not working

**Self-host, Windows 10. Just installed 2.5.5.
When I run the .delmsgoncmd command, it comes up saying it was successful and messages will be deleted. Messages are not being deleted and this is what the bot is saying each time a command is called upon:**
0 17:21:58 AdministrationService | Delmsgoncmd errored...
0 17:21:58 AdministrationService | Discord.Net.HttpException: The server responded with error 403: Forbidden
at Discord.Net.Queue.RequestBucket.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Discord.Net.Queue.RequestQueue.d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Discord.API.DiscordRestApiClient.d__62.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Discord.API.DiscordRestApiClient.d__51.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Discord.API.DiscordRestApiClient.d__81.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Discord.Rest.MessageHelper.d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at NadekoBot.Modules.Administration.Services.AdministrationService.<>c__DisplayClass4_0.<<DelMsgOnCmd_Handler>b__0>d.MoveNext()

your bot doesn't have permission to delete messages. Atleast not yours.


Removed unused code that used HashWithIndifferentAccess

HashWithIndifferentAccess is soft-deprecated in Rails 5.1.  The file that used it is dead code along with one lib file used by that file (and their specs).

@scytacki should this be done on master since it is all dead code anyway?

@dougmartin yeah I think anything we can do on master we should, just to spread any pain (from finding unexpected consequences) out over more weeks instead of all at the end.

Closing to redo this on master


Feature/jothees

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 2 committers have signed the CLA.:x: kavisneka:x: jotheesvdYou have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 2 committers have signed the CLA.:x: kavisneka:x: jotheesvdYou have signed the CLA already but the status is still pending? Let us recheck it.


Fixes issue when clicking main.blocks when main.ts has errors results in data loss without warning

PR fixes issue #21

Hi @microsoftsam, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Sam El-Husseini). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;


Automated Package Upgrade

:tada: This PR is included in version 25.3.250 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Broken link to repository in npm package

Clicking from https://www.npmjs.com/package/hardhat-noir to Repository lands at Page not found.
https://github.com/spalladino/hardhat-noir/blob/688bfd358b5475847ddd54616f9383e3d0bd26d8/package.json#L5

Good catch! Fixed in df5d4c7d8ff64a1a02e685b3cb6815fa65581387.


ccache is not working on cpu builds

Description
I think after this PR #13456  ccache is not being used for CPU builds. I suggest to use CC and CXX environment variables instead of the wrappers.
@marcoabreu
Environment info (Required)
What to do:
1. Download the diagnosis script from https://raw.githubusercontent.com/apache/incubator-mxnet/master/tools/diagnose.py
2. Run the script using `python diagnose.py` and paste its output here.

Build info (Required if built from source)
Compiler (gcc/clang/mingw/visual studio):
MXNet commit hash:
0a2419ffbc7b94448110bf20e52d83557ccf441f
Minimum reproducible example

./dev_menu.py menu 5

This should use CCACHE

Please provide more details around the current behaviour, the expected behaviour, how to observe/measure it and in how far the linked PR changed that.

@mxnet-label-bot [ci]

My data does not show any regressions as result of merging #13456 on 14th of December.

It also prevents executing the build function two times. Why do we need to use these wrappers? Why not just using CC and CXX environment variables?
jenkins_slave@013086bf91e1:/work/mxnet$ /work/runtime_functions.sh build_ubuntu_cpu

NOSE_COVERAGE_ARGUMENTS='--with-coverage --cover-inclusive --cover-xml --cover-branches --cover-package=mxnet'
NOSE_TIMER_ARGUMENTS='--with-timer --timer-ok 1 --timer-warning 15 --timer-filter warning,error'
CI_CUDA_COMPUTE_CAPABILITIES='-gencode=arch=compute_52,code=sm_52 -gencode=arch=compute_70,code=sm_70'
CI_CMAKE_CUDA_ARCH_BIN=52,70
set +x
export CC=gcc
CC=gcc
export CXX=g++
CXX=g++
build_ccache_wrappers
set -ex
'[' -z x ']'
'[' -z x ']'
mkdir /tmp/ccache-redirects
mkdir: cannot create directory '/tmp/ccache-redirects': File exists

It is the recommended way to use ccache - as explained previously: https://ccache.samba.org/manual/latest.html#_run_modes

Please feel free to submit a PR to make a conditional mkdir.

It is required because underlying build-systems don't respect the wrapper methods.

Ok maybe it's calling ccache but it's not obvious because of the wrappers, it's more obvious when the command includes ccache.
Reproduction with:
docker         run         --cap-add         SYS_PTRACE         --rm         --shm-size=500m         -v         /home/piotr/mxnet:/work/mxnet         -v         /home/piotr/mxnet/build:/work/build         -v         /home/piotr/.ccache:/work/ccache         -u         1001:1001         -e         CCACHE_MAXSIZE=500G         -e         CCACHE_TEMPDIR=/tmp/ccache         -e         CCACHE_DIR=/work/ccache         -e         CCACHE_LOGFILE=/tmp/ccache.log         -ti         mxnetci/build.ubuntu_cpu

/work/runtime_functions.sh build_ubuntu_cpu

/work/runtime_functions.sh build_ubuntu_cpu

I expect to be able to execute /work/runtime_functions.sh build_ubuntu_cpu several times.
But seems ccache is in fact working.

@marcoabreu there's two modes to run it according to the documentation:
"There are two ways to use ccache. You can either prefix your compilation commands with ccache or you can let ccache masquerade as the compiler by creating a symbolic link (named as the compiler) to ccache. "

We already had this discussion in https://github.com/apache/incubator-mxnet/pull/13456

@marcoabreu please list the submodules and dependencies which have these hardcoded paths, you didn't respond to the latest question in the PR you linked ( https://github.com/apache/incubator-mxnet/pull/13456 ) I don't see we have a direct dependency on zeromq but only through a shell script. I don't think this is a valid reason to require root in all the build functions and override the compiler globally.


Yarn integration

Switching to using yarn to downland and assemble dependencies. Addresses https://github.com/G-Research/armada/issues/1486

Switching from npm to yarn looks to save about 40-50s.
4:49 to 4:01
5:07 to 4:21s.

LGTM @carlocamurri is going to follow up with team to see if we can merge this.  It will require internal changes to build system so let's hold on merge until we get a Good to go.


Screen rotation

Hey;
Can you please tell me how to support rotating? When I rotate the screen from portrait to landscape, the size of the pager doesn't change and sticking to the left side of the screen.
Portrait:

Landscape

Thanks

@Reapert : I have same issue with you. Did you find any solution for this issue?


router LocationStrategy 'harcoded' within bootsrap.ts

Short description of the problem:
Ideally the LocationStrategy is configurable as this will be 'hacky' to override from application level.
What do you think?
What behavior are you expecting?
That LocationStrategy is configurable pre-bootstrap.
Steps to reproduce:

Cannot reproduce as this is a suggestion and cannot really replicate it

Hello, thanks for opening an issue with us! Routing with the angular 2 router is going to change completely very soon as the angular team has deprecated the old router and are working on a new one. We have halted integrating with this router until it is more complete. Thanks for using ionic.


[support] Add keyboard shortcut (xfce4)

Hello,
Thanks for this great piece of software.
But I fail to map it to a hotkey in xfce4.
How would I go about this ? I'd like to use ddgr.
rofu itself works great and all needed dependencies are installed.

Glad that you find it useful.
Setting global hotkey in xfce environment is out of the scope of this application.
You can follow one of many tutorials on the internet, for example:
https://www.unixmen.com/how-to-add-shortcut-keys-in-xfce/
If you decide to follow the above tutorial, you would then fill in the  path/to/rofi-search on your system to the command input box when creating a new shortcut..
If you wanna use ddgr, make sure that the ddgr package is installed on your system and use the most recent version of rofi-search from master branch..

Closing due to lack of response.

Closing due to lack of response.


[wip] Pets

Start growing some pets. Needs the petset controller from https://github.com/kubernetes/kubernetes/pull/24912.
@smarterclayton

This list a first cut at how I plan to handle these pets. I'm planning to break them out into individual prs, cut images, and run "Feature:PetSet" e2es on at least 3 of them (a generic: for all pets; create, write data, delete all pets, read data;) in time for 1.3. Most likely going to start with zk, mysql and probably c*, maybe throw in redis or mongo.
Please see https://github.com/kubernetes/contrib/pull/921 for the first one

closing in favor of https://github.com/kubernetes/contrib/pull/921


Frontend changes to support backend race changes

ACS & Covid Tracking project are going to split race_and_ethnicity into two columns:
something like:
race_or_ethnicity & reports_ethnicity
In the frontend, we'll use these two columns to create the race_and_ethnicity field (as we currently have it). (API should ultimately be returning same values to the cards)
Additionally, instead of one table for cases, deaths and hospitalizations we will have 3 different tables. Each variable may contain different values for various metadata fields (such as reports_ethnicity)
So the current single dataset feeding into CovidProvider is of the format:
FIPS/race_and_ethnicity/cases/hospitalizations/deaths
And we will now have it turn into 3 datasets of the format:
FIPS/race_or_ethnicity/reports_ethnicity/some_metadata/some_other_metadata/cases
FIPS/race_or_ethnicity/reports_ethnicity/some_metadata/some_other_metadata/deaths
FIPS/race_or_ethnicity/reports_ethnicity/some_metadata/some_other_metadata/hospitalizations
CovidVariable provider will now need to take a MetricQuery in getData() now so we know which datasetId to get since each Metric will now require a different one.
Additionally, we want MetricQueryResponse to have a new attribute returning those metadata fields (reports_ethnicity, some_metadata, some_other_metadata). Metadata fields in MetricQueryResponse can be used as warnings or footnotes on the card. For instance: "Races for NC covid cases does not include hispanic" and "Races for NC deaths does include hispanic"

Given that we aren't using CTP anymore we're pivoting what we're doing here pre-launch.
Frontend will expect backwards compatibility as far as using the existing "race_and_ethnicity" column. ACS data from backend will now also send "race_includes_hispanic" boolean (https://github.com/SatcherInstitute/health-equity-tracker/issues/339#issuecomment-786762651). This boolean should be added to MetricQueryResponse and available for use in CardWrapper. For datasets that don't provide this value from backend, we'll hardcode it's value for now in each provider.
I'll sync with Chi to figure out how we are displaying this information in the Cards.

The BE changes to add separate race and ethnicity columns are done. Over time post-launch, we should move the FE to start using these new columns. Moving to backlog

A note for whoever ends up picking this up later
In order to migrate away from using race_and_ethnicity, I think we'd have to either:

Port the Race enum functionality to the frontend so it can convert race_category_id into human-readable labels, or
If we need to use the same mapping from race_category_id => (race, race_and_ethnicity, race_includes_hispanic) on both the frontend and backend, we could export the race metadata as a table and request that from the frontend.


Add auth for pulling posts

Note: removed code that converts response to JSON in _get so that the wrapper can also be used for urls that return HTML

Hi Miles,
It does currently work for me. How exactly are you calling gabber? I've been doing it from the command line, like:
export GAB_USER=[USER_HERE]
export GAB_PASS=[PASS_HERE]

poetry run gabber --first [START_ID_HERE] --last [END_ID_HERE] --posts --created-after [DATE_HERE]


Make it painfully obvious what to do.

There were a couple of gotchas getting this set up - mainly because I hadn't spotted the difference between "rails_mongo_store" and "rack_mongo_store". A tweak to the readme should help.

Thanks!


UTF8 encoding problem

I have implemented into my project the code from your example at https://github.com/auth0/angular-token-auth/
However, if the payload contains an UTF8 character, in my case 'ć' the payload is badly encoded, and I get an error when doing a JSON.parse of the payload, like I described here https://github.com/auth0/angular-token-auth/issues/9

This was an issue in node-jws, I was using binary as the default encoding with no option to override. I just released v2.0.0 which changes the default to utf8 and gives the option to override the encoding.

Same problem with @MilosStanic , see below code:
var token = jwt.sign({
    username: '測試'
 }, key)

then when:
jwt.verify(token, key)

with error Unexpected token at JSON.parse.

@brianloveswords Awesome! 👍

It will be fixed on v4. Thank you guys!


Make release check more informative

Also doesn't spew a SHA hash JSON snipped to console.

Thanks!


Correction for raw affiliation Univ Lyon, Université Lumière Lyon 2, CNRS, UMR 5600 EVS, F-69635

Correction needed for raw affiliation Univ Lyon, Université Lumière Lyon 2, CNRS, UMR 5600 EVS, F-69635
raw_affiliation_name: Univ Lyon, Université Lumière Lyon 2, CNRS, UMR 5600 EVS, F-69635
new_rors: 02feahw73;029brtt94;03rth4p18;0256r1e04
previous_rors: 02feahw73;029brtt94;03rth4p18
works_examples: W4388723769
contact: c2ad207987d1c1c7ded865141f35229f:ce7a2d0ef00431272994a7070b73 @ ens-lyon.fr

This issue was accepted and ingested by the OpenAlex team on 2024-12-19. The new affiliations should be visible within the next 7 days.


Use Recognizers Cultures in Choice & Confirm Prompt

Description
Currently, Confirm and Choice Prompts use an object with all-lowercase keys for localization:
{
    'es-es': { inlineSeparator: ', ', inlineOr: ' o ', inlineOrMore: ', o ', includeNumbers: true },
    [...]
};

The locale used for the prompt is determined with something like this:
ChoicePrompt.defaultChoiceOptions[locale]

If the locale is not all-lowercase, it defaults to en-us. This can be problematic because:

activity.locale uses ISO 3166, which I believe is normally recognized as all-caps
WebChat sends the capitalized country-code version

So, if an activity comes in with locale: "fr-FR" instead of locale: "fr-fr", they're going to get an en-us prompt. Tested to confirm.
This allows for locales like:

fr-fr
fr-FR
FR
fr

to all get mapped to the appropriate fr-fr
Thanks to @stevkan for the assist!
Specific Changes
I could have just done .toLowerCase() in each prompt, but instead, kept it more in line with the DotNet versions (Note: recognizers-text essentially calls toLowerCase() as well):
C#
{ Spanish, (new Choice("Sí"), new Choice("No"), new ChoiceFactoryOptions(", ", " o ", ", o ", true)) },

by using:
Node
import { Culture } from '@microsoft/recognizers-text';
[...]
[Culture.Spanish]: { choices: ['Sí', 'No'], options: { inlineSeparator: ', ', inlineOr: ' o ', inlineOrMore: ', o ', includeNumbers: true }},

Testing
Current tests DO test for locale and all current tests pass:

@stevengum I big time added those tests. Not sure how a couple of those unrelated changes snuck in there, though. Let me know if I need to remove them somehow.


Adding DHCP lease management

This PR fixes #436 by adding an API to check if the current DHCP lease has expired, which allows external users to deconfigure the IP address from the interface.
This fixes #307 by updating DHCP to utilize the lease duration provided by the DHCP server.
TODO:

[x] Add tests for parsing DHCP lease duration
[x] Test updates on hardware

CC @whitequark / @Dirbaio - This should now be ready for review when either of you get a chance. I've verified that it's functioning as intended on hardware by sniffing the DHCPACK and verifying that with a 10 minute lease time, the client properly re-requests after 5 minutes

Very nice! Is my understanding on what changed correct?
Previous behavior:

Start renew 60 seconds after ACK
retry every 60 seconds, give up after 3 retries

New behavior:

Start renew lease_time/2 after ACK
retry every 60 seconds, give up when lease expires

If that's the case, :+1:  from me.
There's one concern: routers typically set very high lease times, so a smoltcp device could now become offline for hours if a network changes its IP range or some other configuration. I'd like to see some option to set a "ceiling" on the renew/lease time, so users can choose to mitigate this. We can add this later, I'm fine with merging this PR without it.

Very nice! Is my understanding on what changed correct?
Previous behavior:

Start renew 60 seconds after ACK
retry every 60 seconds, give up after 3 retries

New behavior:

Start renew lease_time/2 after ACK
retry every 60 seconds, give up when lease expires

If that's the case, 👍 from me.

This summary is correct. lease_time / 2 is recommended by RFC 2131

There's one concern: routers typically set very high lease times, so a smoltcp device could now become offline for hours if a network changes its IP range or some other configuration. I'd like to see some option to set a "ceiling" on the renew/lease time, so users can choose to mitigate this. We can add this later, I'm fine with merging this PR without it.

As far as my reading of the RFC, even if the router changes the port range, the assigned IP address to the device is still respected for the entire lease duration, so the device isn't "off-line". The DHCP server will be checking to see if addresses are already assigned before handing them out even between configuration changes. As far as I understand it, the RFC essentially states that the provided IP + lease is guaranteed to be valid for the whole duration, regardless of server reboots/configurations (it explicitly states the server should store IP assignments in persistent storage)

@Dirbaio / @whitequark Is there any feedback that needs to be incorporated before this can be merged?

Not honoring the lease time and instead renewing significantly more frequently is somewhat problematic. It can reasonably be seen as non-compliant and causing unnecessary or unwanted traffic. To migrate DHCP configurations, you'd do something similar to DNS migration, decrease the lease time/TTL on the server, then migrate, then increase again.

I know, but our customers have no idea about that, are using crappy consumer-grade routers where these options may not be even configurable, and expect our devices to Just Work. :)

Yeah, but I would argue that should be baked into the application logic (e.g. you have a ping service going every minute) and not in the underlying DHCP implementation


Delta compression using up to 8 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (18/18), 2.30 MiB | 1.27 MiB/s, done.
Total 18 (delta 6), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> R Console app detected
remote: -----> Vendoring R 3.4.0 for cedar-14 stack (latest)
remote:        Downloading and unpacking R binaries (http://heroku-buildpack-r.s3.amazonaws.com/cedar-14/R-3.4.0-binaries-latest.tar.gz)
remote: /tmp/build_a203b3c12beff13be94122152205e5a8/.tools/fakechroot/sbin/chroot.fakechroot: line 93:   182 Segmentation fault      env -u FAKECHROOT_BASE_ORIG FAKECHROOT_CMD_ORIG= LD_LIBRARY_PATH="$fakechroot_chroot_paths" FAKECHROOT_BASE="$fakechroot_chroot_base" "$fakechroot_chroot_chroot" "${@:1:$(($fakechroot_chroot_n - 1))}" "${fakechroot_chroot_newroot#$FAKECHROOT_BASE_ORIG}" "${@:$(($fakechroot_chroot_n + 1))}"
remote:  !     Push rejected, failed to compile R Console app.
remote:
remote:  !     Push failed
remote: Verifying deploy...
remote:
remote: !	Push rejected to aspajobs.
remote:
To https://git.heroku.com/aspajobs.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/aspajobs.git'
Code:

Blank init.R
run.R:
library(shiny)

port <- Sys.getenv('PORT')
shiny::runApp(
appDir = getwd(),
host = '<IP_ADDRESS>',
port = as.numeric(port)
)

Hi @doprdele
There appears to be some issues with 3.4.0. I've reverted back to 3.3.3 in the meantime, while I investigate the underlying problem.

Hi @doprdele
I've managed to sort out your issue with the v3.4.0 build under the cedar-14-chroot branch, and have updated the buildpack.


operators [O] prometheus (0.47.0)

Signed-off-by: Zahar Pecherichny<EMAIL_ADDRESS>thanks to #1045 for mentioning
the operator tries to monitor all namespaces even in single namespace installation.
when the installation will be namespace scoped, the operator should work as previously.
when the operator is installed cluster scoped, he will manage all the serviceMonitors, prometheusRules... in all namespaces, and the prometheus, alertmanager instances only in his namespace.
i didnt checked the cluster scoped option yet, but the namespace scoped work as always worked before.

/merge possible

/merge possible


Can I use maskrcnn-benchmark train my dataset  without mask annotation for object detection?

My dataset have  classes and boudingboxxes annotation . I don't have mask annotation.
I want to know can i train my dataset use this benchmark even i don't have mask annotation ?

Yes, you can use maskrcnn-benchmark in only object detection configuration without mask annotations. Check out the config files that start with e2e_faster_rcnn
For example, as in this config:
https://github.com/facebookresearch/maskrcnn-benchmark/blob/master/configs/e2e_faster_rcnn_fbnet.yaml
And you can compare with MODEL.MASK_ON True configuration here
https://github.com/facebookresearch/maskrcnn-benchmark/blob/master/configs/e2e_mask_rcnn_fbnet.yaml

Yes, you can. As mentioned by Dorozhko-Anton, you can turn off the mask in the config file. Besides, you can use the area of the bbox as the segmentation(although it doesn't take the benefit of having a segmentation), or use another semantic segmentation code (deeplabv3+, for example) to first predict the segmentation and then use that for your training on maskRcnn.

I know, thank you very much

@tianlanli  Did you succeed in using faster_rcnn mode of maskrcnn_benchmark?

@tianlanli Did you succeed in using faster_rcnn mode of maskrcnn_benchmark?

yes

Thanks @Dorozhko-Anton ! I'm closing this issue now.


Support backends without total_count in list views

correctly renders row count label even when total_count is not implemented by the backend
fixes seed script and uses real input files (ported from #175)
fixes lint

Expected behavior

until last page is reached, the total row count should be rendered with a '+' to indicate more rows may be present
upon reaching the last page, '+' should disappear and the next button should be disabled
going back after reaching the last page should keep the '+' hidden as we now know the total count

To reproduce
Run the seed script. It's intended to have JupyterLab served from dev/.
cd dev/
python seed.py
jupyter lab

Then change the body of SchedulerService.getJobs() in handler.ts:
    ...
    // eslint-disable-next-line @typescript-eslint/ban-ts-comment
    // @ts-ignore
    delete data.total_count;
    return data as Scheduler.IListJobsResponse;

Demo
https://user-images.githubusercontent.com/44106031/197866246-a83454e8-5549-4415-8f78-866043cb668c.mov
Issues closed

Closes #182.

Let's not merge this until we get feedback from @ellisonbg.


Release 0.0.3

Codecov Report

Merging #3 (125ab36) into master (5ed50cc) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #3   +/-   ##
=======================================
  Coverage   83.60%   83.60%
=======================================
  Files          11       11
  Lines         500      500
=======================================
  Hits          418      418
  Misses         82       82

Continue to review full report at Codecov.

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


Simplified regex match storing code

Rather than first writing matches to a temporary variable, we write them directly to the class member variable. This eliminates the temporary $matches variable and also the temporary $result variable.
Note that we also eliminated the if statement which is intentional because it is this author's belief that it is incorrect for two reasons:

It should not be conditional whether $matches are saved; if the method is called then $matches should always be updated rather than persist the result from a previous call.
As an aside, and although not addressed by this PR, it is this author's strong belief that storing transient data, such as regex matches, between method calls is an anti-pattern because it is not concurrency-safe. Such runtime information should be returned immediately by the method. However, this refactoring is left for future work and affects the entire class design, not just this method.

I will add the following test to make sure $matches doesn't persist.
    /** @test */
    public function matches_does_not_persit_across_multiple_calls()
    {
        $this->CrawlerDetect->isCrawler('Mozilla/5.0 (iPhone; CPU iPhone OS 7_1 like Mac OS X) AppleWebKit (KHTML, like Gecko) Mobile (compatible; Yahoo Ad monitoring; https://help.yahoo.com/kb/yahoo-ad-monitoring-SLN24857.html)');
        $matches = $this->CrawlerDetect->getMatches();
        $this->assertEquals($this->CrawlerDetect->getMatches(), 'monitoring', $matches);

        $this->CrawlerDetect->isCrawler('This should not match');
        $matches = $this->CrawlerDetect->getMatches();
        $this->assertNull($this->CrawlerDetect->getMatches());
    }


Cannot read properties of undefined (reading 'dragStartDisposable')

TypeError: Cannot read properties of undefined (reading 'dragStartDisposable')
at p.Q in src/vs/base/browser/ui/list/listView.ts:554:9
at p.splice in src/vs/base/browser/ui/list/listView.ts:538:16
at <anonymous> in src/vs/base/browser/ui/list/splice.ts:17:35
at Array.forEach (<anonymous>)
at t.splice in src/vs/base/browser/ui/list/splice.ts:17:20
at <anonymous> in src/vs/base/browser/ui/list/listWidget.ts:1468:57
at fn in src/vs/base/common/event.ts:1206:13
at Y.splice in src/vs/base/browser/ui/list/listWidget.ts:1468:22
at Y.splice in src/vs/base/browser/ui/tree/abstractTree.ts:1445:9
at o.u in src/vs/base/browser/ui/tree/indexTreeModel.ts:441:13
at o.t in src/vs/base/browser/ui/tree/indexTreeModel.ts:405:23
at <anonymous> in src/vs/base/browser/ui/tree/indexTreeModel.ts:399:53
at fn in src/vs/base/common/event.ts:1206:13
at o.setCollapsed in src/vs/base/browser/ui/tree/indexTreeModel.ts:399:29
at R.setCollapsed in src/vs/base/browser/ui/tree/objectTreeModel.ts:239:21
at h.collapseAll in src/vs/base/browser/ui/tree/abstractTree.ts:1821:14
at ti.Qc in src/vs/workbench/contrib/preferences/browser/settingsEditor2.ts:1422:18
at ti.Oc in src/vs/workbench/contrib/preferences/browser/settingsEditor2.ts:1360:14
at <anonymous> in src/vs/workbench/contrib/preferences/browser/settingsEditor2.ts:594:47
at task in src/vs/base/common/async.ts:331:13

Go to Errors Site

Still showing up in telemetry: https://errors.code.visualstudio.com/card?ch=6c3e3dba23e8fadc360aed75ce363ba185c49794&bH=bb506b43-8495-3717-024b-73dc1e4d1dd2


Feat/UI: Remove shadow from NavBar, add polkadot background, and add back-to-top button.

I'm removing shadow from NavBar, and add polkadot background to the page, I think it's the matter of personal preference but It's more visual pleasing, but I'm sure you'll be agree.

Sometimes some pages is too long, makes it hard to quickly return to the top when I want to go back to the previous page, so I'm adding a back-to-top button.

I want to add dark mode, but i have no idea if it is necessary, need your opinion about it.

I want to add dark mode, but i have no idea if it is necessary, need your opinion about it.

Hey, I'm sorry I missed this reply. That's incredibly good. There are some people request for dark mode. Can't wait for this PR!


"Go Back" or "Go Forward" should support navigation only across opened files.

see #154152
During code navigation, VS Code will open too many files. If I don't care about a file, I will close it.
So code navigation should only work across opened files, like Source Insight.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Added tests for HS-JAVA-134 rule

Signed-off-by: Maximillian Arruda<EMAIL_ADDRESS>
- What I did : I followed the issue (#630) description;
- How to verify it: I should execute the tests by make test;
- Description for the changelog: Cover the HS-JAVA-134;

LGTM. I'ill squash these two commits into a single one but on the next PRS considering amend commit changes instead add new ones.


Incorrect installation documentation for Centos/RedHat

Documentation: http://docs.kalabox.io/en/stable/users/install/
The current recommend instructions may only be accurate for Fedora.
sudo dnf update -y
sudo dnf install bridge-utils iptables cgroup-bin
sudo rpm -i kalabox.deb

On CentOS 7 (and I presume equivalent RHEL) the necessary commands are
yum update -y
yum install bridge-utils iptables cgroup-bin
yum install kalabox-v2.0.1.rpm

And even with these commands, one gets the following warning/error:
warning: %post(kalabox-2.0.1-1.x86_64) scriptlet failed, exit status 1
Non-fatal POSTIN scriptlet failure in rpm package kalabox-2.0.1-1.x86_64

To avoid this, one needs to use these commands instead:
yum update -y
yum install bridge-utils iptables cgroup-bin xdg-utils
yum install kalabox-v2.0.1.rpm

It should also be noted, that a web server listening on all 443 TCP ports will cause an error as well on install:
Cannot start container cdd298fd09beed13564a12d74ca044403dd8a76db2d3b90bd2259e438f8fea21: failed to create endpoint kalabox_proxy_1 on network bridge: Error starting userland proxy: listen tcp <IP_ADDRESS>:443: bind: address already in use

I think you got the wrong project man. See: https://github.com/kalabox/kalabox/issues ?

Definitely my mistake. Sorry.


start of unshare in contructor

I realize this is some nasty code... but it's failing for me locally with
/usr/bin/newuidmap 30757 0 1000 1 1<PHONE_NUMBER>6 (null)
newuidmap: uid range [0-1) -> [1000-1001) not allowed
img: failed to use newuidmap: Success

$ cat /etc/subgid
jessie:231072:65536

jessie at debian in ~/.go/src/github.com/jessfraz/img on unshare
$ cat /etc/subuid
jessie:231072:65536

cc @AkihiroSuda just wondering if you see a problem off the bat but I'm sure its me

Thank you a lot for working on this!
I think the problem is that this code executes newuidmap within unshared space.
IIUC we need to fork(2) and the parent process should execute newuidmap for the unshared child.
cc @cyphar

Ah cool I can change it tomorrow
On Fri, Mar 2, 2018 at 22:23 Akihiro Suda<EMAIL_ADDRESS>wrote:

Thank you a lot for working on this!
I think the problem is that this code executes newuidmap within unshared
space.
IIUC we need to fork(2) and the parent process should execute newuidmap
for the unshared child.
cc @cyphar https://github.com/cyphar
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jessfraz/img/pull/56#issuecomment-370112975, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABYNbDiA454ZGBADrpIOyUbmHERXM-jDks5tagy2gaJpZM4SawPI
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

Jess, you could probably just copy the code we have in runc that does the mappings so you don't have to re-write it (you also don't need to use newuidmap because AFAICS you're only mapping one user?).

AFAICS you're only mapping one user

No, typically apt requires an extra user (_apt).
Even yum/dnf/apk/zypper would require extra users for certain packages.

@AkihiroSuda I could've sworn that this PR only mapped a single user (but it looks like it actually maps the entire set of /etc/subuid and /etc/subgid). Oops.
(Also zypper doesn't require a separate user from my testing of rootless containers (or maybe setresuid fails silently, I'm not sure).)

going to update this, over the weekend :)

ok so this works but it's not properly exiting after running i think because the parent is not properly being killed but working on it

Codecov Report

Merging #56 into master will not change coverage.
The diff coverage is n/a.

@@         Coverage Diff          @@
##           master   #56   +/-   ##
====================================
  Coverage       0%    0%
====================================
  Files          11    11
  Lines         546   546
====================================
  Misses        546   546

Codecov Report

Merging #56 into master will not change coverage.
The diff coverage is n/a.

@@         Coverage Diff          @@
##           master   #56   +/-   ##
====================================
  Coverage       0%    0%
====================================
  Files          11    11
  Lines         546   546
====================================
  Misses        546   546

any update? ^^

will update

Codecov Report

Merging #56 into master will increase coverage by 0.17%.
The diff coverage is 2.7%.

@@            Coverage Diff            @@
##           master     #56      +/-   ##
=========================================
+ Coverage       0%   0.17%   +0.17%
=========================================
  Files          11      11
  Lines         554     588      +34
=========================================
+ Hits            0       1       +1
- Misses        554     586      +32
- Partials        0       1       +1

Is this mergeable?

FYI: https://github.com/opencontainers/runc/pull/1693 is recently merged.
The --force-mapping-tool flag is no longer needed.

merging :) also dope :)

Could you update r.j3ss.co/img as well?

Docker image seems broken? I locally built an image but it fails silently.

$ docker run -it --rm --entrypoint sh --privileged img
/$ strace unshare -U
execve("/usr/bin/unshare", ["unshare", "-U"], 0x7fffd77103d8 /* 6 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7f132f97fb88) = 0
set_tid_address(0x7f132f97fbc0)         = 26
mprotect(0x7f132f97c000, 4096, PROT_READ) = 0
mprotect(0x55d096fc0000, 16384, PROT_READ) = 0
getuid()                                = 1000
getgid()                                = 1000
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1 RT_2], [], 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], NULL, 8) = 0
setgid(1000)                            = 0
futex(0x7f132f9800a0, FUTEX_WAKE_PRIVATE,<PHONE_NUMBER>) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1 RT_2], [], 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], NULL, 8) = 0
setuid(1000)                            = 0
futex(0x7f132f9800a0, FUTEX_WAKE_PRIVATE,<PHONE_NUMBER>) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
geteuid()                               = 1000
getegid()                               = 1000
unshare(CLONE_NEWUSER)                  = 0
execve("/bin/sh", ["-sh"], 0x7ffc44709880 /* 6 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7fd6cdba2b88) = 0
set_tid_address(0x7fd6cdba2bc0)         = 26
mprotect(0x7fd6cdb9f000, 4096, PROT_READ) = 0
mprotect(0x563af464a000, 16384, PROT_READ) = 0
getuid()                                = 65534
getgid()                                = 65534
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1 RT_2], [], 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], NULL, 8) = 0
setgid(65534)                           = -1 EINVAL (Invalid argument)
futex(0x7fd6cdba30a0, FUTEX_WAKE_PRIVATE,<PHONE_NUMBER>) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(2, "sh: setgid: Invalid argument\n", 29sh: setgid: Invalid argument
) = 29
exit_group(1)                           = ?
+++ exited with 1 +++

😢

crap I will look into it sorry
On Thu, Apr 26, 2018 at 10:54 PM, Akihiro Suda<EMAIL_ADDRESS>wrote:

$ docker run -it --rm --entrypoint sh --privileged img
/$ strace unshare -U
execve("/usr/bin/unshare", ["unshare", "-U"], 0x7fffd77103d8 /* 6 vars /) = 0
arch_prctl(ARCH_SET_FS, 0x7f132f97fb88) = 0
set_tid_address(0x7f132f97fbc0)         = 26
mprotect(0x7f132f97c000, 4096, PROT_READ) = 0
mprotect(0x55d096fc0000, 16384, PROT_READ) = 0
getuid()                                = 1000
getgid()                                = 1000
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1 RT_2], [], 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], NULL, 8) = 0
setgid(1000)                            = 0
futex(0x7f132f9800a0, FUTEX_WAKE_PRIVATE,<PHONE_NUMBER>) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1 RT_2], [], 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], NULL, 8) = 0
setuid(1000)                            = 0
futex(0x7f132f9800a0, FUTEX_WAKE_PRIVATE,<PHONE_NUMBER>) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
geteuid()                               = 1000
getegid()                               = 1000
unshare(CLONE_NEWUSER)                  = 0
execve("/bin/sh", ["-sh"], 0x7ffc44709880 / 6 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7fd6cdba2b88) = 0
set_tid_address(0x7fd6cdba2bc0)         = 26
mprotect(0x7fd6cdb9f000, 4096, PROT_READ) = 0
mprotect(0x563af464a000, 16384, PROT_READ) = 0
getuid()                                = 65534
getgid()                                = 65534
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1 RT_2], [], 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], NULL, 8) = 0
setgid(65534)                           = -1 EINVAL (Invalid argument)
futex(0x7fd6cdba30a0, FUTEX_WAKE_PRIVATE,<PHONE_NUMBER>) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(2, "sh: setgid: Invalid argument\n", 29sh: setgid: Invalid argument
) = 29
exit_group(1)                           = ?
+++ exited with 1 +++
😢
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/genuinetools/img/pull/56#issuecomment-384848663, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABYNbGVUP1L5hmX0xVBjO3L5TDS9JLxvks5tsohIgaJpZM4SawPI
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

This unshare is cool and it is really important for rootless mode 👍
But I have a question here:
unshare.c is imported here and nsexec() will be called.
However the source nsexec.c from runc has some updates after this issue closed.
Should they be backported? Especially for the PR - [nsenter: clone /proc/self/exe to avoid exposing host binary to container](https://github.com/opencontainers/runc/commit/0a8e4117e7f715d5fbeef398405813ce8e88558b)


Request to be a member of sealer

I have been deeply attracted by the design of sealer since I got to know the project. Gradually, I began to participate in some work and discussions in the community. I found that the people in the community are very warm-hearted. In the process of participating in the community work, I have learned a lot and feel that I still have a lot to learn. Therefore, I hope to become a sealer member of this excellent community, learn more from the community, improve myself and make more contributions to the community!

You're more than welcome to join us! 👏
And, of course, looking forward to your first big feature: building sealer's e2e test framework with container infra!

@allencloud  Could you please help add @zhy76 as a member?

@zhy76 I have sent the invitation to you. After your permission, you will be in sealer org as a member and be a sealer reviewer. /cc @Starnop

Thanks all, I think I can learn more in the community, and I hope I can do more valuable and meaningful things in the community!


Update Accessibility Model to use wil

Description of the new feature/enhancement
We currently manually keep track of our own RefCount for our accessibility providers. This can cause improper RefCounts and updating, as well as improper transferring of ownership.
We should be using the wil library to fix these issues. Starting by making references wil::com_ptrs. This probably won't be too bad for Windows Terminal. We'll have to update some ConHost code too.

And WRL!

Moving this out to 1911. Splitting it into a fix for #3209.


Lifebane and command update

I changed a bunch and thought it would be faster to just upload the whole thing to my fork lol

Added Stuff looks Good but Going to added in myself but going to put "added Changes by Taxolotl"

File Changes have been added
file added here: https://github.com/KingofMidnight/Mystical-Curses-and-Spells/commit/f849dab9c678fa9ce0f7a874c4778f1a44503f24


BUG: Prevent negative lookup in history.

Raise a value error on negative bar counts to prevent lookups ahead of
simulation time.

Coverage increased (+0.05%) to 87.165% when pulling a1ae9a32cc356747751a385736f81ee538894dda on prevent-negative-history-lookup into 5579b04095963990457cc2d75e46c71a86791fee on master.