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

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 forbidde

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

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 forbidde

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

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 forbidde

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

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.

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

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.

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

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.

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

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:

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

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:

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

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:

Bug#982030: nmu: libpod_libpod

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

Bug#982030: nmu: libpod_libpod

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

Bug#981849: podman build does not use the cache

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

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

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

Bug#981849: podman build does not use the cache

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

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

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

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

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

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

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

Re: Podman 3.0 and Debian bullseye

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

Re: Podman 3.0 and Debian bullseye

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

Re: Podman 3.0 and Debian bullseye

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 pod

Re: Podman 3.0 and Debian bullseye

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 pod

Re: Podman 3.0 and Debian bullseye

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

Re: Podman 3.0 and Debian bullseye

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

Re: Podman 3.0 and Debian bullseye

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

Re: Podman 3.0 and Debian bullseye

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

Re: Podman 3.0 and Debian bullseye

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

Re: Podman 3.0 and Debian bullseye

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

Re: Podman 3.0 and Debian bullseye

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?

Re: Podman 3.0 and Debian bullseye

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?

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

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

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

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:

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

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:

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

** 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

Re: Podman 3.0 and Debian bullseye

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 > > varli

Re: Podman 3.0 and Debian bullseye

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 > > varli

Podman 3.0 and Debian bullseye

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

Podman 3.0 and Debian bullseye

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

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

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 &

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

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 &

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

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 &

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

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.

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

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.

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

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.

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

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

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

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 Deb

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

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 Deb

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

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 Deb

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

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 wrot

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

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 wrot

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

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 wrot

[Bug 1905443] Re: Podman/libpod crash

=> 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 Ubun

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

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

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

d 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 fai

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

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

Bug#979313: marked as pending in libpod

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:

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

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

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

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

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

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

helping golang-golang-x-sys to migrate

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

Bug#976924: Test timeouts on ppc64el not RC

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

Bug#976924: Test timeouts on ppc64el not RC

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

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

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

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

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:

Bug#977502: marked as pending in libpod

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:

Bug#977502: marked as pending in libpod

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:

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

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

