Charts made with helm create don't follow best practices

A spirited debate happened on our team just now due to inconsistencies between the helm docs and the chart that is created when helm create... is used.
The crux of the inconsistency is as follows:
In the created chart, values like ingress.enabled are used to then conditionally enable the resource in question.
The best practices section for values includes a section recommended against nested values like this.

@mattfarina Agreed, I personally feel that nesting values that are related, regardless of whether or not they're optional, makes the values file far more readable than

@bacongobbler Yeah, that does make sense. I think it's a little subtle for most people. But I could spread this knowledge on my team like "If you see nested values it indicates that a) they are related and b) at least one of them is non-optional"
And I agree with the others, I personally like the nested values in many cases. Maybe the best practice could be worded less strongly, but maybe not. The doc is pretty fair already since it says things like "generally" and "in most cases" to my recollection.
I'm okay with either course. If you'd like to close this issue that is fine. If people think an update is warranted, also fine.


giphy: Only show GIF on hover.

We display the still image of the GIF which is provided by GIPHY,
but on hover we replace the still image with the animated GIF.
This offers lower CPU consumption for an idle browser tab with
zulip narrow open containing a GIF.

This is promising!
Can you make a screencast showing this working and post it in #design?  I want to wait for a bit more thinking about naming before deploying to chat.zulip.org, in case we tweak the interface.

Posted in https://chat.zulip.org/#narrow/stream/6-frontend/topic/disable.20GIFs


Add --output-dir-template flag to the fetch command

Adds an --output-dir-template flag to the fetch command so that users can decide the directory structure inside the output directory:
$ helmfile fetch --help
Fetch charts from state file

Usage:
  helmfile fetch [flags]

Flags:
      --concurrency int              maximum number of concurrent helm processes to run, 0 is unlimited
      --output-dir string            directory to store charts (default: temporary directory which is deleted when the command terminates)
      --output-dir-template string   go text template for generating the output directory (example: "{{ .OutputDir }}/{{ .Release.Name }}")
      --skip-deps                    skip running "helm repo update" and "helm dependency build"

Resolves #453

@elchenberg fix DCO issue.


DATE type handling for Python

DATE is converted as datetime.date for fetchall and numpy.datetime64 with second as units for fetchnumpy and fetchdf.
Do you agree with this choice?

Looks great, could you please add a test case as well?

That was my next task...
On Wed, Mar 11, 2020 at 10:25 PM Hannes Mühleisen<EMAIL_ADDRESS>wrote:

Looks great, could you please add a test case as well?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cwida/duckdb/pull/458#issuecomment-597886011, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB4BD2NM4CXZASBS43VR34TRG76VRANCNFSM4LF5ZAEA
.

Great, thanks for the test, but at this moment this only checks that the result is of the correct type, not that it actually has the correct value. Would you mind adding that as well please?

Sure!
On Thu, Mar 12, 2020 at 9:23 PM Hannes Mühleisen<EMAIL_ADDRESS>wrote:

Great, thanks for the test, but at this moment this only checks that the
result is of the correct type, not that it actually has the correct value.
Would you mind adding that as well please?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cwida/duckdb/pull/458#issuecomment-598401976, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB4BD2ODCXY3UAJ4JN3VRSTRHFAC5ANCNFSM4LF5ZAEA
.

Thank you!


bst1: buildstream is not compatible with python 3.11

See https://github.com/apache/buildstream/pull/1757
This is a problem as, for example,  the Fedora 37 default installation only includes python 3.11
Issue for master (buildstream2): #1802

It seems that ruamel.yaml.clib is the problem here, it doesn't provide a 3.11 wheel and fails to build with 3.11. But since it's an optional dependency, we can probably skip it for python 3.11 for now.
Sadly, it's not optional for bst2 so we'll have to wait for bst2.

