> Can simply replacing the dependency in all of them with bbolt work?
I don't know myself, but some upstream think it's not a trivial change. For
example, see:
https://github.com/hashicorp/raft-boltdb/pull/19#issuecomment-703732437
In short: hashicorp-raft-boltdb wants to make sure there's no
On Sat, Jan 9, 2021 at 2:00 AM Chris Mitchell wrote:
> On Fri, 8 Jan 2021 11:38:59 +0700
> El boulangero wrote:
>
> > Hi Chris,
> >
> > I believe what you refer to is a well-known issue with docker. I have
> > this reference from Apr. 2015:
> > https:/
Hi Chris,
I believe what you refer to is a well-known issue with docker. I have this
reference from Apr. 2015:
https://fosterelli.co/privilege-escalation-via-docker.html
This is how docker works. The most easy mitigation is NOT to add a user to
the docker group. This way, you will always invoke
tic
bool) ([]byte, error) {
+func (m *CodeGeneratorResponse_File) Marshal(b []byte, deterministic bool)
([]byte, error) {
I really have no idea if these changes are significant.
On Wed, Jan 6, 2021 at 11:45 AM El boulangero
wrote:
> It can be fixed with regeneration, in an ugly way. I
th 1.3.4-2 is really
minor.
So I thought that, given the timeline, it was better to make as little
change as possible to this package.
On Wed, Jan 6, 2021 at 11:32 AM Shengjing Zhu wrote:
> On Wed, Jan 06, 2021 at 10:16:16AM +0700, El boulangero wrote:
> > Hello Go Team,
> >
> &g
Yes it's packaged already and waiting in the NEW queue:
https://ftp-master.debian.org/new.html
Cheers,
Arnaud
On Wed, Dec 16, 2020 at 12:10 AM Roger Shimizu
wrote:
> On Thu, Dec 10, 2020 at 2:18 PM Arnaud Rebillout
> wrote:
> >
> > * Package name: golang-golang-x-term
> > Version
Hi! Docker 20.10 is now in unstable.
Best,
Arnaud
On Sat, Dec 12, 2020 at 4:18 AM Michael Biebl wrote:
> On Fri, 27 Nov 2020 15:50:03 +0700 El boulangero
> wrote:
> > Hello all, here comes news from the docker package.
>
> Awesome news.
> I see you have uploaded do
Thanks for the details.
So I just uploaded a new version in experimental, it is
20.10.0~rc1+dfsg3-1. In this version docker.io vendors the old go-radix, as
suggested.
If someone can give it a try and confirm that indeed the bug is fixed, that
would be great. Thanks again.
Arnaud
On Wed, Dec
I just uploaded docker.io 20.10.0~rc1+dfsg2-3 to experimental. containerd
has been completely removed from this version. Now docker.io build-depends
on golang-github-containerd-containerd-dev, and at runtime it depends on
containerd.
There's still some work to be done on the package, mainly
On Sat, Nov 28, 2020 at 11:35 PM Shengjing Zhu wrote:
> Hi
>
> On Sun, Nov 29, 2020 at 12:06 AM El boulangero
> wrote:
> >
> > This broke the build for containerd, and also for docker.io which
> embeds containerd:
> >
> >
> https://buildd.debian.org/st
This broke the build for containerd, and also for docker.io which embeds
containerd:
https://buildd.debian.org/status/fetch.php?pkg=docker.io=s390x=20.10.0%7Erc1%2Bdfsg1-1=1606547204=0
/<>/.gopath/src/
github.com/containerd/containerd/vendor/sigs.k8s.io/structured-merge-diff/v3/value
(vendor
Hello all, here comes news from the docker package.
I can confirm, if ever there was a need, that docker 19.03 does not work
with `systemd.unified_cgroup_hierarchy=true`.
$ dpkg -l | grep docker
ii docker.io 19.03.13+dfsg3-2 amd64 Linux container runtime
$ findmnt /sys/fs/cgroup
ding cgroupv2, systemd maintainer has proposed to switch to cgroupv2
> by default 1year ago. Please see #943981. It seems docker is the only
> blocker now.
>
> // send from my mobile device
>
> El boulangero 于 2020年11月19日周四 11:24写道：
>
>> Hi Shengjing,
>>
>> th
Hi Shengjing,
thanks for the message. I agree that we should start packaging docker
20.10.x in experimental.
Regarding docker 19.03.x: do you know if it will work at all in bullseye?
Right now it works for me, running Debian unstable. I guess it's because
both cgroup interfaces are available:
I could solve the issue by patching spf13/cobra as suggested by Tianon. See
[1] for the patch. I just uploaded the package.
Since docker.io has to embed spf13/cobra, I could patch it there. But if
other packages in Debian have the same issue, then maybe this patch should
be applied to
:
> On Mon, 21 Sep 2020 at 13:48, wrote:
> > On Sun, Sep 20, 2020 at 09:58:45AM +0700, El boulangero wrote:
> > > Do you know what's special with the `tianon/true` image? On what
> OS/release
> > > is it based?
> >
> > It's an image that contains only a single b
Hi,
I can indeed reproduce the issue. Note that this doesn't happen with the
`debian` image, only with the image `tianon/true`.
$ sudo docker run --rm -it debian echo ok
ok
Do you know what's special with the `tianon/true` image? On what OS/release
is it based?
Additionally, did you try with
The patch test--fix-against-libcap2-2.43.patch actually fails the build for
me, in a sid chroot with libcap 2.43.
=== RUN TestTarUntarWithXattr
archive_unix_test.go:267: assertion failed: string
"/tmp/docker-test-untar-origin293876876/2 = cap_block_suspend+ep\n" does
not contain
oby/milestone/76
- https://github.com/docker/cli/milestone/25
On Fri, Jul 17, 2020 at 1:08 PM El boulangero
wrote:
> Hey Reinhard,
>
> glad that you could find a way without patching docker :)
>
> I'd prefer not to patch docker for other packages, especially when it's
> msmtp-mta ships a minimal smtp daemon but it is (normally and on purpose)
> disabled by default so there is no daemon listening unless you enable it.
Ah indeed, that was not immediately clear to me. I just installed
msmtp-mta. The service is indeed disabled by default.
Thanks,
Arnaud
On
Hey Reinhard,
glad that you could find a way without patching docker :)
I'd prefer not to patch docker for other packages, especially when it's not
trivial like this.
The milestone page https://github.com/docker/cli/milestone/25?closed=1
seems to indicate that docker is close to release a 20.03
21 matches
Mail list logo
