text:
Failed to Complete Chroot Setup.

Please paste the output of the following command here:
useradd: group sudo exists - if you want to add this user to that group, use -g
Failed to complete chroot setup.
Unmounting /mnt/stateful_partition/crouton/chroots/xenial...
Please describe your issue:
Trying to install Ubuntu on my chromebook with Crouton.
Enabled chromebook into developer mode.
Downloaded Crouton & downloaded the latest script.
Opened the terminal & typed shell.
Have tried several desktop environments!
Xfce; Unity; Trusty
After typing in the username: sudo startunity or sudo startxfce4 I get the below error.
Chromebook is an Asus.

If known, describe the steps to reproduce the issue:

@ktea4,
It is expecting a 'username' at that prompt, you instead entered the start script for the xfce4 target.
Try running the following command and see if it will again prompt you for a username:

sudo enter-chroot -n xenial

If that does not prompt you for a username then you may have to run the following:

sudo sh ~/Downloads/crouton -n xenial -u

Enter a unique username and when it's accepted it will prompt you for a password twice, you will NOT see the password you type in, that's normal.
If neither of those commands prompts you for a username you may have to delete the chroot with:

sudo delete-chroot xenial

Then start over.
Hope this helps,
-DennisLfromGA

@DennisLfromGA
Thank you! I typed sudo enter-chroot -n xenial
How do I get the xfce session/ubuntu desktop to pop up? Sorry, I have no knowledge of this kind of stuff. Clearly.

@ktea4,
The 'start*' scripts allow you to launch your desktop(s) directly from outside your crouton chroot in a Chrome OS shell with elevated permissions like this:

sudo startxfce4

From inside the crouton chroot you can launch your desktop but without elevated permissions like this:

startxfce4

Hope this helps,
-DennisLfromGA


text:
Improved bootstrapping

This patch comes up because the directory structure of http.kali.org has changed. There is no directory called stable anymore. It is substituted by kali/. However I think this can be a universal improvement as the implementation of bootstrapping kali we have currently only works for kali, not for other derived distros.
This fix has been part of my effort to add the Trisquel distro and it has been sleeping in my fork for quite a long time now. :P
Fixed according to #1868

I think this makes sense, but needs some style fixes :)

@dnschneid fixed

Staging?

Thanks for fixing this!

source: gharchive/pull-request

authors: dnschneid tonyxue

repo: dnschneid/crouton

license_type: permissive

license_source: github-api


text:
🛑 Site SCAE RGA is down

In 29f040f, Site SCAE RGA (https://www.sca-rga.interieur.gouv.fr/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Site SCAE RGA is back up in 4e1abc9.

source: gharchive/issue

repo: dnum-mi/stats-sites-api

license: MIT


text:
Fix issue where bundle.js expect empty array for include option, instead of null

Problem
If package.include is not defined in the serverless.yml, the following error will be returned:
TypeError: Cannot read property 'length' of undefined
    at GlobAll.globNext (/Users/faizhasim/dev/github/serverless-dynamic-dynamodb/node_modules/glob-all/glob-all.js:84:20)
    at GlobAll.run (/Users/faizhasim/dev/github/serverless-dynamic-dynamodb/node_modules/glob-all/glob-all.js:78:8)
    at Function.globAll.sync (/Users/faizhasim/dev/github/serverless-dynamic-dynamodb/node_modules/glob-all/glob-all.js:192:41)
    at BbPromise (/Users/faizhasim/dev/github/serverless-dynamic-dynamodb/node_modules/serverless-plugin-browserify/lib/bundle.js:32:31)
    at SlsBrowserify.bundle (/Users/faizhasim/dev/github/serverless-dynamic-dynamodb/node_modules/serverless-plugin-browserify/lib/bundle.js:31:12)
    at SlsBrowserify.BbPromise.bind.then.then.then (/Users/faizhasim/dev/github/serverless-dynamic-dynamodb/node_modules/serverless-plugin-browserify/index.js:70:26)
From previous event:
    at browserify:validate (/Users/faizhasim/dev/github/serverless-dynamic-dynamodb/node_modules/serverless-plugin-browserify/index.js:70:10)
    at BbPromise.reduce (/Users/faizhasim/dev/github/serverless-dynamic-dynamodb/node_modules/serverless/lib/classes/PluginManager.js:160:50)
    at runCallback (timers.js:651:20)
    at tryOnImmediate (timers.js:624:5)
    at processImmediate [as _immediateCallback] (timers.js:596:5)
From previous event:
    at PluginManager.run (/Users/faizhasim/dev/github/serverless-dynamic-dynamodb/node_modules/serverless/lib/classes/PluginManager.js:160:22)
    at Serverless.run (/Users/faizhasim/dev/github/serverless-dynamic-dynamodb/node_modules/serverless/lib/Serverless.js:91:31)
    at serverless.init.then (/Users/faizhasim/dev/github/serverless-dynamic-dynamodb/node_modules/serverless/bin/serverless:23:50)
    at process._tickCallback (internal/process/next_tick.js:103:7)

Workaround
Workaround is to define package.include as folowing:
package:
  individually: true
  include:
    - yarn.lock

Fix
This PR is just a simple fix for that.

Btw, we use optimizely plugin during serverless 0.5, then went for webpack plugin when migrating to serverless 1.0-beta. Looking forward to use browserify again with this plugin. ❤

I ran into the same issue and applied the workaround. What is yarn.lock?  Is it just some arbitrary file?

What is yarn.lock? Is it just some arbitrary file?

We are using yarn instead of NPM to manage the dependencies. It spits out yarn.lock, similar to Gem lock or npm shrinkwrap. In this context, it's just some arbitrary files.

@faizhasim hero! This PR fixes the exactly same problem I'm having here. Thanks v much :)

authors: bjfletcher faizhasim jamiechong

license: mit

license_source: bigquery


text:
Javascript embed code

need to wrap all vendored scripts in new js scope?

closed in https://github.com/dobtco/formrenderer-base/commit/68c16e84a6300b0cb03c5514a0026681cf0bf969

repo: dobtco/formrenderer-base


text:
docker stop results in SIGTERM being sent

Hi,
is there something wrong about using docker stop to shutdown the postgres container?
After examining the logs I notice the following:
2016-08-10T17:37:48.649652549Z LOG:  received smart shutdown request
2016-08-10T17:37:48.649779343Z LOG:  autovacuum launcher shutting down
2016-08-10T17:39:23.315340438Z LOG:  database system was interrupted; last known up at 2016-08-10 17:34:54 UTC
2016-08-10T17:39:23.619640237Z LOG:  database system was not properly shut down; automatic recovery in progress
2016-08-10T17:39:23.629918073Z LOG:  redo starts at 0/70D0028
2016-08-10T17:39:23.629963085Z LOG:  invalid record length at 0/70D0108
2016-08-10T17:39:23.629969782Z LOG:  redo done at 0/70D00D0
2016-08-10T17:39:23.636000325Z LOG:  MultiXact member wraparound protections are now enabled
2016-08-10T17:39:23.639092551Z LOG:  database system is ready to accept connections
2016-08-10T17:39:23.640314686Z LOG:  autovacuum launcher started

Even if I run docker stop --time=60 postgres, the stop just waits for those 60 seconds, after which it probably sends SIGKILL causing the postres shutdown and subsequent warning during start.
Thanks for any info

I've not seen an issue in stopping a postgres container (though mine don't usually have much data or load) and so mine stop almost instantly after receiving SIGTERM.  If you need more control, you could use docker kill -s TERM postgres, then you don't get the automatic KILL signal.

I experience the same all the time, did you find a better solution @yntelectual?

I had actually experienced data corruption because postgress process was SIGKILLed in the middle of flushing logs.
Now, I always make sure to do docker exec -u postgres $CID pg_ctl stop instead of docker stop $CID
Solving this correctly would require something along EXITPOINT hook described here https://github.com/docker/docker/issues/6982, but sadly that feature seems to be abandoned.

As referenced above, your best bet is to run docker kill -s TERM xyz directly and skip docker stop entirely (thus avoiding SIGKILL):

I've not seen an issue in stopping a postgres container (though mine don't usually have much data or load) and so mine stop almost instantly after receiving SIGTERM.  If you need more control, you could use docker kill -s TERM postgres, then you don't get the automatic KILL signal.

Additionally, you might have luck with specifying --stop-timeout on the container itself to give docker stop a larger default, but I think that'll just be a stop-gap solution if it's taking longer than 60 seconds for your database to shut down.  It sounds like you might have some architectural issues you'll want to look into to figure out why it's taking so long for your database to shut down.
In the future, these sorts of questions/requests would be more appropriately posted to the Docker Community Forums, the Docker Community Slack, or Stack Overflow.

Well, as stated in https://www.postgresql.org/docs/10/static/server-shutdown.html:

Smart Shutdown: ... lets existing sessions end their work normally. It shuts down only after all of the sessions terminate.

So if the connection is idle in another process, 60 seconds may never be enough.
Since we don't have a fine-grained shutdown control order in docker I'm using the stop_signal to change the behavior and get a clean shutdown with docker-compose.
postgres:
  image: postgres:10.4-alpine
  container_name: postgres
  stop_signal: SIGINT                 # Fast Shutdown mode

I think you can change the Dockerfile and specify the STOPSIGNAL.
It should fix too...

Given that SIGTERM is more graceful (and less likely to break folks'
databases), I'm wary of explicitly changing that.

Sure, this is the safest choice. I'm not saying to change the default signal.
What I really want to say is:
As everyone should know their own application and their workload, that may be the tip someone needs to tweak their needs.

authors: jjmata navossoc rkrzewski tianon yntelectual yosifkit

repo: docker-library/postgres


text:
Fix godev workflow

Dockerized godev refresh is a bit overkill. Switch to a dedicated workflow. When merged I will create the first v0.1.0 release and update https://github.com/docker/buildx/pull/747.
cc @thaJeztah @chris-crone
Signed-off-by: CrazyMax crazy-max@users.noreply.github.com

Codecov Report

Merging #7 (6afa7a6) into main (fe6dc62) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #7   +/-   ##
=======================================
  Coverage   34.73%   34.73%
=======================================
  Files           4        4
  Lines         429      429
=======================================
  Hits          149      149
  Misses        243      243
  Partials       37       37

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 fe6dc62...6afa7a6. Read the comment docs.

authors: codecov-commenter crazy-max

repo: docker/cli-docs-tool


text:
Will docker private registry support webhooks for some specified events?

Webhooks can allow the developers to build or set up integrations which subscribe to certain events on private docker registry. When one of those events is triggered, the private docker registry sends a HTTP POST payload to the webhook's configured URL. For example, When new docker image is pushed to repository, webhooks can be post messages to a chat server or deploy containers to a Kubernetes cluster.
Each webhook can be installed on a specific respository. Once installed, they will be triggered each time a subscribed event occurs on that repository.  Can we support this feature?

