docker: no amd64 arch for v0.11.0

The latest version (v0.11.0) doesn't have any amd64 arch available.
https://hub.docker.com/layers/grafana/cortex-tools/v0.11.0/images/sha256-7f081e85823c6965780fb9d2c0eddfbd46526e3a237ddd538ea550a1ebd5142b?context=explore

100% the dev used a Macbook and had no idea about the M2 chip vs. X64 lol.

It's still an issue, meaning that latest image from grafana/cortex-tools:v0.11.0 cannot be used in ci pipelines that are running on amd64 arch. Current workaround to use Docker image built internally.
Fix is quite simple, adding --platform=linux/amd64 to base docker image would pull in the correct base layer and building locally with: docker buildx build --platform=linux/amd64 --no-cache -t grafana/cortex-tools .
FROM --platform=linux/amd64 golang:1.16.8-stretch as build
ARG GOARCH="amd64"
COPY . /build_dir
WORKDIR /build_dir
ENV GOPROXY=https://proxy.golang.org
RUN make clean && make cortextool

FROM      --platform=linux/amd64 alpine:3.14
RUN        apk add --update --no-cache ca-certificates
COPY       --from=build /build_dir/cmd/cortextool/cortextool /usr/bin/cortextool
EXPOSE     80
ENTRYPOINT [ "/usr/bin/cortextool" ]

Is this a supported image by Grafana? Is anyone planning on fixing this?

Hi! 👋 I just pushed v0.11.1 which includes a build for linux/amd64.

@grobinson-grafana - I guess there's no actual difference between 0.11.0 and 0.11.1 except the architecture for which it was built.  Just in case some is wondering.

We had to upgrade the Go version to 1.22, but otherwise no changes.


Simplify naive datafrog analysis

Removes all unnecessary iterations and data copies.
Fixes #37.

Nice — I wanted to double check that we still produce same tuples before I merged, but this basically looks right to me.

Probably not a big deal, but this does change the output of -v and --stats from the previous datafrog and timely versions.
It'd be nice to keep the comments up-to-date :

removing the indices makes them not // redundantly computed index anymore
the note at the top can now be removed

@nikomatsakis I've tried diffing the output against the dataopt strategy -- there are no differences at all.


How to get the best results

Hi
Lets say i have 5 encodings of each person. Now when i do face recognition i check all the 5 encodings against the face encoding that was sent.
Is this the best way to get the end result:

I mean, i can also check if their all true or if 4/5 is true, but is this how i should approch the recognition phase?

@ehrsten
Majority decision is not bad.
I guess there is low face quality image and it occurs increase distance between query and target.
So we should use majority decision if we can not take high quality image (front facial).


Tab completion is broken for buttons

Describe the bug
A clear and concise description of what the bug is.
text about the problem here.
Open a new arcade project,
switch to JS
then follow the .gif

starting work

starting work

Note to self:
Related: https://github.com/microsoft/pxt/pull/7291

Note to self:
Related: https://github.com/microsoft/pxt/pull/7291

Note that this repros on the released version of Arcade today. This dates back to before at least Aug 11th.

Note that this repros on the released version of Arcade today. This dates back to before at least Aug 11th.

The issue is pretty subtle. We have an assumption in our language service that each Symbol will have one Snippet.
However this isn't true. Both of these use the same symbol (onEvent) and yet their snippets must be different:
controller.anyButton.onEvent
controller.A.onEvent

In both of these completion cases, we were returning the snippet as: controller.anyButton.onEvent(Pressed, ...)
I'll need to think about the solution.

The issue is pretty subtle. We have an assumption in our language service that each Symbol will have one Snippet.
However this isn't true. Both of these use the same symbol (onEvent) and yet their snippets must be different:
controller.anyButton.onEvent
controller.A.onEvent

In both of these completion cases, we were returning the snippet as: controller.anyButton.onEvent(Pressed, ...)
I'll need to think about the solution.

One possible solution: return the snippet in parts. So instead of one string: controller.anyButton.onEvent(Pressed, ...) we return a series of qualifiers ["controller", "anyButton"] and the function string onEvent(Pressed, ...) then the insert location can choose which qualifiers to include or not. In the case that we're already several "."s in, we discard all the qualifiers.
Doesn't feel particularly principled but might be the smallest fix.

One possible solution: return the snippet in parts. So instead of one string: controller.anyButton.onEvent(Pressed, ...) we return a series of qualifiers ["controller", "anyButton"] and the function string onEvent(Pressed, ...) then the insert location can choose which qualifiers to include or not. In the case that we're already several "."s in, we discard all the qualifiers.
Doesn't feel particularly principled but might be the smallest fix.

We switched to the stock monaco service


Is this plugin works with last AS 4.0 and last Gradle plugin?

I tried to use it, ma is not working
Thanks

Hi @francescogatto - I just tried with AS 4.0.1, Android build plugin 4.0.1, and Gradle wrapper 6.1.1 and it worked for me. I'm going to need a bit more details such as:

Have you added the changes on both root and app build.gradle files?
Are you using it after the plugin declaration for com.android.application?
After creating your template, have you built your project before looking for the generated strings?
What versions of the android build plugin and gradle wrapper are you using?

Thanks.

I'll close this issue due to inactivity, please reopen if you keep seeing the issue and if you can provide the details asked above, it will help sort it out.
Thanks.


Support multiple audio tracks

Maybe it's only me who need this, so I'm OK if this PR is not accepted.
I added support for multiple audio tracks, including:

User defined audio track numbers/IDs.
User defined audio track names.
Changes to the chunk sorting algorithm to support any number of tracks.

With 3. it's trivial to support multiple video tracks, but I really don't know who needs that...
My biggest concern is that the API change makes it harder to use for users who only need one audio track, because they always need to specify audio track numbers (in options and in addAudioChunk). Maybe:

Mark AudioTrack["trackNumber"] as optional. At runtime, require it to be specified if MuxerOptions["audio"] have multiple items
Move the trackNumber parameter in addAudioChunk method to the last and make it optional. At runtime, require it to be specified if MuxerOptions["audio"] have multiple items

This is lovely, thanks for the PR! I knew multiple tracks were coming, especially with audio, since this is often used for multiple languages in movies, but I'm sure there are other uses for it too. Perhaps multiple video tracks are also useful for the same reason - as a kid, I watched a lot of Pixar movies, and they would translate on-screen text (like a book) into the selected audio language.
Anyhow, I'll of course have to read through this PR more thoroughly and test it (I only skimmed over the code for now, but looks promising), but I wouldn't be opposed to adding this feature.
You recognized that the biggest challenge here is likely the API. Let me ramble about this: For a longer time, I have been toying with the idea of creating a more "meta" library that uses my muxers under the hood. Thing FFmpeg but without FFmpeg, only WebCodecs. "Meta" in the sense that it also takes away the effort of having to set up encoders manually, but you can give it a canvas, webcam stream, microphone stream, audio file, whatever, directly, since I see a lot of people in Issues struggling with WebCodecs usage issues instead of library issues.
If I did this, I'd probably switch from an "object configuration"-style API to a more programmatic one, where you'd call methods like .addVideoTrack on the muxer. This API change would then effortlessly support multiple tracks of any media, be it audio, video, or even subtitles. And then adding chunks would be a method on the track, not on the muxer, making the associating unambiguous. The question is if it's worth changing to that API or if I should keep it somewhat backwards compatible. I personally don't mind breaking things, since people can just stay on the old version, and migrating wouldn't take long anyway. So, I need to see!

since this is often used for multiple languages in movies,

I considered that, but IMO the possibility to produce a multi-language video in browsers is pretty low.
This use case also needs the language element, I can add that.

but I'm sure there are other uses for it too

In my case, I want to record desktop audio and microphones (maybe multiple microphones, if the device has them) at the same time, and into separated audio tracks (for editing later).
With multiple video tracks, it can record a whole video conference, with each speaker's camera and microphone separated into their own tracks.

where you'd call methods like .addVideoTrack on the muxer.

I like this design. Actually, the code in my project already uses a wrapper that creates individual track objects for adding chunks to them. I think it very similar to what you are talking. I think it can also allocate track numbers automatically.
This design also doesn't make using only one video and one audio tracks more complex.
I think Matroska doesn't allows adding tracks after starting, so it might need a start method to write tracks?

Gonna take a while 'til I properly get to this PR, so feel free to use your own fork or something in the meantime so you're not blocked building whatever you need to build.

I think I'll close this PR for now. I think the general idea is good, it's just that I would use a different API for it which would fundamentally change the entire API of this library. Since I like to keep mp4-muxer in sync with this library API-wise, I'd also need to adjust that lib. Since I have plans to unite the two in the future anyways, I will implement multiple tracks then. In which case I'll use your implements efforts here as reference!
Again, feel free to run your own fork until then, nothing wrong with that.


error building on VS2015

Hi,
I've been using portable-file-dialogs, but with the update https://github.com/samhocevar/portable-file-dialogs/commit/5d96dae879e4f155c75abc6c22cea1f019e1d651 for folder selection it stopped building.
portable-file-dialogs.h(501): error C2065: 'callback': undeclared identifier

I took a look at the code and can't figure out a good way to fix it, seems to be that because callback is not within that lambda scope it can't resolve, but it's not possible to pass [&] as it stops being a valid BFFCallback?

I don't mind fixing this myself just wanted to know an idea of the best way to do so. Also lp and pData variables in callback will throw an unreferenced formal parameter as they are not being used.
Thank you for your time.

Thanks for reporting this. It is a bug in the Visual Studio compiler which unfortunately was only fixed in versions 2017 and later, as you can see. I’m happy to try to keep the code VS2015-friendly, though.
Your analysis is correct, there’s a catch-22 here that will prevent fixing this in an elegant way. I’ll think about it but if you have a suggestion let me know.

This problem can be solved by changing the callback function and the variable wdefault _ path, wtitle to the global.

Thanks. Personally I've since updated from VS2015 to 2017 so I don't need the fix anymore. This is still useful for anyone who's still on VS2015

