text:
Add support for overloading comparison operations in relay (#2910)

This commit adds support for overloaded comparison operators in the python binding for relay. I'm not sure how best to add testcases for this and couldn't find any obvious examples. A simple python script that uses all the comparison operators as in the issue #2910 report works just fine.
This is my first contribution to tvm, so all suggestions are welcome.

Looks good, could you add some tests cases to ensure it is working as intended?

Thanks for the feedback . I've had a look and tried to add some testcases and there was something that puzzled me and I don't fully understand.
I would have expected a testcase like this to pass.
from tvm import relay
a = relay.Var("a")
b = relay.expr.const (1.0, dtype='float32')
c = (a == b)
d = relay.equal(a, b)
assert (c.astext() == d.astext())
while
c = (a < b)
d = relay.less (a, b)
assert (c.astext () == d.astext ())
passes.
Any clues / suggestions ?

We don't overload equality because it interacts with Python's collections is ways which are not desirable. You should just test the comparisons you added.
We can add an english method for checking equality if we want.

ping @u99127

@tqchen - sorry I've been a bit busy recently. I've now pushed in my updates with the tests.

thanks @u99127 , this PR is now merged

authors: jroesch tqchen u99127


text:
XGBoost Fails with Polars DataFrames Containing Categorical Columns

XGBoost raises a ValueError when trying to train a model with a Polars dataframe with categorical data.
import polars as pl
import xgboost as xgb

X = pl.DataFrame({
    'num1': [1, 2, 3, 4],
    'cat1': ['A', 'B', 'A', 'B']
})

y = pl.Series('age', [10, 9, 8, 11])
X = (X
     .with_columns(cat1=pl.col('cat1').cast(pl.Categorical))
     )

clf = xgb.XGBRegressor(enable_categorical=True)
clf.fit(X, y)

Error:
{
	"name": "ValueError",
	"message": "could not convert string to float: 'A'",
	"stack": "---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[7], line 17
     15 # Attempt to train an XGBoost model
     16 clf = xgb.XGBRegressor(enable_categorical=True)
---> 17 clf.fit(X, y)

File ~/.envs/menv/lib/python3.10/site-packages/xgboost/core.py:726, in require_keyword_args.<locals>.throw_if.<locals>.inner_f(*args, **kwargs)
    724 for k, arg in zip(sig.parameters, args):
    725     kwargs[k] = arg
--> 726 return func(**kwargs)

File ~/.envs/menv/lib/python3.10/site-packages/xgboost/sklearn.py:1081, in XGBModel.fit(self, X, y, sample_weight, base_margin, eval_set, verbose, xgb_model, sample_weight_eval_set, base_margin_eval_set, feature_weights)
   1079 with config_context(verbosity=self.verbosity):
   1080     evals_result: TrainingCallback.EvalsLog = {}
-> 1081     train_dmatrix, evals = _wrap_evaluation_matrices(
   1082         missing=self.missing,
   1083         X=X,
   1084         y=y,
   1085         group=None,
   1086         qid=None,
   1087         sample_weight=sample_weight,
   1088         base_margin=base_margin,
   1089         feature_weights=feature_weights,
   1090         eval_set=eval_set,
   1091         sample_weight_eval_set=sample_weight_eval_set,
   1092         base_margin_eval_set=base_margin_eval_set,
   1093         eval_group=None,
   1094         eval_qid=None,
   1095         create_dmatrix=self._create_dmatrix,
   1096         enable_categorical=self.enable_categorical,
   1097         feature_types=self.feature_types,
   1098     )
   1099     params = self.get_xgb_params()
   1101     if callable(self.objective):

File ~/.envs/menv/lib/python3.10/site-packages/xgboost/sklearn.py:596, in _wrap_evaluation_matrices(missing, X, y, group, qid, sample_weight, base_margin, feature_weights, eval_set, sample_weight_eval_set, base_margin_eval_set, eval_group, eval_qid, create_dmatrix, enable_categorical, feature_types)
    576 def _wrap_evaluation_matrices(
    577     missing: float,
    578     X: Any,
   (...)
    592     feature_types: Optional[FeatureTypes],
    593 ) -> Tuple[Any, List[Tuple[Any, str]]]:
    594     \"\"\"Convert array_like evaluation matrices into DMatrix.  Perform validation on the
    595     way.\"\"\"
--> 596     train_dmatrix = create_dmatrix(
    597         data=X,
    598         label=y,
    599         group=group,
    600         qid=qid,
    601         weight=sample_weight,
    602         base_margin=base_margin,
    603         feature_weights=feature_weights,
    604         missing=missing,
    605         enable_categorical=enable_categorical,
    606         feature_types=feature_types,
    607         ref=None,
    608     )
    610     n_validation = 0 if eval_set is None else len(eval_set)
    612     def validate_or_none(meta: Optional[Sequence], name: str) -> Sequence:

File ~/.envs/menv/lib/python3.10/site-packages/xgboost/sklearn.py:1008, in XGBModel._create_dmatrix(self, ref, **kwargs)
   1006     except TypeError:  # `QuantileDMatrix` supports lesser types than DMatrix
   1007         pass
-> 1008 return DMatrix(**kwargs, nthread=self.n_jobs)

File ~/.envs/menv/lib/python3.10/site-packages/xgboost/core.py:726, in require_keyword_args.<locals>.throw_if.<locals>.inner_f(*args, **kwargs)
    724 for k, arg in zip(sig.parameters, args):
    725     kwargs[k] = arg
--> 726 return func(**kwargs)

File ~/.envs/menv/lib/python3.10/site-packages/xgboost/core.py:878, in DMatrix.__init__(self, data, label, weight, base_margin, missing, silent, feature_names, feature_types, nthread, group, qid, label_lower_bound, label_upper_bound, feature_weights, enable_categorical, data_split_mode)
    875     assert self.handle is not None
    876     return
--> 878 handle, feature_names, feature_types = dispatch_data_backend(
    879     data,
    880     missing=self.missing,
    881     threads=self.nthread,
    882     feature_names=feature_names,
    883     feature_types=feature_types,
    884     enable_categorical=enable_categorical,
    885     data_split_mode=data_split_mode,
    886 )
    887 assert handle is not None
    888 self.handle = handle

File ~/.envs/menv/lib/python3.10/site-packages/xgboost/data.py:1259, in dispatch_data_backend(data, missing, threads, feature_names, feature_types, enable_categorical, data_split_mode)
   1257 if _has_array_protocol(data):
   1258     array = np.asarray(data)
-> 1259     return _from_numpy_array(array, missing, threads, feature_names, feature_types)
   1261 converted = _convert_unknown_data(data)
   1262 if converted is not None:

File ~/.envs/menv/lib/python3.10/site-packages/xgboost/data.py:253, in _from_numpy_array(data, missing, nthread, feature_names, feature_types, data_split_mode)
    251 \"\"\"Initialize data from a 2-D numpy matrix.\"\"\"
    252 _check_data_shape(data)
--> 253 data, _ = _ensure_np_dtype(data, data.dtype)
    254 handle = ctypes.c_void_p()
    255 _check_call(
    256     _LIB.XGDMatrixCreateFromDense(
    257         _array_interface(data),
   (...)
    264     )
    265 )

File ~/.envs/menv/lib/python3.10/site-packages/xgboost/data.py:224, in _ensure_np_dtype(data, dtype)
    222 if _array_hasobject(data) or data.dtype in [np.float16, np.bool_]:
    223     dtype = np.float32
--> 224     data = data.astype(dtype, copy=False)
    225 if not data.flags.aligned:
    226     data = np.require(data, requirements=\"A\")

ValueError: could not convert string to float: 'A'"
}

Expected result: That it works like pandas
import polars as pl
import xgboost as xgb

X = pl.DataFrame({
    'num1': [1, 2, 3, 4],
    'cat1': ['A', 'B', 'A', 'B']
})

y = pl.Series('age', [10, 9, 8, 11])
X = (X
     .with_columns(cat1=pl.col('cat1').cast(pl.Categorical))
     )

clf = xgb.XGBRegressor(enable_categorical=True)
clf.fit(X.to_pandas(), y)

We haven't supported polars yet. I'm hoping https://github.com/dmlc/xgboost/issues/10452 can help XGBoost manage the variety of dataframe inputs. We currently have cuDF, pandas, pyarrow (no categorical support yet due to missing feature in pyarrow the last time we check), and datatable. The dispatching code is getting out of hand now.

source: gharchive/issue

authors: mattharrison trivialfis

repo: dmlc/xgboost

license_type: permissive

license_source: github-api


text:
xgb.XGBClassifier and xgb.train give very different results

I have found that xgb.XGBClassifier fit and predict, and xgb.train + xgb.predict are giving hugely different answers.
I started off by using xgb.train + predict to get a quick look at how my data set trains. Things went well with a auc of 0.8 when comparing the prediction of the training y to the predicted yhat.
I then used the xgb.XGBClassifier, entered all of the same parameters and got back a score of 0.51 for auc on the y vs yhat. I then check all of the docs I can find on the sklearn parameters and the xgb parameters and double check and retrain the sklearn. Still it gives back a bad score of 0.51.
What is going on here? I understand that this is very likely a user error, but I exhausted all scenarios that I can think of. What information can I provide to help diagnose this issue?

Can you provide a minimal code example?

I can give code, however I think I know what the problem was. xgb.train(objective='binary:logistic'),predict() is equivalent to xgb.XGBClassifier().predict_probab(). Is this correct? I was using  xgb.XGBClassifier().predict() for my comparison of the two models and so my auc score was very different. I have changed to using .predict_probab and seems to be the same auc now. I think this issue could be marked as resolved.

@JoshuaC3, you are correct that XGBClassifier().predict_proba() is the same as the Booster.predict() when using 'binary:logistic' objective.  However, I believe that XGBClassifier().predict_proba() will give you an array of 2n_samples in a binary problem (with the first column in the array being the probability of 0 class and the second being the probability of 1 class).  Booster.predict() will give you a 1n_samples vector where it is just the probability of the 1 class.
You should be able to close this issue if you comment below.


text:
Not an issue per se; more of a suggestion.

Hello there,
I was trying to install xgboost today on my windows computer, and God knows the hassle it was. With all the unclear instruction on its 'readthedocs' website (May be it was tough for me, but if you cannot explain it simply, why explain it at all, right?).
So, I went to see in stackoverflow and there was this guy who made everything so simple and with his step-by-step instructions, I could install and use it in no time.
Please have a look at this link : Disco4ever's answer on installing xgboost on Windows
Please add this to your documentation if you see that this will make the user's life a little more simpler.
Thanks and regards.

Old proposition, no answer. Closing

I am waiting for the author's answer. :)


text:
DumpModel stringstream precision problem

hello, in file src/tree/tree_model.cc line 150 std::stringstream fo("");
  std::stringstream fo("");   for (int i = 0; i < param.num_roots; ++i) {     DumpRegTree(fo, *this, fmap, i, 0, false, with_stats, format);   }   return fo.str();
use stringstream output the model text info，the stringstream default precision is 6,  when in  bst_float cond = tree[nid].split_cond();  cond is 100000.5 the output split_thresholds is 100000, thus when we decode the tree dump raw txt and use the tree info online predict the result will wrong. maybe you should reset the stringstream precision.   thanks! @pluskid @tqchen
英文可能有些中式英文，问题是这样的，在将模型dump成可视化文件时，在文件src/tree/tree_model.cc的150行中，使用了stringstream，但stringstream默认精度是6，因此当split_cond的值是7位时，后面的小数点部分会被省略掉，比如split_cond是100000.5时会输出100000，这样就会导致可视化文件和实际二进制文件不一致，当我们自己实现在线预测函数的时候，去解析可视化文件的内容就得到了错误的阈值，所以是不是这里应该把默认精度调到最大会更合适一些

https://github.com/dmlc/xgboost/pull/1726#issuecomment-308935742 #2268 #1204  #1750 #2077 #2608
Please use github search before creating a new issue.

authors: earthwu khotilov


text:
slice method of xgboost.DMatrix will change feature_names.

I find when use the slice method of xgb.DMatrix , the output DMatrix will change feature_names.
This behaviour is very strange. I think it should be fixed.
import numpy as np
import pandas as pd
import xgboost as xgb

data = pd.DataFrame(np.random.randn(5,3),columns = list('abc'))
dtrain = xgb.DMatrix(data)
dslice = dtrain.slice([0,1,2])
print(dtrain.feature_names)
print(dslice.feature_names)

the results is like this:

[u'a', u'b', u'c']
['f0', 'f1', 'f2']

Which version of XGBoost are you using?

@hcho3

Which version of XGBoost are you using?
0.80

The bug has been already fixed. You should upgrade to version 0.81.


text:
Fix include path for CPP test_param

Fixes #3340.

Closing as duplicate of #3317.

source: gharchive/pull-request


text:
Update list of required python depedencies

Impact of the bug
WMCore
Describe the bug
While installing reqmgr2 via PyPi, I noticed that - at least - the pycurl dependency is outdated in our requirements.txt, which asks for:
pycurl==7.19.3

while cmsdist provides:
### RPM external py2-pycurl 7.43.0.3

How to reproduce it
none
Expected behavior
We should update the pycurl version in our requirements.txt, and also take the opportunity to check if there are any other discrepancies between cmsdist spec files and the WMCore requirements.txt file, even though I think everything else is up-to-date.
Additional context and error message
Error message when installing reqmgr2 via pip:
Successfully built reqmgr2 Cheetah dbs-client httplib2 psutil pycurl pycurl-client decorator python-cjson
Installing collected packages: Markdown, Cheetah, backports.functools-lru-cache, six, more-itertools, jaraco.functools, selectors2, cheroot, pytz, tempora, portend, zc.lockfile, contextlib2, CherryPy, Pygments, docutils, MarkupSafe, Jinja2, sphinx-rtd-theme, alabaster, snowballstemmer, babel, Sphinx, python-cjson, pycurl, pycurl-client, dbs-client, future, httplib2, psutil, decorator, py, retry, reqmgr2
ERROR: After October 2020 you may experience errors when installing or updating packages. This is because pip will change the way that it resolves dependency conflicts.

We recommend you use --use-feature=2020-resolver to test your packages with the new resolver before it becomes the default.

pycurl-client 3.7.8 requires pycurl==7.19.0.3, but you'll have pycurl 7.19.3 which is incompatible.

@goughes Erik, since you're into these packaging items, could you please look into this one as well? Thanks

repo: dmwm/WMCore


text:
Explicitly add FQAN for X509 user proxy for job submission - wmagent branch

wmagent branch version of #7740

and pushing it to all the agents.

 Fix #7742 - Explicitly add FQAN for X509 user proxy for job submission


text:
MSOutput: handle very old StepChain/TaskChain workflows with diff schema

Fixes #9726
Status
not-tested
Description
The ChainParentageMap attribute was introduced in the system a few years ago (2017/2018), which means that, if we haven't yet archived all of those, MSOutput service would fail to parse that map.
This PR adds a protection against that and simply uses the top level Campaign attribute of the workflow.
Is it backward compatible (if not, which system it affects?)
yes
Related PRs
Todor is making similar changes here: https://github.com/dmwm/WMCore/pull/9750
External dependencies / deployment changes
none

I cherry-picked this commit in mine PR here https://github.com/dmwm/WMCore/pull/9750 and tested it. It is working properly and we can merge the other one so we have all the changes related to similar bugs in one place. I am closing this one.

Thanks Todor.

authors: amaltaro todor-ivanov


text:
Minor mod to override ENTRYPOINT

Hi @orodeh, something we can discuss at your leisure. Since it doesn't appear that WDL handles / uses Docker's ENTRYPOINT in a particular way, this mod overrides any user-specified ENTRYPOINT to properly run a command within the container.   @mlin and I discussed this earlier today, and I tested it out.

Merged!
I think I managed to make this a little bit nicer, buy allowing the user to set the entrypoint key in the runtime section.

authors: geetduggal orodeh

repo: dnanexus-rnd/dxWDL

license_source: bigquery


text:
Personabar TabOrder after Import

Description
Portal Import resets tab order in 9.1.1 if we have costume ordered tabs earlier.
Steps to reproduce
Create a fresh installation of 9.1.1 or 9.2.0
Create few pages with some content on them
Create few nested pages too.
Export this portal
Import this Portal
Current result
Pages order in new Portal is reset to default (on 9.1.1)
Pages are missing in 9.2
Expected result
Pages should not be missing or order should not be reset to default
Affected version

[x] 9.2
[x] 9.1.1
[ ] 9.1
[ ] 9.0

Fixed by #2074
@dnnsoftware/tag please close at will

license: mit


text:
Login bug/server bug? , forcing unmount is giving trouble also, Please Help! Thanks!

output not looking so good either:
chronos@localhost / $ sudo enter-chroot -n precise trusty croutonversion
Entering /mnt/stateful_partition/crouton/chroots/precise...
-su: 1: trusty: not found
Not unmounting /mnt/stateful_partition/crouton/chroots/precise as another instance is using it.
chronos@localhost / $

Sounds/looks like you might have two chroots and there's some confusion.
Enter: sudo edit-chroot -al and show us see the output.

Try updating your chroot see https://github.com/dnschneid/crouton/wiki/Common-issues-and-reporting
The command to show your croutonversion should be sudo enter-chroot -n precise croutonversion so no trusty in between precise ... croutonversion.
@DennisLfromGA He is missing the croutonversion output when using sudo startunity, so for sure the chroot needs to be updating. Who was that again that made the pull request https://github.com/dnschneid/crouton/pull/1542 ;)

sorry for the late reply i'll type type the commands  and tell you guys the outcome when get back tp my computer.  For now '' duty'' calls. Thanks for the quick replies!

Alright here's what I got

@samtechnewbie - Your chroot is really old so please follow @divx118's advice mentioned above - https://github.com/dnschneid/crouton/issues/1659#issuecomment-95630731

alright i updated chroot and here's my outcome
chronos@localhost / $ sudo enter-chroot -n trusty croutonversion
Entering /mnt/stateful_partition/crouton/chroots/trusty...
crouton: version 1-20141208100324~master:7b8ffff0
release: trusty
architecture: amd64
targets: unity
host: version 6812.75.2 (Official Build) stable-channel squawks
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
chronos@localhost / $

@samtechnewbie -
If you compare the croutonversion number and date in this comment https://github.com/dnschneid/crouton/issues/1659#issuecomment-95712702 with the one in your last comment https://github.com/dnschneid/crouton/issues/1659#issuecomment-95732779, they're the same. I don't think the crouton update you attempted worked.
I also noticed in your very first comment https://github.com/dnschneid/crouton/issues/1659#issue-70282041 that there may be two chroots - trusty and precise.

In the screenshot, when you attempt to startunity without a chrootname, it enters trusty.
When you attempt to startunity with the chrootname of precise, it enters precise.

That's why I asked you to run: sudo edit-chroot -al so we could see everything installed and go from there.
However -
To update your precise chroot, do this: sudo sh ~.Downloads/crouton -u -n precise
To update your trusty chroot, do this: sudo sh ~.Downloads/crouton -u -n trusty

You were right ! I did have 2 chroots for some odd reason I updated trusy chroot to start my long-missed unity everything is working now ! Thanks for the help :+1:

Great, glad we could help.

@samtechnewbie If it is working now then please close the issue. Thanks in advance. It will save the moderators some time.

authors: DennisLfromGA divx118 samtechnewbie

repo: dnschneid/crouton


text:
chroot update (and subsequent reinstall) not completed

this is the final section of the screen at reinstall (after a failed update) ARM 7l Samsung Chromebook. Trusty was running nicely for months until now. Ideas?
  patch
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 80.5 kB of archives.
After this operation, 183 kB of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports/ trusty-updates/main patch armhf 2.7.1-4ubuntu2.3 [80.5 kB]
Fetched 80.5 kB in 0s (122 kB/s)
Selecting previously unselected package patch.
(Reading database ... 13881 files and directories currently installed.)
Preparing to unpack .../patch_2.7.1-4ubuntu2.3_armhf.deb ...
Unpacking patch (2.7.1-4ubuntu2.3) ...
Setting up patch (2.7.1-4ubuntu2.3) ...
patch set to automatically installed.
Compiling CRAS (native)...
common/cras_config.c: In function 'cras_config_get_system_socket_file_dir':
common/cras_config.c:16:9: error: 'CRAS_SOCKET_FILE_DIR' undeclared (first use in this function)
  return CRAS_SOCKET_FILE_DIR;
         ^
common/cras_config.c:16:9: note: each undeclared identifier is reported only once for each function it appears in
common/cras_config.c:17:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
Failed to complete chroot setup.
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
chronos@localhost / $

Please describe your issue
when updating it wouldn't complete the setup of chroot and at subsequent reinstallation AFTER powerwash, I get the same message.
If known, describe the steps to reproduce the issue:
update process and subsequently reinstall process

I should have mentioned that I am on:
Version 52.0.2727.0 dev
Platform 8302.0.0 (Official Build) dev-channel daisy
Firmware Google_Snow.2695.117.0
and using the latest crouton version:
Chromium OS Universal Chroot Environment https://goo.gl/fd3zc

all of this while trying to update (then reinstall Trusty) with targets xfce and core.

OKay I see it's a CRAS issue from #2583. What is the solution to this?

Fix was merged, just try again. (you will want to remove the cache in /tmp/*-installer-cache before re-running the installer)

tip o' my cap to you, Drinkcat. amazing that you guys can figure this stuff
out and make it fly. miraculous that I found the temp directory you flagged
figured out rm -rf to eradicate the old cache. an old dog learning new
tricks.
best wishes and thanks,
Dave
On Tue, May 17, 2016 at 9:55 PM, drinkcat notifications@github.com wrote:

Fix was merged, just try again. (you will want to remove the cache in
/tmp/*-installer-cache before re-running the installer)
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/2593#issuecomment-219904740


text:
Cannot switch to chrome OS after entering xenial chroot

Please paste the output of the following command here: sudo edit-chroot -all

name: xenial
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/xenial...
crouton: version 1-20170309181220~master:a72a0cb5
release: xenial
architecture: amd64
xmethod: xorg
targets: unity
host: version 9000.95.0 (Official Build) stable-channel panther
kernel: Linux localhost 3.8.11 #1 SMP Fri Mar 3 11:23:58 PST 2017 x86_64 x86_64 x86_64 GNU/Linux
freon: yes
Unmounting /mnt/stateful_partition/crouton/chroots/xenial...

Please describe your issue:
Cannot switch back to chrome OS after entering chroot either by keyboard shortcut or by logging out of chroot on asus chromebox cn60
If known, describe the steps to reproduce the issue:
Enter chroot and then log out of chroot or press ctrl + shift + alt + back or forward  switch shortcuts keys. Chroot will exit into a blank screen which does not accept input.
Machine needs to powered and restarted down to escape this screen

@omarwh,
It's working for me with the latest crouton version on lxde, gnome, & kde desktops, I don't currently have unity installed.
See if you can switch back to CrOS from a terminal in the chroot using: croutoncycle cros
You could also add the 'xiwi' target and see if that will work for you, it's my favorite.
Hope this helps,
-DennisL

I can't switch back either but the croutoncycle cros works
Also, I can't use bluez becuase of a dbus file not found error

I have the same issue, but only if I install the xorg target. If I leave out the xorg target and just use x11, I'm able to switch between crouton and chrome. It's too bad; things run really snappy with the xorg target! Anyway, it isn't an ideal fix, but you might try building an environment without xorg and see if that behaves better. Or I think if you add xiwi to your current environment, and do something like "startxiwi -T startxfce4" (or whatever DE you use).
One difference though between my problem and yours is that I was able to go back to chrome by logging out of the DE.  Well, okay, once or twice I had to open a terminal and "sudo killall X.org"

I have run into this issue since yesterday night immediately after ChromeOS upgraded - so I'm guessing something has changed or broken in the update on hotkey binding. It was working fine just before the update (when I switched back to ChromeOS to initiate the update) & stopped working right after the update after reboot.
Working ChromeOS Version
Version 56.0.2924.110 (64-bit)
Platform 9000.91.0 (Official Build) stable-channel falco
Firmware Google_Falco.4389.92.0
Not Working ChromeOS Version
Version 57.0.2987.123 (64-bit)
Platform 9202.56.1 (Official Build) stable-channel falco
Firmware Google_Falco.4389.92.0

Y'all, Make sure to upgrade your chroot(s) after a CrOS update, it just might take care of the issue.

Just did that. Doesn't fix the issue. Here's the output of sudo edit-chroot -all
name: trusty
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/trusty...
crouton: version 1-20170315143304~master:95589555
release: trusty
architecture: amd64
xmethod: xorg
targets: xorg,xiwi,xfce,cli-extra,extension
host: version 9202.56.1 (Official Build) stable-channel falco
kernel: Linux localhost 3.8.11 #1 SMP Wed Mar 22 23:43:55 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux
freon: yes
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...

Same issue with the hotkeys, however, croutoncycle isn't working for me.
name: code-oss-chroot
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/code-oss-chroot...
crouton: version 1-20171122220410~master:99877eaf
release: xenial
architecture: amd64
xmethod: xiwi
targets: extension,xfce,xiwi
host: version 9901.77.0 (Official Build) stable-channel peppy
kernel: Linux localhost 3.8.11 #1 SMP Mon Nov 13 16:38:30 PST 2017 x86_64 x86_64 x86_64 GNU/Linux
freon: yes
Unmounting /mnt/stateful_partition/crouton/chroots/code-oss-chroot...

authors: DennisLfromGA JeffreyWerner abc123me jheiselman omarwh srinathh


text:
Acer Chromebook 14 (edgar) specific touchpad settings.

The following PR should fix the touchpad problems mentioned in issue #2657.
I've chosen to implement a custom path as I felt setting FingerLow and FingerHigh alone didn't offer a sufficient enough usability improvement.

Wow, did you customize each one of those values?

I manually tested every one of them.
Why? Is that a problem?

The question is, does it work reliably with just FingerLow=5 FingerHigh=10? Are all the other settings really necessary?

I was wondering if those settings (FingerLow=5 FingerHigh=10) could also be applied to some other models too, like I mentioned in this comment - https://github.com/dnschneid/crouton/issues/214#issuecomment-232519598
Some have already been applied but these may need the settings too -

chell (HP Chromebook 13)
terra (ASUS Chromebook C202SA)
reks (Lenovo N22 Chromebook)

authors: DennisLfromGA Happy-Ferret dnschneid drinkcat


text:
Search Results can overflow

If the result name is really long and has no spaces (such as for really nested files), the name will overflow.

Now it looks like this:

repo: docat-org/docat

license: MIT


text:
Update "generate-stackbrew-library.sh" to include Debian aliases like "stable", etc

Closes #77

$ diff -u <(bashbrew cat buildpack-deps) <(bashbrew cat <(./generate-stackbrew-library.sh))
--- /dev/fd/63	2018-04-11 13:02:06.878454838 -0700
+++ /dev/fd/62	2018-04-11 13:02:06.878454838 -0700
@@ -31,62 +31,62 @@
 GitCommit: 0db0cf15f1c507b17e7edc6dfbe301b8e357568f
 Directory: bionic

-Tags: buster-curl
+Tags: buster-curl, testing-curl
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: buster/curl

-Tags: buster-scm
+Tags: buster-scm, testing-scm
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 99a1c33fda559272e9322b02a5d778bbd04154e7
 Directory: buster/scm

-Tags: buster
+Tags: buster, testing
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: buster

-Tags: jessie-curl
+Tags: jessie-curl, oldstable-curl
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: jessie/curl

-Tags: jessie-scm
+Tags: jessie-scm, oldstable-scm
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 1845b3f918f69b4c97912b0d4d68a5658458e84f
 Directory: jessie/scm

-Tags: jessie
+Tags: jessie, oldstable
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: jessie

-Tags: sid-curl
+Tags: sid-curl, unstable-curl
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: sid/curl

-Tags: sid-scm
+Tags: sid-scm, unstable-scm
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 99a1c33fda559272e9322b02a5d778bbd04154e7
 Directory: sid/scm

-Tags: sid
+Tags: sid, unstable
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: sid

-Tags: stretch-curl, curl
+Tags: stretch-curl, stable-curl, curl
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: stretch/curl

-Tags: stretch-scm, scm
+Tags: stretch-scm, stable-scm, scm
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 1845b3f918f69b4c97912b0d4d68a5658458e84f
 Directory: stretch/scm

-Tags: stretch, latest
+Tags: stretch, stable, latest
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: stretch
@@ -106,17 +106,17 @@
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: trusty

-Tags: wheezy-curl
+Tags: wheezy-curl, oldoldstable-curl
 Architectures: amd64, arm32v5, arm32v7, i386
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: wheezy/curl

-Tags: wheezy-scm
+Tags: wheezy-scm, oldoldstable-scm
 Architectures: amd64, arm32v5, arm32v7, i386
 GitCommit: 1845b3f918f69b4c97912b0d4d68a5658458e84f
 Directory: wheezy/scm

-Tags: wheezy
+Tags: wheezy, oldoldstable
 Architectures: amd64, arm32v5, arm32v7, i386
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: wheezy

Updated diff for 89ef755:
$ diff -u <(bashbrew cat buildpack-deps) <(bashbrew cat <(./generate-stackbrew-library.sh))
--- /dev/fd/63	2018-04-11 13:06:16.974551532 -0700
+++ /dev/fd/62	2018-04-11 13:06:16.974551532 -0700
@@ -1,137 +1,137 @@
 Maintainers: Tianon Gravi <admwiggin@gmail.com> (@tianon), Joseph Ferguson <yosifkit@gmail.com> (@yosifkit)
 GitRepo: https://github.com/docker-library/buildpack-deps.git

-Tags: artful-curl
+Tags: artful-curl, 17.10-curl
 Architectures: amd64, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: artful/curl

-Tags: artful-scm
+Tags: artful-scm, 17.10-scm
 Architectures: amd64, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 36018aca7e9637c9c04ff623625e59de12d7f161
 Directory: artful/scm

-Tags: artful
+Tags: artful, 17.10
 Architectures: amd64, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: artful

-Tags: bionic-curl
+Tags: bionic-curl, 18.04-curl
 Architectures: amd64, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 0db0cf15f1c507b17e7edc6dfbe301b8e357568f
 Directory: bionic/curl

-Tags: bionic-scm
+Tags: bionic-scm, 18.04-scm
 Architectures: amd64, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 0db0cf15f1c507b17e7edc6dfbe301b8e357568f
 Directory: bionic/scm

-Tags: bionic
+Tags: bionic, 18.04
 Architectures: amd64, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 0db0cf15f1c507b17e7edc6dfbe301b8e357568f
 Directory: bionic

-Tags: buster-curl
+Tags: buster-curl, testing-curl
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: buster/curl

-Tags: buster-scm
+Tags: buster-scm, testing-scm
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 99a1c33fda559272e9322b02a5d778bbd04154e7
 Directory: buster/scm

-Tags: buster
+Tags: buster, testing
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: buster

-Tags: jessie-curl
+Tags: jessie-curl, oldstable-curl
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: jessie/curl

-Tags: jessie-scm
+Tags: jessie-scm, oldstable-scm
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 1845b3f918f69b4c97912b0d4d68a5658458e84f
 Directory: jessie/scm

-Tags: jessie
+Tags: jessie, oldstable
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: jessie

-Tags: sid-curl
+Tags: sid-curl, unstable-curl
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: sid/curl

-Tags: sid-scm
+Tags: sid-scm, unstable-scm
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 99a1c33fda559272e9322b02a5d778bbd04154e7
 Directory: sid/scm

-Tags: sid
+Tags: sid, unstable
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: sid

-Tags: stretch-curl, curl
+Tags: stretch-curl, stable-curl, curl
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: stretch/curl

-Tags: stretch-scm, scm
+Tags: stretch-scm, stable-scm, scm
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 1845b3f918f69b4c97912b0d4d68a5658458e84f
 Directory: stretch/scm

-Tags: stretch, latest
+Tags: stretch, stable, latest
 Architectures: amd64, arm32v5, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: stretch

-Tags: trusty-curl
+Tags: trusty-curl, 14.04-curl
 Architectures: amd64, arm32v7, arm64v8, i386, ppc64le
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: trusty/curl

-Tags: trusty-scm
+Tags: trusty-scm, 14.04-scm
 Architectures: amd64, arm32v7, arm64v8, i386, ppc64le
 GitCommit: 1845b3f918f69b4c97912b0d4d68a5658458e84f
 Directory: trusty/scm

-Tags: trusty
+Tags: trusty, 14.04
 Architectures: amd64, arm32v7, arm64v8, i386, ppc64le
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: trusty

-Tags: wheezy-curl
+Tags: wheezy-curl, oldoldstable-curl
 Architectures: amd64, arm32v5, arm32v7, i386
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: wheezy/curl

-Tags: wheezy-scm
+Tags: wheezy-scm, oldoldstable-scm
 Architectures: amd64, arm32v5, arm32v7, i386
 GitCommit: 1845b3f918f69b4c97912b0d4d68a5658458e84f
 Directory: wheezy/scm

-Tags: wheezy
+Tags: wheezy, oldoldstable
 Architectures: amd64, arm32v5, arm32v7, i386
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: wheezy

-Tags: xenial-curl
+Tags: xenial-curl, 16.04-curl
 Architectures: amd64, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c
 Directory: xenial/curl

-Tags: xenial-scm
+Tags: xenial-scm, 16.04-scm
 Architectures: amd64, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: 2da658b9a1b91fa61d63ffad2ea52685cac6c702
 Directory: xenial/scm

-Tags: xenial
+Tags: xenial, 16.04
 Architectures: amd64, arm32v7, arm64v8, i386, ppc64le, s390x
 GitCommit: d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1
 Directory: xenial

repo: docker-library/buildpack-deps


text:
System error: no such file or directory

I realize this is probably low priority for you, but I thought I'd document it anyway.
On Debian testing (stretch), using docker 1.8.3, the latest mongo images fail with:
Error response from daemon: Cannot start container 3a6e7e6044930ce36c3fe7425168aaa8531e878e5477b77ccfc2d987f00da2d9: [8] System error: no such file or directory

The image tagged mongo:3.2.5 works.

I don't see anything in the image that would break the image between 3.2.5 and 3.2.6 (ie it was only a version bump).  This looks like an issue with the host, maybe docker rmi and pull it again?

You are right. I dismissed the possibility because I thought docker had checksum checking.

authors: ptman yosifkit

repo: docker-library/mongo


text:
Password from .env is cached

I have a docker-compose file with this in it:
  postgres:
    image: postgres:9.6.12-alpine
    env_file: .env
    ports:
      - "54320:5432"
    volumes:
     - postgres_db_data:/var/lib/postgresql/data

In the .env file, I have the POSTGRES_PASSWORD along with everything else the container needs. At some point I had the password set to "B" and did a docker-compose up. I changed the password to "A" in the .env file and restarted the Postgres container, but it still has the password set to "B".
I've tried restarting Docker, restarting Windows, tried updating the image version but it's still using "B".
When I run docker-compose config I can see POSTGRES_PASSWORD: A.
I've used ash to get into the container and run echo $POSTGRES_PASSWORD and it returns "A".
I've tried changing the password to many other things in the .env file but it's stuck as "B".
Postgres Version: 9.6.3-alpine and 9.6.12-alpine
Win 10 Pro
Docker Desktop 2.1.04
Any commands I can do to fix this? Is there a cache for the container I can clear?

I managed to fix it. I re-installed Docker, but also changed the name of the volume to something else so it had to create a new volume. No matter what I did to the docker-compose file or the .env file, it didn't affect Postgres.

https://github.com/docker-library/postgres/issues/203#issuecomment-255200501

authors: kingjerod yosifkit

repo: docker-library/postgres


text:
[WIP] Use relocation map on fixup

- What I did
When we are doing the fixup of a bundle, apply relocation map when necessary.
Previous behaviour:

resolve image

if found, copy or mount
if not found

if image present in local docker image store

push

The goal of this commit is to add one more condition, to copy/mount images that has been previously pushed from the local docker image store and so that can be resolved using the relocation map.
So the behaviour looks like:

resolve image

if found, copy or mount
if not found

look at the relocation map and try to resolve

if found, copy or mount
if not found in the relocation map or not resolved

if image present in local docker image store

push

- How I did it
Use new cnab-to-oci, see https://github.com/docker/cnab-to-oci/pull/82
- How to verify it
The affected workflow is the following:

create a bundle referencing local images. Like after a docker app build

the bundle contains images with, by example, Image: web

push it to a registry
pull it (by example on an other machine)

the bundle contains Image: web associated to an entry in the
relocation map: web: registry/user/repo:tag@sha256...

push it (to an other registry or not)

the image web is not resolved in the registry (but the corresponding
image has already been pushed)
the image cannot be pushed from the local docker image store (the image
doesn't exist there)
the entry from the relocation maps is resolvable and can be copy or mount

- Description for the changelog
Use relocation map to copy images already present on the registry when pushing a pulled bundled without to have locally all the images.

Is this still WIP?

Is this still WIP?

It's waiting for approval on https://github.com/docker/cnab-to-oci/pull/82 (and I will rebase it)

authors: eunomie rumpl

repo: docker/app


text:
Fix pushing unstable tag

Signed-off-by: Silvin Lubecki silvin.lubecki@docker.com

Codecov Report

Merging #153 into master will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #153      +/-   ##
==========================================
- Coverage   65.05%   65.02%   -0.04%
==========================================
  Files          90       90
  Lines       10958    10958
==========================================
- Hits         7129     7125       -4
- Misses       3535     3537       +2
- Partials      294      296       +2

Impacted Files
Coverage Δ

internal/controller/resourceupdater.go
55.55% <0%> (-3.71%)
:arrow_down:

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 fb4b9b6...bb840f8. Read the comment docs.

authors: codecov-io silvin-lubecki

repo: docker/compose-on-kubernetes


text:
docker registry 2.1.1 does not return the image id for a 'docker tag -r -l'

When I query my docker registry with the following command docker tag -r -l 192.168.98.1:8880/sarnott/centos I get the following:
REPOSITORY                         TAG                 IMAGE ID
192.168.98.1:8880/sarnott/centos   test

Why is the image id missing?

You are interacting with the docker daemon when you invoke docker tag.  This github repository is for the docker registry.  Please ask your question in #docker-dev or https://github.com/docker/docker

Furthermore -t and -l are not valid flags for the docker client.  If you are using a fork of docker you should seek help at the origin of the fork

Oh,  we just using the redhat supplied docker RPM for Centos7.

authors: GrantStreetGroup RichardScothern

repo: docker/distribution


text:
Redirect support in Swift driver

Currently registry is serving content directly in case SWIFT is used as storage.
It will be nice if Swift driver can utilize tempUrl functionaly to offload the download to Swift directly.

@lebauce what do you think?

Agreed. This was not part of the original pull request as I couldn't make it work on my setup.
I'm planning to make an other try soon, probably in the 1 or 2 weeks.

@lebauce thanks.  Looking forward to it.

@gschukin @RichardScothern I just pushed a branch that implements the features
Newer versions of Swift allow to set two extra secret keys per container when older versions only allowed to set secret keys per account. I couldn't find a way to detect if per container secret keys are supported, so only per account secret keys are supported.
What do you think ?

@lebauce according to the Swift documentation there is no difference between account or container secret keys as signature is checked against all four keys.

@gschukin Unfortunately, it was not the case in Icehouse and prior versions of Openstack

@lebauce is it reasonable to fetch keys from account metadata? I think storing temp-URL-key in configuration file will give better flexibility.
What do you think?

@gschukin One solution would be to set the account secret key with a POST request if it is specified in the configuration file or fetch it from account metadata otherwise

@gschukin @lebauce There is already an hmac secret shipped with each registry. We consider it a "cluster" secret, meaning all the registry instances operating in a cluster should share it. You may want to consider that as an option if all that is needed is an hmac.

@stevvooe Yes, all that is needed is an hmac. I guess you are talking about the Config.HTTP.Secret key right ? However I couldn't find a way to use it from the driver

@lebauce URLFor takes a parameter map. We could consider adding hmac (or better yet, a crypto.Signer) as a parameter, as long as we can agree that this can be consistently used across drivers.

@stevvooe That would be nice. For now, the library used by the Azure, S3 and Swift internally creates their own hmac object so they must be modified so that we can pass them an existing one.
@ahmetalpbalkan @AndreyKostov @BrianBland  What do you think ?

@lebauce azure does not create an internal hmac object. The URL signing we have is based on url+date+storage service access key.

@lebauce ping

@dmp42 I pushed a new version of the branch. It tested it against a public Swift instance. It also includes compatibility with HP Cloud. It was also tested by @lcarstensen (see https://github.com/lebauce/distribution/pull/2).
I just created a pull request for it.

authors: RichardScothern ahmetalpbalkan dmp42 gschukin lebauce stevvooe


text:
Check 5.14 should not check for container MaximumRetryCount

We have a few Docker services where we set the max_attempts like prescribed:
    deploy:
      restart_policy:
        max_attempts: 5

Still, Check 5.14 fails in Docker Swarm. And I think this check fails for the wrong reasons:
This line https://github.com/docker/docker-bench-security/blob/4edccd78595d1f0d6d71b0ae5316e0c70c537f38/tests/5_container_runtime.sh#L612 checks not only services but also containers. On a container, the MaximumRetryCount will only be set if the restart_policy is set to "on-failure": https://github.com/moby/moby/issues/10809 If your restart_policy is of any other type, this field will be set to zero. So this will give false negative findings even when you set the max_attempts but use a different restart_policy condition (in Docker Swarm it's "any").
Btw I even tried setting the deploy.restart_policy.condition to any other type and in Docker Swarm I still got containers with MaximumRetryCount of 0.
Try this simple example to reproduce:
cat <<EOF > postgres.yaml
version: "3.9"
services:
  postgres:
    image: postgres:14.9
    environment:
      POSTGRES_DB: postgres
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    deploy:
      restart_policy:
        max_attempts: 5
EOF
docker stack up --prune -c postgres.yaml postgres
# Check max_attempts in Docker service (will be 5):
docker inspect --format MaxAttempts='{{ .Spec.TaskTemplate.RestartPolicy.MaxAttempts }}' $(docker service ls -q -f name=postgres)
# Check maximum retry count in container (will be 0):
docker inspect --format MaximumRetryCount='{{ .HostConfig.RestartPolicy.MaximumRetryCount }}' $(docker ps -q -f name=postgres)

I would like to propose to only check Docker services and not containers in 5.14.

Hi @jscheytt and thanks for creating the issue, but as stated on https://github.com/docker/docker-bench-security/blob/master/tests/5_container_runtime.sh#L589: "Ensure that the 'on-failure' container restart policy is set to '5' (Automated)", and in the CIS Docker Benchmark:
"By using the --restart flag in the docker run command you can specify a restart policy for how a container should or should not be restarted on exit. You should choose the on-failure restart policy and limit the restart attempts to 5."

Thanks for the clarification, I missed that point!
However, as I stated above, even when I set the condition to "on-failure", the resulting container still has a MaximumRetryCount of zero.

What does docker-bench-security.sh -c check_5_14 return?

Actually, I cannot really reproduce this locally (MacBook w/ docker v24). The specific circumstances under which this is happening is RHEL 8.9 with docker v23.0.1, and out of about 40 services (all exactly equally configured for 5.14, now also with "condition: on-failure"), the benchmark script only marks two services as not meeting the criteria (Artifactory and a Postgres). And on some environments, even all services are marked as non-passing. I hoped I could find some way to more easily analyse what is going wrong here, but I guess trying to reproduce the exact same circumstances will be a bit cumbersome, so for now I will just deactivate 5.14 ...

authors: jscheytt konstruktoid

repo: docker/docker-bench-security


text:
get.docker.com provides edge channel instead of stable

https://get.docker.com/ provides edge channel instead of stable.
DEFAULT_CHANNEL_VALUE="edge"
if [ -z "$CHANNEL" ]; then
	CHANNEL=$DEFAULT_CHANNEL_VALUE
fi

As intended. The script isn't meant for production use, it's meant as a convenience to install the latest Docker CE version quickly. If you'd like to lock yourself into the stable channel you can configure it with your package manager.

authors: mahnunchik seemethere

repo: docker/docker-install


text:
Remove list of Buildkit benefits from reference page

File: engine/reference/builder.md
For someone who is completely new to using Docker and Dockerfiles, I found the following section unnecessary:
Starting with version 18.09, Docker supports a new backend for executing your builds that is provided by the
moby/buildkit project. The BuildKit backend provides many benefits compared to the old implementation.
For example, BuildKit can:

* Detect and skip executing unused build stages
* Parallelize building independent build stages
* Incrementally transfer only the changed files in your build context between builds
* Detect and skip transferring unused files in your build context
* Use external Dockerfile implementations with many new features
* Avoid side-effects with rest of the API (intermediate images and containers)
* Prioritize your build cache for automatic pruning

This list of benefits from the BuildKit interrupts the flow of this guide. It also sounds a lot like marketing copy. You might consider removing this list in order to keep this guide more succinct, example:
Starting with version 18.09, Docker supports the moby/buildkit project for executing your builds. To use the
BuildKit backend, you need to set an environment variable `DOCKER_BUILDKIT=1` on the CLI before
invoking `docker build`.

For more information about the benefits of the BuildKit backend, see [link to some other page]().

Thanks for sharing this. This content is pulled from an upstream repo and not maintained in this repo. If the issue is still applicable, please create an issue or PR in the source repo at https://github.com/docker/cli/blob/master/docs/reference/builder.md

authors: craig-osterhout telpirion


text:
--user lacks extended description and usage policy is unclear

File: engine/reference/commandline/run.md, CC @johndmulhausen

Hi, @gdennie
The contents of this page are automatically generated from Docker's source code. If you want to suggest a change, you'll need to find the string by searching this repo:  https://github.com/docker/cli


text:
Update tmpfs.md

Proposed changes

Unreleased project version (optional)

Related issues (optional)

Deploy preview for docsdocker ready!
Built with commit dea585582ec6aad357c593e7ee2a08d54c247d0c
https://deploy-preview-8711--docsdocker.netlify.com

authors: GordonTheTurtle scjane


text:
doc: docker images should explain repository column and when none

doc: docker images should explain repository column and when none. Or provide a link to where these are explained.
https://docs.docker.com/reference/commandline/cli/#images
docker images starts "The default docker images will show all top level images, their repository and tags, and their virtual size."  It goes on to do a good job of explaining the last item "virtual size".

Hi!
If you are reporting a new issue, PLEASE make sure that does not have any duplicates already open.
We would like to take this time to remind you of the information we need to debug the problem you are seeing. This is an automated response so if this ticket is not about a bug, do not fret.
If you fail to provide this information within 7 days, we will close this because we cannot debug your issue. We can reopen whenever the information is provided.
Thank you.
Please see:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues
Description of problem:

`docker version`:

`docker info`:

`uname -a`:

Environment details (AWS, VirtualBox, physical, etc.):

How reproducible:

Steps to Reproduce:
1.
2.
3.

Actual Results:

Expected Results:

Additional info:

#ENEEDMOREINFO

@GordonTheTurtle you silly bot. How do I get you not to respond for doc bugs?

@lloydde perhaps you are willing to create a pull-request to enhance the description of those columns?

@thaJeztah unfortunately my motivation of filing this is, because I don't know the answers. I was surprised that many images have  for their repository.
I think I've read that when an image is "replaced" the old image would be untagged. This part makes more sense.

There actually was some work done on adding a glossary to the documentation in https://github.com/docker/docker/pull/11897.
You can read it here; http://docs.master.dockerproject.com/reference/glossary/
I just noticed it is no longer linked in the menu, so I will ask if there's any reason for that.

@thaJeztah that's helpful! Thank you.
The definition for "registry" in the glossary reads "containing repositories of images" and does not address images having <none> for their registry.
http://docs.master.dockerproject.com/reference/glossary/#registry

@lloydde hm, true. Not sure that part should be explained there. But I agree that we might to explain somewhere that "un tagging" and image will show it as <none> in the output of docker images.

Note: Page has moved, here's the link to the latest doc
https://docs.docker.com/reference/commandline/images/

hi @lloydde  and @thaJeztah from what I learnt above, is it a question about
$ docker images
REPOSITORY                TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
               77af4d6b9913        19 hours ago        1.089 GB
this none case ?

@HackToday the output can still show <none> if an image is untagged (e.g. on repeated builds, the latest version is tagged, and the previous version of the image will show as <none>;
REPOSITORY            TAG                                   IMAGE ID            CREATED             VIRTUAL SIZE
docs-base             update-ubuntu-install                 56bbadd77a9b        4 days ago          672.5 MB
docs-base             fix-api-network-output                d08282e1e03e        6 days ago          672.4 MB
<none>                <none>                                ca73b76e31c1        6 days ago          672.4 MB
<none>                <none>                                8f55a964bb3e        6 days ago          672.4 MB

@thaJeztah The doc already has a section about untagged images(dangling).
Can you clarify what exactly needs to be done in this issue then, I will like to work on this issue.

@sammyshj good question, I think that section covers it quite well. Perhaps we should explicitly mention <none>, and explain that those are untagged images?

Okay working on it right now.
Following the Docker Contribution Guide, #dibs.

Awesome @sammyshj, thanks!

authors: GordonTheTurtle HackToday charleswhchan lloydde sammyshj thaJeztah

repo: docker/docker


text:
apt warns about untrusted source on recent lxc-docker .deb update

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
root@build:~# docker version
Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d
OS/Arch (server): linux/amd64
root@build:~#

docker info:
root@build:~# docker info
Containers: 3
Images: 18
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.1.5-x86_64-linode61
Operating System: Debian GNU/Linux 7 (wheezy)
CPUs: 4
Total Memory: 3.858 GiB
Name: build
ID: M3DG:JTLB:D7RX:2MY4:HEL7:I2KA:OFFS:DZCO:NYTG:TAQR:7WVM:FNIR
WARNING: No swap limit support

uname -a:
root@build:~# uname -a
Linux build 4.1.5-x86_64-linode61 #7 SMP Mon Aug 24 13:46:31 EDT 2015 x86_64 GNU/Linux

Provide additional environment details (AWS, VirtualBox, physical, etc.):
Linode VPS.
List the steps to reproduce the issue:

Run aptitude safe-upgrade

Describe the results you received:
WARNING: untrusted versions of the following packages will be installed!
Untrusted packages could compromise your system's security.
You should only proceed with the installation if you are certain that
this is what you want to do.
lxc-docker lxc-docker-1.9.0
Describe the results you expected:
Upgraded packages without warnings
Provide additional info you think is important:
Hi,
Recently I started to notice a trust issue on my Debian servers. The official repository is generating warnings even though the official key was added.
root@build:~# wget -qO- https://get.docker.com/gpg | sudo apt-key add -
OK
root@build:~# aptitude safe-upgrade
Resolving dependencies...
The following NEW packages will be installed:
  lxc-docker-1.9.0{a}
The following packages will be REMOVED:
  lxc-docker-1.7.1{u}
The following packages will be upgraded:
  lxc-docker
1 packages upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 8487 kB of archives. After unpacking 13.9 MB will be used.
Do you want to continue? [Y/n/?] y
WARNING: untrusted versions of the following packages will be installed!

Untrusted packages could compromise your system's security.
You should only proceed with the installation if you are certain that
this is what you want to do.

  lxc-docker lxc-docker-1.9.0

Do you want to ignore this warning and proceed anyway?
To continue, enter "Yes"; to abort, enter "No": No
Abort.
root@build:~# apt-cache policy lxc-docker
lxc-docker:
  Installed: 1.7.1
  Candidate: 1.9.0
  Version table:
     1.9.0 0
        500 https://get.docker.com/ubuntu/ docker/main amd64 Packages
 *** 1.7.1 0
        100 /var/lib/dpkg/status
root@build:~#

Note that the key is present:
pub   2048R/A88D21E9 2013-08-16
uid                  Docker Release Tool (releasedocker) <docker@dotcloud.com>

Was there a signing issue for the 1.9.0 package?
----------END REPORT ---------

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

Hm, the package for Ubuntu is now called docker-engine, not lxc-docker. Could you try the manual procedure, as described in http://docs.docker.com/engine/installation/ubuntulinux/ ?

Interesting. That page points to a completely different repository.
That's the one I had from my initial installation in the source list:
deb https://get.docker.com/ubuntu docker main

The new one points to:
deb https://apt.dockerproject.org/repo debian-wheezy main

I followed http://docs.docker.com/engine/installation/debian/#debian-wheezy-stable-7-x-64-bit to solve my issue.
One question remains though. Why suddenly the old repository served a new lxc-docker upgrade that wasn't properly signed?

One question remains though. Why suddenly the old repository served a new lxc-docker upgrade that wasn't properly signed?

Good question; @jfrazelle any ideas here?

Alright, small update; first of all, the 1.9 release is indeed still published to the old repo's as well (I actually didn't know that was still the case), this is just to give users time to move to the new repositories, so it's advisable to migrate to the new repositories (apt.dockerproject.org) - 1.9 is the last release that will be published on the old repo.
We're currently looking into the signing issue; it's possibly a cache issue on a CDN, but its being investigated; see https://github.com/docker/docker/issues/12461#issuecomment-153758535 for more information

Thanks, closing this issue as my problem has been resolved and you guys seem to be on top the signing issue with a discussion at #12461.

Thanks @mulander, and thanks for reporting!

authors: GordonTheTurtle mulander thaJeztah


text:
[DOCS] Development environment setup tutorial outdated

Tutorial  Work with a development container talks about the binary directory. Current development source makes binary-client and binary-daemon. This modifies a few steps, like the one where we copy the binary file.
The documentation can benefit from updates also.

Thanks for reporting @abheekg there's work in progress for updating that documentation, but the "binary split" (client / daemon) has not yet been incorporated in those changes. See https://github.com/docker/opensource/pull/62

This is an old issue.  I will close it as stale.

authors: abheekg sam-thibault thaJeztah


text:
Add syslog-facility option

This PR adds an option to set the syslog facility.

I would recommend more user friendly values, such as daemon and local0 (instead of LOG_DAEMON and LOG_LOCAL0).

I chose not to do that, because now it's not needed to replicate the list in the documentation. It does make sense to have nicer names though. Should I then add a list of supported facilities in the documenation, or refer to, say the syslog rfc?

Updated for nicer names and also integer facilities.

Sounds good to me, I think I can move this to code review ping @LK4D4

LGTM

LGTM

pign @thaJeztah @moxiegirl

ping @thaJeztah @moxiegirl :)

thanks @LK4D4, this one slipped my mind. I'll look at this later today

Thanks! I added a suggestion to add to the docs.

Thanks for addressing; LGTM
ping @fredlf @jamtur01 @moxiegirl @SvenDowideit

@spil-dennis sorry this needs a rebase :/

Hehe sure np

ping @moxiegirl

@moxiegirl Thanks for the review, updated as per your suggestions.

@moxiegirl Thanks for the review, updated as per your suggestions.

@spil-dennis Thanks for the contribution and the quick response.  Very sorry for the delay in processing this.  ping @LK4D4 moving to merge status.

authors: LK4D4 d23 moxiegirl phemmer runcom spil-dennis thaJeztah


text:
Add zsh completion for 'docker build' multi tags

Ref. #15780
In addition: Fix some others repeatable option
Signed-off-by: Steve Durrheimer s.durrheimer@gmail.com

thanks again @sdurrheimer, @vi PTAL
to maintainers: don't merge yet, because this should go in after https://github.com/docker/docker/pull/15780

Rebased and ready to be merged.

LGTM

@sdurrheimer quick thinking here; the "fixes" in this PR probably should be in the 1.9 release (if possible), but the "multiple tag" feature will be part of 1.10
Can you move the fixes to a separate PR? that enables us to cherry pick the fixes in the 1.9 release without cherry-picking the new feature
(hope I'm making sense here :smile:)

@thaJeztah Done #17333 :)

Thanks @sdurrheimer !

LGTM, thanks @sdurrheimer !

authors: cpuguy83 sdurrheimer thaJeztah


text:
Update Tini to fix photon build-rpm compilation errors

Should fix #28548 — building locally to make sure.
It updates tini to not require xxd for the license, see https://github.com/docker/docker/issues/28548#issuecomment-261343734. Thanks a lot @krallin
diff --git a/CMakeLists.txt b/CMakeLists.txt
index e16d8c2..b5b93ba 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -58,16 +58,6 @@ set (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-Bsymbolic-functions

 # Build

-execute_process(
-  COMMAND xxd -i "LICENSE" "${PROJECT_BINARY_DIR}/tiniLicense.h"
-  WORKING_DIRECTORY "${PROJECT_SOURCE_DIR}"
-  RESULT_VARIABLE xxd_ret
-)
-
-if(NOT "${xxd_ret}" EQUAL 0)
-	message(SEND_ERROR "xxd on LICENSE failed: ${xxd_ret}")
-endif()
-
 configure_file (
 	"${PROJECT_SOURCE_DIR}/src/tiniConfig.h.in"
 	"${PROJECT_BINARY_DIR}/tiniConfig.h"
diff --git a/ci/install_deps.sh b/ci/install_deps.sh
index da7412d..ce5d104 100755
--- a/ci/install_deps.sh
+++ b/ci/install_deps.sh
@@ -7,7 +7,7 @@ apt-get update
 apt-get install --no-install-recommends --yes \
   build-essential git gdb valgrind cmake rpm \
   python-dev libcap-dev python-pip python-virtualenv \
-  hardening-includes gnupg vim-common \
+  hardening-includes gnupg \
   gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu libc6-dev-arm64-cross \
   gcc-arm-linux-gnueabihf binutils-arm-linux-gnueabi libc6-dev-armhf-cross

diff --git a/ci/run_build.sh b/ci/run_build.sh
index 728da5c..7658ac7 100755
--- a/ci/run_build.sh
+++ b/ci/run_build.sh
@@ -118,7 +118,7 @@ if [[ -n "${ARCH_NATIVE:=}" ]]; then
       "${tini}" -h

       echo "Testing $tini for license"
-      "${tini}" -l | grep -q -i "mit license"
+      "$tini" -l | diff - "${SOURCE_DIR}/LICENSE"

       echo "Testing $tini with: true"
       "${tini}" -vvv true
diff --git a/src/tiniLicense.h b/src/tiniLicense.h
new file mode 100644
index 0000000..db230ad
--- /dev/null
+++ b/src/tiniLicense.h
@@ -0,0 +1,95 @@
+unsigned char LICENSE[] = {
+  0x54, 0x68, 0x65, 0x20, 0x4d, 0x49, 0x54, 0x20, 0x4c, 0x69, 0x63, 0x65,
+  0x6e, 0x73, 0x65, 0x20, 0x28, 0x4d, 0x49, 0x54, 0x29, 0x0a, 0x0a, 0x43,
+  0x6f, 0x70, 0x79, 0x72, 0x69, 0x67, 0x68, 0x74, 0x20, 0x28, 0x63, 0x29,
+  0x20, 0x32, 0x30, 0x31, 0x35, 0x20, 0x54, 0x68, 0x6f, 0x6d, 0x61, 0x73,
+  0x20, 0x4f, 0x72, 0x6f, 0x7a, 0x63, 0x6f, 0x20, 0x3c, 0x74, 0x68, 0x6f,
+  0x6d, 0x61, 0x73, 0x40, 0x6f, 0x72, 0x6f, 0x7a, 0x63, 0x6f, 0x2e, 0x66,
+  0x72, 0x3e, 0x0a, 0x0a, 0x50, 0x65, 0x72, 0x6d, 0x69, 0x73, 0x73, 0x69,
+  0x6f, 0x6e, 0x20, 0x69, 0x73, 0x20, 0x68, 0x65, 0x72, 0x65, 0x62, 0x79,
+  0x20, 0x67, 0x72, 0x61, 0x6e, 0x74, 0x65, 0x64, 0x2c, 0x20, 0x66, 0x72,
+  0x65, 0x65, 0x20, 0x6f, 0x66, 0x20, 0x63, 0x68, 0x61, 0x72, 0x67, 0x65,
+  0x2c, 0x20, 0x74, 0x6f, 0x20, 0x61, 0x6e, 0x79, 0x20, 0x70, 0x65, 0x72,
+  0x73, 0x6f, 0x6e, 0x20, 0x6f, 0x62, 0x74, 0x61, 0x69, 0x6e, 0x69, 0x6e,
+  0x67, 0x20, 0x61, 0x20, 0x63, 0x6f, 0x70, 0x79, 0x0a, 0x6f, 0x66, 0x20,
+  0x74, 0x68, 0x69, 0x73, 0x20, 0x73, 0x6f, 0x66, 0x74, 0x77, 0x61, 0x72,
+  0x65, 0x20, 0x61, 0x6e, 0x64, 0x20, 0x61, 0x73, 0x73, 0x6f, 0x63, 0x69,
+  0x61, 0x74, 0x65, 0x64, 0x20, 0x64, 0x6f, 0x63, 0x75, 0x6d, 0x65, 0x6e,
+  0x74, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x20, 0x66, 0x69, 0x6c, 0x65, 0x73,
+  0x20, 0x28, 0x74, 0x68, 0x65, 0x20, 0x22, 0x53, 0x6f, 0x66, 0x74, 0x77,
+  0x61, 0x72, 0x65, 0x22, 0x29, 0x2c, 0x20, 0x74, 0x6f, 0x20, 0x64, 0x65,
+  0x61, 0x6c, 0x0a, 0x69, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x53, 0x6f,
+  0x66, 0x74, 0x77, 0x61, 0x72, 0x65, 0x20, 0x77, 0x69, 0x74, 0x68, 0x6f,
+  0x75, 0x74, 0x20, 0x72, 0x65, 0x73, 0x74, 0x72, 0x69, 0x63, 0x74, 0x69,
+  0x6f, 0x6e, 0x2c, 0x20, 0x69, 0x6e, 0x63, 0x6c, 0x75, 0x64, 0x69, 0x6e,
+  0x67, 0x20, 0x77, 0x69, 0x74, 0x68, 0x6f, 0x75, 0x74, 0x20, 0x6c, 0x69,
+  0x6d, 0x69, 0x74, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x20, 0x74, 0x68, 0x65,
+  0x20, 0x72, 0x69, 0x67, 0x68, 0x74, 0x73, 0x0a, 0x74, 0x6f, 0x20, 0x75,
+  0x73, 0x65, 0x2c, 0x20, 0x63, 0x6f, 0x70, 0x79, 0x2c, 0x20, 0x6d, 0x6f,
+  0x64, 0x69, 0x66, 0x79, 0x2c, 0x20, 0x6d, 0x65, 0x72, 0x67, 0x65, 0x2c,
+  0x20, 0x70, 0x75, 0x62, 0x6c, 0x69, 0x73, 0x68, 0x2c, 0x20, 0x64, 0x69,
+  0x73, 0x74, 0x72, 0x69, 0x62, 0x75, 0x74, 0x65, 0x2c, 0x20, 0x73, 0x75,
+  0x62, 0x6c, 0x69, 0x63, 0x65, 0x6e, 0x73, 0x65, 0x2c, 0x20, 0x61, 0x6e,
+  0x64, 0x2f, 0x6f, 0x72, 0x20, 0x73, 0x65, 0x6c, 0x6c, 0x0a, 0x63, 0x6f,
+  0x70, 0x69, 0x65, 0x73, 0x20, 0x6f, 0x66, 0x20, 0x74, 0x68, 0x65, 0x20,
+  0x53, 0x6f, 0x66, 0x74, 0x77, 0x61, 0x72, 0x65, 0x2c, 0x20, 0x61, 0x6e,
+  0x64, 0x20, 0x74, 0x6f, 0x20, 0x70, 0x65, 0x72, 0x6d, 0x69, 0x74, 0x20,
+  0x70, 0x65, 0x72, 0x73, 0x6f, 0x6e, 0x73, 0x20, 0x74, 0x6f, 0x20, 0x77,
+  0x68, 0x6f, 0x6d, 0x20, 0x74, 0x68, 0x65, 0x20, 0x53, 0x6f, 0x66, 0x74,
+  0x77, 0x61, 0x72, 0x65, 0x20, 0x69, 0x73, 0x0a, 0x66, 0x75, 0x72, 0x6e,
+  0x69, 0x73, 0x68, 0x65, 0x64, 0x20, 0x74, 0x6f, 0x20, 0x64, 0x6f, 0x20,
+  0x73, 0x6f, 0x2c, 0x20, 0x73, 0x75, 0x62, 0x6a, 0x65, 0x63, 0x74, 0x20,
+  0x74, 0x6f, 0x20, 0x74, 0x68, 0x65, 0x20, 0x66, 0x6f, 0x6c, 0x6c, 0x6f,
+  0x77, 0x69, 0x6e, 0x67, 0x20, 0x63, 0x6f, 0x6e, 0x64, 0x69, 0x74, 0x69,
+  0x6f, 0x6e, 0x73, 0x3a, 0x0a, 0x0a, 0x54, 0x68, 0x65, 0x20, 0x61, 0x62,
+  0x6f, 0x76, 0x65, 0x20, 0x63, 0x6f, 0x70, 0x79, 0x72, 0x69, 0x67, 0x68,
+  0x74, 0x20, 0x6e, 0x6f, 0x74, 0x69, 0x63, 0x65, 0x20, 0x61, 0x6e, 0x64,
+  0x20, 0x74, 0x68, 0x69, 0x73, 0x20, 0x70, 0x65, 0x72, 0x6d, 0x69, 0x73,
+  0x73, 0x69, 0x6f, 0x6e, 0x20, 0x6e, 0x6f, 0x74, 0x69, 0x63, 0x65, 0x20,
+  0x73, 0x68, 0x61, 0x6c, 0x6c, 0x20, 0x62, 0x65, 0x20, 0x69, 0x6e, 0x63,
+  0x6c, 0x75, 0x64, 0x65, 0x64, 0x20, 0x69, 0x6e, 0x0a, 0x61, 0x6c, 0x6c,
+  0x20, 0x63, 0x6f, 0x70, 0x69, 0x65, 0x73, 0x20, 0x6f, 0x72, 0x20, 0x73,
+  0x75, 0x62, 0x73, 0x74, 0x61, 0x6e, 0x74, 0x69, 0x61, 0x6c, 0x20, 0x70,
+  0x6f, 0x72, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x20, 0x6f, 0x66, 0x20, 0x74,
+  0x68, 0x65, 0x20, 0x53, 0x6f, 0x66, 0x74, 0x77, 0x61, 0x72, 0x65, 0x2e,
+  0x0a, 0x0a, 0x54, 0x48, 0x45, 0x20, 0x53, 0x4f, 0x46, 0x54, 0x57, 0x41,
+  0x52, 0x45, 0x20, 0x49, 0x53, 0x20, 0x50, 0x52, 0x4f, 0x56, 0x49, 0x44,
+  0x45, 0x44, 0x20, 0x22, 0x41, 0x53, 0x20, 0x49, 0x53, 0x22, 0x2c, 0x20,
+  0x57, 0x49, 0x54, 0x48, 0x4f, 0x55, 0x54, 0x20, 0x57, 0x41, 0x52, 0x52,
+  0x41, 0x4e, 0x54, 0x59, 0x20, 0x4f, 0x46, 0x20, 0x41, 0x4e, 0x59, 0x20,
+  0x4b, 0x49, 0x4e, 0x44, 0x2c, 0x20, 0x45, 0x58, 0x50, 0x52, 0x45, 0x53,
+  0x53, 0x20, 0x4f, 0x52, 0x0a, 0x49, 0x4d, 0x50, 0x4c, 0x49, 0x45, 0x44,
+  0x2c, 0x20, 0x49, 0x4e, 0x43, 0x4c, 0x55, 0x44, 0x49, 0x4e, 0x47, 0x20,
+  0x42, 0x55, 0x54, 0x20, 0x4e, 0x4f, 0x54, 0x20, 0x4c, 0x49, 0x4d, 0x49,
+  0x54, 0x45, 0x44, 0x20, 0x54, 0x4f, 0x20, 0x54, 0x48, 0x45, 0x20, 0x57,
+  0x41, 0x52, 0x52, 0x41, 0x4e, 0x54, 0x49, 0x45, 0x53, 0x20, 0x4f, 0x46,
+  0x20, 0x4d, 0x45, 0x52, 0x43, 0x48, 0x41, 0x4e, 0x54, 0x41, 0x42, 0x49,
+  0x4c, 0x49, 0x54, 0x59, 0x2c, 0x0a, 0x46, 0x49, 0x54, 0x4e, 0x45, 0x53,
+  0x53, 0x20, 0x46, 0x4f, 0x52, 0x20, 0x41, 0x20, 0x50, 0x41, 0x52, 0x54,
+  0x49, 0x43, 0x55, 0x4c, 0x41, 0x52, 0x20, 0x50, 0x55, 0x52, 0x50, 0x4f,
+  0x53, 0x45, 0x20, 0x41, 0x4e, 0x44, 0x20, 0x4e, 0x4f, 0x4e, 0x49, 0x4e,
+  0x46, 0x52, 0x49, 0x4e, 0x47, 0x45, 0x4d, 0x45, 0x4e, 0x54, 0x2e, 0x20,
+  0x49, 0x4e, 0x20, 0x4e, 0x4f, 0x20, 0x45, 0x56, 0x45, 0x4e, 0x54, 0x20,
+  0x53, 0x48, 0x41, 0x4c, 0x4c, 0x20, 0x54, 0x48, 0x45, 0x0a, 0x41, 0x55,
+  0x54, 0x48, 0x4f, 0x52, 0x53, 0x20, 0x4f, 0x52, 0x20, 0x43, 0x4f, 0x50,
+  0x59, 0x52, 0x49, 0x47, 0x48, 0x54, 0x20, 0x48, 0x4f, 0x4c, 0x44, 0x45,
+  0x52, 0x53, 0x20, 0x42, 0x45, 0x20, 0x4c, 0x49, 0x41, 0x42, 0x4c, 0x45,
+  0x20, 0x46, 0x4f, 0x52, 0x20, 0x41, 0x4e, 0x59, 0x20, 0x43, 0x4c, 0x41,
+  0x49, 0x4d, 0x2c, 0x20, 0x44, 0x41, 0x4d, 0x41, 0x47, 0x45, 0x53, 0x20,
+  0x4f, 0x52, 0x20, 0x4f, 0x54, 0x48, 0x45, 0x52, 0x0a, 0x4c, 0x49, 0x41,
+  0x42, 0x49, 0x4c, 0x49, 0x54, 0x59, 0x2c, 0x20, 0x57, 0x48, 0x45, 0x54,
+  0x48, 0x45, 0x52, 0x20, 0x49, 0x4e, 0x20, 0x41, 0x4e, 0x20, 0x41, 0x43,
+  0x54, 0x49, 0x4f, 0x4e, 0x20, 0x4f, 0x46, 0x20, 0x43, 0x4f, 0x4e, 0x54,
+  0x52, 0x41, 0x43, 0x54, 0x2c, 0x20, 0x54, 0x4f, 0x52, 0x54, 0x20, 0x4f,
+  0x52, 0x20, 0x4f, 0x54, 0x48, 0x45, 0x52, 0x57, 0x49, 0x53, 0x45, 0x2c,
+  0x20, 0x41, 0x52, 0x49, 0x53, 0x49, 0x4e, 0x47, 0x20, 0x46, 0x52, 0x4f,
+  0x4d, 0x2c, 0x0a, 0x4f, 0x55, 0x54, 0x20, 0x4f, 0x46, 0x20, 0x4f, 0x52,
+  0x20, 0x49, 0x4e, 0x20, 0x43, 0x4f, 0x4e, 0x4e, 0x45, 0x43, 0x54, 0x49,
+  0x4f, 0x4e, 0x20, 0x57, 0x49, 0x54, 0x48, 0x20, 0x54, 0x48, 0x45, 0x20,
+  0x53, 0x4f, 0x46, 0x54, 0x57, 0x41, 0x52, 0x45, 0x20, 0x4f, 0x52, 0x20,
+  0x54, 0x48, 0x45, 0x20, 0x55, 0x53, 0x45, 0x20, 0x4f, 0x52, 0x20, 0x4f,
+  0x54, 0x48, 0x45, 0x52, 0x20, 0x44, 0x45, 0x41, 0x4c, 0x49, 0x4e, 0x47,
+  0x53, 0x20, 0x49, 0x4e, 0x0a, 0x54, 0x48, 0x45, 0x20, 0x53, 0x4f, 0x46,
+  0x54, 0x57, 0x41, 0x52, 0x45, 0x2e, 0x0a
+};
+unsigned int LICENSE_len = 1099;

/cc @crosbymichael @andrewhsu @vieux
Signed-off-by: Vincent Demeester vincent@sbr.pm

Can you post the diff in the description ? ;)

I can :angel:

LGTM

thanks to https://github.com/krallin/tini/issues/62

authors: crosbymichael glensc vdemeester


text:
Do not fail in TearDown if container not found when removing

If the container is not found when removing, it means it's already not there anymore, so it's safe to ignore. This should reduce a bit some TearDown flakyness..
17:15:30 ----------------------------------------------------------------------
17:15:30 FAIL: check_test.go:157: DockerSuite.TearDownTest
17:15:30
17:15:30 check_test.go:159:
17:15:30     deleteAllContainers(c)
17:15:30 docker_utils_test.go:142:
17:15:30     c.Assert(err, checker.IsNil)
17:15:30 ... value *errors.errorString = &errors.errorString{s:"\nCommand: /go/src/github.com/docker/docker/bundles/1.14.0-dev/binary-client/docker rm -fv e09bc5ab6556\nExitCode: 1, Error: exit status 1\nStdout: \nStderr: Error response from daemon: No such container: e09bc5ab6556\n\n\nFailures:\nExitCode was 1 expected 0\nExpected no error\n"} ("\nCommand: /go/src/github.com/docker/docker/bundles/1.14.0-dev/binary-client/docker rm -fv e09bc5ab6556\nExitCode: 1, Error: exit status 1\nStdout: \nStderr: Error response from daemon: No such container: e09bc5ab6556\n\n\nFailures:\nExitCode was 1 expected 0\nExpected no error\n")
17:15:30
17:15:30
17:15:30 ----------------------------------------------------------------------
17:15:30 PANIC: docker_cli_build_unix_test.go:130: DockerSuite.TestBuildCancellationKillsSleep
17:15:30
17:15:30 ... Panic: Fixture has panicked (see related PANIC)
17:15:30
17:15:30 ----------------------------------------------------------------------

Depending on the "configuration" of the daemon and container running, the container might have killed himself between listing it docker ps -aq and removing it docker rm.
On a side note (and for a future PR 👼), these teardown helper method should really use the API directly (through the Go client) instead.
/cc @thaJeztah @AkihiroSuda @tonistiigi @cpuguy83 @dnephin
🐸
Signed-off-by: Vincent Demeester vincent@sbr.pm

Windows failures are not related, and this fixes some flakiness on CI. I see @AkihiroSuda's comment was addressed, so going ahead and merging

authors: thaJeztah vdemeester


text:
[WIP] Add Application plugin and Event repeater

This PR add concept of application plugin. ( Related #435 )
Infrakit 'app' is an application that can talk to the infrakit plugins using the plugin api but itself listens on a port and offers a REST api for operations.
An example of App is Event repeater.
It is subscribe event plugin and publish the messages to other protocol brocker(e.g. mqtt).
** Get Start
*** Prepare
Start event plugin and mqtt broker
$ ./build/infrakit-event-time
$ docker run -it --rm -p 1883:1883 eclipse-mosquitto

*** Run event repeater
$ ./build/infrakit-application-repeater -h
Event Repeater Application plugin

Usage:
  ./build/infrakit-application-repeater [flags]

Flags:
      --allowall              Allow all event from source and repeat the event to sink as same topic name. default: false
      --log int               Logging level. 0 is least verbose. Max is 5 (default 4)
      --name string           Application name to advertise for discovery (default "app-event-repeater")
      --sink string           Event sink address. default: localhost:1883 (default "localhost:1883")
      --sinkprotocol string   Event sink protocol. Now only mqtt and stderr is implemented. (default "mqtt")
      --source string         Event sourve address. (default "event-plugin")

$ ./build/infrakit-application-repeater --source ~/.infrakit/plugins/event-time --sink tcp://localhost:1883

Now your app connected to event plugin and mqtt broker.
If you set —-allowall, your app subscribe ‘.’ Topic from event and publish all events to broker with original topic.
You can specify repeat topics with infrakit command like below.
$ ./build/infrakit application update -h

___  ________   ________ ________  ________  ___  __    ___  _________
|\  \|\   ___  \|\  _____\\   __  \|\   __  \|\  \|\  \ |\  \|\___   ___\
\ \  \ \  \\ \  \ \  \__/\ \  \|\  \ \  \|\  \ \  \/  /|\ \  \|___ \  \_|
 \ \  \ \  \\ \  \ \   __\\ \   _  _\ \   __  \ \   ___  \ \  \   \ \  \
  \ \  \ \  \\ \  \ \  \_| \ \  \\  \\ \  \ \  \ \  \\ \  \ \  \   \ \  \
   \ \__\ \__\\ \__\ \__\   \ \__\\ _\\ \__\ \__\ \__\\ \__\ \__\   \ \__\
    \|__|\|__| \|__|\|__|    \|__|\|__|\|__|\|__|\|__| \|__|\|__|    \|__|

Update application's resouce

Usage:
  ./build/infrakit application update [flags]

Flags:
      --op int            update operation 1: Add, 2: Delete, 3: Update, 4: Read(default) (default 3)
      --resource string   target resource
      --value string      update value

Global Flags:
  -H, --host stringSlice        host list. Default is local sockets
      --httptest.serve string   if non-empty, httptest.NewServer serves on this address and blocks
      --log int                 log level (default 4)
      --log-caller              include caller function (default true)
      --log-format string       log format: logfmt|term|json (default "term")
      --log-stack               include caller stack
      --log-stdout              log to stdout
      --name string             Name of plugin
$ ./build/infrakit application update --name app-event-repeater --op 1 --resource event --value '[{"sourcetopic":"timer/sec/1","sinktopic":"/time/1s"},{"sourcetopic":"timer/msec/500","sinktopic":"/time/500m"}]'

Events are described json style.
Then you can delete registerd event.
./build/infrakit application update --name app-event-repeater --op 2 --resource event --value '[{"sourcetopic":"timer/sec/1”}]’

@chungers  want to show you my image with a working code. Of cource I will add tests and documents!

@YujiOshima  - nice work!
Can you add some docs on the use of MQTT?   Also let's add some tests...
There's a infrakit util subcommand that is used to start some useful daemons like the mux proxy (for remote client) and a fileserver (for serving config files/templates during development).  Maybe we should just add a subcommand under util for this?  Like infrakit util event-repeater and infrakit util event-repeater update?

@YujiOshima - thank you for taking the lead on this.
Let's leave this PR / branch open and refine it.  I think you're onto something very cool.  My initial thinking when we talked about this was not very refined, but seeing your POC has gotten me thinking about a general API.   Can you have a look at my questions and lets discuss more.  Thank you!

@chungers Thankyou for your comments!
I'm willing to discuss and refine it.
First, We need general rest API (of course tests and docs :) )

Hi @chungers ! I added tests and moved commands to under util.
And I've made the application publish the REST API instead of rpc.
You can use both of unix socket and tcp port.
I also modified the commands and APIs associated with it.
I updated documents: https://github.com/YujiOshima/infrakit/blob/749e1f2a285fba712105c5b643446442b51668c5/pkg/application/eventrepeater/README.md.
Please take a look. Thanks!

@YujiOshima  - can you sync and update this PR?  Sorry the cmd/cli directory has been renamed to cmd/infrakit plus a few fixes.  I will take a look at your README. Thank you!

@chungers Thanks! This PR is now up to date !

@YujiOshima
I get the event repeater but I am little confused by the usage of the infrakit util application tool.  I understand how it is used to add / change/ update topics in the event repeater, but how do you envision this work with the rest of the plugin system?  In particular, you have this path that can map to resource/resourceID -- do these relate to the plugins?
If the infrakit util application is more closely coupled to the event repeater, then maybe we can structure the commands to be infrakit util event-repeater run and infrakit util event-repeater manage ...?

@chungers Thank you for review. I understand you said and I agree that is more reasonable about event-repeater.
But in that case, we will not have any schema for the application.
I think it's ok now, but we need discuss about the schema when other application will add.

@chungers I integrated two commands to event-repater command.
I remained path option for I want to enable to manage with path.
For example, `infrakit util manage post --path /events/EVENTNAME/ --value ...
What do you think.

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "evrepeater" git@github.com:YujiOshima/infrakit.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842354568776
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

Hi @YujiOshima  - Let's discuss this PR.  I think now that we have some useful patterns in terms of controllers vs. plugins, we should revisit this.
I am thinking of the recent example of an enrollment controller that tracks group membership with an instance plugin (e.g. for NFS volume authorization -- see #678 )  could have a nice application here.   We can have a controller that maintains a list of topics to register.  When the user updates the specification either by add/change/and delete entries, we can synchronize this in MQTT via this controller -- perhaps via calls to "Provision" or "Destroy" an MQTT topic...  This would have the nice property of allowing us declaratively specify the MQTT topics from a cluster -- instead of a lot of command line calls that only bash_history remembers...   What do you think?  Let's talk in person if you are at the Moby Summit in Copenhagen.

authors: GordonTheTurtle YujiOshima chungers

repo: docker/infrakit


text:
Jenkins Container - failes to map volumes

Expected behavior
Opening Jenkins Volume should not crash the container
Actual behavior
Container crashes when enabling Volumes
Information about the Issue
It is consistant.
Steps to reproduce the behavior

... Download Jenkins container.
... Start Jenkins
... Click the volume in the Kitematic interface
... Enable Volumes
... Container crashes

unable to replicate on my part - What image are you using? Where do you map the volume? what version of Docker? What operating system?

Closing this issue due to lack of update/activity - Feel free to re-open if appropriate.

authors: FrenchBen thomasgpeters

repo: docker/kitematic


text:
broken link to youtube in readme

When I go to https://youtu.be/vE1iDPx6-Ok?list=PLkA60AVN3hh9gnrYwNO6zTb9U3i1Y9FMY&t=2088
it says the video is private

The whole section for live debugging a Node.js application is just a video, and as this person has pointed out it's a private video.  Can someone either update this or at least remove the section.

authors: CNFloss Romamok

repo: docker/labs


text:
Libnetwork Integration with Plugin and Remote Driver Backend

Now that the modular plugin infra is available as a Docker Package, we can integrate it to support Remote Driver.
This PR integrates Libnetwork and the Plugin Infra to dynamically discover NetworkDriver.
Being a modular package, there is no dependancy on the Docker runtime itself as evidenced in the tests added to libnetwork_test.

@squaremo took care of your comments. it certainly simplifies and makes the remote driver more readable.

took care of your comments

Nice one. The implementation of both lazy- and auto-registration looks good to me.

Thanks @squaremo . ping @mrjana & @aboch

LGTM

LGTM

authors: aboch mavenugo mrjana squaremo

repo: docker/libnetwork


text:
ssh timeout is not configurable

I am working on a custom driver that builds a stack using cloud formation,   and as such that driver does not require a ssh identity file as we are using a third party ssh authentication mechanism.  Unfortunately, the first time I connect to the host the ssh prompt takes a bit of time since some data needs to be retrieved from our identity server.  This can take more than the hard coded 10seconds for ssh timeout.
Would it make sense to either a) increase the timeout or b) make it customizable via a config switch? I'd be willing to commit the change if I thought that there was a chance that the PR would be merged in.
from client.go
var (
baseSSHArgs = []string{
	"-o", "PasswordAuthentication=no",
	"-o", "IdentitiesOnly=yes",
	"-o", "StrictHostKeyChecking=no",
	"-o", "UserKnownHostsFile=/dev/null",
	"-o", "LogLevel=quiet", // suppress "Warning: Permanently added '[localhost]:2022' (ECDSA) to the list of known hosts."
	"-o", "ConnectionAttempts=3", // retry 3 times if SSH connection fails
	"-o", "ConnectTimeout=10", // timeout after 10 seconds
	"-o", "ControlMaster=no", // disable ssh multiplexing
	"-o", "ControlPath=no",
}
defaultClientType = External
)

I'm wondering what is the best case to handle those cases.
Increasing the timeout is not a great idea. It is a not a "one size fits all" thing.
Adding the ConnectTimeout flag is a way of doing it, but this will add yet another flag. And what about ControlPath or StrictHostKeyChecking etc...
I believe we should investigate a solution where we should add a ssh-arg and pass them to the ssh command, overriding default if needed.

Agree with providing option to override entire ssh options.  Default would use existing settings if flag not provided. Or perhaps delegate to the driver.

On Dec 15, 2015, at 5:33 AM, Jean-Laurent de Morlhon notifications@github.com wrote:
I'm wondering what is the best case to handle those cases.
Increasing the timeout is not a great idea. It is a not a "one size fits all" thing.
Adding the ConnectTimeout flag is a way of doing it, but this will add yet another flag. And what about ControlPath or StrictHostKeyChecking etc...
I believe we should investigate a solution where we should add a ssh-arg and pass them to the ssh command, overriding default if needed.
—
Reply to this email directly or view it on GitHub.

Just to make sure, are you 100% positive that the -o ConnectTimeout=no is the issue?  Do you have some ssh -vvv logs from doing so manually that I could take a look at?  Seems like a really long time for one SSH command to be waiting.

Yes we are sure. Our ssh daemon is doing some magic behind the scenes the
first time a user logs in. Sets up user account etc. I have a ticket open
with those people to see if there is something they can fix but subsequent
log ins are normal.
On Tue, Dec 15, 2015 at 5:36 PM Nathan LeClaire notifications@github.com
wrote:

Just to make sure, are you 100% positive that the -o ConnectTimeout=10 is
the issue? Do you have some ssh -vvv logs from doing so manually that I
could take a look at? Seems like a really long time for one SSH command to
be waiting to connect.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/machine/issues/2581#issuecomment-164913846.

It doesn't connect even at second or third attempt?

Actually it seems that the issue is that after I hand the Create call back the instance still isn't "ready" as its installing the conjur ssh key management piece via cloud formation.  The real issue is that the default number of retries 60 isn't sufficient.
A possible work around,  although It seems ugly to me is to poll ssh within the driver before handing back control to docker machine.

A possible work around, although It seems ugly to me is to poll ssh within the driver before handing back control to docker machine.

Although I usually explicitly discourage this type of behavior in drivers (we're converging on a model where they should be as uninvolved with provisioning as possible), in this case it might be unavoidable.

I am going to go ahead and close this for now since I have a viable work around.

Thanks for following up to close @jeffellin .  What was the workaround?

Cloud formation has a script that you can execute during init on the host to delay completion of the stack.  By this time connection succeeds.
Sent from my iPhone.

On Jan 4, 2016, at 6:13 PM, Nathan LeClaire notifications@github.com wrote:
Thanks for following up to close @jeffellin . What was the workaround?
—
Reply to this email directly or view it on GitHub.

authors: fsoppelsa jeanlaurent jeffellin nathanleclaire

repo: docker/machine


text:
Disable portmapper ports (111)

We've recently received an e-mail from our ISP which they forwarded from BSI, German Federal Office for Information Security, in which they inform us about open ports on our servers. All of them are created with docker-machine, that's the reason why I am posting this here.

Original e-mail in German
English translation from Google

Note: This an informational message and not an immediate security threat.
But nonetheless I would like to ask, if there's a possibility to minimize any services, open ports, etc. running on machines create with docker-machine.

Sorry, I just realized, that we just the generic driver here and it's an issue of the VM host image.


text:
_get_comp_words_by_ref missing

Hi docker-machine authors,
I was trying out the bash completion scripts. After adding
docker-machine.bash
docker-machine-prompt.bash
to ~/.bashrc and "source" them, this error was thrown:
$ docker-machine -bash: _get_comp_words_by_ref: command not found
-bash: ((: i < : syntax error: operand expected (error token is " ")
-bash: _get_comp_words_by_ref: command not found
-bash: ((: i < : syntax error: operand expected (error token is " ")

I searched for _get_comp_words_by_ref in this repository, but only a usage was found. It might have been removed, I guess. Do you guys still have that function by any chance?

_get_comp_words_by_ref is a function provided by the bash-completion package.
Possible causes for your error message would be

bash-completion is not installed
bash-completion is not invoked from your login scripts
you source the completion files before bash-completion is initialized

Thanks @albers . I'm going to close the issue as I think it's related to installation issues

source /etc/profile if you aren't already (i.e.: when using bash with alpine).

source /etc/profile if you aren't already (i.e.: when using bash with alpine).

This worked for bash with centos.
thanks!

authors: albers diver-sity mateothegreat nathanleclaire pradhyu