Bug#983395: podman lacks a runtime dependency on rootlesskit

[Reinhard Tartler]

Control: retitle -1 Please print nicer error message if newuidmap is not
installed
Control: severity -1 wishlist
Control: tag -1 upstream

Andrey, please stop this bug ping-pong.

Feel free to escalate this to the TC, but I don't think you are being
reasonable here.

-- 
regards,
Reinhard

[pkg-go] Bug#983395: podman lacks a runtime dependency on rootlesskit

[Reinhard Tartler]

Control: retitle -1 Please print nicer error message if newuidmap is not
installed
Control: severity -1 wishlist
Control: tag -1 upstream

Andrey, please stop this bug ping-pong.

Feel free to escalate this to the TC, but I don't think you are being
reasonable here.

-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#983395: podman lacks a runtime dependency on rootlesskit

[Reinhard Tartler]

Control: retitle -1 Please print nicer error message if newuidmap is not
installed
Control: severity -1 wishlist
Control: tag -1 upstream

On Wed, Mar 10, 2021 at 11:07 AM Andrej Shadura  wrote:

> Hi,
>
> On Wed, 10 Mar 2021, at 17:04, Shengjing Zhu wrote:
> > > 2) Docker doesn’t require installing anything else to be useful for
> non-root users, if podman does, it should be in Depends.
>
> > No, it's wrong.
>
> > Docker has two modes.
> > 1. root mode. It runs a daemon, and listens to a local socket, which
> > is /var/run/docker.sock The socket is owned by docker group. Non root
> > can't access this unless you are in the docker group.
> > 2. rootless mode, you need the uidmap and rootlesskit package to setup
> > the demon for non root users.
>
> > So, it never requires no thing for non root users.
>
> That’s an implementation detail. From the user’s point of view, a package
> which gives an error on install without any clear pointers to what went
> wrong (e.g. "try to run as root?") looks like a broken package.
>
>
> Can you please report this at https://github.com/containers/podman/issues
and report back with a link to your report?

-- 
regards,
Reinhard

[pkg-go] Bug#983395: podman lacks a runtime dependency on rootlesskit

[Reinhard Tartler]

Control: retitle -1 Please print nicer error message if newuidmap is not
installed
Control: severity -1 wishlist
Control: tag -1 upstream

On Wed, Mar 10, 2021 at 11:07 AM Andrej Shadura  wrote:

> Hi,
>
> On Wed, 10 Mar 2021, at 17:04, Shengjing Zhu wrote:
> > > 2) Docker doesn’t require installing anything else to be useful for
> non-root users, if podman does, it should be in Depends.
>
> > No, it's wrong.
>
> > Docker has two modes.
> > 1. root mode. It runs a daemon, and listens to a local socket, which
> > is /var/run/docker.sock The socket is owned by docker group. Non root
> > can't access this unless you are in the docker group.
> > 2. rootless mode, you need the uidmap and rootlesskit package to setup
> > the demon for non root users.
>
> > So, it never requires no thing for non root users.
>
> That’s an implementation detail. From the user’s point of view, a package
> which gives an error on install without any clear pointers to what went
> wrong (e.g. "try to run as root?") looks like a broken package.
>
>
> Can you please report this at https://github.com/containers/podman/issues
and report back with a link to your report?

-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#983395: podman lacks a runtime dependency on rootlesskit

[Reinhard Tartler]

Control: tag -1 unreproducible

On Wed, Mar 10, 2021 at 10:28 AM Andrej Shadura  wrote:

> Control: reopen -1
>
> On Wed, 10 Mar 2021, at 16:23, Reinhard Tartler wrote:
>
>
>
> On Wed, Feb 24, 2021 at 12:33 AM Shengjing Zhu  wrote:
>
> On Wed, Feb 24, 2021 at 06:47:20AM +0200, Andrei POPESCU wrote:
> > Control: reassign -1 src:libpod 3.0.0+dfsg1-2
> >
> > On Ma, 23 feb 21, 14:26:12, Andrej Shadura wrote:
> > > Package: src:podman
> > > Version: 3.0.0+dfsg1-2
> > > Severity: important
> > >
> > > Dear Maintainer,
> > >
> > > I get an error message when I try to run podman:
> > >
> > > Error: Cannot connect to the Podman socket, make sure there is a
> Podman REST API service running.:
> > > cannot find newuidmap: exec: "newuidmap": executable file not found in
> $PATH
> > >
> > > Installing package rootlesskit fixes the issue.
>
> The errors look like you don't have "newuidmap" binary, instead of
> "rootlesskit".
> For newuidmap, it's provided by uidmap, which is in podman's Recommends.
>
>
> Shengjing is correct, podman works on my laptop just fine without
> rootlesskit.
> The uidmap package is required for running 'rootless' podman, podman itself
> should work just fine without it in 'rootful' mode.
>
>
> I may be wrong about the package needed to make it work  but it does *not*
> in fact work at all without it. It just prints the error message and exits.
> I’m not sure it’s fair to close the issue without investigating further.
>
>
This is where I get stuck:

siretart@x1:~$ newuidmap
-bash: newuidmap: command not found
siretart@x1:~$ podman run --rm -it debian
root@7fb45cf973ac:/# id
uid=0(root) gid=0(root) groups=0(root)
root@7fb45cf973ac:/# exit
siretart@x1:~$ sudo podman run --rm -it debian
root@834154bb33dd:/# exit


in short: I can't reproduce it at all. Can you please help me with a better
test-case?


-- 
regards,
Reinhard

[pkg-go] Bug#983395: podman lacks a runtime dependency on rootlesskit

[Reinhard Tartler]

Control: tag -1 unreproducible

On Wed, Mar 10, 2021 at 10:28 AM Andrej Shadura  wrote:

> Control: reopen -1
>
> On Wed, 10 Mar 2021, at 16:23, Reinhard Tartler wrote:
>
>
>
> On Wed, Feb 24, 2021 at 12:33 AM Shengjing Zhu  wrote:
>
> On Wed, Feb 24, 2021 at 06:47:20AM +0200, Andrei POPESCU wrote:
> > Control: reassign -1 src:libpod 3.0.0+dfsg1-2
> >
> > On Ma, 23 feb 21, 14:26:12, Andrej Shadura wrote:
> > > Package: src:podman
> > > Version: 3.0.0+dfsg1-2
> > > Severity: important
> > >
> > > Dear Maintainer,
> > >
> > > I get an error message when I try to run podman:
> > >
> > > Error: Cannot connect to the Podman socket, make sure there is a
> Podman REST API service running.:
> > > cannot find newuidmap: exec: "newuidmap": executable file not found in
> $PATH
> > >
> > > Installing package rootlesskit fixes the issue.
>
> The errors look like you don't have "newuidmap" binary, instead of
> "rootlesskit".
> For newuidmap, it's provided by uidmap, which is in podman's Recommends.
>
>
> Shengjing is correct, podman works on my laptop just fine without
> rootlesskit.
> The uidmap package is required for running 'rootless' podman, podman itself
> should work just fine without it in 'rootful' mode.
>
>
> I may be wrong about the package needed to make it work  but it does *not*
> in fact work at all without it. It just prints the error message and exits.
> I’m not sure it’s fair to close the issue without investigating further.
>
>
This is where I get stuck:

siretart@x1:~$ newuidmap
-bash: newuidmap: command not found
siretart@x1:~$ podman run --rm -it debian
root@7fb45cf973ac:/# id
uid=0(root) gid=0(root) groups=0(root)
root@7fb45cf973ac:/# exit
siretart@x1:~$ sudo podman run --rm -it debian
root@834154bb33dd:/# exit


in short: I can't reproduce it at all. Can you please help me with a better
test-case?


-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

Control: reassign -1 golang-github-containers-common
Control: tag -1 wontfix
Control: severity -1 normal
Control: affects -1 podman

On Mon, Jan 4, 2021 at 3:47 PM Antonio Terceiro  wrote:

> On Thu, Dec 31, 2020 at 11:26:49AM -0300, Antonio Terceiro wrote:
> > Control: done -1 2.2.1+dfsg1-1
> >
> > On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> > > Can you please try the podman version in experimental? I believe what
> you
> > > describe (the shortnames) should work with version 2.2 just fine
> thanks to
> > > the shortnames.conf file.
> >
> > Ah yes the version in exprimental does fix this. Thanks!
>
> Actually, this only solves the issue for the few official images that
> are listed by default in
> /etc/containers/registries.conf.d/shortnames.conf
>
> Other image names still won't work. But I guess unqualified names are an
> anti-pattern in general?
>
In short, yes.

podman does support what you are asking for, it is just not enabled
by default.

If you wish to, you may set the option "unqualified-search-registries" for
your user
in $HOME/.config/containers/registries.conf, or system-wide
in /etc/containers/registries.conf.
This is documented in great detail on
http://manpages.debian.org/containers-registries.conf

In general, I would find it a reasonable choice to not trust the images on
docker.io
in general. You may want to prefer another container registry, possibly a
local one, over the
one hosted by hub.docker.com. Possibly you require encryption or other
security features.
Podman offers a lot of knobs that are documented in that manpage.

As package maintainer, setting the option of an unqualified path makes
decisions on behalf
of the local system administrator that I'm not necessarily comfortable
making in general. By
refusing to set this, I am trying to raise awareness of the security
implication and hope this
encourages users that may not be familiar with the security implications of
using OCI images
from untrusted sources to do some additional research.

I hope this reasoning makes sense to you. I'm happy to discuss this further
and consider
additional thoughts and input on the matter.

-- 
regards,
Reinhard

[pkg-go] Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

Control: reassign -1 golang-github-containers-common
Control: tag -1 wontfix
Control: severity -1 normal
Control: affects -1 podman

On Mon, Jan 4, 2021 at 3:47 PM Antonio Terceiro  wrote:

> On Thu, Dec 31, 2020 at 11:26:49AM -0300, Antonio Terceiro wrote:
> > Control: done -1 2.2.1+dfsg1-1
> >
> > On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> > > Can you please try the podman version in experimental? I believe what
> you
> > > describe (the shortnames) should work with version 2.2 just fine
> thanks to
> > > the shortnames.conf file.
> >
> > Ah yes the version in exprimental does fix this. Thanks!
>
> Actually, this only solves the issue for the few official images that
> are listed by default in
> /etc/containers/registries.conf.d/shortnames.conf
>
> Other image names still won't work. But I guess unqualified names are an
> anti-pattern in general?
>
In short, yes.

podman does support what you are asking for, it is just not enabled
by default.

If you wish to, you may set the option "unqualified-search-registries" for
your user
in $HOME/.config/containers/registries.conf, or system-wide
in /etc/containers/registries.conf.
This is documented in great detail on
http://manpages.debian.org/containers-registries.conf

In general, I would find it a reasonable choice to not trust the images on
docker.io
in general. You may want to prefer another container registry, possibly a
local one, over the
one hosted by hub.docker.com. Possibly you require encryption or other
security features.
Podman offers a lot of knobs that are documented in that manpage.

As package maintainer, setting the option of an unqualified path makes
decisions on behalf
of the local system administrator that I'm not necessarily comfortable
making in general. By
refusing to set this, I am trying to raise awareness of the security
implication and hope this
encourages users that may not be familiar with the security implications of
using OCI images
from untrusted sources to do some additional research.

I hope this reasoning makes sense to you. I'm happy to discuss this further
and consider
additional thoughts and input on the matter.

-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Restic 0.12 and Debian Bullseye

[Reinhard Tartler]

Hi Felix,

I took the liberty of updating restic to version 0.12 because I needed to
use the rewritten prune feature to clean up a repository that was left
unattended for too long. For this, I also had to update the
golang-github-cenkalti-backoff package to version 4.1.0, which you updated
in git but never got uploaded.