I see the following error when running bst build --track-all:
[00:00:00][4043f233][build:freedesktop-sdk.bst:bootstrap/build/base-sdk/filtered.bst] BUG     Build

    An unhandled exception occured:

    Traceback (most recent call last):
      File "/usr/lib/python3.11/site-packages/buildstream/_scheduler/jobs/job.py", line 384, in _child_action
        result = self.child_process()
                 ^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib/python3.11/site-packages/buildstream/_scheduler/jobs/elementjob.py", line 94, in child_process
        return self._action_cb(self._element)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib/python3.11/site-packages/buildstream/_scheduler/queues/buildqueue.py", line 35, in process
        return element._assemble()
               ^^^^^^^^^^^^^^^^^^^
      File "/usr/lib/python3.11/site-packages/buildstream/element.py", line 1534, in _assemble
        collect = self.assemble(sandbox)
                  ^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib/python3.11/site-packages/buildstream/plugins/elements/filter.py", line 108, in assemble
        dep.stage_artifact(sandbox, include=self.include,
      File "/usr/lib/python3.11/site-packages/buildstream/element.py", line 641, in stage_artifact
        files = list(self.__compute_splits(include, exclude, orphans))
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib/python3.11/site-packages/buildstream/element.py", line 2329, in __compute_splits
        self.__init_splits()
      File "/usr/lib/python3.11/site-packages/buildstream/element.py", line 2313, in __init_splits
        self.__splits = {
                        ^
      File "/usr/lib/python3.11/site-packages/buildstream/element.py", line 2314, in <dictcomp>
        domain: re.compile('^(?:' + '|'.join([utils._glob2re(r) for r in rules]) + ')$')
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib64/python3.11/re/__init__.py", line 227, in compile
        return _compile(pattern, flags)
               ^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib64/python3.11/re/__init__.py", line 294, in _compile
        p = _compiler.compile(pattern, flags)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib64/python3.11/re/_compiler.py", line 743, in compile
        p = _parser.parse(p, flags)
            ^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib64/python3.11/re/_parser.py", line 980, in parse
        p = _parse_sub(source, state, flags & SRE_FLAG_VERBOSE, 0)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib64/python3.11/re/_parser.py", line 455, in _parse_sub
        itemsappend(_parse(source, state, verbose, nested + 1,
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib64/python3.11/re/_parser.py", line 863, in _parse
        p = _parse_sub(source, state, sub_verbose, nested + 1)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib64/python3.11/re/_parser.py", line 455, in _parse_sub
        itemsappend(_parse(source, state, verbose, nested + 1,
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib64/python3.11/re/_parser.py", line 841, in _parse
        raise source.error('global flags not at the start '
   re.error: global flags not at the start of the expression at position 23

The problem is a broken regex here:
      File "/usr/lib/python3.11/site-packages/buildstream/element.py", line 2314, in <dictcomp>
        domain: re.compile('^(?:' + '|'.join([utils._glob2re(r) for r in rules]) + ')$')
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

@nanonyme found https://github.com/apache/buildstream/commit/e8055a56d265d558248557782fa3ed0e6419caa4 which went into bst2. Probably need to backport that?

The CI result is bogus. pip installation of bst1 (or rather its dependency) ruamel.yaml.clib fails on Fedora 37. But this is an optional dependency which Fedora does not normally ship. So bst1 should be installable from distro packages.

It's possible https://sourceforge.net/p/ruamel-yaml-clib/code/ci/default/tree/_ruamel_yaml.c simple needs regenerating with newer cython.

It's possible https://sourceforge.net/p/ruamel-yaml-clib/code/ci/default/tree/_ruamel_yaml.c simple needs regenerating with newer cython.

Indeed revisioning cython generated code (if indeed that’s what this is) is not feasible, especially given that cython accesses internal/unstable apis from cpython.

@gtristan history says it was regenerated with cython

The problem is potentially now solved upstream. We should regenerate dependencies again.

Tried that, got these dependencies:
click==8.1.3
grpcio==1.50.0
Jinja2==3.1.2
pluginbase==1.0.1
protobuf==4.21.9
psutil==5.9.3
ruamel.yaml==0.17.21
ruamel.yaml.clib==0.2.7
setuptools==59.6.0
pyroaring==0.3.3
ujson==5.5.0
python-dateutil==2.8.2
## The following requirements were added by pip freeze:
MarkupSafe==2.1.1
six==1.16.0

ruamel.yaml.clib 0.2.7 fixes the cython issue for ruamel.yaml.
pyroaring now fails with the same issue. There is some discussion about python 3.11 support just starting: https://github.com/Ezibenroc/PyRoaringBitMap/issues/78

As said in IRC, I suggest submitting to pyroaring PR where relevant file is regenerated with newer Cython (probably same version as was used to fix ruamel.yaml.clib).

@ssssam also please create a separate issue about bst2 Python 3.11 support. This is about bst1.

Neither is tested on Python 3.11 though yet.

For people like me with bst1 in Fedora 37 and python 3.11 ; i fixed buildstream/element.py with the following:
buildstream/element.py:2370
    def __file_is_whitelisted(self, path):
        # Considered storing the whitelist regex for re-use, but public data
        # can be altered mid-build.
        # Public data is not guaranteed to stay the same for the duration of
        # the build, but I can think of no reason to change it mid-build.
        # If this ever changes, things will go wrong unexpectedly.
        if not self.__whitelist_regex:
            bstdata = self.get_public_data('bst')
            whitelist = _yaml.node_get(bstdata, list, 'overlap-whitelist', default_value=[])
            whitelist_expressions = [
                utils._glob2re(
                    self.__variables.subst(
                        exp.strip(),
                        _yaml.node_get_provenance(bstdata, key='overlap-whitelist', indices=[index])
                    )
                )[5:] # FIX Skip flags "(?ms)" to avoid "global flags not at the start of the expression at position 4"
                for index, exp in enumerate(whitelist)
            ]
            expression = ('^(?:' + '|'.join(whitelist_expressions) + ')$')
            self.__whitelist_regex = re.compile(expression, flags=re.M|re.S) # FIX Add global flags
        return self.__whitelist_regex.match(path) or self.__whitelist_regex.match(os.path.join(os.sep, path))

This allowed me to open my dev_shell successfully.

Do you mean the bug is still not fixed? There are technical issues running CI against Python 3.11.  If you have a fix to code that doesn't result in regressions, pull requests welcome

I dare not imply that. I did not test your PR because i'm a buildstream user only and i don't know how to build buildstream ; That is why i call that a "quick fix". I just wanted my installation (recently upgraded to Fedora 37) to work without waiting for your PR to land in a release available to me...
Although, just by reading the code, i'm not sure it would be sufficient to upgrade yaml ; because buildstream/element.py does something that is deprecated since Python 3.6 : concatenate multiple regex expressions that have global flags like (?ms). My quick fix is a workaround, albeit a dirty one, not sure it is ok to put such a code in a production code base.
Would be better either to ask yaml not to generate the flags, or ensure the newer yaml version does not generate them anymore, or to make sure it ALWAYS generates exactly "(?ms)" at the beginning.

I am currently using bst 1.6.8.
I check if any fedora updates are available and will keep you posted.

That is indeed the latest version.

@mcatanzaro was your original problem fixed?

Reading the element.py on master it seems this exact problem is solved (by not using yaml at all) in bst2.
    # _file_is_whitelisted()
    #
    # Checks if a file is whitelisted in the overlap whitelist
    #
    # This is only internal (one underscore) and not locally private
    # because it needs to be proxied through ElementProxy.
    #
    # Args:
    #    path (str): The path to check
    #
    # Returns:
    #    (bool): True of the specified `path` is whitelisted
    #
    def _file_is_whitelisted(self, path):
        # Considered storing the whitelist regex for re-use, but public data
        # can be altered mid-build.
        # Public data is not guaranteed to stay the same for the duration of
        # the build, but I can think of no reason to change it mid-build.
        # If this ever changes, things will go wrong unexpectedly.
        if not self.__whitelist_regex:
            bstdata = self.get_public_data("bst")
            whitelist = bstdata.get_sequence("overlap-whitelist", default=[])
            whitelist_expressions = [utils._glob2re(self.__variables.subst(node)) for node in whitelist]
            expression = "^(?:" + "|".join(whitelist_expressions) + ")$"
            self.__whitelist_regex = re.compile(expression, re.MULTILINE | re.DOTALL)
        return self.__whitelist_regex.match(os.path.join(os.sep, path))

Git blame shows it was this commit that fixed it in utils._glib2re which was the culprit :
https://github.com/apache/buildstream/commit/782555a674de2ab6f1760f13c4a1b17400f64533#diff-ddfabb836a421fd2981aea75354b2c11dba5343df2543c56124a8393aa651cc5
This is a much better fix than mine.

And also, you did fix utils._glob2re in bst1 here 4755665c3665bbaba8794b35acf69f2d7b9a8ac3
I don't understand why it did not happened to be in my 1.6.8 although it is commited on the bst-1 branch and in the 1.6.8 tag history ??

I read your commit https://github.com/apache/buildstream/commit/4755665c3665bbaba8794b35acf69f2d7b9a8ac3 badly. It actually introduces the BUG !

We're pretty sure (?ms) was put into wrong place before that commit. Would you like to make a PR? You can just pip install the project from git to test your change locally.

@germinolegrand I ended up just doing blind backport. Can you try if this helps for you? https://github.com/apache/buildstream/pull/1800/files (pip install .)

@mcatanzaro was your original problem fixed?

Yes, I don't need to use toolbx anymore.

@nanonyme I tried your PR code, it worked for me !

Okay, so this is clearly a follow-up bug.

Unfortunately, today I'm hitting almost the original bug again, so apparently not. The entire backtrace is identical to the one that I posted above except for the final line, which is now re.error: global flags not at the start of the expression at position 4. The error was previously at position 23 but is now at position 4. Hopefully your #1800 will fix it.

@mcatanzaro can you try pip install . with that branch? CI is currently not available for Fedora 37 so these are kind of blind fixes.

No, sorry, messing with pip and custom buildstream installs requires time and effort. I can test Fedora packaged builds, though.
The history of problems with python could be avoided with better CI. buildstream should test upcoming python versions well before they are released, not after. I think testing with Fedora rawhide might be adequate to achieve this? You'll never get sufficient test coverage by using numbered releases unless your CI builds its own python.

@nanonyme can you rebase your PR https://github.com/apache/buildstream/pull/1800 on top of https://github.com/apache/buildstream/pull/1757 so we know test pass (it will test in F37 and python3.11)

Well, okay does not hang but does not finish either. I have some more work in https://github.com/apache/buildstream/pull/1785 about it

I was trying to make BuildStream instead be launched as external executable and found out that the tests are relying on living in same process with BuildStream so they can extract failures from stack.

BuildStream 2 is broken in different ways IOW pyroaring does not yet support Python 3.11.

Anything more needed here? Surely it's time to release a fix for this issue?

Anything more needed here? Surely it's time to release a fix for this issue?

No this is not trivial.
unfortunately we use grpc, which is a steaming pile of google trash which breaks in mysterious ways multiple times a year, and won’t pass BuildStream tests at the latest grpc version even with Python 3.10, grpc for Python 3.11 needs to be the more recent broken version.
I don’t think overall it’s realistic to try using fresh python versions without letting the ecosystem harden for at least 6 months or so, but we do cook docker images, which should be helpful for those to really want bleeding edge distros on their hosts.

@gtristan I would again note it's not BuildStream+grpcio that break, it's the unit tests which are running BuildStream in same process repeatedly. This is not done by normal users. @mcatanzaro has already been testing BuildStream with latest fixes and could build projects with it.

The CI should probably be rewritten from scratch to run BuildStream commands in new processes.

I don’t think overall it’s realistic to try using fresh python versions without letting the ecosystem harden for at least 6 months or so

It's super annoying for GNOME release team to be unable to use buildstream outside a special container environment. buildstream is supposed to itself be the container environment....

I thought these were just regular Fedora containers with BuildStream and its deps distributed with them with supported versions.

I don’t think overall it’s realistic to try using fresh python versions without letting the ecosystem harden for at least 6 months or so

It's super annoying for GNOME release team to be unable to use buildstream outside a special container environment. buildstream is supposed to itself be the container environment....

I agree, but I don’t think anyone is mandating that release team members use latest fedora either (and I’m not sure that it’s suitable for fedora to wrap such a new python version into a “stable” release either).

@gtristan I would again note it's not BuildStream+grpcio that break, it's the unit tests which are running BuildStream in same process repeatedly. This is not done by normal users. @mcatanzaro has already been testing BuildStream with latest fixes and could build projects with it.

Yes I’ve heard that, still will take a bit of fiddling to try that out, tests have to pass or we don’t know.
asides from that, this is just one of the plethora of ways grpc likes to constantly break its consumers, we’re constantly pinning it due to flagrant instability, as long as that doesn’t change we’re still gonna have this problem with the bleeding edge.

And yes, I agree we cannot claim Python 3.11 support or close this issue without fixing the tests. The question is whether to ship the regexp fixes which allow bst to work at all on Python 3.11 or not. Currently it doesn't work because our CI doesn't fail on deprecation warnings so we've been more than a year worth of deprecations unfixed in this project.

I agree, but I don’t think anyone is mandating that release team members use latest fedora either

I spend half my time on the next stable Fedora, so using the latest Fedora is slow for me. Using a previous stable release is out of the question. We need to develop the next one.

(and I’m not sure that it’s suitable for fedora to wrap such a new python version into a “stable” release either).

Similarly, Fedora often ships the next stable python. This is essential to ensure the quality of python releases; otherwise, if no distros ship until the stable release, how to ensure the stable release actually works with a large body of python software? Same reason we build spring Fedoras with prerelease GCC, to ensure the GCC release is good. python 3.12 is just around the corner now.

Unfortunately we use grpc, which is a steaming pile of google trash which breaks in mysterious ways multiple times a year, and won’t pass BuildStream tests at the latest grpc version even with Python 3.10, grpc for Python 3.11 needs to be the more recent broken version.

Just floating the idea here: what do you think of porting to grpclib instead of grpcio? It claims to be pure python so it should be less prone to breaking with newer versions.

I'm suspicious about performance impact on bst1. With bst2 it might be less due to usage of buildbox-casd as proxy. But maybe it would for maintenance reasons still be worth it.

We also claim to support Python 3.6 for bst1 and grpclib requires Python 3.7 or newer.

Note that BuildStream is now broken with Fedora 37. Fedora 38 is going to be released soon which means that there will soon not be non-EOL Fedora that BuildStream supports. This should be a serious matter for BuildStream upstream if it regards BuildStream 1.6 maintained.

@gtristan can you please tag a 1.6 release? I believe that's all that's needed to end the emergency.

I'm at wits end here. Are there no maintainers willing to make a release?

I'm bamboozled as to what the hold-up is here and am no longer willing to wait. @gtristan if you don't release by the end of this week, I will create a fork of buildstream on gitlab.gnome.org with no source code changes and release there. Would be much easier if you would simply tag a release.

To be fair, that might not be so horrible outcome. BuildStream 1 is not an Apache project.

You may want to only grab bst-1 branch if you end up doing that.

Having an extra project is going to be confusing, so it would be more ideal to release here IMO. But any release is better than leaving the current release broken.

You may want to only grab bst-1 branch if you end up doing that.

That's the plan.

Sure. I'm not a project member, I'm not telling whether or not to do that. I would just prefer keeping things clean if that is done.

I'm bamboozled as to what the hold-up is here and am no longer willing to wait. @gtristan if you don't release by the end of this week, I will create a fork of buildstream on gitlab.gnome.org with no source code changes and release there. Would be much easier if you would simply tag a release.

@mcatanzaro I can sympathise with you and I know this is not ideal (remember I have opened this issue!), but I'm aware tristan has been extremely busy at work this last weeks. Seems the situation is better now so let's have a bit of patience please

@jjardon regardless of workload for @gtristan it is a big problem that the fundamental component for building freedesktop-sdk and gnome runtimes seems to have this low bus factor. It was just presented in FOSDEM that flatpak is more or less winning the desktop application race. Now is not the time to slow down, now is time to ramp up speed and make even better software platforms.

@jjardon regardless of workload for @gtristan it is a big problem that the fundamental component for building freedesktop-sdk and gnome runtimes seems to have this low bus factor. It was just presented in FOSDEM that flatpak is more or less winning the desktop application race. Now is not the time to slow down, now is time to ramp up speed and make even better software platforms.

I do not disagree

Should this now be closed as @gtristan got CI to work with bst1 and there is a release tag with the fixes?

I think so. Thanks @gtristan !

Fixed with https://github.com/apache/buildstream/pull/1827

This is fixed by #1827.


e2e: increase accesslog retry timeout

Please provide a description of this PR:
fixes: https://github.com/istio/istio/issues/48243

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

/retest

@zirain: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-cni_istio
da8922cc0e8bfb6fc357ea478e118e6295bb2e75
link
unknown
/test integ-cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-cni


[DO NOT MERGE] Adding VA support for manged instance

Adding Vulnerability Assessment APIs on managed instance
Those APIs are the same as the Vulnerability Assessment APIs on regular Azure db with the difference of using "/managedInstances/{managed instance name}/" instead of "/servers/{server name}/"
The Vulnerability Assessment APIs on regular Azure db are approved and can be found at:
https://github.com/Azure/azure-rest-api-specs/blob/master/specification/sql/resource-manager/Microsoft.Sql/preview/2017-03-01-preview/databaseVulnerabilityAssessmentBaselines.json
https://github.com/Azure/azure-rest-api-specs/blob/master/specification/sql/resource-manager/Microsoft.Sql/preview/2017-03-01-preview/databaseVulnerabilityAssessments.json
https://github.com/Azure/azure-rest-api-specs/blob/master/specification/sql/resource-manager/Microsoft.Sql/preview/2017-10-01-preview/databaseVulnerabilityAssessmentScans.json
This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] The spec follows the guidelines described in the Swagger checklist document.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-python

Automation for azure-sdk-for-java

Automation for azure-sdk-for-ruby

@jaredmoo for reference

Automation for azure-sdk-for-go

Automation for azure-sdk-for-node

@sarangan12 - can we get someone from ARM to review the API?

@ravbhatnagar Can you please review this from ARM side and provide your signoff?

@sarangan12 - can you help.
This PR is waiting for a long time...

Can one of the admins verify this patch?

@sarangan12  - can you help?

Ping...

@AutorestCI regenerate azure-sdk-for-go

@sarangan12 - can you merge the PR.


WaitForADDomain: Fix Find-DomainController handling of inner exception

Pull Request (PR) description
Fixes an issue within Find-DomainController when used by WaitForADDomain which caused an unhandled exception to be thrown when a domain controller was not yet available.
This was due to a check for a base exception of System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException which instead was being surfaced as an InnerException of System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException.
This Pull Request (PR) fixes the following issues

Fixes #530

Task list

[x] Added an entry to the change log under the Unreleased section of the
file CHANGELOG.md. Entry should say what was changed and how that
affects users (if applicable), and reference the issue being resolved
(if applicable).
[ ] Resource documentation added/updated in README.md.
[ ] Resource parameter descriptions added/updated in README.md, schema.mof
and comment-based help.
[ ] Comment-based help added/updated.
[ ] Localization strings added/updated in all localization files as appropriate.
[ ] Examples appropriately added/updated.
[x] Unit tests added/updated. See DSC Community Testing Guidelines.
[ ] Integration tests added/updated (where possible). See DSC Community Testing Guidelines.
[x] New/changed code adheres to DSC Community Style Guidelines.

This change is

As per #530 I've created this pull request (my first ever pull request on Github, so please let me know if anything is incorrect).
I did have a question around the cleanup of the existing check for System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException:
https://github.com/dsccommunity/ActiveDirectoryDsc/blob/5ea5a1300fcee61c447b6c544aab7c28a9339216/source/Modules/ActiveDirectoryDsc.Common/ActiveDirectoryDsc.Common.psm1#L2057
Should be now removed as part of this change, or if this was added to account for another potential exception which may be thrown?

Congratulations on your first GitHub PR @xpn! I hope it will be the first of many.
The checks are currently failing as you haven't added an entry to the CHANGELOG.md file. If you can do this, I'll then review the change.

Please see https://github.com/dsccommunity/ActiveDirectoryDsc/issues/530#issuecomment-582304291 for an update on this.

@xpn @X-Guardian Would love for this fix to go live so I don't have to manually edit the module on the image I use to get this working.

Hi @jcuzzi, we still don't know the correct exception to check for. Please see the discussion in issue #530. If you can re-create the issue, please add the verbose messages to your module and let us know what exception you are getting.

@X-Guardian, it seems that using the wrapper function is what causes the nested exception.  Take a look at the following snip and results:
function Find-DomainControllerFindOneWrapper
{
    [CmdletBinding()]
    [OutputType([System.DirectoryServices.ActiveDirectory.DomainController])]
    param
    (
        [Parameter(Mandatory = $true)]
        [System.DirectoryServices.ActiveDirectory.DirectoryContext]
        $DirectoryContext
    )

    return [System.DirectoryServices.ActiveDirectory.DomainController]::FindOne($DirectoryContext)
}

Add-Type -AssemblyName 'System.DirectoryServices'

Write-Verbose -Message ($script:localizedData.NewDirectoryContext -f 'Domain') -Verbose

$newObjectArgumentList = @(
    'Domain'
)
$newObjectArgumentList += @(
    'asdf.io'
)

$newObjectParameters = @{
    TypeName     = $typeName
    ArgumentList = $newObjectArgumentList
}

[System.DirectoryServices.ActiveDirectory.DirectoryContext]$adDirectoryContext = New-Object @newObjectParameters

try
{
    Write-Host "Using Wrapper:"
    $domainControllerObject = Find-DomainControllerFindOneWrapper -DirectoryContext $adDirectoryContext
}
catch [System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException]
{
    Write-Host 'Specific catch: ActiveDirectoryObjectNotFoundException'
    Write-Host 'Exception Name: ' + $_.Exception.GetType().FullName
}
catch [System.Management.Automation.MethodInvocationException]
{
    Write-Host 'Specific catch: MethodInvocationException'
    Write-Host 'Exception Name: ' + $_.Exception.GetType().FullName
    Write-Host 'Inner Exception Name: ' + $_.Exception.InnerException.GetType().FullName
}
catch
{
    Write-Host 'Generic catch'
    Write-Host 'Exception Name: ' + $_.Exception.GetType().FullName
    Write-Host 'Inner Exception Name: ' + $_.Exception.InnerException.GetType().FullName
}

try
{
    Write-Host "Not using Wrapper:"
    $domainControllerObject = [System.DirectoryServices.ActiveDirectory.DomainController]::FindOne($adDirectoryContext)
}
catch [System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException]
{
    Write-Host 'Specific catch: ActiveDirectoryObjectNotFoundException'
    Write-Host 'Exception Name: ' + $_.Exception.GetType().FullName
}
catch [System.Management.Automation.MethodInvocationException]
{
    Write-Host 'Specific catch: MethodInvocationException'
    Write-Host 'Exception Name: ' + $_.Exception.GetType().FullName
    Write-Host 'Inner Exception Name: ' + $_.Exception.InnerException.GetType().FullName
}
catch
{
    Write-Host 'Generic catch'
    Write-Host 'Exception Name: ' + $_.Exception.GetType().FullName
    Write-Host 'Inner Exception Name: ' + $_.Exception.InnerException.GetType().FullName
}

Using Wrapper:
Specific catch: MethodInvocationException
Exception Name:  + System.Management.Automation.MethodInvocationException
Inner Exception Name:  + System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException
Not using Wrapper:
Specific catch: ActiveDirectoryObjectNotFoundException
Exception Name:  + System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException
I don't see the purpose of the wrapper function since its only running a single return line and only used in one place.

Hi @jcuzzi, the point of the wrapper function is so that it can be mocked within the unit tests.
We proved that a try/catch block will match on either the exception or the inner exception, so I don't think that is the issue. I still think we are hitting a different exception, we just need to know what one.

Hi @X-Guardian.  This commit did resolve the issue for me: 20250c59f21226f21f60debe9a034e52dcaa8a91
I don't see any additional exceptions being thrown.

Were you consistently getting the 'Domain Controller not Found' error though?

Yes.  I use this module in combination with terraform to configure lab environments from scratch. Every client using the WaitForADDomain resource would run into this error because the domain does not exist until the PDC is configured.
I ended up manually editing the the module on my base image to include 20250c59f21226f21f60debe9a034e52dcaa8a91 which fixed the issue for me.

OK, if you want to see it fixed permanently, please add the verbose messaging to an unmodified module as discussed in https://github.com/dsccommunity/ActiveDirectoryDsc/issues/530#issuecomment-582304291 and recreate the issue, then post the verbose logs to the issue.

@X-Guardian was this resolved by merged PR https://github.com/dsccommunity/ActiveDirectoryDsc/pull/577?

Hi @johlju,
No, still need to re-work the Find-DomainController function exception handling.

We still have the ActiveDirectoryObjectNotFoundException duplicated in this PR, but I'm not confident enough to remove the original catch, in case there is still a scenario which hits it. I'm therefore going to get this merged so it can be included in the 6.0 release.


hysteria: 2.3.0 -> 2.4.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/hysteria/versions.
meta.description for hysteria is: A feature-packed proxy & relay utility optimized for lossy, unstable connections
meta.homepage for hysteria is: https://github.com/apernet/hysteria
Updates performed

Golang update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.4.0 with grep in /nix/store/8nbds647igialpy99lnd2dx9qjvnj2aq-hysteria-2.4.0
found 2.4.0 in filename of file in /nix/store/8nbds647igialpy99lnd2dx9qjvnj2aq-hysteria-2.4.0

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
hysteria

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/df7556345844ffbaa225ef78618857a0e4a2be4d#hysteria

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

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

1 package built:

hysteria

Maintainer pings
cc @oluceps for testing.

sadly review comments still don't work, only regular comments


chore(deps): update

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


No output received after porting this example to tmpm46b cortex m4 mcu

Hi all,
I have compiled this source code for tmpm46b mcu. Compilation is successful but not getting any output on the terminal.
Is there any dependency i have to follow for choosing cmsis, mbedos, etc.

It worked. There was some mismatch between mbed version.


Please add Cyrillic support

I'm submitting a feature request
Brief Description

OSMCha now uses the Open Sans font without Cyrillic characters. Typically, users from Ukraine, Belarus, and Russia write a comment to a changeset in their native language. The following comments have a bad look in the OSMCha interface:

It would be great if full Cyrillic support was enabled. The full version of Open Sans font supports these characters.
What is the motivation / use case for this feature?

Mappers from Ukraine, Belarus and Russia will be pleased to use this site

Thank you very much for your report, @mellangr !
@rasagy, could you take a look on this? I suppose it can be an issue of https://github.com/mapbox/assembly

Thank you, @willemarcel

@mellangr sorry for my lack of knowledge about Cyrillic.... would you mind giving me more details about what is wrong? I compared the comment text in osmcha with the OSM website and api and it looks the same. I also verified the text in opensans with the Google Fonts website and didn't notice any difference. It would be useful to have an image of the correct way that text should be rendered.
Thanks!

@willemarcel sorry, my English is very bad, but I will try to explain. Now in one line the text is written in two fonts:

But the Open Sans font supports Cyrillic, and ideally it should be:

Here's another screenshot:

Thank you very much @mellangr! I confirmed the issue and pushed a fix to assembly

@mellangr this issue has been solved and deployed!

Thank you very much @willemarcel !


Create system test for exportable

Since we've had data-integrity problems in the past (including but not limited to #1286) I and the rest of the data team would feel a lot more comfortable if we included an end-to-end test of data and exportable in the test suite.
Self-assigning this issue before I knock it out over the coming week.

Can you do me a solid and spec out what exact behavior we need to test and lock in @mdworken ?

Yes, will do!
I'm super swamped with data team stuff, but I should be able to flesh this out a little more within the next week or two.

@mdworken is this still a pressing concern? Can we either close or spec this out? I'm not familiar with the particular pain point you all have been experiencing, and there's not a next step here currently.

I think we're likely to broadcast any particular major breaking changes to this, and core functionality is covered by the controller tests, so I'm going to close this out as a wontfix for now. If we have specific concerns around locking in behavior we can revisit, but this hanging out in the backlog for a full year is I think a signal that it's not particularly scary; also as we've seen the exportable code doesn't move that much.


fio: 3.11 -> 3.12

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/fio/versions.
meta.description for fio is: '"Flexible IO Tester - an IO benchmark tool"'.
Compare changes on GitHub

Checks done (click to expand)

built on NixOS
/nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fio passed the binary check.
Warning: no invocation of /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fio-genzipf had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fio-btrace2fio had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fio-dedupe had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fio-verify-state had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fio_generate_plots had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fio2gnuplot had a zero exit code or showed the expected version
/nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/genfio passed the binary check.
/nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fiologparser.py passed the binary check.
Warning: no invocation of /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fiologparser_hist.py had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fio_jsonplus_clat2csv had a zero exit code or showed the expected version
3 of 11 passed binary check by having a zero exit code.
1 of 11 passed binary check by having the new version present in output.
found 3.12 with grep in /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12
directory tree listing: https://gist.github.com/e4b804ae1295e640d31470292b7f055e
du listing: https://gist.github.com/0ebc4cf406da371e649adb565f75fc0c

Outpath report (click to expand)

Outpath difference report
7 total rebuild paths
2 package rebuilds
2 x86_64-linux rebuilds
2 i686-linux rebuilds
1 x86_64-darwin rebuilds
2 aarch64-linux rebuilds
First ten rebuilds by attrpath
fio
xfstests

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A fio https://github.com/r-ryantm/nixpkgs/archive/4f3f9c1e2567620e531a1b5b6f902002f15b836c.tar.gz

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

Success on aarch64-linux (full log)
Attempted: fio
Partial log (click to expand)
stripping (with command strip and flags -S) in /nix/store/l2z6kv4r0hlkxb8cnh90mi9p3k1clr17-fio-3.12/bin
patching script interpreter paths in /nix/store/l2z6kv4r0hlkxb8cnh90mi9p3k1clr17-fio-3.12
/nix/store/l2z6kv4r0hlkxb8cnh90mi9p3k1clr17-fio-3.12/bin/fio_jsonplus_clat2csv: interpreter directive changed from "/usr/bin/python2.7" to "/nix/store/74b1xd5srd6ja54xwznvbrd5hcfl6k1n-python-2.7.15/bin/python2.7"
/nix/store/l2z6kv4r0hlkxb8cnh90mi9p3k1clr17-fio-3.12/bin/fiologparser_hist.py: interpreter directive changed from "/usr/bin/python2.7" to "/nix/store/74b1xd5srd6ja54xwznvbrd5hcfl6k1n-python-2.7.15/bin/python2.7"
/nix/store/l2z6kv4r0hlkxb8cnh90mi9p3k1clr17-fio-3.12/bin/fiologparser.py: interpreter directive changed from "/usr/bin/python2.7" to "/nix/store/74b1xd5srd6ja54xwznvbrd5hcfl6k1n-python-2.7.15/bin/python2.7"
/nix/store/l2z6kv4r0hlkxb8cnh90mi9p3k1clr17-fio-3.12/bin/genfio: interpreter directive changed from "/usr/bin/bash" to "/nix/store/dsyc1z7ck08ga7l0b1jcxx35wj69qcii-bash-4.4-p23/bin/bash"
/nix/store/l2z6kv4r0hlkxb8cnh90mi9p3k1clr17-fio-3.12/bin/fio2gnuplot: interpreter directive changed from "/usr/bin/python2.7" to "/nix/store/74b1xd5srd6ja54xwznvbrd5hcfl6k1n-python-2.7.15/bin/python2.7"
/nix/store/l2z6kv4r0hlkxb8cnh90mi9p3k1clr17-fio-3.12/bin/fio_generate_plots: interpreter directive changed from "/bin/sh" to "/nix/store/dsyc1z7ck08ga7l0b1jcxx35wj69qcii-bash-4.4-p23/bin/sh"
checking for references to /build in /nix/store/l2z6kv4r0hlkxb8cnh90mi9p3k1clr17-fio-3.12...
/nix/store/l2z6kv4r0hlkxb8cnh90mi9p3k1clr17-fio-3.12

Success on x86_64-linux (full log)
Attempted: fio
Partial log (click to expand)
stripping (with command strip and flags -S) in /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin
patching script interpreter paths in /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12
/nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fiologparser.py: interpreter directive changed from "/usr/bin/python2.7" to "/nix/store/2brlr94ahy3a9mvcjy0qbqpv8zrb7b7s-python-2.7.15/bin/python2.7"
/nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fio_generate_plots: interpreter directive changed from "/bin/sh" to "/nix/store/r47p5pzx52m3n34vdgqpk5rvqgm0m24m-bash-4.4-p23/bin/sh"
/nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fiologparser_hist.py: interpreter directive changed from "/usr/bin/python2.7" to "/nix/store/2brlr94ahy3a9mvcjy0qbqpv8zrb7b7s-python-2.7.15/bin/python2.7"
/nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fio2gnuplot: interpreter directive changed from "/usr/bin/python2.7" to "/nix/store/2brlr94ahy3a9mvcjy0qbqpv8zrb7b7s-python-2.7.15/bin/python2.7"
/nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/genfio: interpreter directive changed from "/usr/bin/bash" to "/nix/store/r47p5pzx52m3n34vdgqpk5rvqgm0m24m-bash-4.4-p23/bin/bash"
/nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12/bin/fio_jsonplus_clat2csv: interpreter directive changed from "/usr/bin/python2.7" to "/nix/store/2brlr94ahy3a9mvcjy0qbqpv8zrb7b7s-python-2.7.15/bin/python2.7"
checking for references to /build in /nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12...
/nix/store/r07h1986lnjx7a3ib0i2zija1kk8mgv3-fio-3.12

Success on x86_64-darwin (full log)
Attempted: fio
Partial log (click to expand)
strip is /nix/store/g5r4apl0za012ffs6ladinwa5w0m1l3k-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/30p8c7gjhvvw80xv6ygnfrsxgpb67xzl-fio-3.12/bin
patching script interpreter paths in /nix/store/30p8c7gjhvvw80xv6ygnfrsxgpb67xzl-fio-3.12
/nix/store/30p8c7gjhvvw80xv6ygnfrsxgpb67xzl-fio-3.12/bin/fio2gnuplot: interpreter directive changed from "/usr/bin/python2.7" to "/nix/store/c6mnc84yva1wa85nzjfha6mxfsk6qbg7-python-2.7.15/bin/python2.7"
/nix/store/30p8c7gjhvvw80xv6ygnfrsxgpb67xzl-fio-3.12/bin/fio_generate_plots: interpreter directive changed from "/bin/sh" to "/nix/store/n9hba031gjky8hpjgx9fnlaxhidyzxbz-bash-4.4-p23/bin/sh"
/nix/store/30p8c7gjhvvw80xv6ygnfrsxgpb67xzl-fio-3.12/bin/fio_jsonplus_clat2csv: interpreter directive changed from "/usr/bin/python2.7" to "/nix/store/c6mnc84yva1wa85nzjfha6mxfsk6qbg7-python-2.7.15/bin/python2.7"
/nix/store/30p8c7gjhvvw80xv6ygnfrsxgpb67xzl-fio-3.12/bin/fiologparser.py: interpreter directive changed from "/usr/bin/python2.7" to "/nix/store/c6mnc84yva1wa85nzjfha6mxfsk6qbg7-python-2.7.15/bin/python2.7"
/nix/store/30p8c7gjhvvw80xv6ygnfrsxgpb67xzl-fio-3.12/bin/fiologparser_hist.py: interpreter directive changed from "/usr/bin/python2.7" to "/nix/store/c6mnc84yva1wa85nzjfha6mxfsk6qbg7-python-2.7.15/bin/python2.7"
/nix/store/30p8c7gjhvvw80xv6ygnfrsxgpb67xzl-fio-3.12/bin/genfio: interpreter directive changed from "/usr/bin/bash" to "/nix/store/n9hba031gjky8hpjgx9fnlaxhidyzxbz-bash-4.4-p23/bin/bash"
/nix/store/30p8c7gjhvvw80xv6ygnfrsxgpb67xzl-fio-3.12

@GrahamcOfBorg build xfstests

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: xfstests
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: xfstests
Partial log (click to expand)
shrinking /nix/store/43pa57c93qf7nbn7cfikab086adhl08v-xfstests-2018-04-11/lib/xfstests/ltp/doio
shrinking /nix/store/43pa57c93qf7nbn7cfikab086adhl08v-xfstests-2018-04-11/lib/xfstests/ltp/aio-stress
shrinking /nix/store/43pa57c93qf7nbn7cfikab086adhl08v-xfstests-2018-04-11/lib/xfstests/ltp/fsstress
shrinking /nix/store/43pa57c93qf7nbn7cfikab086adhl08v-xfstests-2018-04-11/lib/xfstests/ltp/fsx
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/43pa57c93qf7nbn7cfikab086adhl08v-xfstests-2018-04-11/lib  /nix/store/43pa57c93qf7nbn7cfikab086adhl08v-xfstests-2018-04-11/bin
patching script interpreter paths in /nix/store/43pa57c93qf7nbn7cfikab086adhl08v-xfstests-2018-04-11
/nix/store/43pa57c93qf7nbn7cfikab086adhl08v-xfstests-2018-04-11/bin/xfstests-check: interpreter directive changed from "/bin/sh" to "/nix/store/r47p5pzx52m3n34vdgqpk5rvqgm0m24m-bash-4.4-p23/bin/sh"
checking for references to /build in /nix/store/43pa57c93qf7nbn7cfikab086adhl08v-xfstests-2018-04-11...
/nix/store/43pa57c93qf7nbn7cfikab086adhl08v-xfstests-2018-04-11

Success on aarch64-linux (full log)
Attempted: xfstests
Partial log (click to expand)
shrinking /nix/store/bxyha1kf7qwglvss7kj698s8bm3b8g96-xfstests-2018-04-11/lib/xfstests/ltp/growfiles
shrinking /nix/store/bxyha1kf7qwglvss7kj698s8bm3b8g96-xfstests-2018-04-11/lib/xfstests/ltp/fsx
shrinking /nix/store/bxyha1kf7qwglvss7kj698s8bm3b8g96-xfstests-2018-04-11/lib/xfstests/ltp/fsstress
shrinking /nix/store/bxyha1kf7qwglvss7kj698s8bm3b8g96-xfstests-2018-04-11/lib/xfstests/ltp/doio
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/bxyha1kf7qwglvss7kj698s8bm3b8g96-xfstests-2018-04-11/lib  /nix/store/bxyha1kf7qwglvss7kj698s8bm3b8g96-xfstests-2018-04-11/bin
patching script interpreter paths in /nix/store/bxyha1kf7qwglvss7kj698s8bm3b8g96-xfstests-2018-04-11
/nix/store/bxyha1kf7qwglvss7kj698s8bm3b8g96-xfstests-2018-04-11/bin/xfstests-check: interpreter directive changed from "/bin/sh" to "/nix/store/dsyc1z7ck08ga7l0b1jcxx35wj69qcii-bash-4.4-p23/bin/sh"
checking for references to /build in /nix/store/bxyha1kf7qwglvss7kj698s8bm3b8g96-xfstests-2018-04-11...
/nix/store/bxyha1kf7qwglvss7kj698s8bm3b8g96-xfstests-2018-04-11


docs: remove github-actions-cpu-cores recommendation

Summary
As of Jest 29.4.0, you no longer need to use the github-actions-cpu-cores action to properly set --max-workers. All that action does is use os.availableParallelism(), which jest now does natively after #13738.
Test plan
Docs only

While that API has been backported to node 18, it has not been backported to v14 or v16, both of which Jest still supports.
I'm happy to tweak the docs to point that out, but I don't think we should remove it yet.

Ah, good to know. I've updated this PR - feedback on phrasing is welcome.

@SimenB , given what you said, is the action inaccurately configured? https://github.com/SimenB/github-actions-cpu-cores/blob/a0a2b80333e58828f914f98cfffe6d91350afa9d/action.yml#L6-L8
It appears to be running on Node 16, which doesn't have the availableParallelism method.

It's forward compatible 😀
Runners are only available using Node 12 (deprecated) and 16: https://github.blog/changelog/2022-05-20-actions-can-now-run-in-a-node-js-16-runtime/

Gotcha. I guess I'm a little bit confused when this action would be useful, then. From what I can gather, as configured, it's using os.cpus().length, which is built into Jest and has been available since Node 14.
Testing this on a sample GitHub action, it looks like os.cpus().length is properly returning 2 CPUs on the default runner.
If os.cpus.length() was returning an invalid response and the github-actions-cpu-cores could opt into Node 18+ (for os.availableParallelism()), I could see why you'd want to use it.
Could you help me understand a concrete scenario where this action would be better than the default Jest behavior?

https://github.com/jestjs/jest/pull/10653#issue-725291647

Jest's default implementation is to leave one core alone, though, which is why I specify it:

Ah, OK, thanks for the explanation. I understand now why the action is helpful. I agree that using all cores on CI by default (with a major version bump) would be a nice improvement. I'll just close this for now. Thanks!


Connecting to external SMTP

I can connect to SMTP server if I set one up on the same server that the KingPhisherServer daemon is running on. However, I cannot connect to any other SMTP no matter what options I choose. Tested on multiple external SMTP servers.
Is this a known issue?

Are you using the proper settings for TLS / disabling SSH tunneling etc.? Check the debug logs and share the error here along with your settings.
Settings for common Public SMTP Servers are available on the wiki.

king-phisher # ./KingPhisher --no-plugins --no-style
Loading .env environment variables…
WARNING  it is not necessary to run the king phisher client as root
Traceback (most recent call last):
File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
self.run()
File "/opt/king-phisher/king_phisher/utilities.py", line 502, in run
super(Thread, self).run()
File "/usr/lib/python3.5/threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
File "/opt/king-phisher/king_phisher/client/tabs/mail.py", line 941, in _set_entry_completion_list_tsafe
url_information = self.application.rpc.graphql_find_file('get_site_templates.graphql')
File "/opt/king-phisher/king_phisher/client/client_rpc.py", line 241, in graphql_find_file
return self.graphql_file(path, query_vars=query_vars)
File "/opt/king-phisher/king_phisher/client/client_rpc.py", line 224, in graphql_file
return self.graphql(query, query_vars=query_vars)
File "/opt/king-phisher/king_phisher/client/client_rpc.py", line 205, in graphql
query_vars=query_vars
king_phisher.errors.KingPhisherGraphQLQueryError
(main.py:27173): Gtk-WARNING **: /build/gtk+3.0-2Ut_nl/gtk+3.0-3.18.9/./gtk/gtkliststore.c:836: Unable to convert from (null) to gchararray
WARNING  received a socket.error while connecting to the SMTP server
WARNING  received a socket.error while connecting to the SMTP server

It can't connect. What are the settings your using?

Just your basic SMTP settings. Whenever I create it myself and host it on the KingPhisherServer it works. I can connect and it mails fine. When I use any external one, it doesn't allow me to connect. I configured the SMTP servers the same way.

I can get it to work ONLY when the SMTP is on the server. I just tried another configuration.
Client & Server on the same machine. I attempted to send from the SMTP that I was able to send from before and received the same error.
Does this confirm my suspicions that the SMTP server has to be setup on the KingPhisherServer?

If you're using an SMTP server that is not on the King Phisher server then you probably want to disable SSH tunneling. I can't help you though if you won't share the actual settings (minus the IP is you're worried about that) and the verbose logging output.

I don't mind sharing anything what do you want me to do in order to diagnose this? Tell me exactly what to do in order to get you the information you need.

Post all of the SMTP settings from the configuration dialog and post all the debug output using the steps from the wiki I linked to two days ago.


Add message service

This WIP PR opens up the versations bot to also post messages to the channel.
Since syncs must happen before messages can be posted, the bot will sync and add any additional logs each time a message is sent as well.

[X] cleanup
[X] refactor to separate sync logic so it can be reused
[x] add CLI
[x] fixup requirements
[x] setup.py -> setup.cfg + package versations instead of just main

Thank you @asmacdo !
Since we do not have tests but also only have 1 deployment, I will just try "as deployed" and file issues if anything comes up.


Fix TS types. Add type linting

There were a couple of problems with TS types that this PR aims to address. We were having following errors when building a project that has express-ajv-swagger-validation library as a dependency:
node_modules/express-ajv-swagger-validation/src/middleware.d.ts:1:22 - error TS6054: File '/Users/savinigo/WebstormProjects/project/node_modules/express-ajv-swagger-validation/src/middleware.js' has unsupported extension. The only supported extensions are '.ts', '.tsx', '.d.ts'.

1 /// <reference path="./middleware.js" />
                       ~~~~~~~~~~~~~~~

node_modules/express-ajv-swagger-validation/src/middleware.d.ts:61:41 - error TS2749: 'AjvValidatorOptions' refers to a value, but is being used as a type here.

61     new(options?: ajvValidatorOptions): AjvValidatorOptions;
                                           ~~~~~~~~~~~~~~~~~~~

node_modules/express-ajv-swagger-validation/src/middleware.d.ts:64:1 - error TS1046: A 'declare' modifier is required for a top level declaration in a .d.ts file.

64 let InputValidationOptions: InputValidationOptionsStatic;
   ~~~

node_modules/express-ajv-swagger-validation/src/middleware.d.ts:70:44 - error TS2749: 'InputValidationOptions' refers to a value, but is being used as a type here.

70     new(options?: inputValidationOptions): InputValidationOptions;
                                              ~~~~~~~~~~~~~~~~~~~~~~

Coverage remained the same at 99.074% when pulling 66afd15fcdcfd13fb79cd1c7d4863024c3a2e102 on fix/typescript-types into b10c8e942cd845f80d5ed6c80e26149fe1a07e10 on master.

Coverage remained the same at 99.074% when pulling 66afd15fcdcfd13fb79cd1c7d4863024c3a2e102 on fix/typescript-types into b10c8e942cd845f80d5ed6c80e26149fe1a07e10 on master.

@kobik Could you please take a look? This is a blocking issue for us :(

@kobik Any updates?..


webpack issues

The branch for webpack can be found at jw/webpack
Please comment with any issues you find, I will consolidate them into a todo list on this issue.
TODO

[x] Look into vis view error
[x] Remove all references of bower
[x] setup webpack dev server

Thank you so much! This is fantastic! Taking a look now and as suggested will add comments here (and/or for trivial stuff, fix in-place if you don't mind)

So! I installed yarn and fiddled with the makefile to make it [a] find yarn and [b] use the right version of node with yarn (more on that another time).
I tried make:
matthew@danger ~/d/compiler-explorer (jw/webpack)> make
Haskell language support disabled
D language support disabled
Rust language support disabled
yarn install
yarn install v1.3.2
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
[5/5] Building fresh packages...
Done in 48.33s.
node node_modules/webpack/bin/webpack.js

ERROR in ./static/cppp-mode.js
Module not found: Error: Can't resolve 'vs/basic-languages/src/cpp' in '/home/matthew/dev/compiler-explorer/static'
 @ ./static/cppp-mode.js 4:10-47
 @ ./static/editor.js
 @ ./static/hub.js
 @ ./static/main.js

ERROR in ./static/ispc-mode.js
Module not found: Error: Can't resolve 'vs/basic-languages/src/cpp' in '/home/matthew/dev/compiler-explorer/static'
 @ ./static/ispc-mode.js 4:10-47
 @ ./static/editor.js
 @ ./static/hub.js
 @ ./static/main.js
Makefile:61: recipe for target 'webpack' failed
make: *** [webpack] Error 2

Any ideas? :)

If it's a clue I noticed the vs directory seems to be in the wrong place:
$ ls
app.build.js  CODE_OF_CONDUCT.md  c-preload/  examples/  LICENSE        package.json  rust/    views/             yarn.lock
app.js*       CODEOWNERS          d/          haskell/   Makefile       README.md     static/  vs/
bower.json    CONTRIBUTING.md     etc/        lib/       node_modules/  Roadmap.md    test/    webpack.config.js
$ git status
[my WIP changes removed]
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	vs/

If I move the vs directory into the node_modules it "worked" ... Maybe the CopyWebpackPlugin needs a to of __dirname, "node_modules/vs" ?

Ok, if I manually move the vs directory, and then make I get a 404 for loader.js

Yup. That looks right. I knew there would be one thing missed!

Sweet, will make the changes. You chill, this is super lovely :)

Change already pushed :)

I don't see the fix, can you double-check you pushed?

https://github.com/jaredwy/compiler-explorer/commit/617471b8f52433861a5ebcbf05fee63d167bb252 as far as I can tell

Oh yes, d'oh I forgot it was in a forked repo and not a branch of CE itself. Cheers!

@jaredwy unless I'm missing something we can kill bower now, right?

Ok, just pulled and have the bower changes and the changes to put things in static/vs but still:
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
[5/5] Building fresh packages...
Done in 22.25s.
node node_modules/webpack/bin/webpack.js

ERROR in ./static/cppp-mode.js
Module not found: Error: Can't resolve 'vs/basic-languages/src/cpp' in '/home/matthew/dev/compiler-explorer/static'
 @ ./static/cppp-mode.js 4:10-47
 @ ./static/editor.js
 @ ./static/hub.js
 @ ./static/main.js

ERROR in ./static/ispc-mode.js
Module not found: Error: Can't resolve 'vs/basic-languages/src/cpp' in '/home/matthew/dev/compiler-explorer/static'
 @ ./static/ispc-mode.js 4:10-47
 @ ./static/editor.js
 @ ./static/hub.js
 @ ./static/main.js

matthew@danger ~/d/compiler-explorer (jw/webpack)> ls static/vs
base/  basic-languages/  editor/  language/  loader.js

However, running make again fixes the issue...
Is there now an ordering thing within the webpack config?
It's 100% reproducible with make clean; make
Will take a look (and also add static/vs to .gitignore)

Image assets 404 locally

Other > Thanks to... 404s

The image assets thing is known. I won't be fixing that in this round.

Going to close this issue @mattgodbolt @RabsRincon what do you think about creating a wiki page with that table above, and start to fill out some "smoke test" steps for all the features listed? So that we have an easy to refer to guide for these large sweeping changes in the future?


#15 Log Stat of Player with Acct

Solves #15
Added function to log play stats of game score into db

Please rename your pull request into something descriptive. What do "stat" and "acct" mean?


BT device advertises only DFU service after firmware update on iOS 10.2.

Hi,
We are using the 3.0.1 version of the SDK. On iOS 10.2 there seems to be some functional change in the BT stack, as our device gets stuck advertising only DFU service 00001530-1212-EFDE-1523-785FEABCD123 after firmware update. This issue does not happen on previous iOS releases. The only fix is to either reboot the device or to turn Bluetooth on the device off and then back on. Restarting the app doesn't help at all, even after force-quitting.
Do you have any idea what could cause this and any suggestions on how to fix it? This is most likely caused by something that we do incorrectly.

Hi, I don't understand fully. Could you give some more details. When your devices advertises with this UUID is it in dfu mode? Did the DFU upload complete? Does is stuck after switching from app mode to DFU mode and can't connect or at the end?
I tried today DFU on iPhone 7 with 10.2 and it send to work. Passed all my tests.

DFU upload completes and the firmware is updated. The fact that this issue is fixed by turning off bluetooth on the device and then back on seems to indicate that causes either the device to remain in DFU mode or the broadcasted services not updating correctly.
Do you have your DFU-related test codes in this repository as well?

You are turning Bluetooth off an on on the device that you have updated our on the phone? After successful DFU the target device should reboot into new app mode. If it doesn't it something wrong with the firmware, I guess.
The phone disconnects successfully of remains connected and turning off Bluetooth disconnects it?

Unfortunately we are lacking any unit tests despite our good will, but we accept pull requests :) I'm just performing tests with different scenarios manually.

I am turning the bluetooth off and back on again on the iPhone, not the peripheral. I think this is not a problem on the peripheral or firmware side, as doing this solely on the phone side fixes the issue. This would also explain why the issue occurs only on iOS 10.2 and no other iOS version so far.
Recreating the CBCentralManager after DFU results in CBCentralManagerStateUnsupported being notified in the centralManagerDidUpdateState callback.
I don't think there's anything wrong with your SDK, but I would appreciate any help or hints you could give me on how to debug this issue. :)
Do you have example test code that connects to a peripheral, puts it into DFU mode, does the firmware update and then reconnects to it that works on iOS 10.2?

We are using nRF Toolbox for that and are working on adding dfu to nRF Connect on iOS.
For development and testing we use the example project.

I'll do some more test tomorrow with 10.2 and try to reproduce your issue. What version of DFU are you using?

Could you elaborate on what you mean by the version of DFU?

What Nordic SDK did you branch your project from? There were some changes in DFU between them, new features were added etc.

Quick update on this issue. It seems that the way how iOS caches ble things has changed in 10.2. Our peripheral's DFU mode did not advertise the app service, so it got cached by iOS was not found even after switching out of the DFU mode.
This could be fixed by waiting for the cache TTL expiration (~15 mins) or by turning the bluetooth off and on again on the phone.
The actual fix we did was to advertise both services also in DFU mode.
The SDK we are using is 3.0.0.

@philips77 there seems to be regression in the SDK version 3.0.1 as it gets stuck in waiting for DFU mode confirmation. This works correctly with SDK version 3.0.0.

I was asking of the SDK version that you have based your firmware on, not iOS lib version.
Regarding the last comment. could you paste logs you get with loggerDelegate here?

My apologies. nRF51SDK version is 6.1.0 and SoftDevice S110 version is v7.3.0 on the firmware side. I will give you the delegate logs here shortly. 👍

The issue seems to have vanished after I rolled back to 3.0.0, tested and then reinstalled 3.0.1. Both firmware and bootloader updates are successful. I will open another issue should this occur again, but for now, let's close this.
Thank you @philips77 for your help!


Speed/disconnection issues when using raf and dat-storage

@blahah and I were debugging some speed + connection issues today. There are a few things causing bad transfer speeds. I can debug this a bit tomorrow and try to open more specific issues/test PRs. Hungry now and wanted to file before I forget =).

Frequent disconnects coming from dat-storage (I think not being able to locate data, see below).
raf storage (single file or multiple) causing hyperdrive to go slower. This one needs more debugging. Sometimes seems like raf, default hyperdrive storage, is much slower than using ram.

1 is definitely related to writing files + raf. I see it most with dat-storage and sometimes (I think, harder to reproduce) with regular raf on the content/data file.
The dat-storage error, could not locate data causes the replication stream to end and forces client to reconnect. Example error:
events.js:163
      throw er; // Unhandled 'error' event
      ^

Error: Could not locate data
    at /Users/rik/.nvm/versions/node/v7.7.4/lib/node_modules/dat-next/node_modules/dat-storage/index.js:50:30
    at loop (/Users/rik/.nvm/versions/node/v7.7.4/lib/node_modules/dat-next/node_modules/dat-storage/index.js:108:19)
    at /Users/rik/.nvm/versions/node/v7.7.4/lib/node_modules/dat-next/node_modules/dat-storage/index.js:75:5
    at /Users/rik/.nvm/versions/node/v7.7.4/lib/node_modules/dat-next/node_modules/hypercore/index.js:888:5
    at onread (/Users/rik/.nvm/versions/node/v7.7.4/lib/node_modules/dat-next/node_modules/random-access-file/index.js:106:25)
    at FSReqWrap.wrapper [as oncomplete] (fs.js:629:17)

I think we solved most of this

I got this error today, trying to add files to a dat-node dat instance via dat.archive.writeFile. See also the where I pass in dat.archive. It always seems to crash at the same location/point in time, after ~1 minute.

@derhuerst can you send the full error message you got? The code for dat-storage has changed quite a bit and I'm not sure what code the original error corresponds to anymore.

It always seems to crash at the same location/point in time, after ~1 minute.

Is the writing happening when it crashes or something else going on after the write finishes?

Right after running npm update before inside build-wikipedia-feed:
cat enwiki-20170720-stub-meta-current.xml.gz | gunzip | build-wikipedia-feed/revisions-list.js 2>/dev/null | build-wikipedia-feed/store-revisions.js

dat /root/.local/share/p2p-wiki/db eb4890cc39eb966cddb35117510405ed8fe26221901ff3d25a9d1e4bdc83a26a
13 @ 783865149 ✓
14 @ 783865160 ✓
10 @ 767284433 ✓
15 @ 783865293 ✓
18 @ 783865299 ✓
19 @ 783821589 ✓
20 @ 783821738 ✓
…
640 @ 789562124 ✓
642 @ 780371012 ✓
643 @ 789562051 ✓
644 @ 375387155 ✓
648 @ 769390556 ✓
Error: Could not locate data
    at /root/wiki-dumps/build-wikipedia-feed/node_modules/dat-storage/index.js:61:30
    at loop (/root/wiki-dumps/build-wikipedia-feed/node_modules/dat-storage/index.js:132:19)
    at /root/wiki-dumps/build-wikipedia-feed/node_modules/dat-storage/index.js:97:5
    at /root/wiki-dumps/build-wikipedia-feed/node_modules/hypercore/index.js:1061:5
    at onread (/root/wiki-dumps/build-wikipedia-feed/node_modules/random-access-file/index.js:130:14)
    at FSReqWrap.wrapper [as oncomplete] (fs.js:664:17)

Is the writing happening when it crashes or something else going on after the write finishes?

I'm opening the dat archive using dat-node, without joining the network (or anything else), and then write many files in parallel, as described above.

Any news on this? I still run across this error.


test: Change test to check for kubelet.service file existence as well.

What type of PR is this?
/kind test

What this PR does / why we need it:
This PR adds a little more context to the test added in https://github.com/Azure/AgentBaker/pull/3104 for issue #2815
The issue #2815 describes the full set of currently required data for custom images which don't rely on the CSE script to execute.
Those are:

/etc/default/kubelet
/var/lib/kubelet/bootstrap-kubeconfig
/etc/kubernetes/certs/ca.crt

The Databricks usecase also has a silly dependency on kubelet.service which I have removed and will roll out in the next month. I've added it as a required file for now, but happy to not if it's possible to otherwise prevent it from being removed in the near term?
/opt/azure/containers/kubelet.sh also shouldn't be required, but currently is because it's referenced by the kubelet.service.
Which issue(s) this PR fixes:
None
Requirements:

[x] uses conventional commit messages

[x] includes documentation
[x] adds unit tests
[x] tested upgrade from previous version

Special notes for your reviewer:
First PR in this repo so apologies if I'm missing something / happy to make changes.
I've confirmed that tests failed first, then passed with this change.
 Under what conditions is it NOT enabled?
Found this - https://github.com/Azure/AgentBaker/blob/a7df3d609eac4ad608ccd3e84ba193565c236243/pkg/agent/utils.go#L355 - but perhaps someone has context already?
Thanks!
Release note:
none

@alexeldeib - updated the commit messages to pass linting - could you re-approve tests at your convenience?
Also - e2e tests failed on the last run due to az login failed - any other follow up I need to make there?

unfortunately we have some annoying rbac issues running the e2e/generated tests from forks today :(
the lint is fine after rebase, I'm about to brea kit again but will squash-merge and ignore the other bit for now.

 Under what conditions is it NOT enabled?

tl;dr - always today. the token itself is generated by RP, so it's possible the field in the struct is empty. but that's never the case today anymore afaik.


MEMORY_UTILITIES reduce_memory_usage()

[x] main function development
[ ] unit tests
[x] documentation

See #274 for a question on the precision / decimal rounding of floating point resolution.


kubeless.jsonnet changes to add kubless controller configmap

Issue Ref: [Issue number related to this PR or None]
#475
Description:
Patch just creates a configmap for kubeless controller and exposes the env variables in the controller.
Patch leveraging the configmap to follow.
[PR Description]
TODOs:

[x] Ready to review
[ ] Automated Tests
[ ] Docs

/lgtm aside from my minor comment

@sebgoa forgot to publish review? Dont see any comment.

Release version does have SHA bitnami/kubeless-controller@sha256:53592e0f023353665569313a1662a3aff18141e48caf4beca54d68436e71e0dc


Not working anymore after 16.06.2020 update?

Hi,
it's not directly a issue of the docker container itself, but
is it possible that running conan exiles server via wine is not working anymore via wine? does someone has an idea how to fix it?
It always crashes somewhere

Ah after adding the comodo certificate it works again:
ADD http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt /usr/local/share/ca-certificates/USERTrustRSAAddTrustCA.crt
RUN update-ca-certificates

Did you add the cert to the redis instance? I currently only run a single conan instance without a redis, I added the cert and ran update-ca-certificates and restarted the docker compose I have, the cert persisted but the issue hasn't been resolved for me.
When not running the docker detached, I do not see any outputs indicating the server is crashing, however I'm still not seeing the server listed in the server browser and I'm not able to connect directly via IP over intranet.
The network errors I receive:
conanexiles_1  | Network:Error: Code: Certificate path env var 'DW_CERTIFICATE_PATH' is not set
conanexiles_1  | Network:Warning: Code: Loading dedicated server provider id certificate: SecureServerProviderID not set.
conanexiles_1  | Network:Display: Looking for dedicated server provider id certificates issued by "C=NO, S=Oslo, L=Oslo, O=Funcom Oslo AS, CN=Funcom Oslo AS"...
conanexiles_1  | Network:Warning: Code: Loading dedicated server provider id certificate: No secure server provider id configured, selecting certificate with id #-1.
conanexiles_1  | Network:Error: Code: KDS passphrase provider failed to initialize. KDS will at some point deny access unless the problem is fixed. Failure message: Error loading dedicated server provider id certificate: No certificate found with id #-1..
conanexiles_1  | Network:Error: Code: KDS passphrase failure: Server provider id certificate unavailable: 0x80092004
conanexiles_1  | Network:Display: Connecting to key distribution web service wss://ce-kds-winunoff-wdc05.funcom.com:7004/server/...
conanexiles_1  | Network:Display: Key distribution web service: Connecting (session: 831F5E454D51D2B1E7A26E856477C3F3, mirror: wss://ce-kds-winunoff-wdc05.funcom.com:7004/server/, fail count: 0, retry time: -1.0)

I guess you guys still using the very old docker image:
alinmear/docker-conanexiles:_12
Digest:sha256:0bb535b461d5428cd8b88aa16f242f75517f2302991addadc23da346ea34675e

If so, this image is 2 years old; does this also happen with :latest ?

The certificate stuff also is a problem on "latest" - I build my image from source, since I've added extensions for automatic mod support to it. But I can't speak for matthew

you can look into my changes here: You can freely use anything from it:
https://github.com/alinmear/docker-conanexiles/compare/master...Flow86:master

Interesting, just made a fresh local provisioning with my latest builds and there are no problems with the certificates. exiles server is installed without problems via steam.
Thanks for sharing your work. i look into your changes, so we can merge it to have proper synergies.

I just merged your changes @Flow86, thx for your work; maybe we can move parts into the Dockerfile; waiting for your comment

Fixed with #40


Feature Request - add recommendation around Encryption with customer-managed keys (CMK)

Deny or Audit resources without Encryption with a customer-managed key (CMK) is not part of the policy list.
This means it lack recommendation on the scope. Back to some of the other ALZ policies questions, why do policy initiatives exist that are not used or recommended?
I believe this should be implemented on intermediate root group as best practice. However, I do understand that not all clients want to use CMK - although this is best practice and recommended. So really, just some clear guidelines around the usage of CMK should be provided.

This comes in the box as nothing built-in exists in the platform. As you correctly call out, not everyone will want/need CMK so we cannot make this a default assignment using the 80/20 rule, therefore it will stay unassigned.
However, customers have it available should they wish to use it.

This comes in the box as nothing built-in exists in the platform. As you correctly call out, not everyone will want/need CMK so we cannot make this a default assignment using the 80/20 rule, therefore it will stay unassigned.
However, customers have it available should they wish to use it.

I completely agree, what I am missing is a place in the wiki that addresses this and mention to people that they have this policy initiative available, and why it would be best practice to use it.

@vegazbabz This is a good call out, and will be more relevant in the near future, where we are planning on adding more custom policies but not assigning by default.
To clarify, CMK is not the best practice for everyone, it's a good practice. Encryption is a best practice, customers managing their own keys in an enhanced practice, if they have the skills available to do so effectively - hence we have MMK.
Your point is taken, and we are in the process of adding custom policies aligned with CMK governance (not assigned by default) but will provide more options to customer wanting that additional level of security - and we'll provide additional wiki guidance aligned with this.
#ab33219

@vegazbabz You're totally correct on your viewpoint and analysis, however, we cannot implement this by default given the vast majority aren't ready for CMK. For those few customers that are ready and aligned to CMK we recommend implementing appropriate policies once ALZ is deployed to meet requirements. ALZ is a reference architecture, not perfect for everyone, but perfect for the 80%.
We're looking into revisiting the CMK perspective but have a lot of other things on the go at the moment, so may be a while before anything moves in ALZ in that space.

Addressed in PR #1622, additionally you will be able to choose the scope to apply the initiative.


Remove jquery from govspeak

What
Remove jquery from govspeak, and associated scripts (youtube link enhancement and bar chart enhancement).
Govspeak relies on magna charta, a jquery plugin, originally included as a minified copy of the code. Magna charta has now been archived, so I've copied the code into the gem and rewritten it as a module without jquery. This has included copying the original tests across from magna charta and rewriting them.
Ultimately we may want to replace magna charta altogether, but this change at least gives us a functioning, non-jquery version that we can apply fixes/changes to if required at any point.
Tests still use jquery in places but jasmine has its own jquery so we don't need to worry about that.
Why
To reduce our dependency on jquery.
Visual Changes
None.

Thanks @injms. I've gone with use classList and explicitly include the classList polyfill, so it can run in IE8+, which wasn't one of your options, but I'm improvising 😁


Enables user-defined buckets in viewportHistogram

histogram: viewportHistogram($prop, [[0, 20], 40, 60, [80, 100]])

You have more control about where the values fall, making easier to
control the UI/UX by having a more stable bucket list.
Closes #1160

Haha, I was waiting for your CR. 😂

Then let's 🚀 🚀 🚀 !


Updated PAT

Updated scopes and images

@jerae-duffin Could you take screenshots without the cursor and optimize the screenshots? I think there's an option to do avoid capturing the cursor in SnagIt. Also, for the border, could you use the color #C7C7C7?


Fix typo in german translation

1. Why is this change necessary?
Fix a typo in snippet
2. What does this change do, exactly?
abesteigend -> absteigend
3. Describe each step to reproduce the issue or behaviour.
Typo occurs on the listing page filter
4. Please link to the relevant issues (if any).
5. Checklist

[ ] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[ ] I have written or adjusted the documentation according to my changes
[ ] 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.

Hi @nexxome and thank you for you contribution.
Sadly this issue is fixed already in our upcoming 6.1 release. This will be synced with the master branch shortly
sunnry regards
pantrtxp


Add KerbinRover Off-Road Vehicles from SpaceDock

This pull request was automatically generated by SpaceDock on behalf of TiktaalikDreaming, to add KerbinRover Off-Road Vehicles to CKAN.
Mod details:
name = /mod/602/KerbinRover%20Off-Road%20Vehicles
author = TiktaalikDreaming
abstract = KerbinRover, famous for their Defender series of vehicles, is now making space adapted versions of their range of vehicles.
license = MIT
Homepage =
description = This is very much an early WIP.  More vehicles to come, and more detail and better textures to come as well.  Currently there's just a half(aka kerbal) scale LandRover Defender with one wheel choice.
Please direct questions about this pull request to TiktaalikDreaming.

Closing this due to the referred PR/issue/commit.


Create github issues from local dir

So I saw that #2 works, which is pretty cool. Is there a way to use tdo to create issues in a current repo's remote?
Say something like
$ cd my-repo
$ tdo add 'this is a new issue'

and have tdo figure out the github remote from the current dir's .gitconfig and remote.
That'd be sweet.

This sounds more like you are looking for an actual Github CLI, which is a little bit outside the scope of this application. 😛

On 2. May 2017, at 15:57, Kilian Koeltzsch<EMAIL_ADDRESS>wrote:
So I saw that #2 works, which is pretty cool. Is there a way to use tdo to create issues in a current repo's remote?
Say something like
$ cd my-repo
$ tdo add 'this is a new issue'
and have tdo figure out the github remote from the current dir's .gitconfig and remote.
That'd be sweet.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

the command would be
tdo github 'this is a new issue'

or
tdo github 'this is a new issue' 'with a body as a description'

but this is an optional feature 😛 Maybe this could be implemented... with a PR?


[DEP]  remove deprecated 'save_transformed_data' and 'transformed_data_' in BaseIntervalForest, FreshPrince, STC,

Deprecation task #1238
Not sure about whether I can just remove the None returned by _fit_estimator, will see if it is ok as is first.

@TonyBagnall dont think i should review this 🙂


Countasync implementation #84

Hi,
@IEvangelist  @mumby0168
Resolves #84

Nice work, will check this over tomorrow 👍🏼

@emrekara37 this looks great. Two general feedback items:

I think it would be good to pair with unit tests and/or sample usages. Looking at the repo, I don't see any DefaultRepository tests, so maybe start with Service + Web tier examples?

Saying this out loud, but assume we can't/don't want to support a string query API overload

@mumby0168 @IEvangelist defer to y'all, but that's my 2 cents.

Yes I would agree with that comment, great work we should definitely look at adding tests for the in memory implementation as all the other methods are covered, I think since there is not test file the default repository at the minute a sample demo will be fine 👍🏼 we do need to look at adding tests for it, maybe need a issue for that.

@IEvangelist would you be able to add @emrekara37 to the all-contributors the bot does not come up in my auto-complete is there some permissions needed for it?

@IEvangelist would you be able to add @emrekara37 to the all-contributors the bot does not come up in my auto-complete is there some permissions needed for it?

Ignore this had just seen @emrekara37 is already in the list.

@IEvangelist would you be able to add @emrekara37 to the all-contributors the bot does not come up in my auto-complete is there some permissions needed for it?

Ignore this had just seen @emrekara37 is already in the list.

Hi @mumby0168 - when I type a comment, it doesn't autocomplete for me either. It should still work for you though, see here:
https://allcontributors.org/docs/en/bot/usage

Hey @emrekara37 really like the look of this PR. Anything I can do to help you? With a few to getting this PR merged?

Hey @emrekara37 really like the look of this PR. Anything I can do to help you? With a few to getting this PR merged?

Hi @mumby0168 ,
I will add some test cases asap .
Thank you

Hey @emrekara37 really like the look of this PR. Anything I can do to help you? With a few to getting this PR merged?

Hi @mumby0168 ,
I will add some test cases asap .
Thank you

Sounds great, no rush 👍 I added this issue to the next release milestone.

hey @emrekara37 any news on this PR 😄

hey @emrekara37 any news on this PR 😄

Worth noting we have a little re shuffle under the hood so UT's can now be written for the DefaultRepository

Hi @emrekara37, really love your work. We were really hoping to include this PR as part of our version 2.4.0 release.
I wanted to give you the opportunity to get the test's finished for this and get this PR merged.
We have the deadline set for the new version at the end of September.
Do you think you'll get a chance to finish this off or would you prefer someone else to pick it up and complete it?
Milestone: https://github.com/IEvangelist/azure-cosmos-dotnet-repository/milestone/1

Sorry @emrekara37 I am going to have to close this PR due to us hoping to release the feature by the end of September.
Thank you very much for your work on this so far 👍

It would be nice to revisit this - perhaps it's as easy as reopening. Looks like all the functionality is there. @mumby0168


Rename "SSL" code elements "TLS"?

Over in pull request 13479 @mehrdada suggested renaming (well, "introducing new aliases of", because we wouldn't want to break anyone) the "SSL" code elements of the gRPC Python API "TLS" (so that ssl_server_credentials becomes tls_server_credentials and so forth). What do you think?

Just to be clear, even if the code element change is infeasible, I am advocating the documentation comments to say TLS instead of SSL.

It's an API; if we wish to do a migration we should be able to do it while also providing aliases under the old names. Help me see where it would be infeasible?

By "infeasible", I mean unless we plan to deprecate them at some point, which will break some users, it is just a duplication of code elements and feels flawed in nature. Between not breaking users vs. fixing the name, I feel the former would be more justified.

I wonder what @jboeuf thinks about the first step, i.e. transitioning API documentation from "SSL" to "TLS", which can precede the actual API changes by years?

CCing @jiangtaoli2016 and @justinburke
If we are going to rename this code, we should think about using HTTPS as opposed to TLS since these credentials carry HTTPS semantics with domain name validation. This is in contrast with other usages for TLS such as www.spiffe.io which have different trust semantics and will probably have their own type of credentials.

@jboeuf I see... would HTTPS still be a good name considering we potentially run on non-HTTP2 transports?

This is a good question. What we want to distinguish is not so much the
transport but the semantics of trust validation in TLS (which is silent
about any given trust model). HTTPS is typically what we refer to for
server host name validation as it references something that the industry
understands.
TlsWithServerHostNameValidation would be a bit sad. Another solution
would be to keep TLS and add options for a given trust model where Server
Host Name validation would be the default.
On Wed, Dec 13, 2017 at 3:50 PM, Mehrdad Afshari<EMAIL_ADDRESS>wrote:

@jboeuf https://github.com/jboeuf I see... would HTTPS still be a good
name considering we potentially run on non-HTTP2 transports?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grpc/grpc/issues/13481#issuecomment-351562752, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AF-P7UTiqYvGla93Pn_Pijw7imLgGYuyks5tAGLMgaJpZM4QmXTr
.

TlsWithServerHostNameValidation would be a bit sad. Another solution
would be to keep TLS and add options for a given trust model where Server
Host Name validation would be the default.

+1 to both these comments. The verbose name, while descriptive, is probably too verbose for the common case. I like the idea of adding an option to specify an alternative validation model.


Get claims by target ID

Link to JIRA ticket
https://hackney.atlassian.net/browse/DOC-1100
Describe this PR
What changes have we introduced

Added gateway function to retrieve all claims by target ID
Added use case to retrieve all claims by target ID
Added new endpoint to GET all claims by target ID
Updated the ClaimRequest validator to only accept Name between 1 - 300 characters
Added unit and integration tests for all of the above

Checklist

[x] Added end-to-end (i.e. integration) tests where necessary e.g to test complete functionality of a newly added feature
[x] Added tests to cover all new production code
[ ] Added comments to the README or updated relevant documentation (add link to documentation), where necessary.
[x] Checked all code for possible refactoring
[x] Code pipeline builds correctly

Follow up actions after merging PR
This new endpoint needs to be locked down so it is only accessible to the MMH team.

We might benefit from adding an index on the targetId column.


docs: Add in documentation for how to bypass adblockers for more accurate analytics

Summary of Changes
Add in documentation for how to bypass adblockers for more accurate analytics
Documentation
Section in https://github.com/amundsen-io/amundsen/blob/master/docs/faq.md for how to bypass content blockers to capture all analytics
CheckList
Make sure you have checked all steps below to ensure a timely review.

[x] PR title addresses the issue accurately and concisely, including a title prefix.
[x] PR includes a summary of changes.
[x] My commits follow the guidelines from "How to write a good git commit message"

thanks @instazackwu


Check Google Pay supported

How to check, that Google Pay is supported?

There's a boolean value returned by StripeNative.nativePayReady. Maybe try that.

StripeNative.nativePayReady just checks the library is configured correctly:
  static bool get nativePayReady =>
      merchantIdentifier.isNotEmpty && publishableKey.isNotEmpty;

Hey, that's right.
I was working with this library, but wasn't able to move to production due to some issues on the iOS side.
It never popped up the Apple Pay sheet.
Ended up switching to, stripe_payment


Try to fix issue#2892 by making sure that when using the JdbcTransact…

Skip autoCommit reset logic: By adding the skipSetAutoCommitOnClose flag, you can control whether autoCommit is reset when closing the connection. If set to true, it means that you do not want to modify autoCommit on close to avoid accidental transaction commits. This is to give developers more flexible transaction management options, especially when they manually manage connections and transactions themselves.

Hello @LLLongA ,
I guess this is another school assignment, right?
I am not going to review it, so please close it when it's done.
And please tell your tutor that this is a bad idea.
You waste other developers' time that could have been used to review real PRs.


exp run: fails with upgrade from 2.51.0 -> 2.6.0

Running experiments in the vscode-dvc-demo project started to fail with
ERROR: failed to reproduce 'train':  output 'training/plots' is already tracked by SCM (e.g. Git).
    You can remove it from Git, then add to DVC.
        To stop tracking from Git:
            git rm -r --cached 'training/plots'
            git commit -m "stop tracking training/plots"

after upgrading DVCLive from 2.5.1 to 2.6.0 previously they completed as expected. training/plots is not tracked by git but may have been previously.
dvc.yaml for the project is here.
DVC version: 2.52.0 (pip)
-------------------------
Platform: Python 3.10.6 on macOS-13.2.1-arm64-arm-64bit
Subprojects:
        dvc_data = 0.46.0
        dvc_objects = 0.21.1
        dvc_render = 0.3.1
        dvc_task = 0.2.0
        scmrepo = 0.2.0
Supports:
        http (aiohttp = 3.8.4, aiohttp-retry = 2.8.3),
        https (aiohttp = 3.8.4, aiohttp-retry = 2.8.3),
        s3 (s3fs = 2023.3.0, boto3 = 1.24.59)
Cache types: reflink, hardlink, symlink
Cache directory: apfs on /dev/disk3s1s1
Caches: local
Remotes: s3
Workspace directory: apfs on /dev/disk3s1s1
Repo: dvc, git
Repo.site_cache_dir: /Library/Caches/dvc/repo/d5a6bcf13ad1fd71779c03d6d85e2dee

Prior to the upgrade the experiments completed with
To track the changes with git, run:

        git add params.yaml dvc.lock train.py dvc.yaml training/metrics.json

To enable auto staging, run:

        dvc config core.autostage true

Ran experiment(s): chewy-foil
Experiment results have been applied to your workspace.

To promote an experiment to a Git branch run:

        dvc exp branch <exp> <branch>

Please LMK if you need anything further to debug.
🙏🏻

I appreciate that there could be an error with the way that the project is setup and this is not a bug. Any help would be appreciated.

It is a regression.
Introduced in https://github.com/iterative/dvclive/pull/511/files
We should not call add when the output is tracked by DVC.