Was fixed by PR #19
Can close this issue


Add Eval Set feature documentation

Adds documentation for the platform Eval Set  feature.
@rannn505, we should update the screenshots under the grid and graph section so that they include the new action but they're using a Configu platform organization I don't have access to that you used to create all the pictures on the Explorer docs page. You should either give me access to that organization so I can re-create the screenshots with the new actions or you can assist me by updating the screenshots on this PR.

@RichardAkman can you open a separate ticket for updating those images?

@RichardAkman can you open a separate ticket for updating those images?

Absolutely, here is a link to the issue #456


Update nr1-common.mdx

Hey @rudouglas  Our workflow for these has transitioned to scraping the CLI to somewhat automate these docs. So this would get overwritten the next time we do that. When I just ran the scraper to see what the new docs would look like, I get:
Fetches data from new relic databases using a nrql (new relic query language) query

### Usage

```sh
nr1 nrql
```

### Options

|||
|---|---|
| `-a`, `--account=account` | (required) user account ID |
| `-q`, `--query=query` | (required) NRQL query to run |
| `-u`, `--ugly` | outputs the content without tabs or spaces |
| `--profile=profile` | the authentication profile you want to use |
| `--verbose` | adds extra information to the output |

### Description

See https://docs.newrelic.com/docs/insights/nrql-new-relic-query-language

I noticed the docs in the description results in a 404. I think the better place to update this link would be in the nr1 CLI.


feat(MLOP-2145): add feature set creation script

Why? :open_book:
Allow users to automatically create feature sets readers and features
What? :wrench:

A class that extract readers and features from a SQL String and infer data types with a sample DataFrame

Working on some suggestions here https://github.com/quintoandar/butterfree/pull/352. WDYT?


fix: allow for undefined value of services

Current dependencies on/for this PR:

main

PR #98   👈

This comment was auto-generated by Graphite.


[d3] added Transition.transition() and optional 'i' on Arc

Added missing transition() for Transition, see https://github.com/mbostock/d3/wiki/Transitions#transition, and missing optional on Arc, see https://github.com/mbostock/d3/wiki/SVG-Shapes#_arc (index is optional).

:+1:

@gustavderdrache thanks!
@fmilitao thanks mate!


wasmer: 4.3.3 -> 4.3.4

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/wasmer/versions.
meta.description for wasmer is: Universal WebAssembly Runtime
meta.homepage for wasmer is: https://wasmer.io/
Updates performed

Rust version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 4.3.4 with grep in /nix/store/gi7drj5kgncic4q2km71aa0lrv4qr67x-wasmer-4.3.4
found 4.3.4 in filename of file in /nix/store/gi7drj5kgncic4q2km71aa0lrv4qr67x-wasmer-4.3.4

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

wasmer

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/gi7drj5kgncic4q2km71aa0lrv4qr67x-wasmer-4.3.4 \
  --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 wasmer https://github.com/r-ryantm/nixpkgs/archive/40eb217fa5e5720d9876d44a7e1b1576fa68dd98.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/40eb217fa5e5720d9876d44a7e1b1576fa68dd98#wasmer

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/gi7drj5kgncic4q2km71aa0lrv4qr67x-wasmer-4.3.4
ls -la /nix/store/gi7drj5kgncic4q2km71aa0lrv4qr67x-wasmer-4.3.4/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.


Feature: certificates for forwarding domains

The ability to create certificates for forwarding domains would be great so that they can forward via https.

Is it the same as #187 ?


Add phpdoc throws

Q
A

Is bugfix?
yes

New feature?
no

Breaks BC?
no

Tests pass?
yes/no

Merged. Thanks!

I'm against such changes. These annotations are not only useless (see https://github.com/yiisoft/yii2/pull/14374#issuecomment-312507991), but actually gives more harm than good. I'm using unhandled exceptions inspection in PHPStorm, and methods with annotations like these are really annoying. You can't do anything practical with it - these exceptions are to general to catch and handle it. The only thing you can do with them is just ignoring. So what is the point of annotations that should be ignored?

Your own PHPStorm make this annotation after find \Exception and \Trowable inside a function body.
If not include it the PHPDoc is mark as wrong.
PHPdoc tell about function directly. You see function PHPDoc (not body!) in many cases. Without throws you not get any info about fact of exception from function
You use one of PHPStorm tools and you get annoying with it. May be can make this tools better? Config it? Not code?

If you against of common \Exception and \Trowable - may be need concrete class?

If you against of common \Exception and \Trowable - may be need concrete class?

I'm open to suggestions, but I'm pretty sure that you don't know what these exceptions means. Nobody knows - they're caught and rethrown "just in case", they don't have any meaning. Meaningless exceptions should not be annotated.

Yep, this is "just in case".
I think for nested ob_start in third-part $_file_ for example. For get buffer / get down to current level /before throw error next.

So... this functional must be ignored?


NLopt version restriction

Ciao,
Is there a reason for the v0.6 constraint on NLopt.jl? Now they have v1.0 out.
It's not really an issue for me (though I can't upgrade the NLopt version now), more of a question.
Pierre

No reason  I guess ... mind to do a PR?
A
On Fri, Oct 20, 2023 at 2:31 PM Pierre Barrat @.***>
wrote:

Ciao,
Is there a reason for the v0.6 constraint on NLopt.jl? Now they have v1.0
out.
It's not really an issue for me (though I can't upgrade the NLopt version
now), more of a question.
Pierre
—
Reply to this email directly, view it on GitHub
https://github.com/pagnani/ArDCA.jl/issues/30, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJYTHRPENY2OIVFJ66K7VTYAJVIVAVCNFSM6AAAAAA6I6U46SVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE2TIMJZGM3DOMQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
Politecnico Torino
Corso Duca degli Abruzzi 24,
I-10129 Torino - Italy
+39<PHONE_NUMBER>
Italian Institute for Genomic Medicine (IIGM)
IRCCS di Candiolo, SP142 km 3,95
10060 Candiolo (TO)


Doesn't work in 0.8.6