The new restic 0.12 package seems to work just fine on my end. An "ratt"
rebuild of the golang-github-cenkalti-backoff package identified 2 issues (
https://salsa.debian.org/-/snippets/526):

- restic (well, the point of this exercise is to get to 0.12)
- golang-github-xenolf-lego

For the last one, I note that you filed
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974866  and updated the
package in salsa. I took the liberty of uploading your changes to
experimental as well. I also ran ratt on that new upstream version and both
docker.io and docker-registry pass.

So, it seems to me that in order to have restic 0.12 in unstable, we'd need
3 uploads. All of these packages have autopkgtests and would TTBOMU pass
the soft freeze policy.

Any thoughts/concerns?

--
regards,
Reinhard

Bug#982967: FTBFS: unsat-dependency: golang-github-rsc-letsencrypt-dev:amd64

[Reinhard Tartler]

Source: docker.io
Version: 19.03.4+dfsg2-2
Severity: serious
Justification: FTBFS

During a test rebuild of the docker.io package, I noticed that it declares a
build-depends relationship on a non-existing package:

,
| Install main build dependencies (apt-based resolver)
| 
| 
| Installing build dependencies
| Reading package lists...
| Building dependency tree...
| Reading state information...
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
| 
| The following packages have unmet dependencies:
|  sbuild-build-depends-main-dummy : Depends: golang-github-rsc-letsencrypt-dev 
but it is not installable
| E: Unable to correct problems, you have held broken packages.
| apt-get failed.
| E: Package installation failed
| Not removing build depends: cloned chroot in use
`


It appears this package has been removed as part of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956744

Bug#982967: FTBFS: unsat-dependency: golang-github-rsc-letsencrypt-dev:amd64

[Reinhard Tartler]

Source: docker.io
Version: 19.03.4+dfsg2-2
Severity: serious
Justification: FTBFS

During a test rebuild of the docker.io package, I noticed that it declares a
build-depends relationship on a non-existing package:

,
| Install main build dependencies (apt-based resolver)
| 
| 
| Installing build dependencies
| Reading package lists...
| Building dependency tree...
| Reading state information...
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
| 
| The following packages have unmet dependencies:
|  sbuild-build-depends-main-dummy : Depends: golang-github-rsc-letsencrypt-dev 
but it is not installable
| E: Unable to correct problems, you have held broken packages.
| apt-get failed.
| E: Package installation failed
| Not removing build depends: cloned chroot in use
`


It appears this package has been removed as part of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956744

Bug#982957: FTBFS: unsat-dependency: golang-github-rsc-letsencrypt-dev:amd64

[Reinhard Tartler]

Source: docker-registry
Version: 2.7.1+ds2-7
Severity: serious
Justification: FTBFS

In a rebuild, I noticed that this package fails to build from source:

,
| Install main build dependencies (apt-based resolver)
| 
| 
| Installing build dependencies
| Reading package lists...
| Building dependency tree...
| Reading state information...
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
| 
| The following packages have unmet dependencies:
|  sbuild-build-depends-main-dummy : Depends: golang-github-rsc-letsencrypt-dev 
but it is not installable
| E: Unable to correct problems, you have held broken packages.
| apt-get failed.
| E: Package installation failed
| Not removing build depends: cloned chroot in use
`


Apparently it depends on golang-github-rsc-letsencrypt-dev which is has been
removed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956744


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#982957: FTBFS: unsat-dependency: golang-github-rsc-letsencrypt-dev:amd64

[Reinhard Tartler]

Source: docker-registry
Version: 2.7.1+ds2-7
Severity: serious
Justification: FTBFS

In a rebuild, I noticed that this package fails to build from source:

,
| Install main build dependencies (apt-based resolver)
| 
| 
| Installing build dependencies
| Reading package lists...
| Building dependency tree...
| Reading state information...
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
| 
| The following packages have unmet dependencies:
|  sbuild-build-depends-main-dummy : Depends: golang-github-rsc-letsencrypt-dev 
but it is not installable
| E: Unable to correct problems, you have held broken packages.
| apt-get failed.
| E: Package installation failed
| Not removing build depends: cloned chroot in use
`


Apparently it depends on golang-github-rsc-letsencrypt-dev which is has been
removed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956744


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#977542: golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Got it.

On Tue, Feb 16, 2021 at 4:03 PM Sebastian Ramacher 
wrote:

> Control: severity -1 serious
>
> [...]
> Tests are executed as part of the binary target:
>
> dh binary --no-act  | grep auto_test
>dh_auto_test
>
> So the "no required targets may attmept network access" rule applies.
> Raising the severity accordingly. Please disable the tests that access
> the network.
>

Thanks for getting back to me. I've just made a sourceful upload that
disables the problematic test.

-- 
regards,
Reinhard

Bug#977542: golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Got it.

On Tue, Feb 16, 2021 at 4:03 PM Sebastian Ramacher 
wrote:

> Control: severity -1 serious
>
> [...]
> Tests are executed as part of the binary target:
>
> dh binary --no-act  | grep auto_test
>dh_auto_test
>
> So the "no required targets may attmept network access" rule applies.
> Raising the severity accordingly. Please disable the tests that access
> the network.
>

Thanks for getting back to me. I've just made a sourceful upload that
disables the problematic test.

-- 
regards,
Reinhard

Bug#977542: marked as pending in golang-github-revel-revel

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #977542 in golang-github-revel-revel reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-revel-revel/-/commit/f3a1c0a862806c283f7c0c6e09d5842396860336


Skip TestGetCustom which requires network access

Closes: #977542


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/977542

Re: golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Got it.

On Tue, Feb 16, 2021 at 4:03 PM Sebastian Ramacher 
wrote:

> Control: severity -1 serious
>
> [...]
> Tests are executed as part of the binary target:
>
> dh binary --no-act  | grep auto_test
>dh_auto_test
>
> So the "no required targets may attmept network access" rule applies.
> Raising the severity accordingly. Please disable the tests that access
> the network.
>

Thanks for getting back to me. I've just made a sourceful upload that
disables the problematic test.

-- 
regards,
Reinhard

Bug#977542: golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Got it, thanks!

On Tue, Feb 16, 2021 at 1:46 AM Paul Gevers  wrote:

> Hi
>
> On 15-02-2021 23:46, Reinhard Tartler wrote:
> > This package doesn't (like most golang-packages) install a
> > debian/tests/control file,
> > but instead has a field 'Testsuite: autopkgtest-pkg-go' in
> > debian/control instead.
> >
> > How to add the 'needs-internet' restriction to this testsuite?
>
> Please read $(man autodep8) section PACKAGE-SPECIFIC CONFIGURATION.
>
>
I believe
https://salsa.debian.org/go-team/packages/golang-github-revel-revel/-/merge_requests/2
should then address the issue. I haven't found any other package in the
archive making use of this feature though.

Is this something appropriate to upload at this point or rather after
bullseye release?


-- 
regards,
Reinhard

Re: golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Got it, thanks!

On Tue, Feb 16, 2021 at 1:46 AM Paul Gevers  wrote:

> Hi
>
> On 15-02-2021 23:46, Reinhard Tartler wrote:
> > This package doesn't (like most golang-packages) install a
> > debian/tests/control file,
> > but instead has a field 'Testsuite: autopkgtest-pkg-go' in
> > debian/control instead.
> >
> > How to add the 'needs-internet' restriction to this testsuite?
>
> Please read $(man autodep8) section PACKAGE-SPECIFIC CONFIGURATION.
>
>
I believe
https://salsa.debian.org/go-team/packages/golang-github-revel-revel/-/merge_requests/2
should then address the issue. I haven't found any other package in the
archive making use of this feature though.

Is this something appropriate to upload at this point or rather after
bullseye release?


-- 
regards,
Reinhard

Bug#977542: golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Dear Golang Team,

On Mon, Feb 15, 2021 at 1:23 PM Paul Gevers  wrote:

> On 15-02-2021 15:08, Reinhard Tartler wrote:
> > Control: severity -1 important
>
> I agree with this. The Debian infra allows for use of the internet (if
> not used to download programs, that's forbidden by ftp-master [1].)
> [...]
> > The package itself appears to be fine. The tests fail if and only if the
> > test setup doesn't provide (proper) internet connectivity. In fact, it
> > tries at test time to reach http://httpbin.org/get
> > <http://httpbin.org/get> - a service aimed at developing and debugging
> > programs that do HTTP/REST calls.
> [...]
> Please a the "needs-internet" restriction. It's there for this reason.
> Your package seems to have never failed in testing, so, from the Debian
> side of things, it looks you're fine.

[...]
>
> 1) test that require internet to test if certain API's out there work
> are fine *if* annotated with the needs-internet restriction. Personally,
> I consider using on-line frameworks for that acceptable if the effort to
> fake is high (that's often the case for maintainers in downstreams like
> Debian)
> 2) if possible, those tests should be in a separate autopkgtest
> paragraph, such then when needs-internet tests are skipped (e.g. because
> the infra doesn't provide access, like in Ubuntu) the rest of the tests
> are still run.
>

This package doesn't (like most golang-packages) install a
debian/tests/control file,
but instead has a field 'Testsuite: autopkgtest-pkg-go' in debian/control
instead.

How to add the 'needs-internet' restriction to this testsuite?

-- 
regards,
Reinhard

Re: golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Dear Golang Team,

On Mon, Feb 15, 2021 at 1:23 PM Paul Gevers  wrote:

> On 15-02-2021 15:08, Reinhard Tartler wrote:
> > Control: severity -1 important
>
> I agree with this. The Debian infra allows for use of the internet (if
> not used to download programs, that's forbidden by ftp-master [1].)
> [...]
> > The package itself appears to be fine. The tests fail if and only if the
> > test setup doesn't provide (proper) internet connectivity. In fact, it
> > tries at test time to reach http://httpbin.org/get
> > <http://httpbin.org/get> - a service aimed at developing and debugging
> > programs that do HTTP/REST calls.
> [...]
> Please a the "needs-internet" restriction. It's there for this reason.
> Your package seems to have never failed in testing, so, from the Debian
> side of things, it looks you're fine.

[...]
>
> 1) test that require internet to test if certain API's out there work
> are fine *if* annotated with the needs-internet restriction. Personally,
> I consider using on-line frameworks for that acceptable if the effort to
> fake is high (that's often the case for maintainers in downstreams like
> Debian)
> 2) if possible, those tests should be in a separate autopkgtest
> paragraph, such then when needs-internet tests are skipped (e.g. because
> the infra doesn't provide access, like in Ubuntu) the rest of the tests
> are still run.
>

This package doesn't (like most golang-packages) install a
debian/tests/control file,
but instead has a field 'Testsuite: autopkgtest-pkg-go' in debian/control
instead.

How to add the 'needs-internet' restriction to this testsuite?

-- 
regards,
Reinhard

Re: golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Dear Golang Team,

On Mon, Feb 15, 2021 at 1:23 PM Paul Gevers  wrote:

> On 15-02-2021 15:08, Reinhard Tartler wrote:
> > Control: severity -1 important
>
> I agree with this. The Debian infra allows for use of the internet (if
> not used to download programs, that's forbidden by ftp-master [1].)
> [...]
> > The package itself appears to be fine. The tests fail if and only if the
> > test setup doesn't provide (proper) internet connectivity. In fact, it
> > tries at test time to reach http://httpbin.org/get
> > <http://httpbin.org/get> - a service aimed at developing and debugging
> > programs that do HTTP/REST calls.
> [...]
> Please a the "needs-internet" restriction. It's there for this reason.
> Your package seems to have never failed in testing, so, from the Debian
> side of things, it looks you're fine.

[...]
>
> 1) test that require internet to test if certain API's out there work
> are fine *if* annotated with the needs-internet restriction. Personally,
> I consider using on-line frameworks for that acceptable if the effort to
> fake is high (that's often the case for maintainers in downstreams like
> Debian)
> 2) if possible, those tests should be in a separate autopkgtest
> paragraph, such then when needs-internet tests are skipped (e.g. because
> the infra doesn't provide access, like in Ubuntu) the rest of the tests
> are still run.
>

This package doesn't (like most golang-packages) install a
debian/tests/control file,
but instead has a field 'Testsuite: autopkgtest-pkg-go' in debian/control
instead.

How to add the 'needs-internet' restriction to this testsuite?

-- 
regards,
Reinhard

Bug#977542: golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Control: severity -1 important

Dear release team,

I'm writing as a member of the pkg-go team and am mostly concerned about
potential removal of depending packages.

The package itself appears to be fine. The tests fail if and only if the
test setup doesn't provide (proper) internet connectivity. In fact, it
tries at test time to reach http://httpbin.org/get - a service aimed at
developing and debugging programs that do HTTP/REST calls.

Based on this, I'm not convinced about removing a significant amount of
packages from the buster release because of this issue. I'm therefore
downgrading the issue to important and would recommend fixing it right
after buster release.

I'm reaching out to you to confirm this thinking. If you do believe this is
something that ought to be fixed for buster, I'd be happy to upload the
proposed patch to sid right away, as it seems appropriate to disable the
test -- the additional test coverage that it could provide is in no
relationship compared to the effort it would take to fake out the internet
service.

--
regards,
Reinhard

Bug#977542: golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Control: severity -1 important

Dear release team,

I'm writing as a member of the pkg-go team and am mostly concerned about
potential removal of depending packages.

The package itself appears to be fine. The tests fail if and only if the
test setup doesn't provide (proper) internet connectivity. In fact, it
tries at test time to reach http://httpbin.org/get - a service aimed at
developing and debugging programs that do HTTP/REST calls.

Based on this, I'm not convinced about removing a significant amount of
packages from the buster release because of this issue. I'm therefore
downgrading the issue to important and would recommend fixing it right
after buster release.

I'm reaching out to you to confirm this thinking. If you do believe this is
something that ought to be fixed for buster, I'd be happy to upload the
proposed patch to sid right away, as it seems appropriate to disable the
test -- the additional test coverage that it could provide is in no
relationship compared to the effort it would take to fake out the internet
service.

--
regards,
Reinhard

golang-github-revel-revel: Depends on network in tests

[Reinhard Tartler]

Control: severity -1 important

Dear release team,

I'm writing as a member of the pkg-go team and am mostly concerned about
potential removal of depending packages.

The package itself appears to be fine. The tests fail if and only if the
test setup doesn't provide (proper) internet connectivity. In fact, it
tries at test time to reach http://httpbin.org/get - a service aimed at
developing and debugging programs that do HTTP/REST calls.

Based on this, I'm not convinced about removing a significant amount of
packages from the buster release because of this issue. I'm therefore
downgrading the issue to important and would recommend fixing it right
after buster release.

I'm reaching out to you to confirm this thinking. If you do believe this is
something that ought to be fixed for buster, I'd be happy to upload the
proposed patch to sid right away, as it seems appropriate to disable the
test -- the additional test coverage that it could provide is in no
relationship compared to the effort it would take to fake out the internet
service.

--
regards,
Reinhard

Bug#982288: podman: Can't run caontainers - failed to connect to container's attach socket

[Reinhard Tartler]

Control: tag -1 upstream
Control: severity important
Control: retitle -1 rootless podman fails with very long uids

On Mon, Feb 8, 2021 at 6:09 AM Sam Morris  wrote:

> Package: podman
> Version: 3.0.0~rc2+dfsg1-2+b1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: s...@robots.org.uk
>
> After upgrading to podman 3, I can't run any containers any more.
>
> $ podman run --rm -it docker.io/library/debian:10
> Error: failed to connect to container's attach socket:
> /run/user/876099160/libpod/tmp/socket/3178d20b8a3a42642dc6a7f32884df47019bc4a2a82af94fe4928b00ed3293c9/attach:
> no such file or directory
>
> The directory /run/user/876099160/libpod/tmp/socket is empty.
>

It works just fine for me:


siretart@x1:/tmp$ podman run --rm -it docker.io/library/debian:10
Trying to pull docker.io/library/debian:10...
Getting image source signatures
Copying blob b9a857cbf04d done
Copying config e7d08cddf7 done
Writing manifest to image destination
Storing signatures
root@55ebd48e763b:/# exit



> According to unix(7), socket paths are limited to 108 bytes, but the
> path in the error message is slightly longer than that:
>
> $ echo -n 
> /run/user/876099160/libpod/tmp/socket/18654637587d169f834095dce40d4812378e0056936974c9b7073ba1ae767bfa/attach
> | wc -c
> 109
>
>
Is 876099160 really the uid of your user? That seems absurdly long to me,
for me it is '1000'.



> Podman had a similar sounding bug a couple of years ago,
> , but that was
> fixed in podman 0.11.1.
>

That indeed seems related. Would you mind filing a new bug with this
information at https://github.com/containers/podman/issues/new and tell me
the bug number?

Thanks.

Bug#982288: podman: Can't run caontainers - failed to connect to container's attach socket

[Reinhard Tartler]

Control: tag -1 upstream
Control: severity important
Control: retitle -1 rootless podman fails with very long uids

On Mon, Feb 8, 2021 at 6:09 AM Sam Morris  wrote:

> Package: podman
> Version: 3.0.0~rc2+dfsg1-2+b1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: s...@robots.org.uk
>
> After upgrading to podman 3, I can't run any containers any more.
>
> $ podman run --rm -it docker.io/library/debian:10
> Error: failed to connect to container's attach socket:
> /run/user/876099160/libpod/tmp/socket/3178d20b8a3a42642dc6a7f32884df47019bc4a2a82af94fe4928b00ed3293c9/attach:
> no such file or directory
>
> The directory /run/user/876099160/libpod/tmp/socket is empty.
>

It works just fine for me:


siretart@x1:/tmp$ podman run --rm -it docker.io/library/debian:10
Trying to pull docker.io/library/debian:10...
Getting image source signatures
Copying blob b9a857cbf04d done
Copying config e7d08cddf7 done
Writing manifest to image destination
Storing signatures
root@55ebd48e763b:/# exit



> According to unix(7), socket paths are limited to 108 bytes, but the
> path in the error message is slightly longer than that:
>
> $ echo -n 
> /run/user/876099160/libpod/tmp/socket/18654637587d169f834095dce40d4812378e0056936974c9b7073ba1ae767bfa/attach
> | wc -c
> 109
>
>
Is 876099160 really the uid of your user? That seems absurdly long to me,
for me it is '1000'.



> Podman had a similar sounding bug a couple of years ago,
> , but that was
> fixed in podman 0.11.1.
>

That indeed seems related. Would you mind filing a new bug with this
information at https://github.com/containers/podman/issues/new and tell me
the bug number?

Thanks.

[pkg-go] Bug#982288: podman: Can't run caontainers - failed to connect to container's attach socket

[Reinhard Tartler]

Control: tag -1 upstream
Control: severity important
Control: retitle -1 rootless podman fails with very long uids

On Mon, Feb 8, 2021 at 6:09 AM Sam Morris  wrote:

> Package: podman
> Version: 3.0.0~rc2+dfsg1-2+b1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: s...@robots.org.uk
>
> After upgrading to podman 3, I can't run any containers any more.
>
> $ podman run --rm -it docker.io/library/debian:10
> Error: failed to connect to container's attach socket:
> /run/user/876099160/libpod/tmp/socket/3178d20b8a3a42642dc6a7f32884df47019bc4a2a82af94fe4928b00ed3293c9/attach:
> no such file or directory
>
> The directory /run/user/876099160/libpod/tmp/socket is empty.
>

It works just fine for me:


siretart@x1:/tmp$ podman run --rm -it docker.io/library/debian:10
Trying to pull docker.io/library/debian:10...
Getting image source signatures
Copying blob b9a857cbf04d done
Copying config e7d08cddf7 done
Writing manifest to image destination
Storing signatures
root@55ebd48e763b:/# exit



> According to unix(7), socket paths are limited to 108 bytes, but the
> path in the error message is slightly longer than that:
>
> $ echo -n 
> /run/user/876099160/libpod/tmp/socket/18654637587d169f834095dce40d4812378e0056936974c9b7073ba1ae767bfa/attach
> | wc -c
> 109
>
>
Is 876099160 really the uid of your user? That seems absurdly long to me,
for me it is '1000'.



> Podman had a similar sounding bug a couple of years ago,
> , but that was
> fixed in podman 0.11.1.
>

That indeed seems related. Would you mind filing a new bug with this
information at https://github.com/containers/podman/issues/new and tell me
the bug number?

Thanks.
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#982030: nmu: libpod_libpod

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

It seems that there is a problem with the image cache in podman 3.0-rc2, which
turns out to be a bug in 'buildah'. I've uploaded a fix to unstable as
golang-github-containers-buildah_1.19.3+dfsg1-2, but now we also need to get
src:libpod rebuilt.


nmu libpod_3.0.0~rc2+dfsg1-2 . ANY . unstable . -m 'Rebuild against 
golang-github-containers-buildah_1.19.3+dfsg1-2 to fix #981849'
dw libpod_3.0.0~rc2+dfsg1-2 . ANY . -m 'golang-github-containers-buildah (>= 
1.19.3+dfsg1-2)'



