Hi,
this morning in its endless wisdom emerge spake to me today:
| WARNING: One or more updates/rebuilds have been skipped due to a dependency
conflict:
|
| app-emulation/containerd:0
|
| (app-emulation/containerd-1.0.0:0/0::gentoo, ebuild scheduled for merge)
conflicts with
| ~app
Put in package.mask:
>=app-emulation/containerd-1.0.0:0/0
On 12/07/2017 08:36 PM, tu...@posteo.de wrote:
> Hi,
>
> this morning in its endless wisdom emerge spake to me today:
>
> | WARNING: One or more updates/rebuilds have been skipped due to a dependency
> conflict:
&
On Fri, 8 Dec 2017 03:36:11 +0100, tu...@posteo.de wrote:
> | WARNING: One or more updates/rebuilds have been skipped due to a
> | dependency conflict:
> |
> | app-emulation/containerd:0
> |
> | (app-emulation/containerd-1.0.0:0/0::gentoo, ebuild scheduled for
> | merge
On 12/08 08:18, Neil Bothwick wrote:
> On Fri, 8 Dec 2017 03:36:11 +0100, tu...@posteo.de wrote:
>
> > | WARNING: One or more updates/rebuilds have been skipped due to a
> > | dependency conflict:
> > |
> > | app-emulation/containerd:0
> > |
> > | (
Blocking the package which gets blocked by its previous one?
Is this a wprkaround, a solution ?
Feels weird...
On 12/07 09:53, Jalus Bilieyich wrote:
> Put in package.mask:
>
> >=app-emulation/containerd-1.0.0:0/0
>
> On 12/07/2017 08:36 PM, tu...@poste
ion
>
> Chain DOCKER (1 references)
> target prot opt source destination
>
> Chain DOCKER-ISOLATION (1 references)
> target prot opt source destination
> RETURN all -- anywhere anywhere
>
ime="2022-12-10T12:17:03.473550705-05:00" level=info msg="scheme \"unix\"
> not registered, fallback to default scheme" module=grpc
> time="2022-12-10T12:17:03.473566413-05:00" level=info
> msg="ccResolverWrapper: sending update to cc:
> {[{unix://
-n 20 /var/log/docker.log
> > time="2022-12-10T12:17:03.473550705-05:00" level=info msg="scheme
> \"unix\"
> > not registered, fallback to default scheme" module=grpc
> > time="2022-12-10T12:17:03.473566413-05:00" level=info
> >
module=grpc
time="2022-12-10T12:17:03.473566413-05:00" level=info
msg="ccResolverWrapper: sending update to cc:
{[{unix:///run/containerd/containerd.sock 0 }] }"
module=grpc
time="2022-12-10T12:17:03.473573787-05:00" level=info msg="ClientConn
switching balancer
;> > time="2022-12-10T12:17:03.473550705-05:00" level=info msg="scheme
>> \"unix\"
>> > not registered, fallback to default scheme" module=grpc
>> > time="2022-12-10T12:17:03.473566413-05:00" level=info
>> > msg="ccRe
otted the -btrfs as soon as I hit Send (of course).
Here's my /etc/portage/package.use/lxc:
app-containers/containerd btrfs
app-containers/docker btrfs overlay
app-containers/lxc examples man
sys-libs/libcap static-libs
--
Regards,
Peter.
t;
One word SECURITY? Trust but verify does come to mind.
Containers are not exactly the most secure apparatus, imho.
"Clair is an open source project for the static analysis of vulnerabilities
in appc and docker containers." [1]. So, I want to hear about the robustness
of the se
k space waste as well. Both of them can be
mitigated by deduplication of RAM and disk pages, but this will eat
lots of CPU and users should be quite advanced to do that.
> Containers are not exactly the most secure apparatus, imho.
> "Clair is an open source project for the static analysis
ut this will eat
lots of CPU and users should be quite advanced to do that.
Containers are not exactly the most secure apparatus, imho.
"Clair is an open source project for the static analysis of vulnerabilities
in appc and docker containers." [1]. So, I want to hear about the robustness
of
ject for the static analysis of vulnerabilities
> in appc and docker containers." [1]. So, I want to hear about the robustness
> of the security on these 'self containerd packages.
> What exactly creates the codes necessary for the container ?
>
> Is their a version that works
;
>> Thank you very much for your responses! Bye! :)
>>
>
> One word SECURITY? Trust but verify does come to mind.
>
> Containers are not exactly the most secure apparatus, imho.
> "Clair is an open source project for the static analysis of vulnerabilities
> in a
do service docker status
* status: crashed
Docker daemon is crashed. To see the reason, I looked at the logs:
pecan@tux ~ $ cat /var/log/docker.log
time="2017-10-07T14:52:13.178261811+02:00" level=info
msg="libcontainerd: new containerd process, pid: 32311"
time=
:
>
> pecan@tux ~ $ sudo service docker status
> * status: crashed
Did you try starting it from the CLI? Any useful messages there?
> Docker daemon is crashed. To see the reason, I looked at the logs:
>
> pecan@tux ~ $ cat /var/log/docker.log
> time="2017-10
S="python3_7 python3_8* -python3_6 -python3_9" 0 KiB
[ebuild R ] app-misc/pax-utils-1.2.6::gentoo USE="seccomp -caps
-debug -python" PYTHON_SINGLE_TARGET="python3_8* -python3_6 -python3_7*
-python3_9%" 0 KiB
[ebuild U ] sys-apps/sandbox-2.20::gentoo [2.18::ge
tatic-libs" ABI_X86="(64) -32 (-x32)"
PYTHON_TARGETS="python3_8* -python3_6 -python3_7* -python3_9" 0 KiB
[ebuild R ] app-misc/pax-utils-1.2.6::gentoo USE="seccomp -caps
-debug -python" PYTHON_SINGLE_TARGET="python3_8* -python3_6 -python3_7*
-python3_
X86="(64) -32 (-x32)" 591 KiB
[ebuild R ] sys-apps/file-5.39-r3::gentoo USE="bzip2 seccomp zlib
-lzma -python -static-libs" ABI_X86="(64) -32 (-x32)"
PYTHON_TARGETS="python3_7 python3_8* -python3_6 -python3_9" 0 KiB
[ebuild R ] app-misc/pax-utils-1.2.6::g
21 matches
Mail list logo