no answer on this?

also interested in this ...

authors: SyCode7 cheyang nanachimi

repo: docker/docker-registry


text:
does not work for raspbian stretch today

File: engine/installation/linux/docker-ce/debian.md, CC @mstanleyjones
There appears to be no armhf stretch stable docker-ce package in your repo, so these instructions don't work.
I was able to find an rpm under stretch/pool/test on the download page and this will install once some additional dependencies have been satisfied.
The hello-world example does not work though. Just exits with no errors or logs.

I got the same issue.
root@raspberrypi:/etc/apt/sources.list.d# cat /etc/apt/sources.list.d/docker.list  deb [arch=armhf] https://download.docker.com/linux/raspbian      stretch stable root@raspberrypi:/etc/apt/sources.list.d# apt-get update Hit:1 http://archive.raspberrypi.org/debian stretch InRelease                        Hit:2 http://mirrordirector.raspbian.org/raspbian stretch InRelease                  Hit:3 https://download.docker.com/linux/raspbian stretch InRelease Reading package lists... Done root@raspberrypi:/etc/apt/sources.list.d# apt-get install docker-ce Reading package lists... Done Building dependency tree        Reading state information... Done E: Unable to locate package docker-ce root@raspberrypi:/etc/apt/sources.list.d#
Thanks in advance

Closing this ticket due to its age, and the impending refactor. If you think this is in error, feel free to reopen. Thanks!

authors: L-Hudson pacdaemon stuuu68


text:
Typo in title