Thanks!

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#982030: nmu: libpod_libpod

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

It seems that there is a problem with the image cache in podman 3.0-rc2, which
turns out to be a bug in 'buildah'. I've uploaded a fix to unstable as
golang-github-containers-buildah_1.19.3+dfsg1-2, but now we also need to get
src:libpod rebuilt.


nmu libpod_3.0.0~rc2+dfsg1-2 . ANY . unstable . -m 'Rebuild against 
golang-github-containers-buildah_1.19.3+dfsg1-2 to fix #981849'
dw libpod_3.0.0~rc2+dfsg1-2 . ANY . -m 'golang-github-containers-buildah (>= 
1.19.3+dfsg1-2)'



Thanks!

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#981849: podman build does not use the cache

[Reinhard Tartler]

Control: reassign -1 buildah 1.19.3+dfsg1-1
Control: affects -1 podman

On Thu, Feb 4, 2021 at 12:55 PM Antonio Terceiro 
wrote:

> Control: forwarded -1 https://github.com/containers/podman/issues/9233
>
> There.
>

Awesome. As it turns out, this is actually an issue in buildah
and needs to be fixed there. The patch for this can be found here:
https://patch-diff.githubusercontent.com/raw/containers/buildah/pull/2967.patch

As for timing, I'd prefer to let the current packages migrate to testing
first,
but if you (or anyone else) feels strongly and where to raise this to RC,
I'd prioritize the upload.
--
regards,
Reinhard

[pkg-go] Bug#981849: podman build does not use the cache

[Reinhard Tartler]

Control: reassign -1 buildah 1.19.3+dfsg1-1
Control: affects -1 podman

On Thu, Feb 4, 2021 at 12:55 PM Antonio Terceiro 
wrote:

> Control: forwarded -1 https://github.com/containers/podman/issues/9233
>
> There.
>

Awesome. As it turns out, this is actually an issue in buildah
and needs to be fixed there. The patch for this can be found here:
https://patch-diff.githubusercontent.com/raw/containers/buildah/pull/2967.patch

As for timing, I'd prefer to let the current packages migrate to testing
first,
but if you (or anyone else) feels strongly and where to raise this to RC,
I'd prioritize the upload.
--
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#981849: podman build does not use the cache

[Reinhard Tartler]

Control: tags -1 upstream

On Thu, Feb 4, 2021 at 10:33 AM Antonio Terceiro 
wrote:

>
> After upgrading from 3.0.0~rc1+dfsg1-1, which was in experimental, to the
> version that was just uploaded to unstable, `podman build` stopped using
> the
> cache when building images.


I've checked with upstream, and got this response:

11:33  siretart: i recall merging a commit that changed the way we
  handle enabling/disabling the build cache, but it should still
  be working + enabled by default
11:34  possible we've introduced a bug, cache is difficult to do
  automated testing on AFAIK
11:34  i would open a github issue about it so we can make sure this
  is resolved prior to 3.0 final

Would you mind filing a new issue at
https://github.com/containers/podman/issues/new and let me know the bug
number?

Thanks!

-- 
regards,
Reinhard

[pkg-go] Bug#981849: podman build does not use the cache

[Reinhard Tartler]

Control: tags -1 upstream

On Thu, Feb 4, 2021 at 10:33 AM Antonio Terceiro 
wrote:

>
> After upgrading from 3.0.0~rc1+dfsg1-1, which was in experimental, to the
> version that was just uploaded to unstable, `podman build` stopped using
> the
> cache when building images.


I've checked with upstream, and got this response:

11:33  siretart: i recall merging a commit that changed the way we
  handle enabling/disabling the build cache, but it should still
  be working + enabled by default
11:34  possible we've introduced a bug, cache is difficult to do
  automated testing on AFAIK
11:34  i would open a github issue about it so we can make sure this
  is resolved prior to 3.0 final

Would you mind filing a new issue at
https://github.com/containers/podman/issues/new and let me know the bug
number?

Thanks!

-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#981708: io.podman.{socket,service} symlinks not cleaned up on upgrades

[Reinhard Tartler]

Hi Michael,

On Tue, Feb 2, 2021 at 8:15 PM Michael Biebl  wrote:

> it seems, podman no longer ships the following two units:
> io.podman.socket and io.podman.service
>

would you mind having a look at
https://salsa.debian.org/debian/libpod/-/merge_requests/3

I'm not sure if it is complete to fix #981708.

Thanks!
-rt

[pkg-go] Bug#981708: io.podman.{socket, service} symlinks not cleaned up on upgrades

[Reinhard Tartler]

Hi Michael,

On Tue, Feb 2, 2021 at 8:15 PM Michael Biebl  wrote:

> it seems, podman no longer ships the following two units:
> io.podman.socket and io.podman.service
>

would you mind having a look at
https://salsa.debian.org/debian/libpod/-/merge_requests/3

I'm not sure if it is complete to fix #981708.

Thanks!
-rt
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

On Tue, Feb 2, 2021 at 3:01 PM Paul Gevers  wrote:

> Unfortunately I believe we're not really in the position to advise you
> on the matter at hand as there are obviously pro's and con's for both
> side which require detailed knowledge to balance them. It seems to me
> that your having a decent discussion so we trust that you'll (together)
> make the right choice, for the users and the release process.
>

Thanks for the feedback.

Based on the productive (and constructive) discussion, and after reflecting
on the matter for another night, I'm going to proceed with uploading the
required
packages. I'll also continue working with Dimtry, podman upstream and nomad
upstream
on finding a solution to get nomad-driver-podman into testing.

Thanks to everyone who has participated in this discussion! Really looking
forward
to bullseye!

-rt


-- 
regards,
Reinhard

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

On Tue, Feb 2, 2021 at 3:01 PM Paul Gevers  wrote:

> Unfortunately I believe we're not really in the position to advise you
> on the matter at hand as there are obviously pro's and con's for both
> side which require detailed knowledge to balance them. It seems to me
> that your having a decent discussion so we trust that you'll (together)
> make the right choice, for the users and the release process.
>

Thanks for the feedback.

Based on the productive (and constructive) discussion, and after reflecting
on the matter for another night, I'm going to proceed with uploading the
required
packages. I'll also continue working with Dimtry, podman upstream and nomad
upstream
on finding a solution to get nomad-driver-podman into testing.

Thanks to everyone who has participated in this discussion! Really looking
forward
to bullseye!

-rt


-- 
regards,
Reinhard

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

On Tue, Feb 2, 2021 at 11:54 AM Adrian Bunk  wrote:

> On Sat, Jan 30, 2021 at 09:08:36PM -0500, Reinhard Tartler wrote:
> >...
> > On Mon, Jan 25, 2021 at 7:15 PM Dmitry Smirnov 
> wrote:
> >...
> > A low-effort workaround could be to add a build-dependency on podman to
> > prevent
> > it from building on mipsen. A better fix could be to patch podman to
> build
> > on
> > mipsen...
> >...
>
> The only code change in golang-github-containers-psgo 1.5.2
> seems to be a fix for a build issue affecting podman on mips,
> this might be sufficient to fix building podman 3.
>
> After that fixing podman 2 on mips would require cherry-picking commits
>
> https://github.com/containers/podman/commit/1ad796677e1ce3f03463c791818176586987c389
>
> https://github.com/containers/podman/commit/9dfc636fd613c5dac4717473ae2fd214f9835748
>
> All of the above untested, but I can check that if someone does the
> trivial golang-github-containers-psgo upgrade.
>

uploaded:
https://tracker.debian.org/news/1227019/accepted-golang-github-containers-psgo-152-1-source-into-unstable/

Tests on mips appreciated. If you can, let me know if rootless podman works
on mips!

-rt

-- 
regards,
Reinhard

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

On Tue, Feb 2, 2021 at 11:54 AM Adrian Bunk  wrote:

> On Sat, Jan 30, 2021 at 09:08:36PM -0500, Reinhard Tartler wrote:
> >...
> > On Mon, Jan 25, 2021 at 7:15 PM Dmitry Smirnov 
> wrote:
> >...
> > A low-effort workaround could be to add a build-dependency on podman to
> > prevent
> > it from building on mipsen. A better fix could be to patch podman to
> build
> > on
> > mipsen...
> >...
>
> The only code change in golang-github-containers-psgo 1.5.2
> seems to be a fix for a build issue affecting podman on mips,
> this might be sufficient to fix building podman 3.
>
> After that fixing podman 2 on mips would require cherry-picking commits
>
> https://github.com/containers/podman/commit/1ad796677e1ce3f03463c791818176586987c389
>
> https://github.com/containers/podman/commit/9dfc636fd613c5dac4717473ae2fd214f9835748
>
> All of the above untested, but I can check that if someone does the
> trivial golang-github-containers-psgo upgrade.
>

uploaded:
https://tracker.debian.org/news/1227019/accepted-golang-github-containers-psgo-152-1-source-into-unstable/

Tests on mips appreciated. If you can, let me know if rootless podman works
on mips!

-rt

-- 
regards,
Reinhard

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

On Mon, Feb 1, 2021 at 4:58 PM Dmitry Smirnov  wrote:

>
> > The fact that as has been mentioned in this thread a) bullseye is around
> > the corner b) nomad-driver-podman isn't even in testing right now, c)
> > podman itself is a much more popular package than nomad-driver-podman
> > (or nomad for that matter), are all very strong points in favor of
> > option (2), but are all *on top* of the original point -- again, IMHO.
>
> [...]



> Also consider the discouragement factor. Me, maintainer of podman, nomad,
> nomad-driver-podman as well as their countless dependency packages,
> is at the verge of saying "whatever" and stop caring or even walk away
> from the mess since the moment when technology become useless to me.
> Too bad I've invested so much time stabilising it if "release concerns"
> require me to break it...
>
> I'll think more about all this.


Thank you for participating in a thoughtful and deliberate manner. I really
appreciate it. Please rest assured that I do care about all users of
'testing' and 'unstable' a lot, and that's precisely why I've started this
discussion thread. It is important to consider what are the tradeoffs at
hand and what's the best interest for our users.

In this case, I'm thinking about users of the upcoming "Debian/stable"
release. They are going to use packages from this distribution this year
and the years to come. Serving them with nomad as a simple and usable
orchestrator surely sounds tempting. The thing is, this thread didn't
convince me so far that nomad-driver-podman with the varlink interface
provides as much value as I wish it had. I've even reached out to podman
upstream to clarify their opinion. Basically, the workaround to avoid a
container registry in the nomad-driver-podman package can be characterized
as "inefficient" at best as podman would parse each and every layer in
every OCI archive on every container start (at least in the 2.x
implementation). Also, [1] makes me question whether this use-case is in
scope of nomad upstream's intention.

I'd also like to point out that while I agree that we should make every
effort to not "break" our users of "testing"/"unstable", the setup remains
a QA vehicle. It would be very limiting if we enforced this goal too
strictly. Taking it to the extreme, it would prevent the release team from
removing packages from 'testing' as even packages with severe bugs like
grave security vulnerabilities still provides a lot of value to users that
run their setups in an air-gapped environment.

I'm a bit surprised that you feel being at the verge of saying "whatever"
and giving up. The basic functionality you are asking for is already
present, and just a matter of integrating into the package, a task that you
have demonstrated to have significantly more skill than most other
developers, me included. The specific setup that you are looking for is
currently missing ind podman 3.0, but the workaround Valentin sketched at
[2] really doesn't sound that hard to implement. Maybe you can look at it
as "almost there" and find motivation in working with upstream on a
solution that serves all nomad users rather than throwing in the towel?

[1]
https://github.com/hashicorp/nomad-driver-podman/issues/67#issuecomment-721042654
[2] https://github.com/containers/podman/issues/8927#issuecomment-762083962

-- 
regards,
Reinhard

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

On Mon, Feb 1, 2021 at 4:58 PM Dmitry Smirnov  wrote:

>
> > The fact that as has been mentioned in this thread a) bullseye is around
> > the corner b) nomad-driver-podman isn't even in testing right now, c)
> > podman itself is a much more popular package than nomad-driver-podman
> > (or nomad for that matter), are all very strong points in favor of
> > option (2), but are all *on top* of the original point -- again, IMHO.
>
> [...]



> Also consider the discouragement factor. Me, maintainer of podman, nomad,
> nomad-driver-podman as well as their countless dependency packages,
> is at the verge of saying "whatever" and stop caring or even walk away
> from the mess since the moment when technology become useless to me.
> Too bad I've invested so much time stabilising it if "release concerns"
> require me to break it...
>
> I'll think more about all this.


Thank you for participating in a thoughtful and deliberate manner. I really
appreciate it. Please rest assured that I do care about all users of
'testing' and 'unstable' a lot, and that's precisely why I've started this
discussion thread. It is important to consider what are the tradeoffs at
hand and what's the best interest for our users.

In this case, I'm thinking about users of the upcoming "Debian/stable"
release. They are going to use packages from this distribution this year
and the years to come. Serving them with nomad as a simple and usable
orchestrator surely sounds tempting. The thing is, this thread didn't
convince me so far that nomad-driver-podman with the varlink interface
provides as much value as I wish it had. I've even reached out to podman
upstream to clarify their opinion. Basically, the workaround to avoid a
container registry in the nomad-driver-podman package can be characterized
as "inefficient" at best as podman would parse each and every layer in
every OCI archive on every container start (at least in the 2.x
implementation). Also, [1] makes me question whether this use-case is in
scope of nomad upstream's intention.

I'd also like to point out that while I agree that we should make every
effort to not "break" our users of "testing"/"unstable", the setup remains
a QA vehicle. It would be very limiting if we enforced this goal too
strictly. Taking it to the extreme, it would prevent the release team from
removing packages from 'testing' as even packages with severe bugs like
grave security vulnerabilities still provides a lot of value to users that
run their setups in an air-gapped environment.