There are no error messages thrown, but none of the configured ability checks are being hidden. The repo is flagged for 0.7.9 so I understand that's likely expected, but is there intention to update?
(I've tried turning off every module except this one)

What version of the module are you running? Latest (0.7.1) should work fine in Foundry 0.8.x.

Oh interesting, The Forge appears to say 0.7.0 is the latest (see below).  Lemme see if I can't manually grab the 0.7.1 version and install it.

Ahh, looks like the JSON file has it flagged as a minimum version of 0.8.7 is required; so I suspect The Forge is detecting that and limiting my ability to install it.
If it's 0.8.x compatible should the minimumCoreVersion and compatibleCoreVersion attributes be modified to reflect that?

Sorry, I misspoke (that's what I get for responding to bug reports at 2am).
The min version 0.8.7 is correct; Foundry had an issue up until 0.8.7 that prevented private rolls from displaying correctly and made the module unusable in 0.8.0 through 0.8.6. There's not really much of anything I can do about that, so compatibility with 0.8.6 isn't an option, unfortunately.

Totally get it :) Thank you!


Independent language settings

Is it possible to set different languages at the same time. For example, the frontend is in Spanish, the backend is in English and a vendor uses French.

@oldcastlehq yes, it is possible but .. the most fast type (noob) is to check url address and if is Vendor (for example) to set French language. You can check in language library (application/library/language) maybe..


Extends moment

In the case you are using extends moment (for example moment-timezone) it will have some conflicts, because material-ui-pickers imports moment from node_modules without possibility to pass extended moment directly.
Seems like the way to fix it pass moment to MomentUtils or setup moment in constructor. I can contribute if needed, let me know if you have any ideas or plans to fix it.
Another example it's a locale.
For example in main project you are using locale.
import moment from 'moment';
moment.locale('sv');
export default moment;

Locale will not work with material-ui-pickers, because it uses node_modules/moment
Environment

Tech
Version

material-ui-pickers
1.0.0-rc.1

material-ui
1.0.0-beta.32

React
16.2.0

Browser
Any

Platform
MacOS

Steps to reproduce

Use moment-timezone in main project.

import moment from 'moment-timezone';
moment.tz.setDefault(timezone);
export default moment;

Using DateTime picker will use your local timezone and have conflicts with current code base
As a result your moment logic will have timezone conflict with pickers if you use another timexone then local one.

Expected behavior
Possibility to pass moment to MomentUtils
Actual behavior
Using moment from node_modules

You can pass already formatted by moment value.
value={moment()}

@dmtrKovalenko I'm trying to use latest rc3 PR now https://github.com/dmtrKovalenko/material-ui-pickers/pull/278. But when I pass value={moment()} with defined timezone, calendar uses my local timezone now. In rc2 everything was ok in this case, defined timezone worked good. Any changes to use it in the new way?

You can now pass moment as a prop to the MuiPickersProvider

Fixed in rc-3


Have a registry of regions?

Would it be helpful to keep track of all region classes? We can do that with a simple meta-class (I could add it)

@astrofrog - What would be the purpose / use cases of a registry of regions?
If there's a use cases for it, then yes, it does sound like a nice thing to have.

I'm 👍  on having a registry of regions.
Probably we should also introduce a "region type" class-level attribute for each region, no?
Looks like shapely does this via the geom_type:
http://toblerity.org/shapely/manual.html#object.geom_type
Where possible we could use the STS-C names (see #21), so that this is also a first step towards supporting the STS-C region data model and serialisation format.
One possible use case for the registry would be to replace the lists of regions here:
https://github.com/astropy/regions/blob/master/regions/shapes/tests/test_api.py
and, in addition to being used in the tests, to also print a text or HTML summary report of which methods are implemented or not (using checks like what's currently done in the tests).
I don't know how to implement a registry well.
@astrofrog - Do you have time to contribute this? Or can you point to some other example of a registry how this should be implemented?

Moving to 0.3 milestone.

@astrofrog @larrybradley  or anyone - Is there a standard pattern or even utilities to implement registries in Astropy core? (in a way that's simultaneously Python 2 and 3 compatible).
Just for references, this is what I came up with via a Google search so far:
https://github.com/faif/python-patterns/blob/master/behavioral/registry.py
http://www.effectivepython.com/2015/02/02/register-class-existence-with-metaclasses/

I don't think this is a blocker for the 0.3 release we wanted to make later this week.
Moved to 0.4 milestone.
If someone has time to implement this, it can go in any time of course.
There was agreement in the discussion above that this would be nice to have.


submit => none type object has no attribute find

I get this error when I do "kg submit out.csv"
config is:
[('username', u's******@gmail.com'), ('password', '********'), ('competition', u'cats-vs-dogs-redux-kernels-edition')]

same issue here:
kg submit submission.zip -c "Carvana Image Masking Challenge" -u USER -p PASS

@stefat77 try kg submit submission.zip -c carvana-image-masking-challenge -u USER -p PASS.

@simonm3 I can't find cats-vs-dogs-redux-kernels-edition but found dogs-vs-cats-redux-kernels-edition. I'm going to add warning tips for typo cases.

fixed https://github.com/floydwch/kaggle-cli/commit/8f3d54dc1419e03cfcaf42bbfc0336de9200ce4f .


Unfreeze Deadskins with updated dependencies

closes #5746
StoneBlue has contacted us on #5746 to authorise re-adding this mod to CKAN.
This sets up a virtual mod DeadskinsTextureSwitch, which is provided by FirespitterCore and InterstellarFuelSwitch-Core.
According to #5746, a future release of Deadskins Relit will move to a mesh-based switching system that can currently only be provided by B9PartSwitch and InterstellarFuelSwitch-Core. PR blowfishpro/B9PartSwitch#54 has been submitted to enable the future change to having B9PartSwitch provide the required new virtual mod "DeadskinsMeshSwitch". This PR includes a provide for this virtual mod to InterstellarFuelSwitch-Core.

Passed without the virtual dependency, which can't be met until this is merged.


add code_arm_required to manual alarm with mqtt

Description:
Add code_arm_required to the manual alarm with mqtt as per the mqtt alarm.  This option bypasses the code check if code_arm_required is false.
Related issue (if applicable): fixes #
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#9087
Example entry for configuration.yaml (if applicable):
alarm_control_panel:
  - platform: manual_mqtt
    state_topic: home/alarm
    command_topic: home/alarm/set
    pending_time: 30
    delay_time: 20
    trigger_time: 4
    code_arm_required: False

Checklist:

[ ] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[x] Tests have been added to verify that the new code works.

It looks like the travis build failed due to an issue not related to this code.  Can it be ran again somehow?

Close, then reopen the PR, it should trigger a new build

Will do.  Thanks again @emontnemery

@JumpMaster You need to open the PR again :)

Hi @emontnemery
I've just added another commit so the checks are completing again now that travis has been removed.

@JumpMaster I think the changes make sense, but since the PR is closed it can't be merged. You need to reopen the PR, and if not possible just create a new PR with the same changes.


Johtaylo/cherry picks 4.4

No issues found in Microsoft.Bot.Builder.dll
No issues found in Microsoft.Bot.Builder.AI.Luis.dll
No issues found in Microsoft.Bot.Builder.AI.QnA.dll
No issues found in Microsoft.Bot.Builder.ApplicationInsights.dll
No issues found in Microsoft.Bot.Builder.Azure.dll
No issues found in Microsoft.Bot.Builder.Dialogs.dll
No issues found in Microsoft.Bot.Builder.TemplateManager.dll
No issues found in Microsoft.Bot.Configuration.dll
No issues found in Microsoft.Bot.Connector.dll
No issues found in Microsoft.Bot.Schema.dll


Timeout on Docker -- ssh_exchange_identification: Connection closed by remote host

Beaker is failing on CentOS 6, running on Docker 1.4.1 from epel-testing. It starts the container, but then is unable to ssh in to it.
Beaker verbose output:
-bash-4.1$ bundle exec rspec spec/acceptance/
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec/helpers/serverspec.rb:43: warning: already initialized constant Module::VALID_OPTIONS_KEYS
/opt/go/agent0/.gems/ruby/2.1.0/gems/specinfra-2.12.1/lib/specinfra/configuration.rb:4: warning: previous definition of VALID_OPTIONS_KEYS was here
Hypervisor for centos6 is docker
Beaker::Hypervisor, found some docker boxes to create
Provisioning docker
provisioning centos6
Creating image
Dockerfile is         FROM chef/centos-6
          RUN yum clean all
          RUN yum install -y sudo openssh-server openssh-clients curl ntpdate
          RUN ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
          RUN ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
        RUN mkdir -p /var/run/sshd
        RUN echo root:root | chpasswd
RUN mkdir -p /root/.ssh
RUN yum -y install tar
        EXPOSE 22
        CMD ["/sbin/init"]
post
/v1.15/build
{:rm=>true}
Dockerfile0000640000000000000000000000064412462207066013315 0ustar00wheelwheel00000000000000        FROM chef/centos-6
          RUN yum clean all
          RUN yum install -y sudo openssh-server openssh-clients curl ntpdate
          RUN ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
          RUN ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
        RUN mkdir -p /var/run/sshd
        RUN echo root:root | chpasswd
RUN mkdir -p /root/.ssh
RUN yum -y install tar
        EXPOSE 22
        CMD ["/sbin/init"]

Creating container from image 99a2b5945d5f
post
/v1.15/containers/create
{}
{"Image":"99a2b5945d5f","Hostname":"centos6"}
Starting container b11e44daf226c7044e4a8220e84bbc530acc1e875fc74a5e38772e4106af32dc
post
/v1.15/containers/b11e44daf226c7044e4a8220e84bbc530acc1e875fc74a5e38772e4106af32dc/start
{}
{"PublishAllPorts":true,"Privileged":true}
get
/v1.15/containers/b11e44daf226c7044e4a8220e84bbc530acc1e875fc74a5e38772e4106af32dc/json
{}

get
/v1.15/containers/b11e44daf226c7044e4a8220e84bbc530acc1e875fc74a5e38772e4106af32dc/json
{}

node available as  ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no<EMAIL_ADDRESS>-p 49155

centos6 16:28:38$ rpm -q curl
Warning: Try 1 -- Host <IP_ADDRESS> unreachable: connection closed by remote host
Warning: Trying again in 1 seconds
Warning: Try 2 -- Host <IP_ADDRESS> unreachable: connection closed by remote host
Warning: Trying again in 1 seconds
Warning: Try 3 -- Host <IP_ADDRESS> unreachable: connection closed by remote host
Warning: Trying again in 2 seconds
Warning: Try 4 -- Host <IP_ADDRESS> unreachable: connection closed by remote host
Warning: Trying again in 3 seconds
Warning: Try 5 -- Host <IP_ADDRESS> unreachable: connection closed by remote host
Warning: Trying again in 5 seconds
Warning: Try 6 -- Host <IP_ADDRESS> unreachable: connection closed by remote host
Warning: Trying again in 8 seconds
Warning: Try 7 -- Host <IP_ADDRESS> unreachable: connection closed by remote host
Warning: Trying again in 13 seconds
Warning: Try 8 -- Host <IP_ADDRESS> unreachable: connection closed by remote host
Warning: Trying again in 21 seconds
Warning: Try 9 -- Host <IP_ADDRESS> unreachable: connection closed by remote host
Warning: Trying again in 34 seconds
Warning: Try 10 -- Host <IP_ADDRESS> unreachable: connection closed by remote host
Warning: Trying again in 55 seconds
Warning: Try 11 -- Host <IP_ADDRESS> unreachable: connection closed by remote host
Warning: Trying again in 89 seconds
Failed to connect to <IP_ADDRESS>
Failed: errored in validate
#<Net::SSH::Disconnect: connection closed by remote host>
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:50
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:46
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:45
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:45
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:43
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:43
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:32
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/session.rb:84
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/session.rb:84
/opt/rubies/ruby-2.1.3/lib/ruby/2.1.0/timeout.rb:76
/opt/rubies/ruby-2.1.3/lib/ruby/2.1.0/timeout.rb:127
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/session.rb:84
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh.rb:207
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh.rb:207
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/ssh_connection.rb:42
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/ssh_connection.rb:33
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host.rb:242
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host.rb:270
/opt/rubies/ruby-2.1.3/lib/ruby/2.1.0/benchmark.rb:294
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host.rb:269
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host/unix/pkg.rb:28
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host_prebuilt_steps.rb:108
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host_prebuilt_steps.rb:107
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host_prebuilt_steps.rb:107
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host_prebuilt_steps.rb:95
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/shared/host_manager.rb:74
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/shared/host_manager.rb:71
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/shared/host_manager.rb:70
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/shared/host_manager.rb:70
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/dsl/patterns.rb:32
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host_prebuilt_steps.rb:84
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/hypervisor.rb:117
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/network_manager.rb:61
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/network_manager.rb:60
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/network_manager.rb:60
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec/beaker_shim.rb:36
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec/spec_helper.rb:43
/opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core.rb:81
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec/spec_helper.rb:5
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec.rb:5
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec.rb:5
/opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec.rb:1
/opt/go/agent0/.gems/ruby/2.1.0/bundler/gems/gamesys_puppet_spec_helper-56066fb0e638/lib/gamesys_puppet_spec_helper/spec_helper_acceptance.rb:1
/opt/go/agent0/.gems/ruby/2.1.0/bundler/gems/gamesys_puppet_spec_helper-56066fb0e638/lib/gamesys_puppet_spec_helper/spec_helper_acceptance.rb:1
/opt/go/agent0/go-agent/pipelines/remote_file/remote_file/spec/spec_helper_acceptance.rb:2
/opt/go/agent0/go-agent/pipelines/remote_file/remote_file/spec/spec_helper_acceptance.rb:2
/opt/go/agent0/go-agent/pipelines/remote_file/remote_file/spec/acceptance/init_spec.rb:1
/opt/go/agent0/go-agent/pipelines/remote_file/remote_file/spec/acceptance/init_spec.rb:1
/opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105
/opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105
/opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105
/opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105
/opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:96
/opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:84
/opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:69
/opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:37
/opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/exe/rspec:4
/opt/go/agent0/.gems/ruby/2.1.0/bin/rspec:23
/opt/go/agent0/.gems/ruby/2.1.0/bin/rspec:23
/opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:50:in `rescue in block (2 levels) in negotiate!': connection closed by remote host (Net::SSH::Disconnect)
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:46:in `block (2 levels) in negotiate!'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:45:in `loop'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:45:in `block in negotiate!'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:43:in `loop'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:43:in `negotiate!'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/server_version.rb:32:in `initialize'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/session.rb:84:in `new'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/session.rb:84:in `block in initialize'
	from /opt/rubies/ruby-2.1.3/lib/ruby/2.1.0/timeout.rb:76:in `timeout'
	from /opt/rubies/ruby-2.1.3/lib/ruby/2.1.0/timeout.rb:127:in `timeout'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh/transport/session.rb:84:in `initialize'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh.rb:207:in `new'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/net-ssh-2.9.2/lib/net/ssh.rb:207:in `start'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/ssh_connection.rb:42:in `connect'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/ssh_connection.rb:33:in `connect'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host.rb:242:in `connection'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host.rb:270:in `block in exec'
	from /opt/rubies/ruby-2.1.3/lib/ruby/2.1.0/benchmark.rb:294:in `realtime'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host.rb:269:in `exec'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host/unix/pkg.rb:28:in `check_for_package'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host_prebuilt_steps.rb:108:in `block in check_and_install_packages_if_needed'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host_prebuilt_steps.rb:107:in `each'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host_prebuilt_steps.rb:107:in `check_and_install_packages_if_needed'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host_prebuilt_steps.rb:95:in `block in validate_host'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/shared/host_manager.rb:74:in `run_block_on'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/shared/host_manager.rb:71:in `block in run_block_on'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/shared/host_manager.rb:70:in `map'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/shared/host_manager.rb:70:in `run_block_on'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/dsl/patterns.rb:32:in `block_on'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/host_prebuilt_steps.rb:84:in `validate_host'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/hypervisor.rb:117:in `validate'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/network_manager.rb:61:in `block in validate'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/network_manager.rb:60:in `each_key'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-2.0.0/lib/beaker/network_manager.rb:60:in `validate'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec/beaker_shim.rb:36:in `validate'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec/spec_helper.rb:43:in `block in <top (required)>'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core.rb:81:in `configure'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec/spec_helper.rb:5:in `<top (required)>'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec.rb:5:in `require'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec.rb:5:in `<module:BeakerRSpec>'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/beaker-rspec-5.0.1/lib/beaker-rspec.rb:1:in `<top (required)>'
	from /opt/go/agent0/.gems/ruby/2.1.0/bundler/gems/gamesys_puppet_spec_helper-56066fb0e638/lib/gamesys_puppet_spec_helper/spec_helper_acceptance.rb:1:in `require'
	from /opt/go/agent0/.gems/ruby/2.1.0/bundler/gems/gamesys_puppet_spec_helper-56066fb0e638/lib/gamesys_puppet_spec_helper/spec_helper_acceptance.rb:1:in `<top (required)>'
	from /opt/go/agent0/go-agent/pipelines/remote_file/remote_file/spec/spec_helper_acceptance.rb:2:in `require'
	from /opt/go/agent0/go-agent/pipelines/remote_file/remote_file/spec/spec_helper_acceptance.rb:2:in `<top (required)>'
	from /opt/go/agent0/go-agent/pipelines/remote_file/remote_file/spec/acceptance/init_spec.rb:1:in `require'
	from /opt/go/agent0/go-agent/pipelines/remote_file/remote_file/spec/acceptance/init_spec.rb:1:in `<top (required)>'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105:in `load'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105:in `block in load_spec_files'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105:in `each'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105:in `load_spec_files'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:96:in `setup'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:84:in `run'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:69:in `run'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:37:in `invoke'
	from /opt/go/agent0/.gems/ruby/2.1.0/gems/rspec-core-3.1.7/exe/rspec:4:in `<top (required)>'
	from /opt/go/agent0/.gems/ruby/2.1.0/bin/rspec:23:in `load'
	from /opt/go/agent0/.gems/ruby/2.1.0/bin/rspec:23:in `<main>'

I tried the SSH command manually on the host and got this:
-bash-4.1$ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no<EMAIL_ADDRESS>-p 49155
ssh_exchange_identification: Connection closed by remote host

This is my nodeset file:
---
HOSTS:
  centos6:
    roles:
    - master
    platform: el-6-x86_64
    image: chef/centos-6
    hypervisor: docker
    docker_image_commands:
    - 'mkdir -p /root/.ssh'
    - 'yum -y install tar'
    docker_cmd: '["/sbin/init"]'
    docker_preserve_image: false
CONFIG:
  type: foss
  log_level: debug

Since you do a mkdir of the .ssh dir it could fail on incorrect rights on the .ssh dir.
if you use beaker 2.2.0 it should be solved in there and you can remove the mkdir command as well.

I'm experiencing the same issue on a CentOS-6 host.. but on a CentOS-7 host, with the exact same SUT yaml configs, the docker runs work perfectly fine. I'm pretty sure Beaker/Docker ran fine on Centos6 until fairly recently, but I've not run the tests since upgrading to 2.2.0
Interestingly, if I remove docker_cmd completely, it defaults to /usr/sbin/ssh -D, and it connects okay until Beaker attempts a service sshd restart, at which point the daemon disconnects and the test fails.
I also assumed it would be caused by the mkdir /root/.ssh I'd put in place to address that missing, but it also fails without that image command being present
It fails on docker-io-1.3.2-2.el6.x86_64 from epel, as well as docker-io-1.4.1-3.el6.x86_64 from epel-testing
nodeset:
---
HOSTS:
  centos6:
    roles:
      - master
    platform: el-6-x86_64
    image: centos:centos6
    hypervisor: docker
    docker_cmd: '["/sbin/init"]'
    docker_image_commands:
      - 'yum install -y tar gcc ruby-devel git'

CONFIG:
  type: foss
  log_level: verbose
  forward_ssh_agent: true

Same here. With /sbin/init as the docker_cmd it times out same as before. Without it, the connection is lost when sshd restarts.
-bash-4.1$ bundle exec rake beaker
/opt/rubies/ruby-2.1.3/bin/ruby -I/opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/lib:/opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-support-3.1.2/lib /opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/exe/rspec spec/acceptance --color
/opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-rspec-5.0.1/lib/beaker-rspec/helpers/serverspec.rb:43: warning: already initialized constant Module::VALID_OPTIONS_KEYS
/opt/go/agent0/.gem/ruby/2.1.3/gems/specinfra-2.12.1/lib/specinfra/configuration.rb:4: warning: previous definition of VALID_OPTIONS_KEYS was here
Hypervisor for centos6 is docker
Beaker::Hypervisor, found some docker boxes to create
Provisioning docker
provisioning centos6
Creating image
Dockerfile is         FROM chef/centos-6
          RUN yum clean all
          RUN yum install -y sudo openssh-server openssh-clients curl ntpdate
          RUN ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
          RUN ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
        RUN mkdir -p /var/run/sshd
        RUN echo root:root | chpasswd
RUN yum -y install tar
        EXPOSE 22
        CMD /usr/sbin/sshd -D
post
/v1.15/build
{:rm=>true}
Dockerfile0000640000000000000000000000062012462403236013304 0ustar00wheelwheel00000000000000        FROM chef/centos-6
          RUN yum clean all
          RUN yum install -y sudo openssh-server openssh-clients curl ntpdate
          RUN ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
          RUN ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
        RUN mkdir -p /var/run/sshd
        RUN echo root:root | chpasswd
RUN yum -y install tar
        EXPOSE 22
        CMD /usr/sbin/sshd -D

Creating container from image df99d6c15b5c
post
/v1.15/containers/create
{}
{"Image":"df99d6c15b5c","Hostname":"centos6"}
Starting container 3f6916ee03df033848d784e2a101113410a9498a8e9fbe6adf374afcc8841ad7
post
/v1.15/containers/3f6916ee03df033848d784e2a101113410a9498a8e9fbe6adf374afcc8841ad7/start
{}
{"PublishAllPorts":true,"Privileged":true}
get
/v1.15/containers/3f6916ee03df033848d784e2a101113410a9498a8e9fbe6adf374afcc8841ad7/json
{}

get
/v1.15/containers/3f6916ee03df033848d784e2a101113410a9498a8e9fbe6adf374afcc8841ad7/json
{}

node available as  ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no<EMAIL_ADDRESS>-p 49159

centos6 10:08:41$ rpm -q curl
Warning: Try 1 -- Host <IP_ADDRESS> unreachable: connection closed by remote host
Warning: Trying again in 1 seconds
Created ssh connection to <IP_ADDRESS>, user: root, opts: {:password=>"root", :port=>"49159", :forward_agent=>false, :user=>"root"}
curl-7.19.7-40.el6_6.3.x86_64

centos6 executed in 1.22 seconds

centos6 10:08:42$ rpm -q ntpdate
ntpdate-4.2.6p5-2.el6.centos.x86_64

centos6 executed in 0.03 seconds

centos6 10:08:43$ echo "/usr/bin"
/usr/bin

centos6 executed in 0.01 seconds

centos6 10:08:43$ echo "/opt/puppet-git-repos/hiera/bin"
/opt/puppet-git-repos/hiera/bin

centos6 executed in 0.01 seconds

centos6 10:08:43$ echo "/opt/puppet-git-repos/hiera/lib"
/opt/puppet-git-repos/hiera/lib

centos6 executed in 0.01 seconds

centos6 10:08:43$ echo "/opt/puppet-git-repos/hiera-puppet/lib"
/opt/puppet-git-repos/hiera-puppet/lib

centos6 executed in 0.01 seconds
setting local environment on centos6

centos6 10:08:43$ echo '
PermitUserEnvironment yes' >> /etc/ssh/sshd_config

centos6 executed in 0.01 seconds

centos6 10:08:43$ /sbin/service sshd restart
Stopping sshd: /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/ruby_compat.rb:30:in `select': closed stream (IOError)
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/ruby_compat.rb:30:in `io_select'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/transport/packet_stream.rb:75:in `available_for_read?'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/transport/packet_stream.rb:87:in `next_packet'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/transport/session.rb:183:in `block in poll_message'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/transport/session.rb:178:in `loop'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/transport/session.rb:178:in `poll_message'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:461:in `dispatch_incoming_packets'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:222:in `preprocess'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:206:in `process'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:170:in `block in loop'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:170:in `loop'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:170:in `loop'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/ssh_connection.rb:96:in `try_to_execute'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/ssh_connection.rb:107:in `execute'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/host.rb:271:in `block in exec'
	from /opt/rubies/ruby-2.1.3/lib/ruby/2.1.0/benchmark.rb:294:in `realtime'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/host.rb:270:in `exec'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/host_prebuilt_steps.rb:489:in `block in set_env'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/shared/host_manager.rb:74:in `run_block_on'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/shared/host_manager.rb:71:in `block in run_block_on'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/shared/host_manager.rb:70:in `map'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/shared/host_manager.rb:70:in `run_block_on'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/dsl/patterns.rb:32:in `block_on'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/host_prebuilt_steps.rb:471:in `set_env'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/hypervisor.rb:111:in `configure'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/network_manager.rb:71:in `block in configure'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/network_manager.rb:70:in `each_key'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-2.2.0/lib/beaker/network_manager.rb:70:in `configure'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-rspec-5.0.1/lib/beaker-rspec/beaker_shim.rb:43:in `configure'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-rspec-5.0.1/lib/beaker-rspec/spec_helper.rb:44:in `block in <top (required)>'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/lib/rspec/core.rb:81:in `configure'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-rspec-5.0.1/lib/beaker-rspec/spec_helper.rb:5:in `<top (required)>'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-rspec-5.0.1/lib/beaker-rspec.rb:5:in `require'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-rspec-5.0.1/lib/beaker-rspec.rb:5:in `<module:BeakerRSpec>'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/beaker-rspec-5.0.1/lib/beaker-rspec.rb:1:in `<top (required)>'
	from /opt/go/agent0/.gem/ruby/2.1.3/bundler/gems/gamesys_puppet_spec_helper-ddcaf8a93a98/lib/gamesys_puppet_spec_helper/spec_helper_acceptance.rb:1:in `require'
	from /opt/go/agent0/.gem/ruby/2.1.3/bundler/gems/gamesys_puppet_spec_helper-ddcaf8a93a98/lib/gamesys_puppet_spec_helper/spec_helper_acceptance.rb:1:in `<top (required)>'
	from /opt/go/agent0/go-agent/pipelines/remote_file/remote_file/spec/spec_helper_acceptance.rb:2:in `require'
	from /opt/go/agent0/go-agent/pipelines/remote_file/remote_file/spec/spec_helper_acceptance.rb:2:in `<top (required)>'
	from /opt/go/agent0/go-agent/pipelines/remote_file/remote_file/spec/acceptance/init_spec.rb:1:in `require'
	from /opt/go/agent0/go-agent/pipelines/remote_file/remote_file/spec/acceptance/init_spec.rb:1:in `<top (required)>'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105:in `load'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105:in `block in load_spec_files'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105:in `each'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105:in `load_spec_files'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:96:in `setup'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:84:in `run'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:69:in `run'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:37:in `invoke'
	from /opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/exe/rspec:4:in `<main>'
/opt/rubies/ruby-2.1.3/bin/ruby -I/opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/lib:/opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-support-3.1.2/lib /opt/go/agent0/.gem/ruby/2.1.3/gems/rspec-core-3.1.7/exe/rspec spec/acceptance --color failed

Could you do a quick test with docker image electrical/centos:6.4-1 instead of the one you are using now?
Just to check if the docker image is misbehaving.

Same behaviour -- timeout with docker_cmd: '["/sbin/init"]', disconnection upon sshd restart without it.
Anything else can provide?

Very weird. because i do the same and has always been working fine for me.
https://github.com/elasticsearch/puppet-elasticsearch/blob/master/spec/acceptance/nodesets/centos-6-x64.yml

One major difference I've noticed, is that this only fails on a centos 6.6 host for me (with docker installed via EPEL), the exact same nodeset works fine on a centos 7 (with docker installed via the standard centos 7 repos)  - I've not tested on any other operating systems though.

I'm running Docker 1.4.1 installed from epel-testing on a CentOS 6.6 host. Can't test it on CentOS 7 as we run stuff on xen and no one has been able to make that combination work yet around here. :)

I'm running on a Ubuntu 14.04 host with docker 1.4.1

How can I investigate this issue further? I'm at a complete loss here...

Must admit its very confusing. Could you try out my exact node config? wonder if that works. it it doesn't i'm fairly out of idea's.

Same results...

It looks as though sshd is not being started in the container when run on a centos6 host; when I attach to a running container that Beaker's created with docker_cmd: '["/sbin/init"]', I don't seem to see a running ssh daemon, as far as I can tell:
-bash-4.1$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS                   NAMES
fc4f926000d0        0364c8063090        "/sbin/init"        About a minute ago   Up About a minute   <IP_ADDRESS>:49153->22/tcp   nostalgic_lalande
-bash-4.1$ docker exec -i -t fc4f926000d0 bash
[root@centos6 /]# ps auxff
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root        85  0.0  0.0  14724  1804 ?        S    17:48   0:00 bash
root        99  0.0  0.0  16624  1044 ?        R+   17:48   0:00  \_ ps auxff
root         1  0.0  0.0  17128  1244 ?        Ss   17:46   0:00 /sbin/init
root        11  0.0  0.0  14860  1908 ?        Ss   17:46   0:00 /bin/bash /etc/rc.d/rc.sysinit
root        28  0.0  0.0  14972  1904 ?        S    17:46   0:00  \_ /bin/bash /sbin/start_udev
root        66  0.2  0.0   8416   720 ?        S    17:46   0:00      \_ /sbin/udevadm settle
root        60  0.0  0.0  10640   492 ?        S<s  17:46   0:00 /sbin/udevd -d

By contrast, on the centos7 host, when I attach to the container from the same nodeset YAML:
[root@ip-172-31-12-185 ~]# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                   NAMES
65bca78c5cc6        a1a7ac8946dc        "/sbin/init"        4 seconds ago       Up 3 seconds        <IP_ADDRESS>:49590->22/tcp   jovial_mestorf
91515fc1153f        a1a7ac8946dc        "/sbin/init"        28 hours ago        Up 28 hours         <IP_ADDRESS>:49185->22/tcp   romantic_wilson
[root@ip-172-31-12-185 ~]# docker exec -i -t 65bca78c5cc6 bash
[root@centos6 /]# ps auxff
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       679  0.4  0.0 108348  1680 pts/2    S    18:33   0:00 bash
root       799  0.0  0.0 110200  1056 pts/2    R+   18:33   0:00  \_ ps auxff
root         1  0.1  0.0  19284  1500 ?        Ss   18:33   0:00 /sbin/init
root        67  0.4  0.0  10824   908 ?        S<s  18:33   0:00 /sbin/udevd -d
root       474  0.0  0.0   4132   652 ?        Ss   18:33   0:00 /sbin/agetty /dev/ttyS0 115200 vt100-nav
root       476  0.0  0.0   4116   596 tty1     Ss+  18:33   0:00 /sbin/mingetty /dev/tty1
root       478  0.0  0.0   4116   596 tty2     Ss+  18:33   0:00 /sbin/mingetty /dev/tty2
root       480  0.0  0.0   4116   596 tty3     Ss+  18:33   0:00 /sbin/mingetty /dev/tty3
root       482  0.0  0.0   4116   596 tty4     Ss+  18:33   0:00 /sbin/mingetty /dev/tty4
root       484  0.0  0.0   4116   592 tty5     Ss+  18:33   0:00 /sbin/mingetty /dev/tty5
root       486  0.0  0.0   4116   592 tty6     Ss+  18:33   0:00 /sbin/mingetty /dev/tty6
root       516  0.0  0.0  66740  1176 ?        Ss   18:33   0:00 /usr/sbin/sshd
root       533  0.5  0.0  96516  4476 ?        Ss   18:33   0:00  \_ sshd: root@notty
root       724 16.3  0.2<PHONE_NUMBER>4 ?        Ssl  18:33   0:00      \_ /usr/bin/ruby /usr/bin/puppet apply --verbose --detailed-exitcodes /tmp/apply_manifest.pp.7kNnS6
[root@centos6 /]#

So, it appears that sshd is not starting correctly when run on a centos6 host, afaict ..
exactly why that's happening, is beyond me, I'm afraid..

Very weird.. could it be a kernel issue? which kernel is it on centos 6 and 7 ?

I suspect that it could be the kernel - there are mentions of issues with 2.6.x kernels in the docker github issue tracker - but afaict, they're all either closed or resolved .. so unless it's a very recent development, it's possible that not many others are experiencing the same issue. In addition to this, I'm not sure whether this is specific to Beaker (or the docker-api gem) or whether it's a general issue with docker on centos6 (due to limitations with the 2.6.x kernels)
What's very confusing is that I could have sworn it was working on centos6 previously, I'm just not sure when it stopped working. I'm going to try with an earlier version of Beaker at some point, but I won't be able to get to this in a while... @cassianoleal - is that something you could try: earlier releases of Beaker, as well as the docker-api gem?

-bash-4.1$ uname -a
Linux puppetci-agent0 2.6.32-504.8.1.el6.x86_64 #1 SMP Wed Jan 28 21:11:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

AFAIK all Docker incompatibilities have been solved on this kernel (it's the latest on CentOS 6).
I'll try to downgrade the gems as @madAndroid suggested and see what happens.
For the record, I spawned a container using the Dockerfile that Beaker generates, then attached to it and sshd is definitely running:
-bash-4.1$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
ed4c51ff27c0        dfb7dc321cea        "/sbin/init"        4 seconds ago       Up 3 seconds        22/tcp              determined_archimedes
-bash-4.1$ cat Dockerfile
        FROM electrical/centos:6.4
          RUN yum clean all
          RUN yum install -y sudo openssh-server openssh-clients curl ntpdate
          RUN ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
          RUN ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
        RUN mkdir -p /var/run/sshd
        RUN echo root:root | chpasswd
RUN yum install -y wget ntpdate rubygems ruby-augeas ruby-devel augeas-devel
RUN touch /etc/sysconfig/network
        EXPOSE 22
        CMD ["/sbin/init"]
-bash-4.1$ docker exec -i -t ed4 /bin/bash
bash-4.1# ps auxff
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       460  0.2  0.0  11304  1556 ?        S    08:20   0:00 /bin/bash
root       468  0.0  0.0  13368  1000 ?        R+   08:20   0:00  \_ ps auxff
root         1  0.0  0.0  19232  1536 ?        Ss   08:03   0:00 /sbin/init
root        78  0.0  0.0  10640   624 ?        Ss   08:03   0:00 /sbin/udevd -d
root       242  0.0  0.0  66688  1228 ?        Ss   08:03   0:00 /usr/sbin/sshd
root       467  0.0  0.0   4060   672 ?        Ss   08:20   0:00 /sbin/mingetty /dev/tty[1-6]

Tried it with Beaker 1.20.1 and hit the same timeout.
While Beaker was trying to SSH into the container, I attached to it to run ps and noticed that sshd was indeed not running, so I started it:
bash-4.1# service sshd start
Generating SSH1 RSA host key:                              [  OK  ]
Starting sshd:                                             [  OK  ]

And then Beaker was able to connect, but what called my attention was the first line where it says it's generating the RSA host key. From what I can tell, that's done as part of the image building process, right?

I've also tried it with docker-api 1.15.0 and saw the same results: no sshd running...

Most likely because the older dockerapi gems have an API miss match with the docker api it self?

How does that explain that I have the same results with 1.15.0 and 1.17.0 (which is the latest)?

ah sorry. i miss understood your findings.

Must admit from my side i never ran on 2.6.x kernels for docker.. always been on 3.x  ( currently on 3.13.x )

This PR https://github.com/puppetlabs/beaker/pull/626 solves my issue.

That does seem like the cleanest option, glad to hear you've made some
progress :)
On Mon, Feb 2, 2015 at 4:30 PM, cassiano<EMAIL_ADDRESS>wrote:

This PR #626 https://github.com/puppetlabs/beaker/pull/626 solves my
issue.
—
Reply to this email directly or view it on GitHub
https://github.com/puppetlabs/beaker/issues/652#issuecomment-72465936.

I'll close this out when the PR626 gets merged.

PR merged, closing.


add self link for record items (#922)

Overview
Adds rel=self links on .../items responses.
Related Issue / Discussion
#922
Additional Information
None
Contributions and Licensing
(as per https://github.com/geopython/pycsw/blob/master/CONTRIBUTING.rst#contributions-and-licensing)

[x] I'd like to contribute [feature X|bugfix Y|docs|something else] to pycsw. I confirm that my contributions to pycsw will be compatible with the pycsw license guidelines at the time of contribution.
[x] I have already previously agreed to the pycsw Contributions and Licensing Guidelines

Thanx Tom!


UICollection.[] getter method should throw when index is invalid

Describe the bug

The first line  var ch0 = grid.Children[10]; should also throw ArgumentOutOfRangeException
Current implementation just returns null, which is very misleading

This isn't specific to Project Reunion, please move this issue to https://github.com/microsoft/microsoft-ui-xaml.

Someone at Microsoft, please tell me - is @Jaiganeshkumaran working for you? Or is he just "trying to be helpful"?


add rpc interface to call wecross

Codecov Report

:exclamation: No coverage uploaded for pull request base (dev@e24e890). Click here to learn what that means.
The diff coverage is 35.37%.

@@          Coverage Diff           @@
##             dev       #2   +/-   ##
======================================
  Coverage       ?   35.33%
  Complexity     ?       22
======================================
  Files          ?        8
  Lines          ?      150
  Branches       ?        8
======================================
  Hits           ?       53
  Misses         ?       94
  Partials       ?        3

Impacted Files
Coverage Δ
Complexity Δ

...com/webank/wecrosssdk/methods/WeCrossCallback.java
0% <0%> (ø)
0 <0> (?)

...ain/java/com/webank/wecrosssdk/rpc/WeCrossRpc.java
100% <100%> (ø)
1 <1> (?)

...n/java/com/webank/wecrosssdk/methods/Response.java
26.66% <26.66%> (ø)
2 <2> (?)

.../com/webank/wecrosssdk/methods/WeCrossRpcRest.java
28.57% <28.57%> (ø)
2 <2> (?)

...rc/main/java/com/webank/wecrosssdk/utils/Path.java
33.33% <33.33%> (ø)
1 <1> (?)

...c/main/java/com/webank/wecrosssdk/rpc/Service.java
44.44% <44.44%> (ø)
5 <5> (?)

...in/java/com/webank/wecrosssdk/methods/Request.java
47.36% <47.36%> (ø)
10 <10> (?)

Continue to review full report at Codecov.

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


Add a build script for publication and use a plain DocC bundle

Adds a separate script that generates a version of the book suitable for publishing on swift.org (with the non-staging header).
This conditionalizes which header.html is used.
This PR also moves away from using the package plugin to generate the book and instead uses plain DocC commands. This simplifies the file structure of the repo.

We'll need to change the swift-ci config after this change:
swift package plugin generate-documentation --target TSPL --transform-for-static-hosting

…to:
docc convert --experimental-enable-custom-templates --hosting-base-path swift-book --output-path "./swift-book" TSPL.docc


I there a way to selectively add flags when linking executables?

Is there a way to selectively add flags when linking test executables?
I am trying to add -Wl,-E,--whole-archive libcrypto.a -Wl,--no-whole-archive to tests that use engines, but there is no obvious way either in code or docs. You may see #17509 for context.
Thanks for your time, if you are reading this )

No, we only support selectiveness in term of type of output (i.e. you can select optional flags on the basis of shared objects, themselves being divided in shared libraries to link with and dynamically loadable modules, executables and static libraries), but not on individual output.  The idea was that build.info files should be platform independent, and compiler flags aren't that at all.
It wouldn't be impossible to add language to support that sort of thing, but for the thing you ask, this isn't a small job...

For reference, a patch in #17509 allows to pass simple flags like -Wl,-E which don't depend on the order. /Configure uses hash to process data and reorders tokens in DEPEND and all the other fields.


Some typos in the preface

"reproductive" https://github.com/betanalpha/quarto_chapters/blob/6b89fa9267d8aff661824081a86b763691ff3d8b/preface/preface.tex#L255
"limitations measurements" https://github.com/betanalpha/quarto_chapters/blob/6b89fa9267d8aff661824081a86b763691ff3d8b/preface/preface.tex#L326
"we need be proficient" https://github.com/betanalpha/quarto_chapters/blob/6b89fa9267d8aff661824081a86b763691ff3d8b/preface/preface.tex#L404
"although that that" https://github.com/betanalpha/quarto_chapters/blob/6b89fa9267d8aff661824081a86b763691ff3d8b/preface/preface.tex#L847
"assumptions inherit to" https://github.com/betanalpha/quarto_chapters/blob/6b89fa9267d8aff661824081a86b763691ff3d8b/preface/preface.tex#L864

Thanks!  All resolved in 278c6ce1ed0d5e27504084fdfe2932f254301955.


Crash on creating new world

crash-2023-03-11_13.55.40-server.txt

I need to update the Fiuidlogged API.
Until then you can use v<IP_ADDRESS>

Fixed in v3.1

Still happens in 3.1 with latest Fluidlogged API.
crash-2023-03-12_14.29.53-server.txt

Interesting. Try to delete the config file for Greenery. It looks like there is error in parsing it.

Deleted configs, still get the same crash.

Can you send the full latest.log?

@Lach01298
I still can not reproduce this.
Can you send the full latest log and, if possible, the debug log too, and also the config file?

Oh okay, now I know what’s causing it. Biome configured in the config doesn’t exist.

Hey! I have the same problem here.
crash-2023-03-13_21.41.30-server.txt

For now you can fix the issue by removing the biomesoplenty:pasture biome from the barley’s world gen config.

It works. Thank u for your help!


Rename new list of bits field to aggregation_bits_list

EIP-7549 changes the bits type inside the attestation from a Bitlist to a List[Bitlist]. To make the change more clear, we should rename aggregation_bits to aggregation_bits_list. Then in internal routines, variables with name aggregation_bits are Bitlist types.
h/t to @hwwhww for the suggestion

closing in favor of #3631


Add test: If I give None to application metadata on update, does it make it None?

Documentation clarified - giving None does nothing in this client, and is a bad request in the server.


 Tokens are stored in the session and are refreshed upon expiration. Basic tests are implemented. Request for feedback on the CodeClimate issues.
Description
Currently, Bookstack support both LDAP and SAML 2.0 for SSO. This pull request intends to extend support to OpenID Connect providers as well. It's built on top of steverhoades' OpenID Connect provider. This pull request intends to supports only Authorization Code flow and the Refresh Token flow from OAuth2, given the nature of Bookstack. The additional code mimics the structure of the existing SAML implementation, to heighten code maintainability.
Benefits
Given that some systems solely support OpenID Connect, this would extend the support SSO solutions. Although this number is quite small at this point in time, the number is non-zero. Moreover, the reduced complexity compared to SAML suggests a possible shift in the future.
Risks
Although all extra code adds some technical debt by nature, the code is based on the already existing SAML integration. Therefore, the additional technical debt should be fairly limited. Moreover, additional dependencies are created. Currently, the code is built on top of steverhoades/oauth2-openid-connect-client. This seemed to be the most efficient approach. Alternatively, the code could potentially be migrated to be built on top of the jumbojett/OpenID-Connect-PHP library.

Hi @jasperweyne, Mainly responding to your discord message.
Thank you very much for offering this. In terms of code it looks like a good start, nice and clean & aligns nicely with the SAML setup. The oauth2-openid-connect-client library is a bit of a concern, just since it has fairly low usage and we'be be somewhat reliant on it.
Overall though, I'm just worried that the efforts are worth the benefits at this stage. Looking at this risk you've stated:

Although all extra code adds some technical debt by nature, the code is based on the already existing SAML integration. Therefore, the additional technical debt should be fairly limited.

I agree that the technical debt should be fairly limited, but I'm more worried about the social/support dept. From my experience of the current authentication options they require a fair amount of attention and they have induced a big hit on the time I've been able to devote to actually making the core platform better, which has really make me jaded in regards to supporting more authentication options. Especially so since it's not long since SAML2 was added and we're still ironing out the bugs or understanding the options needed there.
For getting an idea of support, There are two issues we can look to:

#1157
#1390

There is some support shown there but nothing particularly major. There's also some cloudiness in regards to if people needed OIDC or a generic oAuth solution. I'm not too sure on the technical differences between them. Additionally, both of those issues are older than our SAML2 implementation and some of the platforms mentioned in those issues could now be achieved via SAML2 instead.

Hi @ssddanbrown, thanks for your response!
First, regarding the choice of library, the reason I chose this library was because of its simplicity, combined with the 2 very well-maintained libraries it's based upon, which do most of the work. An alternative would be jumbojett/openid-connect-php, and although this one has been used more often compared to oauth2-openid-connect-client, it pales in comparison to the underlying libraries. A third alternative would be to use yiisoft/yii2-authclient. However, this library is built upon the Yii framework. This would add a lot of unnecessary code from the Yii framework, and it was not immediately clear how well it would integrate with the existing code. Other libraries I've found on Packagist containing OpenID in their names or descriptions often would support OpenID 2.0, which is outdated and incompatible with OpenID Connect. If a change to one of these (or another) library would be desirable, please let me know and I will change the code accordingly.
I'd also like to expantiate upon OIDC vs. OAuth2. OIDC is an authentication protocol, providing user identity to a client. In comparison, OAuth2 is an authorization protocol, providing access permission to a client. For example, OAuth2 can be used for social login, where only a proof of access is returned, without the identity details of the user. However, without additions to the protocol, user details such as a username and email are not provided by OAuth2. Therefore, SSO is not possible by sole use of OAuth2. OpenID Connect intends to solve this in a secure way. This illustration further indicates this difference.
Now, I'd like to respond to your concerns regarding support debt. Without a doubt, I agree that any unnecessary integrations should be avoided. However, I'd personally argue that OpenID Connect would be a valuable addition, next to SAML2. The reason I started on this PR is a simple necessity from my end, since the systems I'm using don't support a SAML2 flow. The SAML2 protocol is for all intents and purposes simply a more complex and therefore more costly protocol compared to OIDC. Since SAML2 has been standardized in November 2003 compared to November 2014 for OIDC, it has been around for a longer time, which of course means that a large share of identity systems are currently covered by SAML2. However, given its complexity and lack of support for other authorization flows compared to OIDC, I personally feel like it could be a valuable addition to BookStack for the future.
Regarding the additional costs in terms of development time, I agree this is a serious issue that shouldn't be overlooked. My take on this is that this can be kept to a minimum when the implementation structure closely follows the structure of both LDAP and SAML. This can be aided further by placing restrictions on what parts of the OIDC protocol are supported, namely by restricting it to the OpenID Connect Core specification. This way, other OIDC specifications are left out (for example single logout or dynamic client registration options), which removes a large burden in terms of development time while leaving out a minimal amount of functionality.
I personally feel that benefits from OpenID Connect support would outweigh the costs. However, this choice is of course up to you. If you feel differently, I will close the pull request and maintain the fork.

Hi all,
We have taken an interest in BookStack as a project and are looking into ways to achieve a SSO with our own Identity Provider. As such I've read through the discussion here and the referenced tickets. Having experience architecting and implementing an OAuth2, OIDC and SAML2 from an Identity Provider side and Service Provider side for the large and some small vendors, I wanted to share some thoughts here as this seems the most concrete discussion.
OAuth2 vs OIDC
@jasperweyne Is extremely correct in his explanation of OAuth2 vs OIDC. So you can trust the distinction as explained by him. However I would add that a generic OAuth2 implementation (which the OIDC implementation could be based on) could be made, but it requires an potentially extra user interaction step after logging in when a user is new/unknown to the BookStack app where the user needs to provide user details. Since OAuth2 is a step down/simpler than OIDC it will offer broader support, but lack the features from the core OIDC spec and its robust additions.
Whether adopting OIDC is a good idea in the first place should be a non-issue. There are plenty of good Identity Providers that support it and the protocol is, from a SP standpoint, much much simpler than either LDAP or SAML2.
We regularly write client integrations of our own without using any libraries for specific utilities. Recently a junior dev in our team (with exceptionally good knowledge of the OIDC framework) created a drop-in OIDC client for Laravel Nova fully replacing the regular login/logout in about 2 days of work. This included discovery and session management and on the fly user provisioning based on userinfo.
How
But how to support it can still be up for discussion. I did not have time to look at the BookStack implementation of the social logins, but I do see socialite being used. I would suggest working towards a model where any socialite provider may be used together with an interface class to patch the holes for providing user details to BookStack itself. If BookStack then also provides ways to hook into adding frontend scripts that would be perfect (like I said, I did not check this but this might be a non-issue).
From there any generic socialite provider could be usable, together with a smaller wrapper class to communicate the proper userdetails to BookStack. A generic OIDC socialite provider and wrapper class could be shipped with BookStack to make it easy to implement with new providers that don't deviate from the specification or used as a reference to implement more custom providers and/or extra features from OIDC.
I do recommend implementing/using at least discovery and maybe session management, which both might be optional, as those extend the functionality far beyond what other protocols offer and minimise configuration load for users.
Looking forward to the future for this feature, depending on direction we might be able to donate code / time to support it.

Hi, I am interested in OpenID support in BookStack, where is this PR?

I've been attempting to get my head around this today but getting pretty burnt out trying to fully understand OIDC and how the standard relates to functionality in this PR and library used. Giving up now for today but listing some core queries and thoughts.

Within this PR is a OPENID_PUBLIC_KEY option that's passed to the underlying library as a publicKey option. What is this supposed to be or look like? The default value shown in the .env.example is a relative path.

While attempting setup on Okta I could not see anywhere to get this public key file and searching generally around that for OIDC I could rarely find anything relating to a key file.
Where the code is used in the library is a comment relating to <IP_ADDRESS> ID Token validation - Bullet point 6 of the spec to it looks like its involved somehow.
Looking at how GitLab configures OIDC, There's a jwks_uri option which is an endpoint for published keys. Following this led to finding the "Autodiscovery" is a thing. Okta seems to provide this autodiscovery (Example) which includes a keys endpoint.

At a glance, could not see this auto-discovery in use right now in the libs were using, Should this be used and is this common? Is it always in use and hence can we rely on it?
If needed, Looks like okta-jwt-verifier-php does autodiscovery and would be fairly testable since you provide a PSR-7 lib for it to use.

A external_id_attribute config option exists which is used in the service but the method its used in is not called, Instead sub is hardcoded as the id attribute which appears to be correct as per spec. Think we should remove the option unless there's meaningful reason to make configurable.

Email attribute is configurable but not sure it needs to be, Default value is as per spec.

There's a OPENID_URL_RESOURCE env option which is passed to lib as urlResourceOwnerDetails. Not exactly sure what this is yet but assuming it's the UserInfo endpoint as per spec. Need to confirm.

Ideally need to align terminology with that per spec and popular use. GitLab (Docs), Okta (Autodiscover URL response props) and spec are all aligned so there is existing convention.

Within the service is a hardcoded sha256 signer. Looking at the library this might just be used to define the algorithm for verifying the id_token. The spec (7.5 bullet point 4) states "The alg value SHOULD be the default of RS256. It MAY also be ES256." It also states (15.1):

OPs MUST support signing ID Tokens with the RSA SHA-256 algorithm (an alg value of RS256), unless the OP only supports returning ID Tokens from the Token Endpoint (as is the case for the Authorization Code Flow) and only allows Clients to register specifying none as the requested ID Token signing algorithm.

So that might be okay but would need to double check. My Okta test seems to be only providing RS256 at it's keys endpoint.

The library used doesn't appear to have tests itself. Might need to go fairly deep with our tests to be confident.

@ssddanbrown Thank you for taking a look at this!
I'll try to give you some responses on some of your points.
Discovery / OPENID_PUBLIC_KEY option
This is something that can be handled by implementing OIDC Discovery - the Okta docs on this probably aren't wrong, but I would advice looking at the spec too / initially; https://openid.net/specs/openid-connect-discovery-1_0.html
Part one is user discovery, rarely implemented (afaik). Part two is provider metadata / openid-configuration endpoint. It is very recommended to get/cache this document to automagically also get all the provider details needed beyond authority url, client id, client secret. Part two includes getting all the provider public keys from the mentioned jwks_uri. The key to validate with should then be picked from this set based on the key ID in the JWT header claims, next to algorithm used.
Discovery is however not always implemented and a public key is then configured as a variable, but this complicates key rotations and means you likely need to be able to configure other variables as well. I'm not sure the base class used for the implementation provides discovery, but it is fairly easy to add. Just get/cache the .well-known/openid-configuration url. But as you can also see in the flow below, keys might not always be needed.
Other points

Using external_id_attribute I imagine is to be able to select another claim from the ID token JWT to base the unique ID off of - could be interesting if providers are identified that do not use the sub for this.
The userinfo endpoint can be gathered from the openid-configuration as well - though an override similar to the external_id_attribute could be made. But yes, keep the names close to the spec.
The algorithm used can be hinted through the JWT header claims, but only a whitelisted list of algorithms should be usable. Due to differences and forward compatibility I would suggest making this semi-automatic. Allow different modern/safe algos to be used next to RS256.

General possible OIDC flow
Typical client implementation on general OIDC provider;

User want to login with OIDC provider
Retrieve provider openid-configuration (& cache)
Use the metadata from discovery, client id, pkce, correct scopes to construct an auth request & redirect user (probably just an auth code request, can be based on the openid-configuration)
User logs in using the OIDC provider

User comes back (happy path);
5. The OIDC provider gives us a response
6. Retrieve provider openid-configuration (from cache)
7. Use metadata from discovery to determine the token and userinfo endpoint
8. Get an access token using the auth code, client id, client secret and pkce
9. Get the userinfo using the access token from the userinfo endpoint
I chose this as a more typical situation as it follows OAuth2 more closely, implicitly validates the source (by getting the access token & userinfo directly from it), and is probably more generally available/implemented.
In this scenario the keys are not even used/needed because the userinfo is retrieved from the userinfo endpoint. If the oidc provider does not have the userinfo endpoint, the auth request could immediately be for the id token, in which case the keys would be needed to validate the received token. Which flow should be followed can/should be a case of preference but also capabilities reported by the openid-configuration document.

Thanks again @jasperweyne for starting this and thanks @sg3s for all the input. Now merged with changes from #2960 to be part of next release.


Remove joi to shrink module size

As noted in #343 & #292 the specific version of joi is bloating the package size. However upgrading to the latest version would break ES5 compatibility.
This PR shrinks the module size from 3.12M to 0.25M by replacing joi with bespoke implementation using lodash helpers.
N.B. To keep the implementation as simple as possible, these changes mean that the validation error messages are marginally less helpful e.g. -
"expiresIn" must be a number versus "expiresIn" is not the correct type
This should also solve #334.

Changes sound good, as soon as I get a chance I'll update the PR.

So it took a little longer than I expect to get back around to doing this but I think I've made all of the suggested changes.

Thanks for the pointer on ECDSA signing, I've updated the tests to use the other key where appropriate.


Add changelogs.md

This adds the free changelogs.md API, which is a public, free API generated by crawling open source projects, parsing their changelogs, and generating JSON structured metadata about new releases.
Example API response: https://changelogs.md/api/github/driveback/create-react-app/

Thanks!


🐛 BUG: self signed certificate error when using TCP socket API

Which Cloudflare product(s) does this pertain to?
Wrangler
What version of Wrangler are you using?
3.0.1
What operating system are you using?
Mac
Describe the Bug
I am trying to connect to PostgreSQL database using a tutorial in Cloudflare Docs. The database requires SSL. I've tried settings sslmodel to allow and require. Both options throw the following error when calling await Client.connect().
Database is a Crunchy Bridge service (hosted PostgreSQL) by Crunchy Data, more about their SSL is here.
kj/compat/http.c++:6628: error: Error in HttpClientAdapter connect(); kj::cp(ex) = kj/compat/tls.c++:215: failed: TLS peer's certificate is not trusted; reason = self signed certificate in certificate chain
stack: 101231953 101231f87 1012396fc 1021d8db0 1021daa0c 1021c2374 1021c888c 1021bf7a8 10134c088 1021cd6d0
Trace: Error: Connection terminated unexpectedly
    at Connection.<anonymous> (index.js:11355:77)
    at Connection.g (index.js:2891:16)
    at emitNone (index.js:2785:13)
    at Connection.emit2 [as emit] (index.js:2999:11)
    at CloudflareSocket.<anonymous> (index.js:9055:16)
    at emitNone (index.js:2785:13)
    at CloudflareSocket.emit2 [as emit] (index.js:2999:11)
    at index.js:8928:18 {
  stack: Error: Connection terminated unexpectedly
    at C… emit] (index.js:2999:11)
    at index.js:8928:18,
  message: Connection terminated unexpectedly
}
    at logConsoleMessage (/Users/vojtadrbohlav/dev/sl/cf-workers/slideslive-metrics/node_modules/wrangler/wrangler-dist/cli.js:127506:25)
    at WebSocket2.<anonymous> (/Users/vojtadrbohlav/dev/sl/cf-workers/slideslive-metrics/node_modules/wrangler/wrangler-dist/cli.js:127225:13)
    at callListener (/Users/vojtadrbohlav/dev/sl/cf-workers/slideslive-metrics/node_modules/wrangler/wrangler-dist/cli.js:108142:18)
    at WebSocket2.onMessage (/Users/vojtadrbohlav/dev/sl/cf-workers/slideslive-metrics/node_modules/wrangler/wrangler-dist/cli.js:108084:13)
    at WebSocket2.emit (node:events:525:35)
    at Receiver2.receiverOnMessage (/Users/vojtadrbohlav/dev/sl/cf-workers/slideslive-metrics/node_modules/wrangler/wrangler-dist/cli.js:109018:24)
    at Receiver2.emit (node:events:513:28)
    at Receiver2.dataMessage (/Users/vojtadrbohlav/dev/sl/cf-workers/slideslive-metrics/node_modules/wrangler/wrangler-dist/cli.js:107628:18)
    at Receiver2.getData (/Users/vojtadrbohlav/dev/sl/cf-workers/slideslive-metrics/node_modules/wrangler/wrangler-dist/cli.js:107570:21)
    at Receiver2.startLoop (/Users/vojtadrbohlav/dev/sl/cf-workers/slideslive-metrics/node_modules/wrangler/wrangler-dist/cli.js:107347:26)
[mf:inf] GET /v1/library 500 Internal Server Error (399ms)

Similar error is reported in #3264 but it was about fetch on Windows.

I am attempting to connect to AWS RDS (which also uses their own certificate) using the following code. I have tried both specifying rejectUnauthorized: false or setting the ca parameter to the value of the rds-ca-2019-root.pem from Amazon. It seems there is no way to provide the self-signed certificate or ignore untrusted errors.
import { Client } from 'pg';
export async function createPgClient() {
    const config = {
        user: 'postgres',
        password: '<XXX>',
        host: '<XXX>.us-west-2.rds.amazonaws.com',
        port: '5432',
        database: '<XXX>',
        ssl: { rejectUnauthorized: false },
    };
    const client = new Client(config);

    console.log('connecting...');
    await client.connect();
    console.log('connected!');

    return client;
}

Running locally in Wrangler 3.0.1 or using the prerelease mentioned in https://github.com/cloudflare/workers-sdk/pull/3352 both end up with the same error:
[mf:inf] Ready on http://<IP_ADDRESS>:8787/
connecting...
kj/compat/http.c++:6628: error: Error in HttpClientAdapter connect(); kj::cp(ex) = kj/compat/tls.c++:215: failed: TLS peer's certificate is not trusted; reason = self signed certificate in certificate chain
stack: 7ff71f1c8abf 7ff71f20ca2d 0 0 0 0 0 0 0 0
[mf:err] Error: Connection terminated unexpectedly
    at Connection.<anonymous> (xxx/node_modules/.pnpm/pg@8.11.0/node_modules/pg/lib/client.js:132:73)
    at Connection.g (xxx\Temp\tmp-70428-4gZxpDVarVj8/node-modules-polyfills:events:276:16)
    at emitNone (xxx\Temp\tmp-70428-4gZxpDVarVj8/node-modules-polyfills:events:74:13)
    at Connection.emit2 [as emit] (xxx\Temp\tmp-70428-4gZxpDVarVj8/node-modules-polyfills:events:168:7)
    at CloudflareSocket.<anonymous> (xxx/node_modules/.pnpm/pg@8.11.0/node_modules/pg/lib/connection.js:63:12)
    at emitNone (xxx\Temp\tmp-70428-4gZxpDVarVj8/node-modules-polyfills:events:74:13)
    at CloudflareSocket.emit2 [as emit] (xxx\Temp\tmp-70428-4gZxpDVarVj8/node-modules-polyfills:events:168:7)
    at null.<anonymous> (xxx/node_modules/.pnpm/pg-cloudflare@1.1.0/node_modules/pg-cloudflare/src/index.ts:141:14)
[mf:inf] GET / 500  (757ms)

Deploying to Cloudflare yields less information from the real-time logs:
  "exceptions": [
    {
      "name": "Error",
      "message": "proxy request failed",
      "timestamp":<PHONE_NUMBER>692
    }
  ],

I was able to workaround this by setting env variable NODE_EXTRA_CA_CERTS to self-signed root certificate used by the database.
Make sure you are using miniflare >= 3.0.1 which includes fix for loading certificated from env variable (https://github.com/cloudflare/workers-sdk/issues/3264).

This may work in workerd but note that TCP sockets don't support custom CAs in production yet (we are working on it).

There is not

Closing this issue as local mode now has support, and remote support is being tracked internally. 👍

Where can we track support for this? Concerned about not using SSL from a worker to a database in a remote datacenter

We're also experiencing this exact issue trying to connect to an Amazon RDS Postgres database over the internet. Are there any updates?

We're also experiencing this exact issue trying to connect to an Amazon RDS Postgres database over the internet. Are there any updates?

Would recommend hyperdrive, which uses SSL to connect to the database https://developers.cloudflare.com/hyperdrive/configuration/connect-to-postgres/#supported-tls-ssl-modes

We also would like to try Hyperdrive. However, we have a significant number of databases and the current limit of 10 per account does not suffice and binding all these Hyperdrives to Workers become rather unwieldy.