File: ee/ucp/interlock/deploy/index.md, CC @johndmulhausen
Title has a typo (missing 'l' in 'layer'
Enable ayer 7 routing
Should be
Enable layer 7 routing
       ^

Note: I tried to use the "Edit this page" functionality to submit the change myself, and got a 404.
@joaofnfernandes

Issue moved to docker/docs-private #586 via ZenHub

authors: davidwilliamson joaofnfernandes


text:
Various cleanup in template, and improvements to 404 page

See individual commits for details

@usha-mandya @StefanScherer ptal

The improved 404 issue creation link is very useful!

Yes, I initially just wanted to move the script, then thought about what me bothered all the time "I found a broken link" issues; well, they basically reported "I (somehow) arrived on an URL that doesn't exist".
Nothing we can do about those unless we know why they arrived there (did it ever exist? did they make a typo when entering the URL? did someone write a blog-post and made a typo? did we forget to update a link or add a redirect?)


text:
Add option to docker run --rm to keep failed containers

It would be nice if docker run --rm accepted an option to keep containers that exit with a non-zero status.

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

I'm not sure we should overload this feature with more options, using a cleanup script to cleanup containers afterwards may be an alternative solution for your use case?

Closing for lack of activity.

authors: GordonTheTurtle LK4D4 kolbe thaJeztah

repo: docker/docker


text:
Environment variable type of array not working

I try to set an environment variable as array but it's seem not working.
I tried with -e, --env and --env-file arguments of run command.
I didn't find anything about this case, so I open this issue.
docker version: Docker version 1.10.0, build 590d5108
I set a variable like this: ARRAY=("foo" "bar" "foobar")
My Dockerfile:
FROM debian:jessie

COPY display-array.sh /display-array
ENTRYPOINT ["/display-array"]

Entrypoint's script:
#!/bin/bash

echo "Test with an environment variable as array passed to run command"
echo "Count elements in ARRAY: "${#ARRAY[*]}
echo "List of elements: "${ARRAY[@]}
if [ ! ${#ARRAY[*]} = 0 ]; then
	cnt_elmt=$((${#ARRAY[*]} - 1))
	for i in `seq 0 $cnt_elmt`
	do
		echo "Element $i = "${ARRAY[$i]}
	done
fi

printf "\nTest with the same environment variable as array assigned directly in bash script\n"
ARRAY=("foo" "bar" "foobar")
echo "Count elements in ARRAY: "${#ARRAY[*]}
echo "List of elements: "${ARRAY[@]}
if [ ! ${#ARRAY[*]} = 0 ]; then
	cnt_elmt=$((${#ARRAY[*]} - 1))
	for i in `seq 0 $cnt_elmt`
	do
		echo "Element $i = "${ARRAY[$i]}
	done
fi

exec "$@"

Build command: docker build -t jessie .
Run commands tried:
docker run -it --rm -e "ARRAY=("foo" "bar" "foobar")"  jessie
docker run -it --rm --env "ARRAY=("foo" "bar" "foobar")"  jessie
docker run -it --rm --env-file ./array.env jessie
With this content in array.env file:
ARRAY=("foo" "bar" "foobar")
Result:
Test with an environment variable as array passed to run command
Count elements in ARRAY: 1
List of elements: ("foo" "bar" "foobar")
Element 0 = ("foo" "bar" "foobar")

Test with the same environment variable as array assigned directly in bash script
Count elements in ARRAY: 3
List of elements: foo bar foobar
Element 0 = foo
Element 1 = bar
Element 2 = foobar

The variable value has been treated like a string not an array.
I don't understand this behavior.
Note:
For the moment, I assign a value separated by a comma like this: ARRAY=foo,bar,foo bar
And i transform it with this code: IFS=',' read -r -a ARRAY <<< "$ARRAY"
Thanks for the help.

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
For more information about reporting issues, see CONTRIBUTING.md.
You don't have to include this information if this is a feature request
(This is an automated, informational response)

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

@sirateck Docker only supports single values env vars, not arrays.

Thanks for your answer @duglin !
But where is this information ?

@sirateck probably falls into the category of "we didn't say we support it, therefore we don't".  :-)
But, see if this PR helps any: #20173
If not let me know and we can work on some more wording.

This is perfect for me.
And yes I am falling into this category type :wink:
Thanks for your time @duglin

I would like to see this as a new feature.
So I can use a flexible way to make a envirovent. e.g. if several service containers use one database container. Using in yaml compose config like:
environment:
- PG_CREATE_USER:
- sonar
- archiva
- PG_CREATE_PASSWORD:
- sonar
- archiva
- PG_CREATE_DB:
- sonar
- archiva_users

POSIX shell does not have array types, so we cannot support this.
@sjatgutzmann I would discourage putting those credentials in the docker-compose file itself; perhaps an env-file per service would help there? https://docs.docker.com/compose/compose-file/#/envfile

authors: GordonTheTurtle duglin sirateck sjatgutzmann thaJeztah


text:
UID/GID not set to zero for all files added with ADD command

This is a continuation of #3950, which was supposedly fixed by #3971. It does not appear to be completely fixed, as of Docker 1.9.1 (a34a1d5).
I'm adding three files (owned by 1001:1001) like this in my Dockerfile:
ADD subdir/file1 subdir/file2 subdir/file3 /root/.somewhere

Result:
# ls al /root/.somewhere
-rw-r--r-- 1 1001    1001   100 Apr 14 21:35 file1
-rw-r--r-- 1 root    root   100 Apr 14 21:35 file2
-rw-r--r-- 1 root    root   100 Apr 14 21:35 file3

The UID/GID are being set for the all of the files except the first.

I used 1.11 docker and not found this issue
ubuntu@interlock:~/tetwok$ docker build -t test  .
Sending build context to Docker daemon 4.608 kB
Step 1 : FROM busybox
 ---> 47bcc53f74dc
Step 2 : ADD subdir/file1 subdir/file2 subdir/file3 /root/.somewhere/
 ---> 6402e6fc6bc7
Removing intermediate container 8619da8e2f39
Successfully built 6402e6fc6bc7
ubuntu@interlock:~/tetwok$ docker images
REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
test                 latest              6402e6fc6bc7        4 seconds ago       1.113 MB
nginx                latest              eb4a127a1188        9 days ago          182.7 MB
ehazlett/interlock   1.0.1               7ec5cfc363b2        3 weeks ago         20.9 MB
busybox              latest              47bcc53f74dc        3 weeks ago         1.113 MB
ubuntu@interlock:~/tetwok$ docker run -it test sh
/ # ls -l /root/.somewhere/file
file1  file2  file3
/ # ls -l /root/.somewhere/
total 4
-rw-rw-r--    1 root     root             6 Apr 15 01:00 file1
-rw-rw-r--    1 root     root             0 Apr 15 01:00 file2
-rw-rw-r--    1 root     root             0 Apr 15 01:00 file3
/ # exit
ubuntu@interlock:~/tetwok$ ls -l
Dockerfile  subdir/
ubuntu@interlock:~/tetwok$ ls -l
Dockerfile  subdir/
ubuntu@interlock:~/tetwok$ ls -l subdir/
total 4
-rw-rw-r-- 1 ubuntu ubuntu 6 Apr 15 01:00 file1
-rw-rw-r-- 1 ubuntu ubuntu 0 Apr 15 01:00 file2
-rw-rw-r-- 1 ubuntu ubuntu 0 Apr 15 01:00 file3

Same thing on 1.8.2-fc22:
[jreinhart@jreinhart-nuc docker_22056]$ ls -l subdir/
total 8
-rw-rw-r--. 1 jreinhart jreinhart 0 Apr 15 08:14 file1
-rw-rw-r--. 1 jreinhart jreinhart 5 Apr 15 08:15 file2
-rw-rw-r--. 1 jreinhart jreinhart 9 Apr 15 08:15 file3
[jreinhart@jreinhart-nuc docker_22056]$ docker build -t test .
Sending build context to Docker daemon  5.12 kB
Step 0 : FROM debian:8.2
 ---> d4b2ba78e3b4
Step 1 : ADD subdir/file1 subdir/file2 subdir/file3 /root/.somewhere/
 ---> 10f6dd22eea1
Removing intermediate container 8c83082c383e
Successfully built 10f6dd22eea1
[jreinhart@jreinhart-nuc docker_22056]$ docker run --rm -it test  ls -l /root/.somewhere
total 8
-rw-rw-r--. 1 1000 1000 0 Apr 15 12:14 file1
-rw-rw-r--. 1 root root 5 Apr 15 12:15 file2
-rw-rw-r--. 1 root root 9 Apr 15 12:15 file3
[jreinhart@jreinhart-nuc docker_22056]$ docker version
Client:
 Version:      1.8.2-fc22
 API version:  1.20
 Package Version: docker-1.8.2-7.gitcb216be.fc22.x86_64
 Go version:   go1.5.1
 Git commit:   cb216be/1.8.2
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2-fc22
 API version:  1.20
 Package Version:
 Go version:   go1.5.1
 Git commit:   cb216be/1.8.2
 Built:
 OS/Arch:      linux/amd64

Ping @crosbymichael @creack

(btw: it looks like you are running a Red Hat build of Docker; https://github.com/projectatomic/docker/commit/cb216be, which contains various modifications, and can in some cases make a difference. Support for those versions should be handled through https://bugzilla.redhat.com)
I was able to reproduce this on 1.8.2, and 1.9.1 on Fedora 22;
Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Wed Oct  7 17:42:41 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Wed Oct  7 17:42:41 UTC 2015
 OS/Arch:      linux/amd64

And
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:34:39 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:34:39 UTC 2015
 OS/Arch:      linux/amd64

But it looks to be resolved in 1.10.3;
Client:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 15:45:58 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 15:45:58 2016
 OS/Arch:      linux/amd64

Files;
ls -la subdir/
total 8
drwxr-xr-x. 2 1001 1001 4096 Apr 15 13:21 .
dr-xr-x---. 6 root root 4096 Apr 15 13:21 ..
-rw-r--r--. 1 1001 1001    0 Apr 15 13:21 file1
-rw-r--r--. 1 1001 1001    0 Apr 15 13:21 file2
-rw-r--r--. 1 1001 1001    0 Apr 15 13:21 file3

Dockerfile:
FROM alpine
ADD subdir/file1 subdir/file2 subdir/file3 /root/.somewhere/
COPY subdir/file1 subdir/file2 subdir/file3 /root/.somewhere-else/
CMD sh

docker build -t owner .
...

docker run -it --rm owner

/ # ls -la /root/.somewhere/
total 8
drwxr-xr-x    2 root     root          4096 Apr 15 12:57 .
drwx------    4 root     root          4096 Apr 15 12:58 ..
-rw-r--r--    1 root     root             0 Apr 15 12:53 file1
-rw-r--r--    1 root     root             0 Apr 15 12:53 file2
-rw-r--r--    1 root     root             0 Apr 15 12:53 file3

/ # ls -la /root/.somewhere-else/
total 8
drwxr-xr-x    2 root     root          4096 Apr 15 12:57 .
drwx------    4 root     root          4096 Apr 15 12:58 ..
-rw-r--r--    1 root     root             0 Apr 15 12:53 file1
-rw-r--r--    1 root     root             0 Apr 15 12:53 file2
-rw-r--r--    1 root     root             0 Apr 15 12:53 file3

Are you still able to reproduce this on docker 1.10.3 or 1.11.0 ?

(btw: it looks like you are running a Red Hat build of Docker; projectatomic@cb216be, which contains various modifications, and can in some cases make a difference. Support for those versions should be handled through https://bugzilla.redhat.com)

@thaJeztah The original bug report was for Docker 1.9.1 (a34a1d5), a non Red Hat build. My comment was regarding a sanity check on a second machine which was using the RH version.
I'm currently unable to update to a different version on the machine running the RH version, because I can't uninstall docker due to Bug 1246826 - Removing docker-selinux removes selinux-policy.

@JonathonReinhart alright, let me close this issue, because this should be resolved, but let us know if it isn't resolved after updating to docker 1.10 or 1.11

Okay, I updated to Docker 1.11.0, and the issue appears to be resolved. Thanks. If I find the MR that fixed it, I will link it here, because the only things I can find about this problem are before it was first the fixed time.

This was re-fixed in PR #18158; no associated issue.

Thanks! Ah, yes, I remember that one :+1:

authors: HackToday JonathonReinhart thaJeztah


text:
how to run container with non-root user

I expect run container with a non-root user, So I use the following command:
docker run -it -v /work:/work -v /remote:/remote --expose 55555 --user=2000 yanren/suse12:1.0 /bin/bash
I execute the script "run_agent", then I check the process
I have no name!@1bc1e0c079f6:/work> ps -ef | grep agent
2000        17     1  0 09:55 ?        00:00:00 /bin/sh /remote/quasr4/quasr/release/agents_2.7/linux/bin/run_agent
root        38    17  0 09:55 ?        00:00:00 /remote/quasr4/quasr/release/agents_2.7/linux/bin/agent -I /tmp/agent_interfaces.55555 -S agent_1
why the owner of run_agent is 2000 that is my assigned user, but the owner of subprocess is root?

What does the run_agent script look like? Also, can you provide information about your setup (docker version and docker info)

docker version:
Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.3.3
Git commit (client): 7c8fca2
OS/Arch (client): linux/amd64
Server version: 1.6.2
Server API version: 1.18
Go version (server): go1.3.3
Git commit (server): 7c8fca2
OS/Arch (server): linux/amd64
docker info:
Containers: 6
Images: 23
Storage Driver: devicemapper
Pool Name: docker-254:2-1802243-pool
Pool Blocksize: 65.54 kB
Backing Filesystem: extfs
Data file: /dev/loop0
Metadata file: /dev/loop1
Data Space Used: 11.52 GB
Data Space Total: 107.4 GB
Data Space Available: 20.47 GB
Metadata Space Used: 7.651 MB
Metadata Space Total: 2.147 GB
Metadata Space Available: 2.14 GB
Udev Sync Supported: true
Data loop file: /docker/devicemapper/devicemapper/data
Metadata loop file: /docker/devicemapper/devicemapper/metadata
Library Version: 1.03.01 (2011-10-15)
Execution Driver: native-0.2
Kernel Version: 3.12.48-52.27-default
Operating System: SUSE Linux Enterprise Server 12
CPUs: 6
Total Memory: 11.75 GiB
Name: mo-27fee68c8
ID: HMWL:7MDL:HCFE:GKXI:WDHT:JTW4:KZ3I:TVJ6:2FLB:UEE7:QNXL:A2IO
WARNING: No swap limit support
the script looks like:
Close stdin because some shells try to read unnecessarily, causing
run_agent to hang
exec < /dev/null
Set umask in case agent is restarted by different user
umask 002
#write interface file
echo "***********************" >> interfaces
HOSTNAME=hostname
agent_name=agent_$HOSTNAME
/remote/quasr4/quasr/release/agents_2.7/linux/bin/agent -I $interfaces_file -S $agent_name >> run_agent.out 2>&1

ok, It seems about my script, because i set 's' bit on agent program.
thanks

authors: thaJeztah yanren


text:
Docker build includes warning message

Docker Version: 1.12.0-rc3
OS: Windows 10 RTM
Issue

Run docker build with the --quiet parameter
Output from command includes the expected image ID, but also includes a warning message

SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '
-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.
sha256:18bd7a97e51e7f07dbbde2934d51252356a697172ef256d58133e3e3f117bafd

Expected Result

The docker build command should not emit a warning message when the --quiet parameter is specified
Extra parsing is required to extract the newly created image ID

Cheers,
Trevor Sullivan

/cc @jhowardmsft wdyt?

I don't have strong feelings either way, but it seems a reasonable suggestion.

@ahmetalpbalkan Unless there was a specific reason I'm not aware of?

agreed, I think it makes sense
@pcgeek86 do you want to open a pull request to change this behavior yourself?

@thaJeztah I don't think you want me touching Docker source code. :) My best ability to contribute is through UX enhancement suggestions and such. The amount of time it would take me to learn about the Docker code and contribution processes would probably take too much time away from my business anyhow.

Tis OK, I have a fix. Is really simple. PR coming shortly.

@pcgeek86 no worries; just checking before I (or @jhowardmsft in this case) opened a pull request. Thanks for contributing through reporting issues 👍 it's appreciated

@jhowardmsft we added this mostly because we add +x to all files archived to context from Windows. And when they get extracted on Linux, all files having +x permission (without telling the user about this) is not quite secure. That's why I added it in the first place.
You can see the discussion at: https://github.com/docker/docker/pull/11397 I'd check with security folks to see if there are any concerns about removing this message.

@ahmetalpbalkan thanks! I know about the reason it was added, and it's still printed, unless someone uses the --quiet option. I think it should be ok to suppress the message in that case (it's printed in all other cases, so users should be aware of the issue).
Happy to hear if there's concerns though

@thaJeztah @ahmetalpbalkan @jhowardmsft
Would you mind explaining why making a file executable with the +x permission poses a security threat?  Alternatively, links to resources on the subject would be great too.  :)
Security is something I'm not an expert in, but I'd really like to know more.  Thanks!

authors: ahmetalpbalkan ellismarkf jhowardmsft pcgeek86 thaJeztah


text:
Cannot exit from docker exec if a background job is running and it blocks some of docker commands

docker version:
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:02:53 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:02:53 2016
 OS/Arch:      linux/amd64

docker info:
$ docker info
Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 1
Server Version: 1.12.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 3
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options:
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 189.3 GiB
Name: sv01
ID: ZWXQ:4D4K:TEK6:KFWK:G7AB:VDTM:Y5EK:IOZP:KXRY:AU6L:VS77:DLA6
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Insecure Registries:
 127.0.0.0/8

uname -a:
debian@sv01:~$ uname -a
Linux sv01 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux

Provide additional environment details (AWS, VirtualBox, physical, etc.):
Docker is running on a physical server.
List the steps to reproduce the issue:

Start a container foo.
Login to foo with docker exec, run a background job and try to exit.
Try to build an image.

## 1.
debian@sv01:~$ docker run -it --name foo debian bash
root@...$:/#

## 2. Another terminal
debian@sv01:~$ docker exec -it foo bash
root@...$:/# sleep 300 &
[1] 13
root@...$:/# exit
exit

## 3. Yet another terminal
debian@sv01:~$ cat > Dockerfile
FROM debian
RUN apt-get update
debian@sv01:~$ docker build -t dummy .
Sending build context to Docker daemon 4.193 MB
Step 1 : FROM debian
 ---> 031143c1c662
Step 2 : RUN apt-get update
 ---> Running in 6e7e2385284b

Describe the results you received:
The exit in 2. freezes until the background job (sleep) finishes.
The docker build in 3. freezes until the exit finishes.
docker ps, docker stop, etc. also freeze until the docker build finishes.
At that time, docker info, docker images, etc. work well.
Describe the results you expected:
An exit from docker exec should not wait the end of background jobs.
Or, it should not block docker build.
Provide additional info you think is important:
Nothing.

I can confirm the bug with 1.12.1 on the Gentoo and Ubuntu. My scripts use exec heavily and I experience hang of some docker commands (docker exec and docker ps).

@femdom note that the docker exec will keep on hanging out if you they exit after starting processes that hang onto the initial IOs.
You may want to start them in detached mode in that case via -d

This is fixed now that #26538 have been merged in (it includes the new containerd).

Thank you!

authors: femdom mlaventure s-yata


text:
allow DefaultBaseFsSize to be configured

Currently these values are hard coded in https://github.com/shykes/docker/blob/9415c2b1f08ecd168ab5a620a80a5bed34df8adb/graphdriver/devmapper/deviceset.go#L19
DefaultDataLoopbackSize     int64  = 100 * 1024 * 1024 * 1024
DefaultMetaDataLoopbackSize int64  = 2 * 1024 * 1024 * 1024
DefaultBaseFsSize           uint64 = 10 * 1024 * 1024 * 1024

I need at least be able to configure DefaultBaseFsSize when starting the server. Even better would it if I could configure this value when creating a container but I don't know if that is feasible at all.

Thank you!

authors: fjakobs hinesmr


text:
Added some error messages and tracing to bridge network initialization

Signed-off-by: John Gossman johngos@microsoft.com

I'm trying to debug docker/docker#12177. No luck so far, but this level of tracing will be helpful to find repros.

I'm not married to any of the wording or where I put messages. Looking for feedback.

It'd be better to add new detail messages to the returned errors instead if logging to output streams.

@ahmetalpbalkan I guess the question is philosophical: is the error returned an aggregate of all the calls that failed, or something easy to read for a user. If the latter, then logging makes more sense. Docker codebase and even golang don't seem to have standard best practices....or at least I don't know them.

LGTM

LGTM

@ehazlett note for the future, we should ask contributors to squash commits into one where possible http://docs.docker.com/project/create-pr/

@ahmetalpbalkan thanks for the heads up!

@ehazlett Thanks for the merge!
@ahmetalpbalkan ps -- I would have squashed, was just waiting to see if I got more feedback.

authors: ahmetalpbalkan crosbymichael ehazlett johngossman


text:
Windows: Fixup compile in daemon_windows.go

Signed-off-by: John Howard jhoward@microsoft.com
@swernli
This PR is part of the proposal described in docker/docker issue 10662 to port the docker daemon to Windows. Easy fix to bring Windows daemon compilation back to working.

LGTM

LGTM

authors: LK4D4 jhowardmsft tiborvass


text:
Don't throw "restartmanager canceled" error for no restart policy container

- What I did
Don't throw "restartmanager canceled" error for no restart policy container
or else if kill a no restart policy container, there is a error log
ERRO[0024] restartmanager canceled
and add the container id to the warning message if a container has restart policy
and make error log to warn log
ping @tonistiigi
- How I did it
- How to verify it
- A picture of a cute animal (not mandatory but encouraged)
Signed-off-by: Lei Jitang leijitang@huawei.com

@cpuguy83  updated

libcontainerd/container_linux.go:8: imported and not used: "strings"

ping @cpuguy83 @tonistiigi PTAL

LGTM

LGTM


text:
[Submission]: μ Registry Explorer

Docker Hub repository name
akisakurai/registry-explorer-extension
Terms of services

[X] I accept the term of services

Hi @AkiSakurai, I see that the extension is a fork of @nico1510's https://github.com/nico1510/registry-explorer-extension. Don't you want to raise a PR on this repo rather than submit it as an extension? I am sure he would be keen on merging this  :)

repo: docker/extensions-submissions


text:
Distributed delete processing

Along with the delete processing, have reorganized the code to reduce the number of events and streamlined the initial endpoint watch notifications strictly after network notifications which solves some corner case issues.
Signed-off-by: Madhu Venugopal madhu@docker.com

LGTM

LGTM

authors: aboch mavenugo mrjana

repo: docker/libnetwork


text:
Document changes in release process given non-external drivers

Following up on: https://github.com/docker/machine/pull/2453#issuecomment-161487141
Now that the installation process and release process is changed somewhat by this PR, we should document the changes so that the release document and installation guide are congruent.
cc @docker/machine-maintainers
cc @londoncalling -- I don't think we'll need you to actively work on this one, but it would be great for you to follow to start to get a feel for our documentation structure and process.

I believe this is done. Feel free to re-open it if I missed something.

authors: jeanlaurent nathanleclaire

repo: docker/machine


text:
Error creating machine: ssh-keygen not found in the path, please install ssh-keygen

docker-machine version: 0.2.0 (48bea37)
C:\Apps\Docker>docker-machine.exe create -d virtualbox dev
←[34mINFO←[0m[0000] Creating SSH key...
←[34mINFO←[0m[0000] No default boot2docker iso found locally, downloading the latest release...
←[34mINFO←[0m[0000] Downloading latest boot2docker release to C:\Users\staama1\.docker\machine\cache\boot2docker.iso...

←[31mERRO←[0m[0083] Error creating machine: ssh-keygen not found in the path, please install ssh-keygen
←[33mWARN←[0m[0083] You will want to check the provider to make sure the machine and associated resources were properly
removed.
←[31mFATA←[0m[0083] Error creating machine

Is docker-machine compatible with puttygen? If so how do I configure docker-machine to use it instead of ssh-keygen?

Looks like ssh-keygen will be removed as a dependency and certs will get created using a library in 0.3.0 #885


text:
Cleanup: remove the unused function

Signed-off-by: Hu Keping hukeping@huawei.com

Can one of the admins verify this patch?

test this please

LGTM pending CI, thank you @HuKeping

LGTM, thanks for cleaning this up!

authors: HuKeping cyli docker-jenkins riyazdf

repo: docker/notary


text:
[ca/manager] Remove root CA key encryption support entirely

Since that feature, neither documented nor advertised, was deprecated almost a year ago.  Rely on MTLS for encryption in transit and raft log encryption for encryption at rest.

LGTM

authors: cyli dperny

repo: docker/swarmkit


text:
Transaction submission blocks forever when called after disconnecting and reconnecting to node.

The second call to connect_and_submit never resolves.
import { Keyring } from '@polkadot/api';
import { cryptoWaitReady, randomAsU8a } from '@polkadot/util-crypto';
import { u8aToHex } from '@polkadot/util';
import { createSignedKeyUpdate } from '../src/utils/did';
import { DockAPI, PublicKeySr25519 } from '../src/api';

const ALICE_DID = '0x416c696365000000000000000000000000000000000000000000000000000000';

(async () => {
  await block('ws://localhost:9944');
  console.log("done");
})().catch(e => {
  console.error(e);
  process.exit(1);
});

async function block(nodeWsUrl) {
  await connect_and_submit(nodeWsUrl);
  console.log("returns the first time");
  await connect_and_submit(nodeWsUrl);
  console.log("the second time it blocks so this statement doesn't get printed");
}

async function connect_and_submit(nodeWsUrl) {
  const dock = new DockAPI();
  await dock.init({ address: nodeWsUrl });
  dock.setAccount(await keypair("//Bob"));

  const [keyUpdate, signature] = await createSignedKeyUpdate(
    dock.did,
    ALICE_DID,
    new PublicKeySr25519(u8aToHex(randomAsU8a())),
    await keypair(u8aToHex(randomAsU8a())),
    undefined // we are not updating the controller
  );
  await dock.did.updateKey(keyUpdate, signature);

  await dock.disconnect();
}

async function keypair(seed) {
  await cryptoWaitReady();
  let keyring = new Keyring({ type: 'sr25519' });
  let key = keyring.addFromUri(seed);
  return key
}

Hint: write this script to ./scripts/block_forever.js then call it with npx babel-node ./scripts/block_forever.js. Make sure you have a development node running.

cant reproduce with latest version (of course this issue is old). cant see what would cause a block, but it might've been polkadot related since a new dockapi instance is created each call here

authors: SamHellawell bddap

repo: docknetwork/sdk


text:
"See Also" links broken on readthedocs

Bug Report
On the readthedocs site, "See also" links are typically broken. It's generally happening because the link does not have ".html".
Steps to Reproduce

Go to https://beta.docs.dockstore.org/en/develop/launch-with/dnastack-launch-with.html
Scroll to the bottom, to See Also
Click on any of the links -- you get a 404.

For example, clicking on AWS batch takes you to https://beta.docs.dockstore.org/advanced-topics/aws-batch/, but it should be taking you to https://beta.docs.dockstore.org/en/develop/advanced-topics/azure-batch.html-- note how the actual page has .html at the end, but the link does not.
┆Issue is synchronized with this Jira Story
┆Issue Type: Story
┆Issue Number: DOCK-1017

I killed a number of these in https://github.com/dockstore/dockstore-documentation/pull/19 but I think we probably need someone to go through it systematically and/or improve the link checker

Already fixed

authors: coverbeck denis-yuen melainalegaspi

repo: dockstore/dockstore


text:
Create Cypress test for Docker Hub tool registration

Is your feature request related to a problem? Please describe.
Several problems with manual tools (that are probably fixed by now), but went unnoticed because of the lack of tests.

Registering Docker Hub tools runs into https://github.com/dockstore/dockstore/issues/3329
After successfully registering the tool, results in https://github.com/dockstore/dockstore-ui2/pull/941
We need some tests to test those

Describe the solution you'd like
Tests

Closing in favor of seabright ticket


text:
Feature/2988/auto default version set

For #2988 and #3683
Didn't save the default version setting in the DB for simplicity. The version/tag that was just pushed is presumably the latest (which works for most cases). Doesn't work if you push a tag that says default should be branch (until you push a branch that says default should be branch)

If I understand correctly, this is a take on the original proposal.
So
workflows:
   - subclass: ...
     primaryDescriptorPath: ...
     defaultVersion: tag

means "if this current push is a tag, it becomes the detault"
      defaultVersion: branch

means "if this current push is a branch, it becomes the detault"
      defaultVersion: manual

means nothing happens which is the same as if the key is completely omitted. Is that correct?
If so, would recommend deleting manual and just having the no key be the only way to represent manual. Would also like to make this consistent with our syntax for github app filters
https://docs.dockstore.org/en/develop/getting-started/github-apps/github-apps.html#why-have-a-dockstore-github-app
So the two remaining modes become
workflows:
   - subclass: ...
     primaryDescriptorPath: ...
     default:
        tags:
             - /.*/

and
workflows:
   - subclass: ...
     primaryDescriptorPath: ...
     default:
         branches:
             - /.*/
         tags:
             - /.*/

A bit of a pain, but there is probably code that can be re-used.
Edit to add:
Can also simplify as this for a first pass
workflows:
   - subclass: ...
     primaryDescriptorPath: ...
     default:
        - tags

and
workflows:
   - subclass: ...
     primaryDescriptorPath: ...
     default:
         - branches
         - tags

The yaml configuration is pretty much https://github.com/dockstore/dockstore/issues/3683#issue-664534277 except config is left out
I can remove manual if we don't want users to explicitly specify manual (like how CircleCI lets u specify a medium VM even though it's default). Not too sure about the benefits of removing it though. The downside is if we move this feature to all tools/workflows, the DB column for defaultVersion would no longer be able to use MANUAL as the default and would have to use NULL.
Not quite sure I understand the purpose or use case of the rest of proposed changes. I want to reiterate the use cases:

A user can specify filters without specifying what the default version should be
A user can specify what the default version should be without specifying filters
A user can specify both what the default should be and filters

I don't think there's a use case for specifying that the default version should be the newest anything (BRANCH or TAG) which makes adding ALL or something like that to be unnecessary.
I don't think defaultVersion should be an array, it would not be intuitive to store it as an array (or table) in the DB and thus I would not want to represent it as an array in the yaml

My current implementation is kind of a shortcut for my initial idea:
switch (defaultVersion):
case TAG:
  search all tags for the newest tag
case BRANCH:
  search all branches for the newest branch
default:
  don't set default

search all tags for the newest tag

To be clear through, this isn't actually the case is it? Briefly looking, the code is just processing the one added version rather than searching through all tags. (Concerned about performance)

Not too sure about the benefits of removing it though

I just like to avoid redundancy

Not quite sure I understand the purpose or use case of the rest of proposed changes

It is mainly that we developed a syntax for github app filters after the initial proposal that was linked to from 2683, which also concerns how we process new versions of a dockstore workflow. Since this is a pretty similar idea, I was thinking about a similar syntax.
That said, I think your breakdown helps point out that a filtered tag or branch cannot logically be set as the default so nevermind.
I agree with you that we should avoid 'ANY' although I expect it to be a feature request, I think I would be opposed to it.
For similar reasons though, I don't think we should be encouraging BRANCH either
So for me, I'm actually just thinking
switch (defaultVersion):
case TAG:
  allow any new tag to become default
default:
  don't set default

To be clear through, this isn't actually the case is it? Briefly looking, the code is just processing the one added version rather than searching through all tags. (Concerned about performance)

The current implementation is a shortcut of "search all tags for the newest tag". It has the downside of the original PR comment "Doesn't work if you push a tag that says default should be branch (until you push a branch that says default should be branch)" which also means it doesn't work if you push a branch that says default should be tag (until you push a tag that says default should be tag). If the currently processing version is a tag, it's presumably the latest tag because GitHub Apps triggered it from a recent commit to it and you wouldn't need to search for it.

Not too sure about the benefits of removing it though

I just like to avoid redundancy

I don't quite consider it redundant (just like our WorkflowMode, cloudformation with default enum, circleCI with default enum, swagger parameters). The manual mode is the default mode that can be explicitly specified. I'm actually having a hard time finding an example elsewhere that doesn't have this behaviour.
So for others, I think this now boils down to 2 questions:

Do we remove being able to set the newest branch as the default
Do we remove being able to explicity set the defaultVersion to "MANUAL"

If we end up with yes to both, then I propose changing it to an optional property like:
setLatestTagAsDefault: true
or
setLatestTagAsDefault: false

If we end up with yes to both, then I propose changing it to an optional property like:
setLatestTagAsDefault: true
and
setLatestTagAsDefault: false

This is a big thread to process :)
Before going deeper, can you clarify what is the latest tag? From the code, it looks like the tag that was most recently processed by Dockstore. Which won't necessarily be the most recent tag on GitHub, although it most likely will be.
More generally, I'm struggling to get my head around this and the publish feature... Everything else in the .dockstore.yml is version specific, these two features apply to the workflow and depend on the order in which Dockstore processes GitHub events. Typically we should process the events in order, but I think that could depend on what people push. And what if we're down for maintenance when one event comes in, and the retry happens after we're back up and a newer event has already been processed -- the older event would win out.
Just brainstorming, and maybe I'm overthinking it.

If we end up with yes to both, then I propose changing it to an optional property like:
setLatestTagAsDefault: true
and
setLatestTagAsDefault: false

This is a big thread to process :)
Before going deeper, can you clarify what is the latest tag? From the code, it looks like the tag that was most recently processed by Dockstore. Which won't necessarily be the most recent tag on GitHub, although it most likely will be.
More generally, I'm struggling to get my head around this and the publish feature... Everything else in the .dockstore.yml is version specific, these two features apply to the workflow and depend on the order in which Dockstore processes GitHub events. Typically we should process the events in order, but I think that could depend on what people push. And what if we're down for maintenance when one event comes in, and the retry happens after we're back up and a newer event has already been processed -- the older event would win out.
Just brainstorming, and maybe I'm overthinking it.

This PR sets it to the most recently processed which although may not always be correct but is almost always correct. I consider it an ok tradeoff for the simplicity it brings.
Yes, I agree it's kind of odd to set workflow level information in what's supposed to be version level endpoint, but the publish property has set precendence so... 🤷

If we end up with yes to both, then I propose changing it to an optional property ...

I agree, I think I ended up here as well before.

the retry happens after we're back up and a newer event has already been processed -- the older event would win out.

I think so and this is why I wanted to confirm what we're doing. Currently, this PR is not doing

search all tags for the newest tag

We're actually doing  allow any new tag to become default depending on when events arrive.
Because the alternative is to actually search. Or at least use a SQL query to verify that there are no workflow versions newer than the "current" version being processed.  I think I agree with Gary on this one. Hopefully we're not down for long enough for people to be making multiple tags ... and caring about which one is last.

(was here from stand-up, agreed could use more opinions)

So for others, I think this now boils down to 2 questions:

Do we remove being able to set the newest branch as the default
Do we remove being able to explicity set the defaultVersion to "MANUAL"

If we end up with yes to both, then I propose changing it to an optional property like:
setLatestTagAsDefault: true
and
setLatestTagAsDefault: false

I think the optional property makes sense and is probably the least confusing for our users

For the first question, I do see Broad HCA's use case of having a tag become the latest being more useful than finding the most recently updated branch. I don't see the immediate use case for switching between branches automatically.
As far as 2, I think that this behavior is in general confusing and I don't think redundancy would hurt the use case much.

I'm think I'm OK with setLatestTagAsDefault proposal, but see nits below. I'm still not clear what "latest" is though -- is it the most recently processed tag, or the most recent tag, date-wise?

As mentioned multiple times (like at least 3 times) and the code should make it obvious.
"The version/tag that was just pushed is presumably the latest (which works for most cases)"
"This PR sets it to the most recently processed which although may not always be correct, it is almost always correct. I consider it an ok tradeoff for the simplicity it brings."

Nits: If I were a bioinformatics developer (which I'm not) with a versioned repo, I probably wouldn't use it. What if I had these tags:

v1.0
v1.1
v2.0
v2.1

If I had to do a patch for the 1.x, I'd create a v1.2 tag. It would be the most recent tag, but I wouldn't want it to be the default. Conversely, if I created a v2.2 tag, I would want it to become a default.

If I were a bioinformatics developer (which I'm not), I would want the version whose version number is closest to a prime number and whose character count is less than 3 to be the default (just because)
In reality, when looking at the first 20 or so workflows on https://dev.dockstore.net/search?entryType=workflows&searchMode=files , workflows almost never even get to a 2.0.0 or 2.0 release. If/when they do, the previous major version are never updated. That use case seems extremely limited for the confusion it may bring to users.

It's almost like there should be a workflow-level setting, where you specify the strategy:

yup, I prefer a workflow-level setting... someone stop me

Manual
Most recent by date
Most recently processed (maybe not)
Most recent by version label (which would only work if tags had the right naming convention)

But this is overkill, and I think the optional property works.

yup, overkill unless someone asks for it. Even newest version (instead of tag) is cut out, then this is even more unlikely.

Hmmm,  so thinking compromise for today
defaultVersionStrategy: latestTag and defaultVersionStrategy:manual (also if omitted) with the same behaviour as what Gary has coded up already
Thinking future ticket for Charles' case, if and only if requested by user for some future version of Dockstore 1.12+
defaultVersionStrategy: latestSemanticTag

Hmmm, so thinking compromise for today
defaultVersionStrategy: latestTag and defaultVersionStrategy:manual (also applicable if the field is omitted altogether) with the same behaviour as what Gary has coded up already
Thinking future ticket for Charles' case, if and only if requested by user for some future version of Dockstore 1.12+
defaultVersionStrategy: latestSemanticTag
Edit to add:
Alternatively,
setLatestTagAsDefault: true
with this as a future expansion
setLatestTagAsDefault: true
semanticTagsAsDefault: true

If it's two states (with one being suitable as "false"), then I prefer to not use an enum and just use a boolean. It just seems simpler. However, if we expect a third state anytime soon, then we may choose a third enum for backwards compatibility. Even so, a third state wouldn't be terriblly difficult since I've made no DB changes.
Not a fan of the
setLatestTagAsDefault: true
semanticTagsAsDefault: true

because it kind of conflicts with each other.

However, if we expect a third state anytime soon, then we may choose an enum for backwards compatibility. Even so, a third state wouldn't be terriblly difficult since I've made no DB changes.

Yeah, I do think Charles' request is a realistic possibility which is why I'm thinking enum.
But you're right, there are no DB changes so we could iterate the yaml version or even just have an enum down the road that overrides this boolean.

authors: NatalieEO coverbeck david4096 denis-yuen garyluu


text:
Issue with Reference in Doctrine DataFixtures

When loading the fixtures and adding the references the ProxyReferenceRepository.php on line 90 fails to get the reference due to the fact that the reference array differs from the rest of the generated fixture
references. see image:

I believe this is because the datafixture reference creation can't handle an entity that has multiple attributes as a primary key, after adding a simple Uuid and setting that as the lone primary key the issue is 'resolved' and my tests run successfully.
The error stack when unit testing is:
Array to string conversion
 /opt/project/vendor/symfony/phpunit-bridge/DeprecationErrorHandler.php:105
 /opt/project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:2956
 /opt/project/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:488
 /opt/project/var/cache/test/appTestDebugProjectContainer.php:4779
 /opt/project/vendor/doctrine/data-fixtures/lib/Doctrine/Common/DataFixtures/ProxyReferenceRepository.php:95
 /opt/project/vendor/doctrine/data-fixtures/lib/Doctrine/Common/DataFixtures/ProxyReferenceRepository.php:122
 /opt/project/vendor/liip/functional-test-bundle/Test/WebTestCase.php:421
 /opt/project/tests/Name/ApiBundle/Controller/SubjectControllerTest.php:26

Could you add the test that does this to doctrine/data-fixtures?

@Ocramius
    public function setUp()
    {
        $this->bootKernel();
        $this->fixtures = $this->loadFixtures(
            [
                LevelFixture::class,
                SubjectFixture::class,
                StudentFixture::class,
                StudentSubjectFixture::class
            ]
        )->getReferenceRepository();
    }

    public function test_get_subjects_success()
    {
        /** @var Student $student */
        $student = $this->fixtures->getReference('student-one');

        $data = [
            'student' => $student->getId()
        ];

        $client = static::createClient();

        $client->request('GET', '/v1/subjects/', $data);

        $response = $client->getResponse();

        $this->assertSame(200, $response->getStatusCode());
    }

@Ocramius I have diverted the issue by  adding a Uuid, but the error should be reproducable by creating for example; Subject and Student with a many to many relationship, and A StudentSubject entity that exists out of references to those two. I get the feeling that because it solely exists out of references that the code breaks.

Given reproducer is incomplete and this is not a proper repository to report this issue. If you still have this issue, please post it to doctrine/data-fixtures with a proper reproducer. Thank you for understanding!

authors: DD-Hussein Ocramius ostrolucky


text:
Some Recipient types missing excludedDocuments field

I'm looking at the Editor.cs and Signer.cs and those classes are missing the excludedDocuments field.  All recipient types, FWIU, must have this field.  The DocuSign REST API shows that this field is included for both Editor  and Signer.
Looks like CarbonCopy.cs does have it though, as well as InPersonSigner.cs.  I haven't checked all the possible recipient types though, but each recipient type must have that field implemented.

Actually Editor is the only one that can't be excluded.  I was referencing an older api doc.  Closing this issue.

repo: docusign/docusign-csharp-client


text:
feat(model): correctly store time data on read / write

Search Records must convert DD/MM/YYYY -> ISO 8061 form
Create Record must convert ISO 8061 form -> DD/MM/YYYY
Patch Record must convert ISO 8061 form -> DD/MM/YYYY
This is done to adhere to data formatting standards set
https://docusign.atlassian.net/browse/XPLAT-3581


text:
Support Java 14

The project's core can be compiled with Java 8, but there are test suites to exercise the latest and greatest Java.
Check if we need to upgrade the version of the ASM library to support Java 13 and try Scott's test suite with Java 14. Language related changes that the test suite should incorporate:

Patthern Matching preview
Switch expression standard
Text blocks 2nd preview
Records
And maybe Helpful NPEs

Bumped asm and javaparser versions. Java 14 preview features in https://github.com/javaparser/javaparser is still work in progress, so on the rendering level not all of them is supported.

repo: dodie/scott


text:
您好, 我在代码中没有找到混淆patch.jar的代码.

请问对patch.jar的混淆是在代码哪个部分进行的, 谢谢.

想通了.   dexTask着一些列过程 应该是已经在proguard过程以后了.

repo: dodola/RocooFix


text:
🛑 Dogchef partners is down

In 75f3b4c, Dogchef partners ($DOGCHEF_PARTNERS_URL?$BF) was down:

HTTP code: 403
Response time: 110 ms

Resolved: Dogchef partners is back up in 8fd67eb.

repo: dogchef-be/uptime-monitor


text:
depends: maintain glibc backcompat on focal for x86_64-apple-darwin11

In preparation for Ubuntu Bionic's end of standard support slated in April of 2023 which in turn has prompted GH Actions Bionic runner becoming fully deprecated on December 1st, 2022 (#3095, #3130), this PR kicks off the migration process by bumping x86_64-apple-darwin11's CI runner OS to Ubuntu Focal 20.04.
In order to accomplish that, I needed a minimal amount of cherry-picks from Bitcoin Core that:

fixed a bug that had to do with archive extraction when building depends: fff1711
bumped clang+llvm from 3.7.1 to 6.0.1 and corresponding build tools (native_cctools, ld64, libtapi): 901eaa3 and 0fff9eb

Once that was pulled in I encountered an issue with QT which is fixed with the patch found in 4314966:

After updating clang+llvm, QT 5.7.1's qfontengine_coretext.mm files variable QFixed errors out as it's a constructor rather than a type in this context. This patch fixes that error.

After I was able to emulate a successful build inside an ubuntu:focal container and in the following commit 9eb81d3 that bumped x86_64-apple-darwin11 matrix OS in CI I had to:

add 2 architecture specific packages: libbz2-dev, python-is-python3
drop duplicate of libtinfo5 from x86_64-apple-darwin11 packages

And finally I made the same changes as the previous commit only this time applicable for our gitian-osx.yml descriptor c930d8a:

temporarily bump docker conditional in gitian-builder to build bin/make-base-vm with ubuntu focal in gitian-build.sh script
bump suite to focal in gitian-osx.yml and replace python and python-setuptools with python3
additionally add python-is-python3 for PATH purposes and add libtinfo5 and xorriso
alphabetize packages list for easier management

Note that this currently disallows a seamless gitian build and folks will have to (after failure when transitioning from osx to windows), build a base-vm for bionic in order to resume building windows and linux archives. I've not yet completed that step but did successfully compile for osx:
cf3eeab11481f3b60e4e2791dc29a11b099c025b9d490d8d4b68e4776e40b868  dogecoin-1.14.7-osx-unsigned.dmg
37d854c9fed8541dca877830338ba72bb4a89b229d7a71e16414b535205b2582  dogecoin-1.14.7-osx-unsigned.tar.gz
cf069aeec64d6b848fb0e4a18e6dab03111d33512acea5a027c7bc43942bc30d  dogecoin-1.14.7-osx64.tar.gz
7136259be06e9ce6bd791476921197ec6087d87461b169c6a429b2869077a156  src/dogecoin-1.14.7.tar.gz
d96a40c1e43924ac54e36eb71a272fddef7c00e807c14e8b9920ec4a8f726175  dogecoin-osx-1.14-res.yml

First off, thanks a bunch for this! The osx-on-focal build problems have been haunting us for over a year and this seems to be a working solution. Thank you!
I did a check on (what is now) 4314966 before this PR was raised, and according to otool, backward compatibility in terms of dynamically linked libraries is exactly the same as with the 1.14.6 released binary (which was built with clang 3.7, so I think we ought to be thankful for clang being awesome too 😁). The gist with output can be found here and I'll see if I can update the symbol check script in contrib/devtools to use otool on cross-compiles and automate this process for CI, as Bitcoin also does in newer versions of the script.

It's my pleasure and I forgot to note that those osx checksums were from a build reproducible (fingers crossed) with the following invocation (with assumption you do so in ./contrib so adjust accordingly): ./gitian-build.sh --docker --setup --build -u https://github.com/xanimo/dogecoin -c c930d8a66861e46a5e2d28e2055bc4a57c022410

Good news: My gitian+docker built shasums match yours
Bad news: I am still working on getting a reliable gitian+lxc setup for this
Some high-level observations:

I think that we'll need to separate fff1711 and 4314966 from this PRs (pref individually.) These influence every build, not just gitian-osx, so we'll need to validate those changes across all builds, which is difficult when we have different base OSs. I assume that these changes are also valid with the current bionic-based gitian descriptors - if I am wrong about that ignore this bullet point.
Can we instead of python-is-python3 just call python3 instead of python like we do everywhere else? What's causing it to fail without this package?
"alphabetize packages list for easier management" and "drop duplicate of libtinfo5 from x86_64-apple-darwin11 packages"- can we do these separately? It's hard to judge the diff this way (now and in the future). I'm okay with a refactor commit in a preceding PR (much like the commits from bullet point 1)
"temporarily bump docker conditional in gitian-builder to build bin/make-base-vm with ubuntu focal in gitian-build.sh" script -> please put this in a separate commit

Good news: My gitian+docker built shasums match yours Bad news: I am still working on getting a reliable gitian+lxc setup for this

I've just built ./gitian-build.sh --docker --setup --build -u https://github.com/xanimo/dogecoin -c a6bcaedcea231bfe4dced1867b4c30824e95353a and got the following checksums for osx:
39244aac1338b4ff91fb53f00204b4516e04a9379c235fc544e26c892f50bf09  gitian-output/dogecoin-binaries/a6bcaedcea231bfe4dced1867b4c30824e95353a/dogecoin-1.14.7-osx64.tar.gz
4101e65ae2d24600494c61db745fea23197d1019dce2285532befcfbd4007e69  gitian-output/dogecoin-binaries/a6bcaedcea231bfe4dced1867b4c30824e95353a/dogecoin-1.14.7-osx-unsigned.dmg
f8cc436df77d5d88ff606ef4760a1423ad7507a416dd0809d2a800baa0dca320  gitian-output/dogecoin-binaries/a6bcaedcea231bfe4dced1867b4c30824e95353a/dogecoin-1.14.7-osx-unsigned.tar.gz
1d2e8e831c9492ee630e558ba0d248a4807b489b7249f5a09c603edaa7dee83c  gitian-output/dogecoin-binaries/a6bcaedcea231bfe4dced1867b4c30824e95353a/dogecoin-1.14.7.tar.gz

I made a note to modify the make-base-vm invocation for everything (not just docker) in the gitian-build script so hopefully that will work on yours and others systems.

Some high-level observations:
* I think that we'll need to separate [fff1711](https://github.com/dogecoin/dogecoin/commit/fff171115c37dccd8b48d927c1c46e6e16c05cae) and [4314966](https://github.com/dogecoin/dogecoin/commit/4314966ff82efa0a30c00ee7ed1ee1262fc2ded1) from this PRs (pref individually.) These influence every build, not just gitian-osx, so we'll need to validate those changes across all builds, which is difficult when we have different base OSs. I assume that these changes are also valid with the current bionic-based gitian descriptors - if I am wrong about that ignore this bullet point.

It turns out fff1711 is not entirely necessary so I'm holding back on opening an additional PR for now but I have dropped it from this one. I did however open one for 4314966 which can be found here: #3141

* Can we instead of `python-is-python3` just call `python3` instead of `python` like we do everywhere else? What's causing it to fail without this package?

I've stricken python-is-python3 and instead updated any use of python to python3 in native_biplist.mk, native_ds_store.mk and native_mac_alias.mk in dogecoin/depends/packages/ (These packages were points of failure when building depends on ubuntu >= focal)

* "alphabetize packages list for easier management" and "drop duplicate of libtinfo5 from x86_64-apple-darwin11 packages"- can we do these separately? It's hard to judge the diff this way (now and in the future). I'm okay with a refactor commit in a preceding PR (much like the commits from bullet point 1)

I have split these up into more atomic commits per your request.

* "temporarily bump docker conditional in gitian-builder to build bin/make-base-vm with ubuntu focal in gitian-build.sh" script -> please put this in a separate commit

Done :+1:

It turns out https://github.com/dogecoin/dogecoin/commit/fff171115c37dccd8b48d927c1c46e6e16c05cae is not entirely necessary so I'm holding back on opening an additional PR for now but I have dropped it from this one.

Yes, we can either do it up front or after we have a full gitian/ci upgrade to focal merged. If it doesn't hurt in bionic, feel free to open it up now - from the commit description I feel it makes building depends more portable

I did however open one for https://github.com/dogecoin/dogecoin/commit/4314966ff82efa0a30c00ee7ed1ee1262fc2ded1 which can be found here: https://github.com/dogecoin/dogecoin/pull/3141

I was anyway planning to tag this PR with "do not merge yet" so I'm doing that and am not going to map out cross-PR dependencies for this in the review board right now, because updating the build environment is very much an all-or-nothing thing.

I have split these up into more atomic commits per your request.

Can you pull these prior and separate like with #3141? I am trying to separate independent refactor / cleanup from functional change - the whole of switching to focal is going to be huge so I think it's in our best interest to keep the scope of the PRs as small as possible.

Tagged do-not-merge until we have all gitian build targets ready for merge.

Absolutely, I'll leave this intact as a reference point for what was needed to achieve successful build on CI and macOS gitian build and pull the ones that are compatible with our existing systems into standalone PRs.
Re fff1711, I realized late last night/early this morning that 3773c63 and 0e3b006 already include partial changes related (tar --no-same-owner...) so I think it would behoove us to pull that which I'll do in a separate standalone PR akin to #3141. And agreed on the depends build portability aspect. I can confirm that it's unobtrusive and works on bionic too according to this run from yesterday: https://github.com/xanimo/dogecoin/actions/runs/3260954920
No worries re do not merge, this is a big change so best to dot our i's and cross our t's :+1:

Tagged Blocked in review board, until we merge the extracted PRs, rebase and have a full focal gitian for all build targets

authors: patricklodder xanimo

repo: dogecoin/dogecoin


text:
Implement simple DNS based discovery.

What change does this introduce?
This PR implements "simple" DNS based discovery.  This is not "DNS-SD", but rather a mechanism that queries a single host and treats each address in the result as a separate target.
Why make this change?
This is part of migrating the discovery system from dogmatiq/configkit.  This particular discoverer is useful under Docker: It is possible to give multiple separate services the same alias on a network. Performing a DNS query against that alias name returns the addresses of all of the containers running across all of those services.
Is there anything you are unsure about?
No
What issues does this relate to?
Partially addresses #1
Based on the branch of PR #7

Sorry, I jumped the gun on this one - it should still be a draft because it depends on #7 being merged first.

Thanks man.

repo: dogmatiq/discoverkit


text:
Documentation: search for multiple fields

In an application I am writing I need to be able to match on multiple fields in an AND combination. I am pretty sure the example given for multiple fields is an OR (but I am not 100% sure). How would I go about saying "title: Deno and language: TypeScript", for example?

You have the possibility to send all kind of queries in query object. It's directly sent to Elasticsearch. So you can search for how to match multiple fields in Elasticsearch.
Basically you should be able to that:
const res: SearchResponse<Source> = await client.search<Source>({
  target: "test-index",
  body: {
    query: {
      // send the query to match multiple fields,
    },
  },
});

Yea my bad, I was confused because I was trying to compare Node ES and Deno ES and I now realize that I can just look up the rest API. Thank you for bearing with me.

authors: dogukanakkaya nsadeh

repo: dogukanakkaya/deno-elasticsearch


text:
Feedback for “Parallax”

The documentation seems to be out of step with the api, suggesting that onProgressChange={progress} will work when progress is defined as const progress = useSharedValue<number>(0);
When I implemented this my IDE complained about a typescript error and the app crashed with an error from reanimated.
What I am observing is that onProgressChange needs a callback with the following function signature.
  const offsetProgress = useSharedValue<number>(0);
  const absoluteProgress = useSharedValue<number>(0);
  const handleProgressChange = (newOffsetProgress: number, newAbsoluteProgress: number) => {
    offsetProgress.value = newOffsetProgress;
    absoluteProgress.value = newAbsoluteProgress;
  }

So that the prop in question is now onProgressChange={handleProgressChange}
For react-native-reanimated-carousel 3.5.1

Thanks bot, since we are chatting, do you know how to set the centre "focus" item in a long horizontal parallax carousel?

repo: dohooo/react-native-reanimated-carousel


text:
3주차 스프링

3주차 스프링

LGTM😊


text:
Unsupported activity types

I get an error: [ERROR]: Statements contain unsupported activity types: ['SSP']. Please, check documentation.
As I see it the SSP type is the stock split.

Yes, SSPs are the stock split events. Support for those activities is in development.

Same here.

SSP and MAS activities are now supported.
https://github.com/doino-gretchenliev/revolut-stocks/commit/e0bff741581581a85b0fe67dcc74ba40c6f39490

repo: doino-gretchenliev/revolut-stocks


text:
Can no longer move left with shortcut

Not sure what changed by I can no longer jump to the left pane. Here's relevant .vimrc entries:
nnoremap <silent> ;h :TmuxNavigateLeft<cr>
nnoremap <silent> ;j :TmuxNavigateDown<cr>
nnoremap <silent> ;k :TmuxNavigateUp<cr>
nnoremap <silent> ;l :TmuxNavigateRight<cr>

This is happening on two different macs.
When I hit ;h to the left pane, here's what happens:

I get some kind of "print this list" option. No idea what that is or where it is coming from.

OK, some other plugin called documap was interfering with the ;h command. Not sure why it suddenly started acting up. Had it installed for as long as I can remember.

repo: dojoteef/tmux-navigate


text:
Low Performance of the IDE

Describe the bug
After version 74, it's impossible to work in the IDE. First time I noticed it in PyCharm when I was coding in a django project. Because of freezing PyCharm all the time, I didn't like to code in it. However, when I updated The Doki Theme from version 22 to 74, Rider also started to freeze all the time. Especially when I try to build or save. I have to wait very long time to do anything (minimum 2 minutes to get control from the IDE). I thought I need to update the IDE, so I updated Rider to the latest version. But it didn't help. The IDE continued to freeze. I disabled all default plugins, that I didn't use (they are pretty much), but it also didn't help. In the end I disabled The Doki Theme, and to my surprise the IDE started to work well.
To Reproduce

Update to version 74
Start to code

Expected Behavior
To work without brakes.
Environment
JetBrains Rider 2021.3.3
Build #RD-213.6775.4, built on January 26, 2022
Runtime version: 11.0.13+7-b1751.25 amd64
VM: Dynamic Code Evolution 64-Bit Server VM by JetBrains s.r.o.
Memory: 3072M
Cores: 4
Non-Bundled Plugins:
    io.unthrottled.theme.randomizer (0.2.1)
    io.unthrottled.amii (0.14.0)
    io.unthrottled.amii.rider (0.4.0)
    io.acari.normandy.progress.bar (1.9.11)
    izhangzhihao.rainbow.brackets (6.21)

PyCharm 2021.2.2
Build #PY-212.5284.44, built on September 14, 2021
Runtime version: 11.0.12+7-b1504.28 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Memory: 2048M
Cores: 4
Registry: ide.intellij.laf.enable.animation=true
Non-Bundled Plugins:
    io.unthrottled.theme.randomizer (0.2.0)
    io.acari.normandy.progress.bar (1.9.10)
    io.acari.DDLCTheme (74.1-1.0.0)
    io.unthrottled.amii (0.14.0)
    izhangzhihao.rainbow.brackets (6.21)

OS: Windows 10
Plugin version: 74.1-1.0.2
Videos
I captured 2 videos. In first I coded with enabled The Doki Theme, in second with disabled. I coded in a small project. Because I wanted to show you what happens even in a small project (also, in a big project the IDE freezes really for a long time).
With plugin
Without plugin

This is going to be a pretty difficult bug for me to find, without getting diagnostic information. Once I figure out how to do that, I'll ask things of you.

I disabled all default plugins, that I didn't use (they are pretty much), but it also didn't help. In the end I disabled The Doki Theme, and to my surprise the IDE started to work well.

Does the issue still persist if you removed all non-bundled plugins, and just use a vanilla/non-fancy theme add-on? Like this one https://plugins.jetbrains.com/plugin/12310-gruvbox-theme .

Does the issue still persist if you removed all non-bundled plugins, and just use a vanilla/non-fancy theme add-on? Like this one https://plugins.jetbrains.com/plugin/12310-gruvbox-theme .

The IDE doesn't freeze in gruvbox

However, when I updated The Doki Theme from version 22 to 74

So 22 was usable, but 74 isn't right?

I think yes. In version 22 it didn't freeze.

Aight, well, I'll ask around to see if there is an easy way to diagnose the issue.
Would like to fix it, and still have all of the current features provided.
I may need to revisit what I have now, and might supply a light-weight and heavy-weight version of the plugin (just an option, if I can't find root cause).

OK, thanks.

You can use the jstack tool to get the call stack of the current thread when the IDE is frozen, which may be used to locate the problem.

@NekoCaffeine
That was actually very useful! Thanks again for your JVM wizardry knowledge!
I was able to replicate the issue. I think it may have to do with a recursive SVG patching issue with the Normandy & Doki plugin running on the AWT event thread..........
JStack dump captured when the IDE was frozen.
test14.txt
I've got a bunch of other things that I need to look at, but that seems most suspect. Considering there are a bunch of SVG icons that probably need to be patch n stuff, and it is running on the AWT thread.

Sure.
I tested in Yuki Theme, the IDE doesn't freeze. Before, it froze for a very long time in that project, so long that I had to close Rider and relaunch it.

Great, thanks!
All of my other IDEs are acting dumb/freezing, and the thread dumps all have the infinite recursion stack in theme.
Since the issue goes away when one or the other plugin is disabled, I'm going to say that that is the issue. I'll have a fix out that should address this issue.

authors: Dragon-0609 NekoCaffeine Unthrottled

repo: doki-theme/doki-theme-jetbrains


text:
Alexa doesn't start

Hi,
I successfully finished Alexa and Audio setup but Alexa doesn't appear but as soon as I activate Alexa in the config the 'Wetterwarnungen' moves from the right side to the middle of the screen. Alexa doesn't also react on an voice command.

Thanks for your help

Hello, Can you please help me with how you got it to work in the first place? I followed all the instructions in this YouTube video  to set up Amazon Developer account and set up an Alexa Device. I also went through all the steps in this github rep  and this github wiki. I obtained all the codes needed (client id, secret, product id, and refresh token, etc). After I did all the steps, every time I add the config to my magic mirror configuration file the screen go black and nothing works! I tried with my credentials and without it and in both cases the result is the same. Also, I tried the config in both formats, i.e.,
{
"module": "MMM-awesome-alexa",
"position": "bottom_bar",
"config": {
"wakeWord": "Alexa",
"clientId": "YOUR_CLIENT_ID",
"clientSecret": "YOUR_CLIENT_SECRET",
"deviceId": "YOUR_DEVICE_ID",
"refreshToken": "YOUR_REFRESH_TOKEN",
"lite": false,
"isSpeechVisualizationEnabled": false
}
}
and
{
module: "MMM-awesome-alexa",
position: "bottom_bar",
config: {
wakeWord: "Alexa",
clientId: "YOUR_CLIENT_ID",
clientSecret: "YOUR_CLIENT_SECRET",
deviceId: "YOUR_DEVICE_ID",
refreshToken: "YOUR_REFRESH_TOKEN",
lite: false,
isSpeechVisualizationEnabled: false
}
}
Can you help me figure out what I am doing wrong? this is so much appreciated.

Added documentation here on why it breaks and how to fix:
https://awesome-alexa.js.org/#/installation?id=modifying-magicmirror-electron

authors: AWSb24 SamerAl-khateeb dolanmiu

repo: dolanmiu/MMM-awesome-alexa


text:
How to show C# MaxLength Data Annotation on FromQuery Parameter properties?

I have this method which uses FromQuery parameter binding:
        [HttpGet()]
        [ApiConventionMethod(typeof(DefaultApiConventions), nameof(DefaultApiConventions.Get))]
        public async Task<ActionResult<List<Order>>> GetOrders([FromQuery] OrdersQueryParameter ordersQueryParameter)
        {
            var data = await _orderHander.GetAsync(ordersQueryParameter);

            #region Pagination Metadata

            var resourcePagingMeta = new ResourcePagingMetadata(data.Item2, ordersQueryParameter.PageNumber, ordersQueryParameter.PageSize);
            var resourceMeta = ResourcePagingHelpers.CreateResourceUri(resourcePagingMeta, ordersQueryParameter, _linkGenerator, HttpContext);
            Response.Headers.Add("X-Pagination", JsonConvert.SerializeObject(resourceMeta));

            #endregion Pagination Metadata
            // Have to return List to allow XML Serialization formatter to work; IEnumerable not work
            return Ok(data.Item1.ToList());
        }

I used following data annotaion: Required and MaxLength
    public class OrdersQueryParameter : ResourcesQueryParameter
    {
        /// <summary>
        /// Test number
        /// </summary>
        /// <value></value>
        [MaxLength(3)]
        [Required]
        public string Number { get; set; }
        ...

But in Swagger UI and schema, the MaxLength is not produced and display (it only show required attribute)

So how can I display the MaxLength in Parameter like in the returned data schema?
For example, this is what I want:

This is a question/feature request for the swagger-ui folks rather than Swashbuckle. I suggest you create a corresponding issue in that repo and link here fore tracking.

This is a question/feature request for the swagger-ui folks rather than Swashbuckle. I suggest you create a corresponding issue in that repo and link here fore tracking.

Closing as external.

authors: DatXN domaindrivendev martincostello


text:
Structural error when using UseInlineDefinitionsForEnums

When using UseInlineDefinitionsForEnums() swashbuckle v5.0.0 generates enum definitions inline but inserts description property inside items:
    "parameters": [
      {
        "in": "query",
        "name": "arrayofenums",
        "description": "Array containing enums",
        "required": true,
        "type": "array",
        "items": {
          "description": "Defines values for TestEnum.",
          "enum": [
            "TestEnumValue1",
            "TestEnumValue2",
            "TestEnumValue3"
          ],
          "type": "string"
        }
      }
    ],

and this is reported as structural error by editor.swagger.io:
Structural error at paths./test.get.parameters.0.items
should NOT have additional properties
additionalProperty: description

Opening this as suggested by @domaindrivendev in https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/1329#issuecomment-595240341_

@older could you please create a minimal app (i.e. starting from empty project), and using the latest version of SB, that repro's this issue and post to github so I can pull it down and troubleshoot.

@older could you please create a minimal app (i.e. starting from empty project), and using the latest version of SB, that repro's this issue and post to github so I can pull it down and troubleshoot.

@domaindrivendev I cannot reproduce it any more. And I tried both with Swashbuckle.AspNetCore 5.0.0 and 5.6.3.
Could it be that it was fixed in some upstream dependency? I only have the latest 5.0.102 SDK installed so I tested only with this SDK version.

@domaindrivendev I cannot reproduce it any more. And I tried both with Swashbuckle.AspNetCore 5.0.0 and 5.6.3.
Could it be that it was fixed in some upstream dependency? I only have the latest 5.0.102 SDK installed so I tested only with this SDK version.

authors: domaindrivendev older


text:
swagger ui with route prefix cant find o2c.html

After authentication the redirect url is not found. UI is correctly hosted and found. I put this in stack overflow but I think its a bug https://stackoverflow.com/questions/49171897/swagger-ui-with-route-prefix-cant-find-o2c-html.
Following are the log messages
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
Request starting HTTP/1.1 GET http://localhost:9092/hole/api/swagger/o2c.html
dbug: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler[9]
AuthenticationScheme: Bearer was not authenticated.
dbug: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[5]
The request path /o2c.html does not match an existing file
dbug: Microsoft.AspNetCore.Builder.RouterMiddleware[1]
Request did not match any routes.
Startup
app.UseSwagger(c => { c.RouteTemplate = $"{Startup.ServiceName}/{{documentName}}/swagger.json"; });
app.UseSwaggerUI(c =>
{
    c.RoutePrefix = $"{Startup.ServiceName}/swagger";
    c.SwaggerEndpoint($"/{Startup.ServiceName}/v1/swagger.json", "Hole Service API V1");

    if (securitySettings.EnableSecurity)
    {
        //HACK
        c.OAuth2RedirectUrl("http://localhost:9092/hole/api/swagger/o2c.html");
        c.OAuthClientId(swaggerAuthenticationOptions.ClientId);
        c.OAuthRealm("swagger-ui-realm");
        c.OAuthAppName("API Swagger UI");
    }
});

If I leave redirect at default url is http://localhost:9092/hole/api/swagger/oauth2-redirect.html but that is not accepted by our identity service.

/oauth2-redirect.html is the new redirect URL that ships with the 3x version of swagger-ui. Can't you just update your identity service to accept this instead of the old value?
If that's really not an option, you could take a look at the ASP.NET Core URL rewrite module to rewrite the old url to the new one.

authors: bklooste domaindrivendev


text:
System.Reflection.Missing showing as string default value in rc5 * .net core 3.1

So... I'm not sure what is going on...
Here is an image of how part of the json looks on firefox.

I'm porting an existing api from .net core 2.2 to .net core 3.1. Some of the endpoints with this error actually work, they just show this on the UI too. I'm also not sure if this could cause issues when generating client files.

This was happening because the method parameters had "[Optional]"

repo: domaindrivendev/Swashbuckle


text:
Deployment: a Helm chart for k8s

First of all, thanks for an awesome project!
This is not really an issue, but more like a question - has anyone deployed this to k8s already / is there a Helm chart version of the sharegpt already?
Would certainly be great to have an ability to deploy sharegpt on our own premises, since using a public instance of sharegpt is not easy to justify in environments, that are super strict about security / compliance.

Hey @gmile, don't think this exists atm. Is this what you need?

Be able to configure a share location for the Chrome Extension other than sharegpt.com
Self-host a version of the app like sharegpt-onprem.com
Share to that on-prem version

Any more context as to how you've been using this so far super helpful

I'm interested in this as well, and have a bare-bones docker-compose.yml that I put together a few days ago.  Didn't want to waste too much time on it until the license issue is clarified (#36)

Have added a license @jjmata – hope this helps

authors: domeccleston gmile jjmata

repo: domeccleston/sharegpt


text:
Schema deletion + plan functionality

Hello,
Thanks for this nice tool ! In your README you speak about the kafka-gitops analogy.
I see two differences mainly:

there is no real "plan" functionality. Does the validate CLI option query the schema-registry to see if there is an update to do or not ?
I played a bit and I see that if I remove a schema from the configuration, this later is not deleted from the schema registry: Is it intentional ? I personally prefer to have it removed but of course, I would need to be able to see it in a "plan" before

Best,
Jerome

Hello Jerome,
first of all: thank you for considering schema-registry-gitops!
Right now, it does not really "plan" in the sense that it will check if there is an update to do. All it does is check if the changes are compatible. But it is on my roadmap to implement a real plan functionality like kafka-gitops does.
Not deleting anything is intentional as all the use cases I had where microservices where each service manages it's schemas itself and must not delete schemas that belong to other services. That is on the roadmap also, but it will not be default mode, rather be explicitely activated by a CLI switch.
Does that answer all your questions?

Hi @domnikl ,
Thanks a lot for the explanation !  My objective is a bit more strict indeed as I do not want the applications register or update the schema outside of the CI.
FYI, in the meantime, I just made a PR on kafka-gitops for this functionality if you are interested or just curious ;-) : https://github.com/devshawn/kafka-gitops/pull/76
Best,
Jerome

I implemented plan and delete in the current master - replacing validate as that must be done implicitely anyways. Will release it as a new major version soon. Your PR is very interesting, tough, thanks for the link!

Really nice @domnikl !
Just as of curiosity, how did you do the diff ? I wanted to do it in my MR but did not had time yet.
Best,
Jerome

authors: domnikl jrevillard

repo: domnikl/schema-registry-gitops


text:
Check whether the "Higher" module works

In MAML we uses "Higher" module which is a library providing support for higher-order optimization developed by Facebook.
It turns existing torch.nn.Module instances "stateless", meaning that changes to the parameters thereof can be tracked.
It is needed to be checked whether the implemented Higher module really tracks the parameters of policy at both outer loop and inner loop.

LGTM!


text:
Guru Meditation Error

When I introduce the "make monitor" after the "make flash", the mysis32 take loop message, and inside of the loop, there is an error that says " Guru Meditation Error: Core  0 panic'ed (StoreProhibited). Exception was unhandled."
Its the only error in the loop, and the i have proved the camera example, and it works and take image in the ip...
Anybody have ever seen this? Anybody knows solve the problem?
thanks

I haven't met this problem.Can you provide more detail?

Yes...
The program doesn't compile correctly and get a cyclic message, with information about the module  ESP and operations thats makes correctly. But inside of the cyclic message, there is a error that says "guru Meditation......"
its like an unfinished compilation...as if the program doesen't get the whole compilation and it failed in a point of it...
The config is ok, the camera pins are configured correctly

Please check the power .The current should be over 1A.Can you show your device picture.


text:
[JP] Add an example for handling of duplicates in list substraction

#642

Thanks, @hinamiyagk!

authors: hinamiyagk nscyclone

repo: doomspork/elixir-school


text:
How to use this repository for a cobot

I have a cobot made by doosan just like UR robot . And I have ROS 2 Support of it. How to use DORA along with it to train a robot. The major issue with that is they won't be having leader and follwwr configuration. So we need some kind of teleoperative interface (gamepad or keyboard) . How to make doraand act policy support for these kind of robots. If any one can suggest me a pipeline I can work on it

Yes, so I am still iterating on the process but i have added a dora-keyboard: https://github.com/dora-rs/dora/tree/main/node-hub/dora-keyboard that makes it possible to collect keystroke into dora and then control a robot.
I use this to then do inverse kinematics ( send cartesian position ) to the robot to make it moves.
The idea is then to collect those keyboard teleoperated data using a recorder and then generating a policy out of it,
We are still iterating on the design for ACT but it will also be a supported platform.

authors: SakethTecholution haixuanTao

repo: dora-rs/dora-lerobot