I'm a bit surprised that you feel being at the verge of saying "whatever"
and giving up. The basic functionality you are asking for is already
present, and just a matter of integrating into the package, a task that you
have demonstrated to have significantly more skill than most other
developers, me included. The specific setup that you are looking for is
currently missing ind podman 3.0, but the workaround Valentin sketched at
[2] really doesn't sound that hard to implement. Maybe you can look at it
as "almost there" and find motivation in working with upstream on a
solution that serves all nomad users rather than throwing in the towel?

[1]
https://github.com/hashicorp/nomad-driver-podman/issues/67#issuecomment-721042654
[2] https://github.com/containers/podman/issues/8927#issuecomment-762083962

-- 
regards,
Reinhard

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

On Sat, Jan 30, 2021 at 10:33 PM Dmitry Smirnov  wrote:

>
> > > No it hasn't... :( There is a serious regression:
> > >   https://github.com/hashicorp/nomad-driver-podman/issues/69
> >
> > I'm having a hard time considering this a "serious" regression. The
> problem
> > as far as I understand is that while the driver does work fine with the
> > new REST interface, it doesn't allow you to upload images in OCI format
> > from local disk.
> > If you instead chose to have imaged pulled from a (local) image registry,
> > the driver would work fine.
>
> Do you have experience operating local container registry??
> I have and I can tell that it is not fun, to say the least. Docker registry
> leaks disk space because it does not garbage collect some images...
> Neither does it like Buildah/Podman's native image format, although it
> can be remedied by building images with "export BUILDAH_FORMAT=docker".
>
> IMHO just saving built images to network share is the best, easiest, most
> reliable way of deploying local images. It is the best to avoid Docker
> registry whenever possible.
>

Have you considered keeping your NFS share with the OCI images,
but using a registry just for distribution to your cluster?
This way your registry is basically just a cache.