[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

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

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

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

[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

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

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

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

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

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

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

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

Bug#976943: golang-github-seccomp-libseccomp-golang: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 github.com/seccomp/libsec

> === RUN TestRuleAddAndLoad > seccomp_test.go:588: Syscall should have returned error code! > --- FAIL: TestRuleAddAndLoad (0.00s) Source code is here: https://sources.debian.org/src/golang-github-seccomp-libseccomp-golang/0.9.1-2/seccomp_test.go/#L529-L589 This test is basically

Bug#976943: golang-github-seccomp-libseccomp-golang: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 github.com/seccomp/libsec

> === RUN TestRuleAddAndLoad > seccomp_test.go:588: Syscall should have returned error code! > --- FAIL: TestRuleAddAndLoad (0.00s) Source code is here: https://sources.debian.org/src/golang-github-seccomp-libseccomp-golang/0.9.1-2/seccomp_test.go/#L529-L589 This test is basically

[pkg-go] Bug#976943: golang-github-seccomp-libseccomp-golang: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 github.com/secco

> === RUN TestRuleAddAndLoad > seccomp_test.go:588: Syscall should have returned error code! > --- FAIL: TestRuleAddAndLoad (0.00s) Source code is here: https://sources.debian.org/src/golang-github-seccomp-libseccomp-golang/0.9.1-2/seccomp_test.go/#L529-L589 This test is basically

Bug#976543: marked as pending in golang-github-rcrowley-go-metrics

Control: tag -1 pending Hello, Bug #976543 in golang-github-rcrowley-go-metrics 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:

Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/

Control: forwarded -1 https://github.com/shirou/gopsutil/issues/881 I'm having a hard time seeing bugs like this as RC-critical. Looking at the testsuite more specifically, I strongly believe this is upstream bug https://github.com/shirou/gopsutil/issues/881 Lucas, can you please post

Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/

Control: forwarded -1 https://github.com/shirou/gopsutil/issues/881 I'm having a hard time seeing bugs like this as RC-critical. Looking at the testsuite more specifically, I strongly believe this is upstream bug https://github.com/shirou/gopsutil/issues/881 Lucas, can you please post

Re: gitlab-shell buster-backports and golang 1.15

On Fri, Oct 30, 2020 at 5:31 AM Shengjing Zhu wrote: > > > I suspect this could be related to version of golang, in > > unstable/testing it is 1.15 so we may need the newer golang version. > > Can someone confirm if this is indeed the case? If yes, do we plan to > > backport golang 1.15? I can

Re: New consul package not migrating to testing because of patroni autopkgtest?

On Wed, Dec 9, 2020 at 2:32 PM Paul Gevers wrote: > > These kind of build failures should be fixed. Builds that regularly fail > are not OK. Same goes for autopkgtest. Flaky tests are RC. > Agreed. > > What's involved with retrying autopkgtests on arm64? -- CC'ing > > debian-release@, maybe

Re: New consul package not migrating to testing because of patroni autopkgtest?

successfully. That's why I'm optimistic about retrying the autopkg tests for consul. What's involved with retrying autopkgtests on arm64? -- CC'ing debian-release@, maybe they have some input? Best, -rt On Mon, Dec 7, 2020 at 6:43 AM Reinhard Tartler wrote: > Ok, thanks! > > I have

Re: [pkg-go] Comments regarding libpod_2.1.1+dfsg1-1_multi.changes

On 12/6/20 4:03 PM, Joerg Jaspert wrote: > Hi Maintainer, > > the following are comments from a review one ftp trainee has done on > your package. While I will accept your package (nothing warrants a > reject), please fix them in your next upload. > [...] Thank you again to whoever did this

Bug#975584: marked as pending in consul

Control: tag -1 pending Hello, Bug #975584 in consul 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:

Bug#976410: glibc breaks libpod autopkgtest: dh_auto_build: error: cd _output && go install -trimpath ...

On Fri, Dec 4, 2020 at 3:24 PM Aurelien Jarno wrote: > > I have tried and for me the issue is reproducible with both old and new > glibc. I am therefore reassign the bug to libpod. > This is because of an upstream update in a dependency. It should be very straight-forward to fix. Unfortunately,

Bug#976410: glibc breaks libpod autopkgtest: dh_auto_build: error: cd _output && go install -trimpath ...

On Fri, Dec 4, 2020 at 3:24 PM Aurelien Jarno wrote: > > I have tried and for me the issue is reproducible with both old and new > glibc. I am therefore reassign the bug to libpod. > This is because of an upstream update in a dependency. It should be very straight-forward to fix. Unfortunately,

[pkg-go] Bug#976410: glibc breaks libpod autopkgtest: dh_auto_build: error: cd _output && go install -trimpath ...

On Fri, Dec 4, 2020 at 3:24 PM Aurelien Jarno wrote: > > I have tried and for me the issue is reproducible with both old and new > glibc. I am therefore reassign the bug to libpod. > This is because of an upstream update in a dependency. It should be very straight-forward to fix. Unfortunately,

Bug#976237: ITP: golang-github-containers-dnsname -- name resolution for containers

Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: dnsname Version : 1.1.1-1 Upstream Author : Containers * URL : https://github.com/containers/dnsname * License : Apache-2.0 Programming Lang: Go Description : name resolution

Bug#976237: ITP: golang-github-containers-dnsname -- name resolution for containers

Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: dnsname Version : 1.1.1-1 Upstream Author : Containers * URL : https://github.com/containers/dnsname * License : Apache-2.0 Programming Lang: Go Description : name resolution

Bug#976237: ITP: golang-github-containers-dnsname -- name resolution for containers

Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: dnsname Version : 1.1.1-1 Upstream Author : Containers * URL : https://github.com/containers/dnsname * License : Apache-2.0 Programming Lang: Go Description : name resolution

Bug#976237: ITP: golang-github-containers-dnsname -- name resolution for containers

Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: dnsname Version : 1.1.1-1 Upstream Author : Containers * URL : https://github.com/containers/dnsname * License : Apache-2.0 Programming Lang: Go Description : name resolution

Bug#972674: ITP: toolbox -- Unprivileged container development environment

suggest changes) and I thought that it might be an >> idea to make an attempt to properly package it and add it to the Debian >> archives. >> >> Will be keen to hear what others think. > > I was looking for the package and I'm glad that you are working on > packagi

<    1   2   3   4   5   6   7   8   9   10   >