Also, there may be alternatives to the official docker registry
image. For instance, debian salsa offers team-specific container
registries (built-in functionality for gitlab). For self-hosting
solutions, maybe quay.io might be a better fit. On
https://docs.projectquay.io/welcome.html you can find instructions
for simple evaluation/developer setups as well as high-availability
configurations (cf. https://docs.projectquay.io/deploy_quay_ha.html)



> > Blocking podman 3.0 because of this is something I can't get behind.
> > But maybe I'm missing something else here?
>
> I hope my answer above helps to understand the issue...
>

I can follow your thinking, and I sympathize, but ultimately, I
still think that on the compromise between keeping varlink and podman
at version 2.1, and updating to podman 3.0 and getting docker-compose
functionality, Debian's users are better served by having podman 3.0
in bullseye.
-- 
regards,
Reinhard

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

On Sat, Jan 30, 2021 at 10:33 PM Dmitry Smirnov  wrote:

>
> > > No it hasn't... :( There is a serious regression:
> > >   https://github.com/hashicorp/nomad-driver-podman/issues/69
> >
> > I'm having a hard time considering this a "serious" regression. The
> problem
> > as far as I understand is that while the driver does work fine with the
> > new REST interface, it doesn't allow you to upload images in OCI format
> > from local disk.
> > If you instead chose to have imaged pulled from a (local) image registry,
> > the driver would work fine.
>
> Do you have experience operating local container registry??
> I have and I can tell that it is not fun, to say the least. Docker registry
> leaks disk space because it does not garbage collect some images...
> Neither does it like Buildah/Podman's native image format, although it
> can be remedied by building images with "export BUILDAH_FORMAT=docker".
>
> IMHO just saving built images to network share is the best, easiest, most
> reliable way of deploying local images. It is the best to avoid Docker
> registry whenever possible.
>

Have you considered keeping your NFS share with the OCI images,
but using a registry just for distribution to your cluster?
This way your registry is basically just a cache.

Also, there may be alternatives to the official docker registry
image. For instance, debian salsa offers team-specific container
registries (built-in functionality for gitlab). For self-hosting
solutions, maybe quay.io might be a better fit. On
https://docs.projectquay.io/welcome.html you can find instructions
for simple evaluation/developer setups as well as high-availability
configurations (cf. https://docs.projectquay.io/deploy_quay_ha.html)



> > Blocking podman 3.0 because of this is something I can't get behind.
> > But maybe I'm missing something else here?
>
> I hope my answer above helps to understand the issue...
>

I can follow your thinking, and I sympathize, but ultimately, I
still think that on the compromise between keeping varlink and podman
at version 2.1, and updating to podman 3.0 and getting docker-compose
functionality, Debian's users are better served by having podman 3.0
in bullseye.
-- 
regards,
Reinhard

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

trimming cc-list

On Mon, Jan 25, 2021 at 7:15 PM Dmitry Smirnov  wrote:

> On Monday, 25 January 2021 10:47:25 PM AEDT Reinhard Tartler wrote:
> > It seems that https://packages.qa.debian.org/n/nomad-driver-podman.html
> > has never made it to testing, which makes me wonder whether
> > it'll make it to bullseye.
>
> Nothing should stop it from getting to "testing". It was blocked on
> due to "autopkgtest-pkg-go" which is useless for binary-only packages.
> At a time I did not mind because I was not sure whether it is
> good enough for "testing".
>

According to https://qa.debian.org/excuses.php?package=nomad-driver-podman
the package won't migrate because of unsatisfiable dependencies on mips64el
and mips64el. This is because the 'podman' package doesn't (currently)
build on mipsen, whereas the nomad-driver-podman does. Apparently "britney"
doesn't permit "partial" migrations...

A low-effort workaround could be to add a build-dependency on podman to
prevent
it from building on mipsen. A better fix could be to patch podman to build
on
mipsen...

> > Luckily it seems that issue
> > has been fixed in latest master of nomad-driver-podman, cf.
>
> No it hasn't... :( There is a serious regression:
>
>   https://github.com/hashicorp/nomad-driver-podman/issues/69


I'm having a hard time considering this a "serious" regression. The problem
as far as I understand is that while the driver does work fine with the new
REST interface, it doesn't allow you to upload images in OCI format from
local
disk. If you instead chose to have imaged pulled from a (local) image
registry,
the driver would work fine.

Blocking podman 3.0 because of this is something I can't get behind. But
maybe
I'm missing something else here?

-- 
regards,
Reinhard

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

trimming cc-list

On Mon, Jan 25, 2021 at 7:15 PM Dmitry Smirnov  wrote:

> On Monday, 25 January 2021 10:47:25 PM AEDT Reinhard Tartler wrote:
> > It seems that https://packages.qa.debian.org/n/nomad-driver-podman.html
> > has never made it to testing, which makes me wonder whether
> > it'll make it to bullseye.
>
> Nothing should stop it from getting to "testing". It was blocked on
> due to "autopkgtest-pkg-go" which is useless for binary-only packages.
> At a time I did not mind because I was not sure whether it is
> good enough for "testing".
>

According to https://qa.debian.org/excuses.php?package=nomad-driver-podman
the package won't migrate because of unsatisfiable dependencies on mips64el
and mips64el. This is because the 'podman' package doesn't (currently)
build on mipsen, whereas the nomad-driver-podman does. Apparently "britney"
doesn't permit "partial" migrations...

A low-effort workaround could be to add a build-dependency on podman to
prevent
it from building on mipsen. A better fix could be to patch podman to build
on
mipsen...

> > Luckily it seems that issue
> > has been fixed in latest master of nomad-driver-podman, cf.
>
> No it hasn't... :( There is a serious regression:
>
>   https://github.com/hashicorp/nomad-driver-podman/issues/69


I'm having a hard time considering this a "serious" regression. The problem
as far as I understand is that while the driver does work fine with the new
REST interface, it doesn't allow you to upload images in OCI format from
local
disk. If you instead chose to have imaged pulled from a (local) image
registry,
the driver would work fine.

Blocking podman 3.0 because of this is something I can't get behind. But
maybe
I'm missing something else here?

-- 
regards,
Reinhard

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

On Sat, Jan 30, 2021 at 5:03 PM Antonio Terceiro 
wrote:

> FWIW I have been using podman 3.0.0~rc1 from experimental for a few days
> and haven't noticed anything wrong with it. I hope we can have that
> version in bullseye.
>


Me too.

Dear release team, do you have any opinion on this topic?

thanks,
-rt



-- 
regards,
Reinhard

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

On Sat, Jan 30, 2021 at 5:03 PM Antonio Terceiro 
wrote:

> FWIW I have been using podman 3.0.0~rc1 from experimental for a few days
> and haven't noticed anything wrong with it. I hope we can have that
> version in bullseye.
>


Me too.

Dear release team, do you have any opinion on this topic?

thanks,
-rt



-- 
regards,
Reinhard

Re: [proposed-migration] libpod 2.1.1+dfsg1-4ubuntu3 stuck in hirsute-proposed for 3 days.

[Reinhard Tartler]

I understand that the issue below is caused by a change
in libpod_2.1.1+dfsg1-4ubuntu3 that drops the binary package
golang-github-containers-libpod-dev. I resorted to this rather
drastic action because of differences in how the ubuntu src:docker.io
package vendors the "docker/libnetwork" golang library. In Debian, the
docker.io package installs it in a directory that can be imported by
libpod, in Ubuntu, it installs it in a nonstandard path that requires
really ugly hackery in debian/rules to get the package built. That hackery
breaks autopkgtest. I've decided to workaround this by removing
the golang-github-containers-libpod-dev package, which is not currently
used by any other package. This change will make the autopkgtest golang
runner not trip off the ugly hackery in the configure target and evidently
now autopkgtests is passing.

Ideally, I'd love to see the docker.io package provide vendored libraries
just like in Debian. I've been in contact with Rick and Lucas (CC'ed) about
this last July, but we couldn't resolve this difference in opinion. As a
result, the packages remain diverged for now and require small, subtle
(read: hard to understand) and ugly deltas to the packages in Debian.

To get the package unstuck now, I guess some ftp-master or release team
member would need to remove the golang-github-containers-libpod-dev from
hirsute. I'm not sure who to contact about this, hence writing this email.

Thank you for your assistance!
-rt

On Fri, Jan 29, 2021 at 10:02 PM Ubuntu Release Team 
wrote:

> Hi,
>
> libpod 2.1.1+dfsg1-4ubuntu3 needs attention.
>
> It has been stuck in hirsute-proposed for 3 days.
>
> You either sponsored or uploaded this package, please investigate why it
> hasn't been approved for migration.
>
>
> http://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#libpod
>
> https://wiki.ubuntu.com/ProposedMigration
>
> If you have any questions about this email, please ask them in
> #ubuntu-release channel on Freenode IRC.
>
> Regards, Ubuntu Release Team.
>


-- 
regards,
Reinhard
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Bug#980480: [pkg-go] Bug#980480: autopkgtest always fail

[Reinhard Tartler]

On Tue, Jan 26, 2021 at 10:44 AM Shengjing Zhu  wrote:

> So for podman, it can either keep this line and drop
> autopkgtest-pkg-go, or write Makefile in a way that autopkgtest-pkg-go
> can recognize.
>

I suppose the issue is around here:
https://salsa.debian.org/go-team/packages/dh-golang/-/blob/21002d72bfeab16a7f86696a585e04aa12803585/script/dh_golang_autopkgtest#L40-45

the issue is that the testsuite is literally invoking debian/rules (with
the options -pRfq), and the `$(info ...)` statement is producing additional
output that confuses the awk script from the debhelper.

I don't see a good solution to that other than
rewriting dh_golang_autopkgtest.

-rt

[pkg-go] Bug#980480: Bug#980480: autopkgtest always fail

[Reinhard Tartler]

On Tue, Jan 26, 2021 at 10:44 AM Shengjing Zhu  wrote:

> So for podman, it can either keep this line and drop
> autopkgtest-pkg-go, or write Makefile in a way that autopkgtest-pkg-go
> can recognize.
>

I suppose the issue is around here:
https://salsa.debian.org/go-team/packages/dh-golang/-/blob/21002d72bfeab16a7f86696a585e04aa12803585/script/dh_golang_autopkgtest#L40-45

the issue is that the testsuite is literally invoking debian/rules (with
the options -pRfq), and the `$(info ...)` statement is producing additional
output that confuses the awk script from the debhelper.

I don't see a good solution to that other than
rewriting dh_golang_autopkgtest.

-rt
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

[Bug 1905443] Re: Error: default OCI runtime "runc" not found: invalid argument

[Reinhard Tartler]

** Summary changed:

- Podman/libpod crash
+ Error: default OCI runtime "runc" not found: invalid argument

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1905443

Title:
  Error: default OCI runtime "runc" not found: invalid argument

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/1905443/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

On Sun, Jan 24, 2021, 21:52 Dmitry Smirnov  wrote:

> On Monday, 25 January 2021 12:02:26 PM AEDT Reinhard Tartler wrote:
> >  - Podman 3 drops the legacy varlink interface. To the best of my
> > knowledge, there are no packages in debian/testing that would require
> > varlink (please correct me if I'm wrong here). Not having to support
> > varlink in Debian seems a support benefit, there is little to no love
> > for it upstream.
>
> Varlink is needed by Nomad/nomad-driver-podman. Unfortunately
> "nomad-driver-podman" is not ready for new HTTP API due to some problems
> with it (strangely enough Varlink interface is more mature at this point).
>

It seems that https://packages.qa.debian.org/n/nomad-driver-podman.html
has never made it to testing, which makes me wonder whether
it'll make it to bullseye.

On the tradeoff "podman 3.0 with docker-compose" support vs.
a "nomad driver for podman", I see more value for (more of)
our users for the newer podman. I base that on popcon numbers:

 - nomand: 35
 - nomad-driver-podman: 4
 - podman: 340



> I'm running some of my infrastructure on "nomad-driver-podman" and loss
> of Varlink is not acceptable to me until Podman and nomad-driver-podman
> resolve some of the issues. I might happen soon, let's hope, but we
> wouldn't
> know until it happen...


Ouch, that's indeed unfortunate.  Luckily it seems that issue
has been fixed in latest master of nomad-driver-podman, cf.

https://github.com/hashicorp/nomad-driver-podman/commit/b580f2d1874273bd61640525d54a02e3747c2df4
https://github.com/hashicorp/nomad-driver-podman/issues/72

Maybe you can integrate that change into the Debian package?

Best,
-rt

Re: Podman 3.0 and Debian bullseye

[Reinhard Tartler]

On Sun, Jan 24, 2021, 21:52 Dmitry Smirnov  wrote:

> On Monday, 25 January 2021 12:02:26 PM AEDT Reinhard Tartler wrote:
> >  - Podman 3 drops the legacy varlink interface. To the best of my
> > knowledge, there are no packages in debian/testing that would require
> > varlink (please correct me if I'm wrong here). Not having to support
> > varlink in Debian seems a support benefit, there is little to no love
> > for it upstream.
>
> Varlink is needed by Nomad/nomad-driver-podman. Unfortunately
> "nomad-driver-podman" is not ready for new HTTP API due to some problems
> with it (strangely enough Varlink interface is more mature at this point).
>

It seems that https://packages.qa.debian.org/n/nomad-driver-podman.html
has never made it to testing, which makes me wonder whether
it'll make it to bullseye.

On the tradeoff "podman 3.0 with docker-compose" support vs.
a "nomad driver for podman", I see more value for (more of)
our users for the newer podman. I base that on popcon numbers:

 - nomand: 35
 - nomad-driver-podman: 4
 - podman: 340



> I'm running some of my infrastructure on "nomad-driver-podman" and loss
> of Varlink is not acceptable to me until Podman and nomad-driver-podman
> resolve some of the issues. I might happen soon, let's hope, but we
> wouldn't
> know until it happen...


Ouch, that's indeed unfortunate.  Luckily it seems that issue
has been fixed in latest master of nomad-driver-podman, cf.

https://github.com/hashicorp/nomad-driver-podman/commit/b580f2d1874273bd61640525d54a02e3747c2df4
https://github.com/hashicorp/nomad-driver-podman/issues/72

Maybe you can integrate that change into the Debian package?

Best,
-rt

Podman 3.0 and Debian bullseye

[Reinhard Tartler]

Dear release-team,

I'm proposing to have podman 3.0 in debian/bullseye. As maintainer of the
package, I'm convinced this is a good step for Debian because:

 - podman 3.0 will be included in RHEL 8.4, which will be released in May
2021. I expect security support for podman in Debian to become
significantly simpler than let's say podman 2.2
 - users have expressed interest in podman 2.2 or late (cf. #978650 and
others)
 - podman 3.0 implements enough of docker's REST API to support
docker-compose (cf. https://www.redhat.com/sysadmin/podman-docker-compose)
 - the salsa team has expressed interest in exploring podman to facilitate
gitlab maintenance. I'd expect this update to make their lives
significantly easier if included in the next stable release

Current concerns/risk:

 - Podman 3.0.0~rc1 was only just released, but I expect it to be released
soon. After all, RHEL 8.4 is scheduled for May 2021
 - Podman 3 drops the legacy varlink interface. To the best of my
knowledge, there are no packages in debian/testing that would require
varlink (please correct me if I'm wrong here). Not having to support
varlink in Debian seems a support benefit, there is little to no love
for it upstream.
 - I've just uploaded podman 3.0 to debian/experimental, and is ready for
wider testing. Uploading to unstable requires a couple of additional
package updates in sid:
   - golang-github-containers-storage
   - golang-github-containers-image
   - golang-github-containers-common
   - golang-github-containers-buildah

I'm not really sure if this update required formal approval by the release
team, but I'd really appreciate your input in any case.

Best,
-rt

Podman 3.0 and Debian bullseye

[Reinhard Tartler]

Dear release-team,

I'm proposing to have podman 3.0 in debian/bullseye. As maintainer of the
package, I'm convinced this is a good step for Debian because:

 - podman 3.0 will be included in RHEL 8.4, which will be released in May
2021. I expect security support for podman in Debian to become
significantly simpler than let's say podman 2.2
 - users have expressed interest in podman 2.2 or late (cf. #978650 and
others)
 - podman 3.0 implements enough of docker's REST API to support
docker-compose (cf. https://www.redhat.com/sysadmin/podman-docker-compose)
 - the salsa team has expressed interest in exploring podman to facilitate
gitlab maintenance. I'd expect this update to make their lives
significantly easier if included in the next stable release

Current concerns/risk:

 - Podman 3.0.0~rc1 was only just released, but I expect it to be released
soon. After all, RHEL 8.4 is scheduled for May 2021
 - Podman 3 drops the legacy varlink interface. To the best of my
knowledge, there are no packages in debian/testing that would require
varlink (please correct me if I'm wrong here). Not having to support
varlink in Debian seems a support benefit, there is little to no love
for it upstream.
 - I've just uploaded podman 3.0 to debian/experimental, and is ready for
wider testing. Uploading to unstable requires a couple of additional
package updates in sid:
   - golang-github-containers-storage
   - golang-github-containers-image
   - golang-github-containers-common
   - golang-github-containers-buildah

I'm not really sure if this update required formal approval by the release
team, but I'd really appreciate your input in any case.

Best,
-rt

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Sun, Jan 24, 2021 at 9:12 AM Reinhard Tartler  wrote:

>
>
> On Sun, Jan 24, 2021 at 7:54 AM Shengjing Zhu  wrote:
>
>> On Sun, Jan 24, 2021 at 8:44 PM Reinhard Tartler 
>> wrote:
>> >
>> > Context is what version of podman to ship in Debian bullseye
>> [...]
>> >
>> > One could be to let's go straight for podman 3.0. Since Debian is going
>> to have a
>> > hard-freeze on 2021-03-12, that's kind of tight, but if doable if we
>> collaborate.
>> > There are a couple of dependencies that we need to update in
>> experimental and I would
>> > really appreciate help with it.
>>
>> If I read the freeze policy correctly, the new version should be in
>> time before soft-freeze(aka 2021-2-12)?
>> It seems upstream has released 3.0.0-rc1 already. So if you want 3.0
>> to be in bullseye, a good start might be uploading 3.0.0~rc1 to
>> experimental first, then talk to the release team?
>>
>
> That sounds like a good plan. It also looks like the required
> updates to containers/* isn't as bad as I thought, I'm updating buildah
> right now, and see how much is missing for 3.0.0~rc1. If it is not, I'll
> upload to experimental and start that conversation.
>
>
ok, I managed to build 3.0.0~rc1 and even managed to use docker-compose
with it.
Things look promising! I've pushed my local branch to salsa at
https://salsa.debian.org/debian/libpod/-/tree/experimental and plan to
upload
to experimental later today.

-- 
regards,
Reinhard

[pkg-go] Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Sun, Jan 24, 2021 at 9:12 AM Reinhard Tartler  wrote:

>
>
> On Sun, Jan 24, 2021 at 7:54 AM Shengjing Zhu  wrote:
>
>> On Sun, Jan 24, 2021 at 8:44 PM Reinhard Tartler 
>> wrote:
>> >
>> > Context is what version of podman to ship in Debian bullseye
>> [...]
>> >
>> > One could be to let's go straight for podman 3.0. Since Debian is going
>> to have a
>> > hard-freeze on 2021-03-12, that's kind of tight, but if doable if we
>> collaborate.
>> > There are a couple of dependencies that we need to update in
>> experimental and I would
>> > really appreciate help with it.
>>
>> If I read the freeze policy correctly, the new version should be in
>> time before soft-freeze(aka 2021-2-12)?
>> It seems upstream has released 3.0.0-rc1 already. So if you want 3.0
>> to be in bullseye, a good start might be uploading 3.0.0~rc1 to
>> experimental first, then talk to the release team?
>>
>
> That sounds like a good plan. It also looks like the required
> updates to containers/* isn't as bad as I thought, I'm updating buildah
> right now, and see how much is missing for 3.0.0~rc1. If it is not, I'll
> upload to experimental and start that conversation.
>
>
ok, I managed to build 3.0.0~rc1 and even managed to use docker-compose
with it.
Things look promising! I've pushed my local branch to salsa at
https://salsa.debian.org/debian/libpod/-/tree/experimental and plan to
upload
to experimental later today.

-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Sun, Jan 24, 2021 at 9:12 AM Reinhard Tartler  wrote:

>
>
> On Sun, Jan 24, 2021 at 7:54 AM Shengjing Zhu  wrote:
>
>> On Sun, Jan 24, 2021 at 8:44 PM Reinhard Tartler 
>> wrote:
>> >
>> > Context is what version of podman to ship in Debian bullseye
>> [...]
>> >
>> > One could be to let's go straight for podman 3.0. Since Debian is going
>> to have a
>> > hard-freeze on 2021-03-12, that's kind of tight, but if doable if we
>> collaborate.
>> > There are a couple of dependencies that we need to update in
>> experimental and I would
>> > really appreciate help with it.
>>
>> If I read the freeze policy correctly, the new version should be in
>> time before soft-freeze(aka 2021-2-12)?
>> It seems upstream has released 3.0.0-rc1 already. So if you want 3.0
>> to be in bullseye, a good start might be uploading 3.0.0~rc1 to
>> experimental first, then talk to the release team?
>>
>
> That sounds like a good plan. It also looks like the required
> updates to containers/* isn't as bad as I thought, I'm updating buildah
> right now, and see how much is missing for 3.0.0~rc1. If it is not, I'll
> upload to experimental and start that conversation.
>
>
ok, I managed to build 3.0.0~rc1 and even managed to use docker-compose
with it.
Things look promising! I've pushed my local branch to salsa at
https://salsa.debian.org/debian/libpod/-/tree/experimental and plan to
upload
to experimental later today.

-- 
regards,
Reinhard

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Sun, Jan 24, 2021 at 1:44 PM Antoine Beaupré  wrote:

>
> Could we still upload 2.1 or 2.2 to unstable in the meantime to have at
> least an update on that front that's solid?
>
>
Debian testing (bullseye)/unstable currently ship with version 2.1.1.
cf. https://packages.qa.debian.org/libp/libpod.html

Best,
-rt

[pkg-go] Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Sun, Jan 24, 2021 at 1:44 PM Antoine Beaupré  wrote:

>
> Could we still upload 2.1 or 2.2 to unstable in the meantime to have at
> least an update on that front that's solid?
>
>
Debian testing (bullseye)/unstable currently ship with version 2.1.1.
cf. https://packages.qa.debian.org/libp/libpod.html

Best,
-rt
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Sun, Jan 24, 2021 at 1:44 PM Antoine Beaupré  wrote:

>
> Could we still upload 2.1 or 2.2 to unstable in the meantime to have at
> least an update on that front that's solid?
>
>
Debian testing (bullseye)/unstable currently ship with version 2.1.1.
cf. https://packages.qa.debian.org/libp/libpod.html

Best,
-rt

Re: [pkg-go] podman (2.1.1+dfsg1-4) - search not working on new install

[Reinhard Tartler]

Hi Imran, thanks for reaching out


On 1/24/21 12:04 PM, Imran Ibrahim wrote:
> I needed to manually add:
> 
> |[registries.search]|
> |registries = ['docker.io ']|
> 
> to etc/containers/registries.conf
> 
> As container search was not working out of the box. Would it be possible to 
> have this as part of the package, because if you are doing a new install you 
> won't be able to search for available containers. It may also put off new 
> users

This issue is being discussed at https://bugs.debian.org/978650


Best,
-rt

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Sun, Jan 24, 2021 at 7:54 AM Shengjing Zhu  wrote:

> On Sun, Jan 24, 2021 at 8:44 PM Reinhard Tartler 
> wrote:
> >
> > Context is what version of podman to ship in Debian bullseye
> [...]
> >
> > One could be to let's go straight for podman 3.0. Since Debian is going
> to have a
> > hard-freeze on 2021-03-12, that's kind of tight, but if doable if we
> collaborate.
> > There are a couple of dependencies that we need to update in
> experimental and I would
> > really appreciate help with it.
>
> If I read the freeze policy correctly, the new version should be in
> time before soft-freeze(aka 2021-2-12)?
> It seems upstream has released 3.0.0-rc1 already. So if you want 3.0
> to be in bullseye, a good start might be uploading 3.0.0~rc1 to
> experimental first, then talk to the release team?
>

That sounds like a good plan. It also looks like the required
updates to containers/* isn't as bad as I thought, I'm updating buildah
right now, and see how much is missing for 3.0.0~rc1. If it is not, I'll
upload to experimental and start that conversation.

best,
-rt

-- 
regards,
Reinhard

[pkg-go] Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Sun, Jan 24, 2021 at 7:54 AM Shengjing Zhu  wrote:

> On Sun, Jan 24, 2021 at 8:44 PM Reinhard Tartler 
> wrote:
> >
> > Context is what version of podman to ship in Debian bullseye
> [...]
> >
> > One could be to let's go straight for podman 3.0. Since Debian is going
> to have a
> > hard-freeze on 2021-03-12, that's kind of tight, but if doable if we
> collaborate.
> > There are a couple of dependencies that we need to update in
> experimental and I would
> > really appreciate help with it.
>
> If I read the freeze policy correctly, the new version should be in
> time before soft-freeze(aka 2021-2-12)?
> It seems upstream has released 3.0.0-rc1 already. So if you want 3.0
> to be in bullseye, a good start might be uploading 3.0.0~rc1 to
> experimental first, then talk to the release team?
>

That sounds like a good plan. It also looks like the required
updates to containers/* isn't as bad as I thought, I'm updating buildah
right now, and see how much is missing for 3.0.0~rc1. If it is not, I'll
upload to experimental and start that conversation.

best,
-rt

-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Sun, Jan 24, 2021 at 7:54 AM Shengjing Zhu  wrote:

> On Sun, Jan 24, 2021 at 8:44 PM Reinhard Tartler 
> wrote:
> >
> > Context is what version of podman to ship in Debian bullseye
> [...]
> >
> > One could be to let's go straight for podman 3.0. Since Debian is going
> to have a
> > hard-freeze on 2021-03-12, that's kind of tight, but if doable if we
> collaborate.
> > There are a couple of dependencies that we need to update in
> experimental and I would
> > really appreciate help with it.
>
> If I read the freeze policy correctly, the new version should be in
> time before soft-freeze(aka 2021-2-12)?
> It seems upstream has released 3.0.0-rc1 already. So if you want 3.0
> to be in bullseye, a good start might be uploading 3.0.0~rc1 to
> experimental first, then talk to the release team?
>

That sounds like a good plan. It also looks like the required
updates to containers/* isn't as bad as I thought, I'm updating buildah
right now, and see how much is missing for 3.0.0~rc1. If it is not, I'll
upload to experimental and start that conversation.

best,
-rt

-- 
regards,
Reinhard

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

Context is what version of podman to ship in Debian bullseye

On Thu, Jan 14, 2021 at 11:29 AM Antonio Terceiro 
wrote:

> On Sat, Jan 09, 2021 at 12:58:05PM +0200, Faidon Liambotis wrote:
> > Hi there,
> >
> > On Thu, Dec 31, 2020 at 01:39:52PM -0500, Reinhard Tartler wrote:
> > > As I thought. Experimental has version 2.2, unstable/testing currently
> 2.1
> > > What you are asking for is one (maybe the?) major new feature
> introduced in
> > > 2.2.0.
> >
> > That's helpful! I was wondering what your plans were with regards to
> > bringing 2.2 to unstable. With my limited testing, things look to work
> > OK with it. It'd be great to release bullseye with a version supporting
> > short names!
>
> yes please :)
>
> > Thank you for your efforts in maintaining the podman/libpod/etc. stack.
>
> +1
>

You're welcome.

In the community meeting on Dec 1 (cf.
https://podman.io/community/meeting/notes/2020-12-01/#brent-baude)
Brent Baude (with some clarifications from Dan Walsh, IIRC) stated that
version 2.2
won't make it into any RHEL release. RHEL 8.3 will go with podman 2.1,
whereas RHEL 8.4
will go straight with podman 3.0. podman 2.2 will only be in Fedora, and
given the
development velocity and support burden for the podman team, I was
hesitating with
committing on podman 2.2 for bullseye. That's not a hard no from my side,
I'm happy
to hear other opinions.

One could be to let's go straight for podman 3.0. Since Debian is going to
have a
hard-freeze on 2021-03-12, that's kind of tight, but if doable if we
collaborate.
There are a couple of dependencies that we need to update in experimental
and I would
really appreciate help with it.

So folks, what do you think?


-- 
regards,
Reinhard

[pkg-go] Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

Context is what version of podman to ship in Debian bullseye

On Thu, Jan 14, 2021 at 11:29 AM Antonio Terceiro 
wrote:

> On Sat, Jan 09, 2021 at 12:58:05PM +0200, Faidon Liambotis wrote:
> > Hi there,
> >
> > On Thu, Dec 31, 2020 at 01:39:52PM -0500, Reinhard Tartler wrote:
> > > As I thought. Experimental has version 2.2, unstable/testing currently
> 2.1
> > > What you are asking for is one (maybe the?) major new feature
> introduced in
> > > 2.2.0.
> >
> > That's helpful! I was wondering what your plans were with regards to
> > bringing 2.2 to unstable. With my limited testing, things look to work
> > OK with it. It'd be great to release bullseye with a version supporting
> > short names!
>
> yes please :)
>
> > Thank you for your efforts in maintaining the podman/libpod/etc. stack.
>
> +1
>

You're welcome.

In the community meeting on Dec 1 (cf.
https://podman.io/community/meeting/notes/2020-12-01/#brent-baude)
Brent Baude (with some clarifications from Dan Walsh, IIRC) stated that
version 2.2
won't make it into any RHEL release. RHEL 8.3 will go with podman 2.1,
whereas RHEL 8.4
will go straight with podman 3.0. podman 2.2 will only be in Fedora, and
given the
development velocity and support burden for the podman team, I was
hesitating with
committing on podman 2.2 for bullseye. That's not a hard no from my side,
I'm happy
to hear other opinions.

One could be to let's go straight for podman 3.0. Since Debian is going to
have a
hard-freeze on 2021-03-12, that's kind of tight, but if doable if we
collaborate.
There are a couple of dependencies that we need to update in experimental
and I would
really appreciate help with it.

So folks, what do you think?


-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

Context is what version of podman to ship in Debian bullseye

On Thu, Jan 14, 2021 at 11:29 AM Antonio Terceiro 
wrote:

> On Sat, Jan 09, 2021 at 12:58:05PM +0200, Faidon Liambotis wrote:
> > Hi there,
> >
> > On Thu, Dec 31, 2020 at 01:39:52PM -0500, Reinhard Tartler wrote:
> > > As I thought. Experimental has version 2.2, unstable/testing currently
> 2.1
> > > What you are asking for is one (maybe the?) major new feature
> introduced in
> > > 2.2.0.
> >
> > That's helpful! I was wondering what your plans were with regards to
> > bringing 2.2 to unstable. With my limited testing, things look to work
> > OK with it. It'd be great to release bullseye with a version supporting
> > short names!
>
> yes please :)
>
> > Thank you for your efforts in maintaining the podman/libpod/etc. stack.
>
> +1
>

You're welcome.

In the community meeting on Dec 1 (cf.
https://podman.io/community/meeting/notes/2020-12-01/#brent-baude)
Brent Baude (with some clarifications from Dan Walsh, IIRC) stated that
version 2.2
won't make it into any RHEL release. RHEL 8.3 will go with podman 2.1,
whereas RHEL 8.4
will go straight with podman 3.0. podman 2.2 will only be in Fedora, and
given the
development velocity and support burden for the podman team, I was
hesitating with
committing on podman 2.2 for bullseye. That's not a hard no from my side,
I'm happy
to hear other opinions.

One could be to let's go straight for podman 3.0. Since Debian is going to
have a
hard-freeze on 2021-03-12, that's kind of tight, but if doable if we
collaborate.
There are a couple of dependencies that we need to update in experimental
and I would
really appreciate help with it.

So folks, what do you think?


-- 
regards,
Reinhard

[Bug 1905443] Re: Podman/libpod crash

[Reinhard Tartler]

This is marked as fixed in Debian, and I'm working on getting the fixed
package into hirsute. It's been a struggle so far with getting the whole
golang stack through the proposed migration.

The workaround for groovy (20.10) is to ensure that both 'runc' as well
as 'crun' packages are present.

** Bug watch added: Debian Bug tracker #971253
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971253

** Also affects: libpod (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971253
   Importance: Unknown
   Status: Unknown

** Changed in: libpod (Ubuntu)
   Status: New => Triaged

** Changed in: libpod (Ubuntu)
   Importance: Undecided => Medium

** Changed in: libpod (Ubuntu)
 Assignee: (unassigned) => Reinhard Tartler (siretart)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1905443

Title:
  Podman/libpod crash

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/1905443/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1851960] Re: [needs-packaging] missing podman

[Reinhard Tartler]

package available in ubuntu 20.10 and later

** Changed in: libpod (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1851960

Title:
  [needs-packaging] missing podman

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/1851960/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: helping golang-golang-x-sys to migrate

[Reinhard Tartler]

Another week has passed, and the original issues seem to have been resolved
by retrying. Thanks for everyone involved in that.

In the mean time, a new test regression occurred at
https://autopkgtest.ubuntu.com/packages/victoriametrics/hirsute/amd64, log
can be seen at
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/v/victoriametrics/20210107_084114_85c06@/log.gz

2021-01-07T08:40:46.015Zinfo
VictoriaMetrics/lib/mergeset/table.go:203   table
"/tmp/autopkgtest.a1SU4e/autopkgtest_tmp/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/TestStorageRegisterMetricNamesConcurrent/indexdb/1657E67DA0CA2C97"
has been opened in 0.002 seconds; partsCount: 0; blocksCount: 0,
itemsCount: 0; sizeBytes: 0
storage_test.go:699: unexpected error: error in SearchMetricNames:
cannot search for tsids, since more than 2 concurrent searches are
performed during -1610008847.000 secs; add more CPUs or reduce query
load
--- FAIL: TestStorageRegisterMetricNamesConcurrent (0.49s)


I suppose the testsuite is running on a machine with only 2 CPUs and
expects more ressources? I've retriggered the test but I'm concerned this
excercise might be a waste of resources. Does anyone share this concern
and/or has any thoughts on how to avoid this?

Best,
-rt

On Thu, Jan 7, 2021 at 11:31 AM Reinhard Tartler  wrote:

> Cool, thanks.
>
> IT seems we have an additional failure now at
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/v/victoriametrics/20210107_084114_85c06@/log.gz
> -- the relevant part might be this one:
>
> 2021-01-07T08:40:46.015Z  info
> VictoriaMetrics/lib/mergeset/table.go:203   table 
> "/tmp/autopkgtest.a1SU4e/autopkgtest_tmp/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/TestStorageRegisterMetricNamesConcurrent/indexdb/1657E67DA0CA2C97"
>  has been opened in 0.002 seconds; partsCount: 0; blocksCount: 0, itemsCount: 
> 0; sizeBytes: 0
> storage_test.go:699: unexpected error: error in SearchMetricNames: cannot 
> search for tsids, since more than 2 concurrent searches are performed during 
> -1610008847.000 secs; add more CPUs or reduce query load
> --- FAIL: TestStorageRegisterMetricNamesConcurrent (0.49s)
>
>
> Maybe the test machine doesn't have enough CPUs for these tests? Can we
> retry the failing tests on larger machines?
>
> -rt
>
> On Thu, Jan 7, 2021 at 3:32 AM Lukasz Zemczak <
> lukasz.zemc...@canonical.com> wrote:
>
>> Hey Reinhard,
>>
>> I see that at least golang-github-canonical-go-dqlite seems like a
>> good candidate to hint with a force-reset-test - I'll do that later
>> today (as it only passed *once* in its whole testing history, so it's
>> not a reliable testsuite).
>> I have retried one of the failures there and will try seeing if the
>> other failures make any sense.
>>
>> Cheers,
>>
>> On Sun, 3 Jan 2021 at 22:11, Reinhard Tartler  wrote:
>> >
>> > Hi folks,
>> >
>> > I couple of golang packages I care deeply about are stuck in
>> hirsute-proposed due to autopkgtest failures that I had a hard time
>> understanding. I've come to the conclusion that the problem must be related
>> to
>> https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#golang-golang-x-sys
>> >
>> > It seems that there are regressions in the following packages:
>> >
>> > - golang-github-canonical-go-dqlite
>> > - golang-github-lucas-clemente-quic-go
>> > - golang-google-grpc
>> >
>> > I'm not familiar with those testsuites, but on the first look, there
>> might be timing issues.
>> >
>> > I'd appreciate some thoughts/comments on helping golang-golang-x-sys
>> migrate to hirsute.
>> >
>> > Thanks!
>> >
>> > --
>> > regards,
>> > Reinhard
>> > --
>> > ubuntu-devel mailing list
>> > ubuntu-devel@lists.ubuntu.com
>> > Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>>
>>
>>
>> --
>> Łukasz 'sil2100' Zemczak
>>  Foundations Team
>>  lukasz.zemc...@canonical.com
>>  www.canonical.com
>>
>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: helping golang-golang-x-sys to migrate

[Reinhard Tartler]

Cool, thanks.

IT seems we have an additional failure now at
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/v/victoriametrics/20210107_084114_85c06@/log.gz
-- the relevant part might be this one:

2021-01-07T08:40:46.015Zinfo
VictoriaMetrics/lib/mergeset/table.go:203   table
"/tmp/autopkgtest.a1SU4e/autopkgtest_tmp/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/TestStorageRegisterMetricNamesConcurrent/indexdb/1657E67DA0CA2C97"
has been opened in 0.002 seconds; partsCount: 0; blocksCount: 0,
itemsCount: 0; sizeBytes: 0
storage_test.go:699: unexpected error: error in SearchMetricNames:
cannot search for tsids, since more than 2 concurrent searches are
performed during -1610008847.000 secs; add more CPUs or reduce query
load
--- FAIL: TestStorageRegisterMetricNamesConcurrent (0.49s)


Maybe the test machine doesn't have enough CPUs for these tests? Can we
retry the failing tests on larger machines?

-rt

On Thu, Jan 7, 2021 at 3:32 AM Lukasz Zemczak 
wrote:

> Hey Reinhard,
>
> I see that at least golang-github-canonical-go-dqlite seems like a
> good candidate to hint with a force-reset-test - I'll do that later
> today (as it only passed *once* in its whole testing history, so it's
> not a reliable testsuite).
> I have retried one of the failures there and will try seeing if the
> other failures make any sense.
>
> Cheers,
>
> On Sun, 3 Jan 2021 at 22:11, Reinhard Tartler  wrote:
> >
> > Hi folks,
> >
> > I couple of golang packages I care deeply about are stuck in
> hirsute-proposed due to autopkgtest failures that I had a hard time
> understanding. I've come to the conclusion that the problem must be related
> to
> https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#golang-golang-x-sys
> >
> > It seems that there are regressions in the following packages:
> >
> > - golang-github-canonical-go-dqlite
> > - golang-github-lucas-clemente-quic-go
> > - golang-google-grpc
> >
> > I'm not familiar with those testsuites, but on the first look, there
> might be timing issues.
> >
> > I'd appreciate some thoughts/comments on helping golang-golang-x-sys
> migrate to hirsute.
> >
> > Thanks!
> >
> > --
> > regards,
> > Reinhard
> > --
> > ubuntu-devel mailing list
> > ubuntu-devel@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
>
>
> --
> Łukasz 'sil2100' Zemczak
>  Foundations Team
>  lukasz.zemc...@canonical.com
>  www.canonical.com
>


-- 
regards,
Reinhard
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Bug#979313: marked as pending in libpod

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #979313 in libpod reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libpod/-/commit/2b95096f49f379cc8d5ce8bc432c82195c8364e5


Ignore containers.conf sysctl when namespaces set to host

Closes: #979313


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/979313

Re: Please Review / Upload golang-github-opencontainers-selinux

[Reinhard Tartler]

On Wed, Jan 6, 2021 at 8:14 PM El boulangero  wrote:

> Hello Go Team,
>
> anyone up for a quick review/upload? This is it:
>
>
> https://salsa.debian.org/go-team/packages/golang-github-opencontainers-selinux
>
> All pushed to salsa, the only thing missing is the debian tag.
>
> This is a minor update. Ratt has been running last night and is happy with
> it.
>

awesome, thanks, uploaded.


-- 
regards,
Reinhard

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

Yes, exactly.

On Mon, Jan 4, 2021 at 3:47 PM Antonio Terceiro  wrote:

> On Thu, Dec 31, 2020 at 11:26:49AM -0300, Antonio Terceiro wrote:
> > Control: done -1 2.2.1+dfsg1-1
> >
> > On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> > > Can you please try the podman version in experimental? I believe what
> you
> > > describe (the shortnames) should work with version 2.2 just fine
> thanks to
> > > the shortnames.conf file.
> >
> > Ah yes the version in exprimental does fix this. Thanks!
>
> Actually, this only solves the issue for the few official images that
> are listed by default in
> /etc/containers/registries.conf.d/shortnames.conf
>
> Other image names still won't work. But I guess unqualified names are an
> anti-pattern in general?
>


-- 
regards,
Reinhard

[pkg-go] Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

Yes, exactly.

On Mon, Jan 4, 2021 at 3:47 PM Antonio Terceiro  wrote:

> On Thu, Dec 31, 2020 at 11:26:49AM -0300, Antonio Terceiro wrote:
> > Control: done -1 2.2.1+dfsg1-1
> >
> > On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> > > Can you please try the podman version in experimental? I believe what
> you
> > > describe (the shortnames) should work with version 2.2 just fine
> thanks to
> > > the shortnames.conf file.
> >
> > Ah yes the version in exprimental does fix this. Thanks!
>
> Actually, this only solves the issue for the few official images that
> are listed by default in
> /etc/containers/registries.conf.d/shortnames.conf
>
> Other image names still won't work. But I guess unqualified names are an
> anti-pattern in general?
>


-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

helping golang-golang-x-sys to migrate

[Reinhard Tartler]

Hi folks,

I couple of golang packages I care deeply about are stuck in
hirsute-proposed due to autopkgtest failures that I had a hard time
understanding. I've come to the conclusion that the problem must be related
to
https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#golang-golang-x-sys

It seems that there are regressions in the following packages:

- golang-github-canonical-go-dqlite
- golang-github-lucas-clemente-quic-go
- golang-google-grpc

I'm not familiar with those testsuites, but on the first look, there might
be timing issues.

I'd appreciate some thoughts/comments on helping golang-golang-x-sys
migrate to hirsute.

Thanks!

-- 
regards,
Reinhard
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Thu, Dec 31, 2020 at 9:26 AM Antonio Terceiro 
wrote:

> Control: done -1 2.2.1+dfsg1-1
>
> On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> > Can you please try the podman version in experimental? I believe what you
> > describe (the shortnames) should work with version 2.2 just fine thanks
> to
> > the shortnames.conf file.
>
> Ah yes the version in exprimental does fix this. Thanks!
>
> > Also, what version of podman did you use in Fedora for this test?
>
> [terceiro@fedora ~]$ podman --version
> podman version 2.2.1
>

As I thought. Experimental has version 2.2, unstable/testing currently 2.1
What you are asking for is one (maybe the?) major new feature introduced in
2.2.0.


-- 
regards,
Reinhard

[pkg-go] Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Thu, Dec 31, 2020 at 9:26 AM Antonio Terceiro 
wrote:

> Control: done -1 2.2.1+dfsg1-1
>
> On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> > Can you please try the podman version in experimental? I believe what you
> > describe (the shortnames) should work with version 2.2 just fine thanks
> to
> > the shortnames.conf file.
>
> Ah yes the version in exprimental does fix this. Thanks!
>
> > Also, what version of podman did you use in Fedora for this test?
>
> [terceiro@fedora ~]$ podman --version
> podman version 2.2.1
>

As I thought. Experimental has version 2.2, unstable/testing currently 2.1
What you are asking for is one (maybe the?) major new feature introduced in
2.2.0.


-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#976232: ITP: ustreamer -- Lightweight and fast MJPG-HTTP streamer

[Reinhard Tartler]

Hi Sam,

On Tue, Dec 1, 2020 at 5:06 PM Sam Reed  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Sam Reed 
>
> * Package name: ustreamer
>   Version : 2.2
>   Upstream Author : Maxim Devaev 
> * URL : https://pikvm.org/
> * License : GPL-3
>   Programming Lang: C
>   Description : Lightweight and fast MJPG-HTTP streamer
>
> µStreamer is a lightweight and very quick server to stream MJPG
> videofrom any V4L2 device to the network. All new browsers have
> native support of this video format, as well as most video
> players such as mplayer, VLC etc. µStreamer is a part of the
> Pi-KVM project designed to stream VGA and HDMI screencast
> hardware data with the highest resolution and FPS possible.
>
> ustreamer is used as part of Pi-KVM (a Raspberry Pi based IP
> KVM), to stream video to a web browser.
>
> It is intended to get this packaged so it will eventually be
> available in Raspberry Pi OS (and other Debian derivatives),
> allowing Pi-KVM to be used on those OS rather than using Arch.
>
> I currently use it as part of the Pi-KVM project, and
> hopefully when it is packaged, also use it as part of
> OctoPrint and the OctoPi OS (version of Raspberry Pi OS).
>
> MJPG-Streamer is alternative software providing the same
> function, however it is currently not packaged for Debian
> either, though it is available in a snap.
>
> I'm happy to work on packaging/maintaining it in future,
> and I believe the upstream Author (Maxim) may be interested
> too, but is currently busy with other work, hence me packaging
> it.
>

Are you still working on the package? I'm happy to review and upload the
package for you, if that was helpful to you.


-- 
regards,
Reinhard

Bug#976232: ITP: ustreamer -- Lightweight and fast MJPG-HTTP streamer

[Reinhard Tartler]

Hi Sam,

On Tue, Dec 1, 2020 at 5:06 PM Sam Reed  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Sam Reed 
>
> * Package name: ustreamer
>   Version : 2.2
>   Upstream Author : Maxim Devaev 
> * URL : https://pikvm.org/
> * License : GPL-3
>   Programming Lang: C
>   Description : Lightweight and fast MJPG-HTTP streamer
>
> µStreamer is a lightweight and very quick server to stream MJPG
> videofrom any V4L2 device to the network. All new browsers have
> native support of this video format, as well as most video
> players such as mplayer, VLC etc. µStreamer is a part of the
> Pi-KVM project designed to stream VGA and HDMI screencast
> hardware data with the highest resolution and FPS possible.
>
> ustreamer is used as part of Pi-KVM (a Raspberry Pi based IP
> KVM), to stream video to a web browser.
>
> It is intended to get this packaged so it will eventually be
> available in Raspberry Pi OS (and other Debian derivatives),
> allowing Pi-KVM to be used on those OS rather than using Arch.
>
> I currently use it as part of the Pi-KVM project, and
> hopefully when it is packaged, also use it as part of
> OctoPrint and the OctoPi OS (version of Raspberry Pi OS).
>
> MJPG-Streamer is alternative software providing the same
> function, however it is currently not packaged for Debian
> either, though it is available in a snap.
>
> I'm happy to work on packaging/maintaining it in future,
> and I believe the upstream Author (Maxim) may be interested
> too, but is currently busy with other work, hence me packaging
> it.
>

Are you still working on the package? I'm happy to review and upload the
package for you, if that was helpful to you.


-- 
regards,
Reinhard

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

Can you please try the podman version in experimental? I believe what you
describe (the shortnames) should work with version 2.2 just fine thanks to
the shortnames.conf file.

Also, what version of podman did you use in Fedora for this test?

-rt

On Tue, Dec 29, 2020 at 12:45 PM Antonio Terceiro 
wrote:

> Package: podman
> Version: 2.1.1+dfsg1-3
> Severity: wishlist
>
> When running stuff that was originally written for docker, image names
> will usually be provided in their short form, i.e. debian:10,
> fedora:rawhide. In the current state of the Debian packaging, those will
> fail like this:
>
> $ cat Containerfile
> FROM debian
> $ podman build -t foobar .
> STEP 1: FROM debian
> Error: error creating build container: (image name "debian" is a short
> name and no search registries are defined in
> /etc/containers/registries.conf): while pulling "debian" as
> "localhost/debian": Error initializing source
> docker://localhost/debian:latest: error pinging docker registry localhost:
> Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection
> refused
>
> On Fedora, on the other hand, this just works, because their
> registries.conf provides by default a list of as few registries
> registries where to look up unqualified image names:
>
> [terceiro@fedora tmp]$ grep -v '^#' /etc/containers/registries.conf
> unqualified-search-registries = ['registry.fedoraproject.org', '
> registry.access.redhat.com', 'registry.centos.org', 'docker.io']
>
> I don't think we want to include the fedora/redhat/centos registries,
> but we should include at least the docker.io registry, which is the _de
> facto_ standard in the container world at the moment. So can we please
> provide something like the line below by default in
> /etc/containers/registries.conf?
>
> unqualified-search-registries = ['docker.io']
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
> 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
> LANGUAGE=pt_BR:pt:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages podman depends on:
> ii  conmon   2.0.20-1
> ii  containernetworking-plugins  0.8.7-1
> ii  crun 0.15.1+dfsg-1
> ii  golang-github-containers-common  0.26.3+ds1-2
> ii  init-system-helpers  1.60
> ii  libc62.31-6
> ii  libdevmapper1.02.1   2:1.02.173-1
> ii  libgpgme11   1.14.0-1+b2
> ii  libseccomp2  2.5.1-1
> ii  runc 1.0.0~rc92+dfsg1-5
>
> Versions of packages podman recommends:
> ii  buildah 1.16.6+dfsg1-2
> ii  catatonit   0.1.5-2
> ii  fuse-overlayfs  1.2.0-1
> ii  slirp4netns 1.0.1-1
> ii  tini0.19.0-1
> ii  uidmap  1:4.8.1-1
>
> Versions of packages podman suggests:
> pn  containers-storage  
>
> -- no debconf information
>


-- 
regards,
Reinhard

[pkg-go] Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

Can you please try the podman version in experimental? I believe what you
describe (the shortnames) should work with version 2.2 just fine thanks to
the shortnames.conf file.

Also, what version of podman did you use in Fedora for this test?

-rt

On Tue, Dec 29, 2020 at 12:45 PM Antonio Terceiro 
wrote:

> Package: podman
> Version: 2.1.1+dfsg1-3
> Severity: wishlist
>
> When running stuff that was originally written for docker, image names
> will usually be provided in their short form, i.e. debian:10,
> fedora:rawhide. In the current state of the Debian packaging, those will
> fail like this:
>
> $ cat Containerfile
> FROM debian
> $ podman build -t foobar .
> STEP 1: FROM debian
> Error: error creating build container: (image name "debian" is a short
> name and no search registries are defined in
> /etc/containers/registries.conf): while pulling "debian" as
> "localhost/debian": Error initializing source
> docker://localhost/debian:latest: error pinging docker registry localhost:
> Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection
> refused
>
> On Fedora, on the other hand, this just works, because their
> registries.conf provides by default a list of as few registries
> registries where to look up unqualified image names:
>
> [terceiro@fedora tmp]$ grep -v '^#' /etc/containers/registries.conf
> unqualified-search-registries = ['registry.fedoraproject.org', '
> registry.access.redhat.com', 'registry.centos.org', 'docker.io']
>
> I don't think we want to include the fedora/redhat/centos registries,
> but we should include at least the docker.io registry, which is the _de
> facto_ standard in the container world at the moment. So can we please
> provide something like the line below by default in
> /etc/containers/registries.conf?
>
> unqualified-search-registries = ['docker.io']
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
> 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
> LANGUAGE=pt_BR:pt:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages podman depends on:
> ii  conmon   2.0.20-1
> ii  containernetworking-plugins  0.8.7-1
> ii  crun 0.15.1+dfsg-1
> ii  golang-github-containers-common  0.26.3+ds1-2
> ii  init-system-helpers  1.60
> ii  libc62.31-6
> ii  libdevmapper1.02.1   2:1.02.173-1
> ii  libgpgme11   1.14.0-1+b2
> ii  libseccomp2  2.5.1-1
> ii  runc 1.0.0~rc92+dfsg1-5
>
> Versions of packages podman recommends:
> ii  buildah 1.16.6+dfsg1-2
> ii  catatonit   0.1.5-2
> ii  fuse-overlayfs  1.2.0-1
> ii  slirp4netns 1.0.1-1
> ii  tini0.19.0-1
> ii  uidmap  1:4.8.1-1
>
> Versions of packages podman suggests:
> pn  containers-storage  
>
> -- no debconf information
>


-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#978524: buildah: build-using-dockerfile not sufficient privileges

[Reinhard Tartler]

Control: tags -1 upstream moreinfo

On Mon, Dec 28, 2020 at 5:27 AM mailing.lists.us 
wrote:

> Dear Maintainer,
>
> while I was trying to build a container from scratch (debian rootfs,
> ubuntu root tarball) I saw that buildah
> doesn't have enough privileges to add/copy over the files (I assume, as I
> can't really read the error correctly)
> [...]
> building with root works fine, but is not desireable. Tested it also with
> the newer version in experimental, still same issue.
> to verify I tested this on other distributions (ubuntu for example which
> has the same version) but works as intended.
>
>
This doesn't sound like a packaging issue but rather a design or usage
issue.
In any case, the error message is indeed hard to read.

Please report this issue upstream at
https://github.com/containers/buildah/issues
so that an upstream developer can have a look at it and form an opinion.

Please let me know the issue number and I'll ink this debian bug with the
upstream one.

-- 
regards,
Reinhard

Bug#977928: obs-studio: virtual camera not working, modinfo not in path

[Reinhard Tartler]

Hi Gregor,

I've applied your patch to our git branch, I think it looks good.


On Tue, Dec 22, 2020 at 7:27 PM gregor herrmann  wrote:

>
> The whole virtualcam support currently is a bit fragile (trying to
> load kernel modules, always using the first of potentially several
> /dev/video* devices … I wonder if a README would make sense, and I'd
> be happy to provide a draft.
>

I think that'd make a lot of sense, I'm not that familiar with this package.
I'm happy to look over your draft and apply it with or without
modifications :-)

Happy Holidays,
-rt

Bug#977928: obs-studio: virtual camera not working, modinfo not in path

[Reinhard Tartler]

Hi Gregor,

I've applied your patch to our git branch, I think it looks good.


On Tue, Dec 22, 2020 at 7:27 PM gregor herrmann  wrote:

>
> The whole virtualcam support currently is a bit fragile (trying to
> load kernel modules, always using the first of potentially several
> /dev/video* devices … I wonder if a README would make sense, and I'd
> be happy to provide a draft.
>

I think that'd make a lot of sense, I'm not that familiar with this package.
I'm happy to look over your draft and apply it with or without
modifications :-)

Happy Holidays,
-rt

Bug#976924: Test timeouts on ppc64el not RC

[Reinhard Tartler]

Control: severity -1 normal

Looking at the logs, it really looks like timeouts in the testsuite. We could 
disable the tests on problematic architectures, patches welcome. As a 
workaround, I'd suggest building the package with export 
DEB_BUILD_OPTIONS=notest. With this, I'm downgrading the severity to normal to 
avoid having dozens of packages removed from testing.

-rt

Bug#976924: Test timeouts on ppc64el not RC

[Reinhard Tartler]

Control: severity -1 normal

Looking at the logs, it really looks like timeouts in the testsuite. We could 
disable the tests on problematic architectures, patches welcome. As a 
workaround, I'd suggest building the package with export 
DEB_BUILD_OPTIONS=notest. With this, I'm downgrading the severity to normal to 
avoid having dozens of packages removed from testing.

-rt

[pkg-go] Bug#976924: Test timeouts on ppc64el not RC

[Reinhard Tartler]

Control: severity -1 normal

Looking at the logs, it really looks like timeouts in the testsuite. We could 
disable the tests on problematic architectures, patches welcome. As a 
workaround, I'd suggest building the package with export 
DEB_BUILD_OPTIONS=notest. With this, I'm downgrading the severity to normal to 
avoid having dozens of packages removed from testing.

-rt

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#976509: marked as pending in golang-github-shirou-gopsutil

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #976509 in golang-github-shirou-gopsutil reported by you has been fixed in 
the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-shirou-gopsutil/-/commit/5085339ce0de2687d9729e011f049e222598e580


Disable cpuinfo related test, Closes: #976509)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/976509

Bug#977502: marked as pending in libpod

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #977502 in libpod reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libpod/-/commit/bafa6d42d5dfc209c6e864494fe0fc8d16d0494d


Rely on upstream's build scripts to install manpages (Closes: #977502)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/977502

Bug#977502: marked as pending in libpod

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #977502 in libpod reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libpod/-/commit/7377dad97a3c3352ad41c9d45c8faedacfa8ef20


Remove conflicting manpage container-mounts(5), Closes: #977502


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/977502

Bug#977717: podman: Images can't be run with non-root USER after upgrade to 2.1.1 due to wrong permissions of / inside the container

[Reinhard Tartler]

Control: fixed -1 2.2.0+dfsg1-1
Control: forwarded -1 https://github.com/containers/podman/issues/7747

Thanks for the clarification. With this, I was able to reproduce the issue
in unstable, and confirm its absence with the podma 2.2 package in
experimental. I've found a patch on the github issue that resolves the
issue in 2.1.

thanks again for your help!
-rt

On Sat, Dec 19, 2020 at 3:09 PM adamo  wrote:

> Hi Reinhard,
>
>
> I was intending to open a bug report after contacting you earlier but
> someone appears to have beaten me to it!
>
>
> I'm still able to reproduce this on my end with the following.
>
> ---
> root@podman:~# podman run docker.io/alpine /bin/echo "Hello"
> Hello
> root@podman:~# adduser --uid 1010 bugtest --gecos "" --no-create-home
> --disabled-login --disabled-password
> Adding user `bugtest' ...
> Adding new group `bugtest' (1010) ...
> Adding new user `bugtest' (1010) with group `bugtest' ...
> Not creating home directory `/home/bugtest'.
> root@podman:~# podman run --user 1010 docker.io/alpine /bin/echo "Hello"
> Error: container_linux.go:370: starting container process caused: apply
> caps: operation not permitted: OCI runtime permission denied error
> ---
>
> This is a fresh image I've pulled and still occurs when running as the
> user 'nobody' as per your example.
>
> I've also tried the steps taken in your example (with an additional step
> to run the container) and managed to reproduce the error.
>
> -
> root@podman:~# cat Dockerfile
> FROM docker.io/debian
> USER nobody
> RUN id
> root@podman:~# podman rm -a
> root@podman:~# podman build -f Dockerfile
> STEP 1: FROM docker.io/debian
> Getting image source signatures
> Copying blob 6c33745f49b4 done
> Copying config 6d6b00c222 done
> Writing manifest to image destination
> Storing signatures
> STEP 2: USER nobody
> --> de292136a39
> STEP 3: RUN id
> uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
> STEP 4: COMMIT
> --> b08e47fc955
> b08e47fc955ccfe7a3c164e9fbd2068758ee145e39ffcc1a5c95d4a53ad4144d
> root@podman:~# podman run
> b08e47fc955ccfe7a3c164e9fbd2068758ee145e39ffcc1a5c95d4a53ad4144d /bin/echo
> "Hello"
> Error: container_linux.go:370: starting container process caused: apply
> caps: operation not permitted: OCI runtime permission denied error
> -
>
> While I don't think it's relevant, I've had this issue with both a VM on
> Linode (which I've upgraded from Debian 10 to bullseye) and on a local VM
> which was created directly from a "testing" iso.
>
> --
> root@podman:~# cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux bullseye/sid"
> NAME="Debian GNU/Linux"
> ID=debian
> HOME_URL="https://www.debian.org/;
> SUPPORT_URL="https://www.debian.org/support;
> BUG_REPORT_URL="https://bugs.debian.org/;
> --
>
> As mentioned, this appears to have been discussed in the issue
> https://github.com/containers/podman/issues/7747 on Github.
>
> If you need any more information from my end, please let me know.
>
> Thanks for your help with this.
>
> Regards,
> Adam.
>
>

-- 
regards,
Reinhard

[pkg-go] Bug#977717: podman: Images can't be run with non-root USER after upgrade to 2.1.1 due to wrong permissions of / inside the container

[Reinhard Tartler]

Control: fixed -1 2.2.0+dfsg1-1
Control: forwarded -1 https://github.com/containers/podman/issues/7747

Thanks for the clarification. With this, I was able to reproduce the issue
in unstable, and confirm its absence with the podma 2.2 package in
experimental. I've found a patch on the github issue that resolves the
issue in 2.1.

thanks again for your help!
-rt

On Sat, Dec 19, 2020 at 3:09 PM adamo  wrote:

> Hi Reinhard,
>
>
> I was intending to open a bug report after contacting you earlier but
> someone appears to have beaten me to it!
>
>
> I'm still able to reproduce this on my end with the following.
>
> ---
> root@podman:~# podman run docker.io/alpine /bin/echo "Hello"
> Hello
> root@podman:~# adduser --uid 1010 bugtest --gecos "" --no-create-home
> --disabled-login --disabled-password
> Adding user `bugtest' ...
> Adding new group `bugtest' (1010) ...
> Adding new user `bugtest' (1010) with group `bugtest' ...
> Not creating home directory `/home/bugtest'.
> root@podman:~# podman run --user 1010 docker.io/alpine /bin/echo "Hello"
> Error: container_linux.go:370: starting container process caused: apply
> caps: operation not permitted: OCI runtime permission denied error
> ---
>
> This is a fresh image I've pulled and still occurs when running as the
> user 'nobody' as per your example.
>
> I've also tried the steps taken in your example (with an additional step
> to run the container) and managed to reproduce the error.
>
> -
> root@podman:~# cat Dockerfile
> FROM docker.io/debian
> USER nobody
> RUN id
> root@podman:~# podman rm -a
> root@podman:~# podman build -f Dockerfile
> STEP 1: FROM docker.io/debian
> Getting image source signatures
> Copying blob 6c33745f49b4 done
> Copying config 6d6b00c222 done
> Writing manifest to image destination
> Storing signatures
> STEP 2: USER nobody
> --> de292136a39
> STEP 3: RUN id
> uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
> STEP 4: COMMIT
> --> b08e47fc955
> b08e47fc955ccfe7a3c164e9fbd2068758ee145e39ffcc1a5c95d4a53ad4144d
> root@podman:~# podman run
> b08e47fc955ccfe7a3c164e9fbd2068758ee145e39ffcc1a5c95d4a53ad4144d /bin/echo
> "Hello"
> Error: container_linux.go:370: starting container process caused: apply
> caps: operation not permitted: OCI runtime permission denied error
> -
>
> While I don't think it's relevant, I've had this issue with both a VM on
> Linode (which I've upgraded from Debian 10 to bullseye) and on a local VM
> which was created directly from a "testing" iso.
>
> --
> root@podman:~# cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux bullseye/sid"
> NAME="Debian GNU/Linux"
> ID=debian
> HOME_URL="https://www.debian.org/;
> SUPPORT_URL="https://www.debian.org/support;
> BUG_REPORT_URL="https://bugs.debian.org/;
> --
>
> As mentioned, this appears to have been discussed in the issue
> https://github.com/containers/podman/issues/7747 on Github.
>
> If you need any more information from my end, please let me know.
>
> Thanks for your help with this.
>
> Regards,
> Adam.
>
>

-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#977717: podman: Images can't be run with non-root USER after upgrade to 2.1.1 due to wrong permissions of / inside the container

[Reinhard Tartler]

Control: tag -1 moreinfo unreproducible


On Sat, Dec 19, 2020 at 9:15 AM Andreas Maus <
023a305472eca90cd389e9dd4a9f30f71a6cf...@ypbind.de> wrote:

> After the upgrade of podman to 2.1.1 container images
> can't be run if the Dockerfile specify a non-root USER.
>

I'm sorry, but I can't reproduce this (anymore):

siretart@x1:/tmp/d$ *podman rmi -a*
8ac063dba0c0659a071a74e67d3661495215ab740724e416d62f264d73a398ce
Untagged: docker.io/library/debian:latest
Deleted: db2b7591a39e6b509f93038f6855f95bb783efdc83aa3a20c347453320b6d345
Deleted: 6d6b00c22231693c9b87e79986d562874446bf10182206e4621e23ca8dfa8e1c
siretart@x1:/tmp/d$ *podman rm -a*
siretart@x1:/tmp/d$ *cat Dockerfile *
*FROM docker.io/debian *
*USER nobody*
*RUN id*
siretart@x1:/tmp/d$ *podman build -f Dockerfile *
STEP 1: FROM docker.io/debian
Getting image source signatures
Copying blob 6c33745f49b4 done
Copying config 6d6b00c222 done
Writing manifest to image destination
Storing signatures
STEP 2: USER nobody
--> 609dac75d3a
STEP 3: RUN id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
STEP 4: COMMIT
--> 037e1690447
037e1690447f0dd7d90d99cf7bc3cf1206f35f81225f2119445b147d5b6aa3a9

I was able to reproduce this error with an cached image that I had, but
deleting the local one
and getting a fresh one from the docker library allowed me to pass that
test.

I was not able to pull your exact image, and to be frank, I'd prefer if you
could describe the
steps to reproduce this with images that are publicly accessible and simple
to reproduce.

Can you please try again with fresh images and the example that I showed
above?

-- 
regards,
Reinhard

[pkg-go] Bug#977717: podman: Images can't be run with non-root USER after upgrade to 2.1.1 due to wrong permissions of / inside the container

[Reinhard Tartler]

Control: tag -1 moreinfo unreproducible


On Sat, Dec 19, 2020 at 9:15 AM Andreas Maus <
023a305472eca90cd389e9dd4a9f30f71a6cf...@ypbind.de> wrote:

> After the upgrade of podman to 2.1.1 container images
> can't be run if the Dockerfile specify a non-root USER.
>

I'm sorry, but I can't reproduce this (anymore):

siretart@x1:/tmp/d$ *podman rmi -a*
8ac063dba0c0659a071a74e67d3661495215ab740724e416d62f264d73a398ce
Untagged: docker.io/library/debian:latest
Deleted: db2b7591a39e6b509f93038f6855f95bb783efdc83aa3a20c347453320b6d345
Deleted: 6d6b00c22231693c9b87e79986d562874446bf10182206e4621e23ca8dfa8e1c
siretart@x1:/tmp/d$ *podman rm -a*
siretart@x1:/tmp/d$ *cat Dockerfile *
*FROM docker.io/debian *
*USER nobody*
*RUN id*
siretart@x1:/tmp/d$ *podman build -f Dockerfile *
STEP 1: FROM docker.io/debian
Getting image source signatures
Copying blob 6c33745f49b4 done
Copying config 6d6b00c222 done
Writing manifest to image destination
Storing signatures
STEP 2: USER nobody
--> 609dac75d3a
STEP 3: RUN id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
STEP 4: COMMIT
--> 037e1690447
037e1690447f0dd7d90d99cf7bc3cf1206f35f81225f2119445b147d5b6aa3a9

I was able to reproduce this error with an cached image that I had, but
deleting the local one
and getting a fresh one from the docker library allowed me to pass that
test.

I was not able to pull your exact image, and to be frank, I'd prefer if you
could describe the
steps to reproduce this with images that are publicly accessible and simple
to reproduce.

Can you please try again with fresh images and the example that I showed
above?

-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#977502: podman,golang-github-containers-common: both ship /usr/share/man/man5/containers-mounts.conf.5.gz

[Reinhard Tartler]

Hi Valentin,

I just received the bug below. It seems that the manpage duplication is
actually upstream:
-
https://github.com/containers/common/blob/master/docs/containers-mounts.conf.5.md
-
https://github.com/containers/podman/blob/master/docs/source/markdown/containers-mounts.conf.5.md

They both seem to have identical content. Maybe one of those copied should
be deleted? How do the fedora packagers get around this issue?

Thanks and best regards,
-rt


On Tue, Dec 15, 2020 at 2:51 PM Andreas Beckmann  wrote:

> Package: podman,golang-github-containers-common
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
> Control: found -1 2.1.1+dfsg1-2
> Control: found -1 0.28.1+ds1-1
>
> Hi,
>
> automatic installation tests of packages that share a file and at the
> same time do not conflict by their package dependency relationships has
> detected the following problem:
>
>   Preparing to unpack
> .../golang-github-containers-common_0.28.1+ds1-1_all.deb ...
>   Unpacking golang-github-containers-common (0.28.1+ds1-1) over
> (0.26.3+ds1-2) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/golang-github-containers-common_0.28.1+ds1-1_all.deb
> (--unpack):
>trying to overwrite '/usr/share/man/man5/containers-mounts.conf.5.gz',
> which is also in package podman 2.1.1+dfsg1-2
>   Errors were encountered while processing:
>
>  /var/cache/apt/archives/golang-github-containers-common_0.28.1+ds1-1_all.deb
>
> This is a serious bug as it makes installation fail, and violates
> sections 7.6.1 and 10.1 of the policy. An optimal solution would
> consist in only one of the packages installing that file, and renaming
> or removing the file in the other package. Depending on the
> circumstances you might also consider Replace relations or file
> diversions. If the conflicting situation cannot be resolved then, as a
> last resort, the two packages have to declare a mutual
> Conflict. Please take into account that Replaces, Conflicts and
> diversions should only be used when packages provide different
> implementations for the same functionality.
>
> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
>
>   usr/share/man/man5/containers-mounts.conf.5.gz
>
> This bug is assigned to both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package. You may
> also register in the BTS that the other package is affected by the bug.
>
> Cheers,
>
> Andreas
>
> PS: for more information about the detection of file overwrite errors
> of this kind see https://qa.debian.org/dose/file-overwrites.html
>


-- 
regards,
Reinhard

Bug#977502: podman,golang-github-containers-common: both ship /usr/share/man/man5/containers-mounts.conf.5.gz

[Reinhard Tartler]

Hi Valentin,

I just received the bug below. It seems that the manpage duplication is
actually upstream:
-
https://github.com/containers/common/blob/master/docs/containers-mounts.conf.5.md
-
https://github.com/containers/podman/blob/master/docs/source/markdown/containers-mounts.conf.5.md

They both seem to have identical content. Maybe one of those copied should
be deleted? How do the fedora packagers get around this issue?

Thanks and best regards,
-rt


On Tue, Dec 15, 2020 at 2:51 PM Andreas Beckmann  wrote:

> Package: podman,golang-github-containers-common
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
> Control: found -1 2.1.1+dfsg1-2
> Control: found -1 0.28.1+ds1-1
>
> Hi,
>
> automatic installation tests of packages that share a file and at the
> same time do not conflict by their package dependency relationships has
> detected the following problem:
>
>   Preparing to unpack
> .../golang-github-containers-common_0.28.1+ds1-1_all.deb ...
>   Unpacking golang-github-containers-common (0.28.1+ds1-1) over
> (0.26.3+ds1-2) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/golang-github-containers-common_0.28.1+ds1-1_all.deb
> (--unpack):
>trying to overwrite '/usr/share/man/man5/containers-mounts.conf.5.gz',
> which is also in package podman 2.1.1+dfsg1-2
>   Errors were encountered while processing:
>
>  /var/cache/apt/archives/golang-github-containers-common_0.28.1+ds1-1_all.deb
>
> This is a serious bug as it makes installation fail, and violates
> sections 7.6.1 and 10.1 of the policy. An optimal solution would
> consist in only one of the packages installing that file, and renaming
> or removing the file in the other package. Depending on the
> circumstances you might also consider Replace relations or file
> diversions. If the conflicting situation cannot be resolved then, as a
> last resort, the two packages have to declare a mutual
> Conflict. Please take into account that Replaces, Conflicts and
> diversions should only be used when packages provide different
> implementations for the same functionality.
>
> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
>
>   usr/share/man/man5/containers-mounts.conf.5.gz
>
> This bug is assigned to both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package. You may
> also register in the BTS that the other package is affected by the bug.
>
> Cheers,
>
> Andreas
>
> PS: for more information about the detection of file overwrite errors
> of this kind see https://qa.debian.org/dose/file-overwrites.html
>


-- 
regards,
Reinhard

[pkg-go] Bug#977502: podman, golang-github-containers-common: both ship /usr/share/man/man5/containers-mounts.conf.5.gz

[Reinhard Tartler]

Hi Valentin,

I just received the bug below. It seems that the manpage duplication is
actually upstream:
-
https://github.com/containers/common/blob/master/docs/containers-mounts.conf.5.md
-
https://github.com/containers/podman/blob/master/docs/source/markdown/containers-mounts.conf.5.md

They both seem to have identical content. Maybe one of those copied should
be deleted? How do the fedora packagers get around this issue?

Thanks and best regards,
-rt


On Tue, Dec 15, 2020 at 2:51 PM Andreas Beckmann  wrote:

> Package: podman,golang-github-containers-common
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
> Control: found -1 2.1.1+dfsg1-2
> Control: found -1 0.28.1+ds1-1
>
> Hi,
>
> automatic installation tests of packages that share a file and at the
> same time do not conflict by their package dependency relationships has
> detected the following problem:
>
>   Preparing to unpack
> .../golang-github-containers-common_0.28.1+ds1-1_all.deb ...
>   Unpacking golang-github-containers-common (0.28.1+ds1-1) over
> (0.26.3+ds1-2) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/golang-github-containers-common_0.28.1+ds1-1_all.deb
> (--unpack):
>trying to overwrite '/usr/share/man/man5/containers-mounts.conf.5.gz',
> which is also in package podman 2.1.1+dfsg1-2
>   Errors were encountered while processing:
>
>  /var/cache/apt/archives/golang-github-containers-common_0.28.1+ds1-1_all.deb
>
> This is a serious bug as it makes installation fail, and violates
> sections 7.6.1 and 10.1 of the policy. An optimal solution would
> consist in only one of the packages installing that file, and renaming
> or removing the file in the other package. Depending on the
> circumstances you might also consider Replace relations or file
> diversions. If the conflicting situation cannot be resolved then, as a
> last resort, the two packages have to declare a mutual
> Conflict. Please take into account that Replaces, Conflicts and
> diversions should only be used when packages provide different
> implementations for the same functionality.
>
> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
>
>   usr/share/man/man5/containers-mounts.conf.5.gz
>
> This bug is assigned to both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package. You may
> also register in the BTS that the other package is affected by the bug.
>
> Cheers,
>
> Andreas
>
> PS: for more information about the detection of file overwrite errors
> of this kind see https://qa.debian.org/dose/file-overwrites.html
>


-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers