Bug#1071648: FTBFS with Linux 6.8+

On Wed, 22 May 2024 at 16:09, Tianon Gravi wrote: > The recent upload of src:linux to 6.8+ (specifically 6.8.9-1, > ironicially uploaded around the same time as the last busybox upload) > causes src:busybox to FTBFS (logs from reproducible-builds): > > ... > > https

Bug#1071648: FTBFS with Linux 6.8+

Source: busybox Version: 1:1.36.1-7 Severity: serious Tags: ftbfs upstream X-Debbugs-Cc: tia...@debian.org The recent upload of src:linux to 6.8+ (specifically 6.8.9-1, ironicially uploaded around the same time as the last busybox upload) causes src:busybox to FTBFS (logs from

Bug#1068755: docker.io: FTBFS: failing tests

On Mon, 6 May 2024 at 17:00, Cyril Brulebois wrote: > I'm adding Tianon to the loop explicitly since I'm definitely no Docker > (or Go) expert, in case some time can be spared to look into this > problem. Otherwise I'll try and come up with something. I think the backport by Reinhard[1][2] is

Bug#1040507: golang-1.21-go: downloads and runs binaries from the Internet without permission

On Thu, 6 Jul 2023 at 14:39, brian m. carlson wrote: > Go 1.21 provides the `GOTOOLCHAIN` environment variable and associated > functionality[0]. As part of this code, if go.mod indicates that a > newer version of Go is required than the current toolchain supports, it > proceeds by default to

Bug#1027114: docker.io: FTBFS: daemon/graphdriver/btrfs/btrfs.go:437:11: args.lim.max_referenced undefined (type _Ctype_struct_btrfs_qgroup_limit has no field or method max_referenced)

On Tue, 27 Dec 2022, 15:18 Sebastian Ramacher, wrote: > ---> Making bundle: dynbinary (in bundles/dynbinary) > Building: bundles/dynbinary-daemon/dockerd-20.10.21+dfsg1 > GOOS="" GOARCH="" GOARM="" > # github.com/docker/docker/daemon/graphdriver/btrfs > daemon/graphdriver/btrfs/btrfs.go:437:11:

Bug#1022854: debuerreotype: autopkgtest rebuilds with different toolchain and expects the same result

On Fri, 28 Oct 2022 at 10:42, Luca Boccassi wrote: > (18:32:13) bluca: the debuerrotype maintainer explicitly asked not to, > and instead to ask for a migration hint > (18:32:46) elbrus: we'll not do that > (18:32:58) elbrus: as the autopkgtest regression in testing is RC Sorry, this was my

Bug#1020085: python-astor: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13

forwarded 1020085 https://github.com/berkerpeksag/astor/issues/212 thanks On Sat, 17 Sept 2022 at 23:45, Lucas Nussbaum wrote: > > p = <[ValueError('Exceeds the limit (4300) for integer string conversion') > > raised in repr()] int object at 0x556a03b67200> > > imaginary = False > > > > def

Bug#1013726: python-astor: FTBFS: pytest7 regression, deprecated pytest feature: -k-

On Fri, 24 Jun 2022 at 15:57, Louis-Philippe Véronneau wrote: > I had a closer look at the error log and identified the regression as: > 'deprecated pytest feature: -k-'. Hopefully, that's helpful! Thanks! I've updated Git with a fix now (`-k 'not ...'`), but I'm not sure when I'll have a

Bug#1002344: hy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

On Wed, 22 Dec 2021 at 00:04, Lucas Nussbaum wrote: > Source: hy > Version: 0.19.0-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20211220 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to

Bug#995623: refind FTBFS: error: conflicting types for ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’

tags 995623 + pending thanks On Sat, 23 Oct 2021 at 07:25, Rod Smith wrote: > > I've fixed this problem with commit 10f838: > > https://sourceforge.net/p/refind/code/commit_browser > > You should be able to cherry-pick that, although changes to NEWS.txt and > include/version.h might need to be

Bug#995623: refind FTBFS: error: conflicting types for ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’

On Tue, 19 Oct 2021 at 17:07, Tianon Gravi wrote: > > Hey Rod, this is an interesting one -- looking at the definitions of > the "EFI_DEVICE_PATH_UTILITIES_PROTOCOL" typedef in both refind's code > and grub-efi's, they appear to be compatible to me (which makes sense, > probab

Bug#995623: refind FTBFS: error: conflicting types for ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’

Hey Rod, this is an interesting one -- looking at the definitions of the "EFI_DEVICE_PATH_UTILITIES_PROTOCOL" typedef in both refind's code and grub-efi's, they appear to be compatible to me (which makes sense, probably from the same original source?) Is this something you plan to resolve in

Bug#994950: Command not found after installation

severity 994950 wishlist thanks On Thu, 23 Sept 2021 at 11:12, Abraham Raji wrote: > avronr@alucard:~$ debootstrap > bash: debootstrap: command not found The "debootstrap" command gets installed into "/usr/sbin" so you'll need to either add that to your PATH, use an explicit full path

Bug#985963: debuerreotype: uses debian-archive-keyring in autopkgtests without real dependency

tags 985963 + pending thanks On Fri, 26 Mar 2021 at 15:45, Gianfranco Costamagna wrote: > Hello, looks like the debian/tests/stretch is using the keyring but the > package has only a recommends on that dependency. > This makes the autopkgtest fail when apt is configured with >

Bug#983512: Bug#983513: debuerreotype: autopkgtest seems to hard-code amd64 signature

On Thu, 25 Feb 2021 at 12:09, Paul Gevers wrote: > On 25-02-2021 20:40, Tianon Gravi wrote: > > Hi Paul! Thanks for filing these -- I've pushed two commits to the > > Git repo which fix both 983512 and 983513 (and made it more forgiving > > of other architectures for the f

Bug#983512: Bug#983513: debuerreotype: autopkgtest seems to hard-code amd64 signature

On Thu, 25 Feb 2021 at 04:18, Paul Gevers wrote: > Your package has an autopkgtest, great. However, it always fails on > non-amd64 architectures. Looking at the error message, it seems to > compare the build tar ball with a pre-computed hash that's only valid on > amd64. (And then the log becomes

Bug#975230: [pkg-go] Bug#975230: golang-pault-go-ykpiv: FTBFS: src/pault.ag/go/ykpiv/ykpiv.go:539:12: _Ctype_struct_ykpiv_state can't be allocated in Go; it is incomplete (or unallocatable)

On Thu, 19 Nov 2020 at 02:01, Lucas Nussbaum wrote: > > src/pault.ag/go/ykpiv/ykpiv.go:539:12: _Ctype_struct_ykpiv_state can't be > > allocated in Go; it is incomplete (or unallocatable) > > src/pault.ag/go/ykpiv/ykpiv.go:569:11: _Ctype_struct_ykpiv_state can't be > > allocated in Go; it is

Bug#971789: FTBFS: Could not determine section for ./.gopath/src/github.com/docker/cli/man/man1/docker-attach.1

On Wed, 7 Oct 2020 at 02:09, Shengjing Zhu wrote: > Maybe due to the go-md2man v2 transition, docker.io is now FTBFS. > > dh_installman: warning: Section for > ./.gopath/src/github.com/docker/cli/man/man1/docker-attach.1 is computed as > "2020", which is not a valid section > dh_installman:

Bug#957754: refind: ftbfs with GCC-10

On Fri, 15 May 2020 at 10:15, Rod Smith wrote: > The below-described bug can be fixed with a change to compiler options > -- namely, adding -fno-tree-loop-distribute-patterns. I've implemented > this change in commit e34a16 on the rEFInd Sourceforge git repository: > >

Bug#948087: future of aufs in Debian.

On Wed, 27 May 2020 at 14:33, Noah Meyerhans wrote: > Docker no longer users aufs by default, though, having switched to > overlayfs some time ago. I'm sure we could get them to drop the > Recommends if we're considering getting rid of it. This is something I'd been considering for quite a

Bug#959631: hy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

On Tue, 5 May 2020 at 10:55, Tianon Gravi wrote: > I was definitely over my head with this one, so I reached out to the > Hy community and was pointed to https://bugs.python.org/issue39562, > which does seem quite related from my own limited understanding, so > this might technica

Bug#959631: hy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

On Sun, 3 May 2020 at 06:12, Lucas Nussbaum wrote: > > ... > > === warnings summary > > === > > .pybuild/cpython3_3.8_hy/build/tests/native_tests/comprehensions.hy::test_fors[sfor] > > /<>/hy/models.py:133: RuntimeWarning: coroutine '' >

Bug#953759: debootstrap: mandatory security support breaks too many things

On Thu, 12 Mar 2020 at 18:27, Cyril Brulebois wrote: > The latest batch of bug reports filed by Johannes 'josch' Schauer seems > to confirm my initial assessment: this will break (too) many use cases > (#953404, #953588, #953593, #953594, #953617). +1, thanks (to you both) for doing this -- my

Bug#950672: hy: diff for NMU version 0.17.0-1.1

On Tue, 4 Feb 2020 at 08:57, Stefano Rivera wrote: > I've prepared an NMU for hy (versioned as 0.17.0-1.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. Nice, I think this is perfectly reasonable, thanks! I'm hoping to get 0.18.0 packaged soon, which

Bug#949130: refind-install fails to determine the ESP partition

On Sun, 19 Jan 2020 at 09:40, Pelzi wrote: > I found the cure for the problem: the ESP partition was listed as fs type > „msdos“ in fstab. Changing this to „vfat" made refind-install work for me. Ah nice catch! So it sounds like at most, this should be an upstream feature request to have

Bug#949130: refind-install fails to determine the ESP partition

On Fri, 17 Jan 2020 at 01:39, Andreas Feldner wrote: > on an existing installation, the refind package started to break apt-get > upgrade runs, > presumably with the availability of an update of the package. > > The issue arrived w/o interaction on unattended upgrade runs and can easily >

Bug#948417: marked as pending in python-astor

Control: tag -1 pending Hello, Bug #948417 in python-astor 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#913614: [pkg-gnupg-maint] Bug#913614: gnupg2 fails with "cannot open '/dev/tty': No such device or address"

On Tue, 13 Nov 2018 15:18:22 +0100 Werner Koch wrote: > For any script use you should anyway use --batch which disables the use > of the tty as a side-effect. Even for something that shouldn't have a reason to prompt, like "--recv-keys" with a full fingerprint? It makes some sense logically,

Bug#906229: docker: FTBFS with dpkg-buildpackage -A

On Wed, 15 Aug 2018 at 12:42, Tianon Gravi wrote: > I think the attached patch is likely going to be our simplest fix > unless anyone following along (to src:docker!) sees any issues with > it? Idiot old me, forgot the attachment. ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4

Bug#906229: docker: FTBFS with dpkg-buildpackage -A

On Wed, 15 Aug 2018 at 10:12, Santiago Vila wrote: > > [...] > debian/rules build-indep > make: *** No rule to make target 'build-indep'. Stop. > dpkg-buildpackage: error: debian/rules build-indep subprocess

Bug#902258: any docker command triggers an attempt to unlock my GPG key

On Sat, 23 Jun 2018 at 18:51, Yaroslav Halchenko wrote: > IMHO doker must not ask for unlocking GPG key at all AFAIK, unless may be > some functionality requires signing et. > > I've not yet tried to figure out what exactly leads to it. I'll bet you've got "pass" [1] installed, and this is thus

Bug#901808: debootstrap: --merged-usr is silently ignored on "blacklisted" suites like stretch

Package: debootstrap Version: 1.0.102 Severity: serious Justification: https://lists.debian.org/debian-boot/2018/06/msg00238.html See the conversation around/following [1] for more context. [1]: https://lists.debian.org/debian-boot/2018/06/msg00175.html The TLDR is that the previous version of

Bug#883558: linux: not yet ready to enter testing

Salvatore Bonaccorso wrote: > We think 4.14.2-1 should not yet enter testing, thus filling a > blocking bug to preventing migration. > > We will close the bug as soon we think 4.14.2-1 or an increment is > good. In the quest for a little more detail (because I'm wanting to test 4.14 on a buster

Bug#878912: docker.io: docker run fails saying that containerd-shim not installed

tags 878912 + moreinfo unreproducible severity normal thanks On 17 October 2017 at 10:05, Antonio Terceiro wrote: > On a completely up to date sid system: > > $ docker run -it --rm debian:sid > docker: Error response from daemon: containerd-shim not installed on system. I

Bug#877146: Bug#877329: Bug#877146: update to runc (1.0.0~rc4) breaks docker

On 10 October 2017 at 12:59, Tianon Gravi <tia...@debian.org> wrote: > I've been working on a "docker-containerd" package today (since that's > going to be useful regardless), and found that there are other > packages needed which depend on > "golang-github-opencon

Bug#877146: Bug#877329: Bug#877146: update to runc (1.0.0~rc4) breaks docker

On 3 October 2017 at 15:52, Bálint Réczey wrote: > I think it would be cleaner to go without the Provides: and adding > docker-containerd build-depending on > golang-github-opencontainers-docker-runc-dev, but feel free to go either way. > > I think the most efficient way

Bug#877146: update to runc (1.0.0~rc4) breaks docker

On 30 September 2017 at 08:37, Bálint Réczey wrote: > Tianon, could you please switch to docker-runc in docker.io? > > I have the packaging commits in git for docker-runc but I did not want to > push it to the go packages' area so when I get approved to the Docker >

Bug#871344: golang-1.6: FTBFS: test fails

On 7 August 2017 at 08:51, Lucas Nussbaum wrote: > Source: golang-1.6 > Version: 1.6.3-1 > Severity: serious > Tags: buster sid This has me a bit confused -- there's no "golang-1.6" in sid (or buster) that I can find: - https://packages.debian.org/sid/source/golang-1.6 -

Bug#850951: CVE-2016-9962

On 31 January 2017 at 20:46, Tianon Gravi <tia...@debian.org> wrote: > I'm preparing a patch for the package now, but I'm curious what the > implications of an upload will be so close to the freeze -- do we need > to request a freeze exception or a migration adjustment after the &g

Bug#850951: [pkg-go] Bug#850951: Bug#850951: CVE-2016-9962

On 30 January 2017 at 11:31, Salvatore Bonaccorso wrote: > Disclaimer: I'm not too deep into that. I just noticed that > https://bugzilla.novell.com/show_bug.cgi?id=1012568 though seem to > indicate as well 0.1.1 based version are affected. But I cannot tell > more (at the

Bug#850951: [pkg-go] Bug#850951: CVE-2016-9962

On 11 January 2017 at 07:21, Moritz Muehlenhoff wrote: > Please see: > https://bugzilla.suse.com/show_bug.cgi?id=1012568 > https://github.com/docker/docker/compare/v1.12.5...v1.12.6 > https://github.com/opencontainers/runc/commit/50a19c6ff828c58e5dab13830bd3dacde268afe5 I've

Bug#835686: docker.io: FTBFS: .gopath/src/github.com/docker/containerd/api/grpc/types/api.pb.go:1137: cannot use _API_CreateContainer_Handler (type func(interface {}, "golang.org/x/net/context".Contex

On 22 December 2016 at 11:05, Antonio Terceiro wrote: > We are very close to a point where docker will not be part of stretch. > Is there any chance this gets fixed before that? If someone were to come up with a patch which fixes this, I'd be happy to test it, but I can't

Bug#836991: golang-doc: fails to upgrade from 'jessie': error: directory '/usr/lib/go' contains files not owned by package golang-go:i386, cannot switch to symlink

On 5 December 2016 at 21:06, Tianon Gravi <tia...@debian.org> wrote: > I _think_ adding "golang-doc (<< 2:1.6.1+1~)" to the existing "Breaks" > on "golang-go" might actually be the solution to this issue (since the > "golang-doc"

Bug#836991: golang-doc: fails to upgrade from 'jessie': error: directory '/usr/lib/go' contains files not owned by package golang-go:i386, cannot switch to symlink

On 5 December 2016 at 21:01, Tianon Gravi <tia...@debian.org> wrote: > Now to try and figure out exactly which new conflicts/breaks are > necessary... :x I _think_ adding "golang-doc (<< 2:1.6.1+1~)" to the existing "Breaks" on "golang-go" mig

Bug#836991: golang-doc: fails to upgrade from 'jessie': error: directory '/usr/lib/go' contains files not owned by package golang-go:i386, cannot switch to symlink

On 20 November 2016 at 18:45, Tianon Gravi <tia...@debian.org> wrote: > Any thoughts or hrefs on the "correct" way to fix this in the > packaging? (Or a simple way to figure out _which_ files don't belong > so we can evaluate more clearly?) > > I don't want to j

Bug#845398: x11-common: Can't configure

On Wed, 23 Nov 2016 01:53:45 +0100 Samuel Thibault wrote: > I guess what was meant was rather > > db_unregister x11-common/xwrapper/allowed_users > db_unregister x11-common/xwrapper/actual_allowed_users I tested this locally just to see if I could get past the configure

Bug#842806: docker.io: Can't connect to the daemon

severity 842806 important thanks On 21 November 2016 at 00:18, Kurt Roeckx wrote: > It's not installed. So, does installing "cgroupfs-mount" (and making sure the "service" is started from its init script) fix the issue with Docker? :) >> Any objections to lowering the severity

Bug#841575: [pkg-go] Bug#841575: docker-registry: FTBFS: Tests failures

On 20 November 2016 at 20:31, Tianon Gravi <tia...@debian.org> wrote: > I wasn't able to dig into the details yet, but looking at the log I > noticed the following which I believe is the real test failure output: That being said, I currently get the (more severe IMO) failure when try

Bug#841575: [pkg-go] Bug#841575: docker-registry: FTBFS: Tests failures

On 21 October 2016 at 06:10, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build on > amd64. I wasn't able to dig into the details yet, but looking at the log I noticed the following which I believe is the real test failure output: >

Bug#835686: docker.io: FTBFS: .gopath/src/github.com/docker/containerd/api/grpc/types/api.pb.go:1137: cannot use _API_CreateContainer_Handler (type func(interface {}, "golang.org/x/net/context".Contex

On 28 August 2016 at 03:23, Lucas Nussbaum wrote: >> ---> Making bundle: dynbinary (in bundles/1.11.2/dynbinary) >> Building: bundles/1.11.2/dynbinary/docker-1.11.2 >> # github.com/docker/containerd/api/grpc/types >>

Bug#842806: docker.io: Can't connect to the daemon

On 2 November 2016 at 00:25, Kurt Roeckx wrote: > I'm guessing this is something systemd sets up, but that I might > need to manually set up if not using it? Ah yeah, sounds like it -- did you install recommends when installing docker.io? That should've pulled in the

Bug#843530: docker.io: docker broken: oci runtime error: could not synchronize with container process

severity 843530 important thanks On 8 November 2016 at 09:52, Tianon Gravi <tia...@debian.org> wrote: > Ouch, looks like we're now hitting > https://github.com/opencontainers/runc/issues/1175, which doesn't > appear to have a Docker or runc workaround yet (

Bug#832103: docker.io: Can't run images after upgrading to 1.11.2~ds1-6

severity 832103 important thanks On 31 August 2016 at 12:02, Felipe Sateler wrote: > Ack. > > Anyway, isn't this a condition docker can detect (mismatch between > binaries and the running daemon)? In that case it could print a > suitable help message for the user. Yeah, I

Bug#836991: golang-doc: fails to upgrade from 'jessie': error: directory '/usr/lib/go' contains files not owned by package golang-go:i386, cannot switch to symlink

On 7 September 2016 at 14:18, Andreas Beckmann wrote: > Preparing to unpack .../golang-go_2%3a1.7~1_i386.deb ... > dpkg-maintscript-helper: error: directory '/usr/lib/go' contains files not > owned by package golang-go:i386, cannot switch to symlink > dpkg: error

Bug#837485: [pkg-golang-devel] Bug#837485: Bug#837485: golang-1.6: FTBFS with bindnow and PIE enabled

On 5 November 2016 at 09:00, Niels Thykier wrote: > Cool! :) > > Should I file a bug against ftp.d.o, asking them to remove golang-1.6 > from unstable? :) If you're willing, that sounds great! (I always end up having to re-read the docs any time I use the BTS for more than

Bug#843530: docker.io: docker broken: oci runtime error: could not synchronize with container process

On 7 November 2016 at 05:34, Stef Walter wrote: > The docker package is unfortunately currently broken. It fails to run > containers and instead produces the following message: > > rpc error: code = 2 desc = "oci runtime error: could not synchronise with > container process:

Bug#837485: [pkg-golang-devel] Bug#837485: Bug#837485: golang-1.6: FTBFS with bindnow and PIE enabled

On 31 October 2016 at 17:50, Tianon Gravi <tia...@debian.org> wrote: > Checking reverse dependencies... > # Broken Build-Depends: > golang-github-docker-go: golang-1.6-go > golang-1.6-src > > Dependency problem found. After that last golang-github

Bug#842806: docker.io: Can't connect to the daemon

On 1 November 2016 at 05:35, Kurt Roeckx wrote: > The file /var/run/docker.sock seems to exist, is created when it starts, > but it really seems to be listening to an other socket. > > The process that's running shows: > containerd -l

Bug#837485: [pkg-golang-devel] Bug#837485: Bug#837485: golang-1.6: FTBFS with bindnow and PIE enabled

On 31 October 2016 at 17:12, Michael Hudson-Doyle wrote: > The question is, do we backport the fixes for golang-1.6, or just remove it > from the archive? Looks like removal would be fairly straightforward; the only package currently affected is

Bug#839364: [pkg-golang-devel] Bug#839364: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt

On 3 October 2016 at 15:49, Tianon Gravi <tia...@debian.org> wrote: > Oh dur, good point. src:golang-defaults took over all the binaries > from src:golang; I'll file an FTP team bug. #839690 :) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4

Bug#839364: [pkg-golang-devel] Bug#839364: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt

On 3 October 2016 at 15:47, Michael Hudson-Doyle wrote: > That's src:golang-defaults, isn't it? > >> >> Is there some cruft in the archive we need >> to ask the FTP team to take care of that's causing this older version >> to get included in the rebuild? > > > I

Bug#839364: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt

On 1 October 2016 at 01:49, Lucas Nussbaum wrote: > Source: golang > Version: 2:1.6.1-2 > Severity: serious > Tags: stretch sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20160930 qa-ftbfs > Justification: FTBFS on amd64 I'm honestly confused about where this one

Bug#827851: Bug#831258: refind: pending bugs

tags 831258 - pending thanks On 30 September 2016 at 13:29, Tianon Gravi <tia...@debian.org> wrote: > Finally tested my FTBFS patch on a real box, and definitely glad I > did. It doesn't even boot, so clearly my patch isn't correct. O:) I was searching around to try and find som

Bug#827851: Bug#831258: refind: pending bugs

On 31 August 2016 at 07:49, Tianon Gravi <tia...@debian.org> wrote: > Fixes for both of these are in Git now, but I'd like to test the > result on a real box before I upload. Finally tested my FTBFS patch on a real box, and definitely glad I did. It doesn't even boot, so clearly my

Bug#832103: docker.io: Can't run images after upgrading to 1.11.2~ds1-6

On 25 July 2016 at 07:42, Felipe Sateler wrote: > I had this problem too. Restarting the daemon seems to have fixed the > issue. I think the docker daemon should be restarted on package > upgrades, as most daemons do. Normally I would tend to agree, but in this case,

Bug#827851: refind: pending bugs

tags 827851 + pending tags 831258 + pending thanks Fixes for both of these are in Git now, but I'd like to test the result on a real box before I upload. ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4

Bug#831258: refind: FTBFS: edk2/ComponentName.h:55:23: error: conflicting types for 'EFI_COMPONENT_NAME_GET_DRIVER_NAME'

On 14 July 2016 at 03:28, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build on > amd64. The attached patch allows the package to build again, but I'd rather make sure from Rod before officially applying it that just removing these

Bug#830729: [pkg-go] Bug#830729: Bug#830729: Bug#830729: golang-github-mitchellh-go-homedir: FTBFS: homedir_test.go:44: "/home/lamby" != "~"

On 31 July 2016 at 20:20, Potter, Tim (HPE Linux Support) wrote: > Patch attached to fix this, but it's a bit icky (and has been replaced by a > shell out to call > getent in a later version. Very nice catch indeed! Given that the code in question is rewritten in newer

Bug#832103: docker.io: Can't run images after upgrading to 1.11.2~ds1-6

On 22 July 2016 at 03:40, Sandro Knauß wrote: > downgrading to 1.11.2~ds1-5 and restart the daemon fixed the problem: Did you try restarting the daemon before you downgraded? (and if not, would you be willing to upgrade again and give it a shot?) ♥, - Tianon 4096R / B42F

Bug#830729: [pkg-go] Bug#830729: golang-github-mitchellh-go-homedir: FTBFS: homedir_test.go:44: "/home/lamby" != "~"

On 17 July 2016 at 08:22, Chris Lamb wrote: > So, I can make the tests pass if I *remove* the "HOME=" bit in > debian/rules. Sorry I can't be more help. It looks like it passes in the reproducible builds framework, but I think I might have a hunch for what's failing on your

Bug#830729: [pkg-go] Bug#830729: golang-github-mitchellh-go-homedir: FTBFS: homedir_test.go:44: "/home/lamby" != "~"

On 10 July 2016 at 13:30, Chris Lamb wrote: > go install -v github.com/mitchellh/go-homedir > github.com/mitchellh/go-homedir > debian/rules override_dh_auto_test > make[1]: Entering directory >

Bug#830656: [pkg-go] Bug#830656: Bug#830656: src:golang-github-docker-libnetwork: FTBFS due to libkv changes

On 9 July 2016 at 16:06, Dmitry Smirnov wrote: > Thank you very much, Tianon. :) > > Would you prefer if I upgrade libnetwork to v0.7.2-rc.1 ? Sure, that'd be great! This patch wasn't backported to 0.7.2 though, was it? (not seeing it in

Bug#830656: src:golang-github-docker-libnetwork: FTBFS due to libkv changes

Package: src:golang-github-docker-libnetwork Version: 0.7.0~rc.6+dfsg-2 Severity: serious The newest upload of "docker-libkv" changed the API slightly, causing the current libnetwork version to FTBFS. | # github.com/docker/libnetwork/datastore |

Bug#830519: [pkg-go] Bug#830519: docker-swarm: FTBFS: docker/swarm/api/flusher.go:8:2: cannot find package "github.com/docker/docker/pkg/ioutils"

On 8 July 2016 at 14:29, Chris Lamb wrote: > src/github.com/docker/swarm/api/flusher.go:8:2: cannot find package > "github.com/docker/docker/pkg/ioutils" in any of: This sounds like another case of #830478, which should've been fixed with src:docker.io 1.11.2~ds1-2 (uploaded

Bug#828089: [pkg-golang-devel] Bug#828089: consul fails to build on arm64 due to missing poll

reassign 828089 golang-golang-x-sys-dev thanks On 24 June 2016 at 14:00, Peter Michael Green wrote: > src/golang.org/x/sys/unix/zsyscall_linux_arm64.go:57: undefined: SYS_POLL "golang.org/x/sys" is a separate package now specifically to avoid the need to get a revbump on

Bug#822395: [pkg-go] Bug#822395: Bug#822395: Bug#822395: prometheus: FTBFS: cannot find package "golang.org/x/sys/unix"

On 26 April 2016 at 15:46, Michael Hudson-Doyle wrote: > Could/should dh_golang provide help for getting this right? It's kinda > similar to the work I did recently to make Built-Using more accurate > -- roughly speaking one needs the -dev package to Depend: on the >

Bug#821000: [PATCH] Restore setting of GOPATH during build removed by mistake in 1.14.

On Fri, 15 Apr 2016 09:46:34 +1200 Michael Hudson-Doyle wrote: > --- a/lib/Debian/Debhelper/Buildsystem/golang.pm > +++ b/lib/Debian/Debhelper/Buildsystem/golang.pm > @@ -161,6 +161,7 @@ sub get_targets { > sub build { > my $this = shift; > > +

Bug#816440: openjdk-9-jdk: file conflict jawt.h

On Tue, 1 Mar 2016 12:44:41 -0800 Joseph Ferguson wrote: > Here is the truncated output of "apt-get install openjdk-9-jdk": > Unpacking openjdk-9-jdk:amd64 (9~b107-1) ... > dpkg: error processing archive > /var/cache/apt/archives/openjdk-9-jdk_9~b107-1_amd64.deb (--unpack): >

Bug#818122: docker.io: FTBFS in stretch

On 26 March 2016 at 23:37, Dmitry Smirnov wrote: > Thank you. It would be awesome if you could have a look whether you can build > newer Docker. I think I've uploaded most if not all the dependencies it needs > but there seems to be a problem with versioning of docker-notary

Bug#818122: docker.io: FTBFS in stretch

On 26 March 2016 at 21:54, Dmitry Smirnov wrote: > However Docker still FTBFS for another reason unrelated to runc as far as I > can tell... It looks like an API change in the new runc (libcontainer bits):

Bug#818122: docker.io: FTBFS in stretch

On 26 March 2016 at 20:49, Tianon Gravi <tia...@debian.org> wrote: > Reassigning to the appropriate -dev package whose recent bump missed a > Depends entry. :) It looks like the fix is already in 0.0.8+dfsg-2 (at least in Git), too! :D ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E3

Bug#818122: docker.io: FTBFS in stretch

reassign 818122 golang-github-opencontainers-runc-dev 0.0.8+dfsg-1 retitle 818122 golang-github-opencontainers-runc-dev: missing "golang-github.com-docker-go-units" in Depends thanks On 13 March 2016 at 15:05, Santiago Vila wrote: >

Bug#818320: [pkg-go] Bug#818320: golang-golang-x-tools: FTBFS with go 1.6

On 15 March 2016 at 15:06, Michael Hudson-Doyle wrote: > (or you can approve my > request to join pkg-go on alioth :-p) You're long since approved by now! ;) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4

Bug#796400: [pkg-go] Bug#796400: Bug#796400: Bug#796400: golang-github-jacobsa-ratelimit: Non-determistically FTBFS due to unreliable timing in tests

On 18 February 2016 at 15:46, Tianon Gravi <tia...@debian.org> wrote: > Are there any other consumers of this ratelimit package that might warrant > some kind of workaround here? Seems the answer to that is "not currently in the archive, there aren't": ("dak r

Bug#796400: [pkg-go] Bug#796400: Bug#796400: Bug#796400: golang-github-jacobsa-ratelimit: Non-determistically FTBFS due to unreliable timing in tests

On 25 August 2015 at 10:21, Michael Stapelberg wrote: > I don’t think the intention of the test in question is to point out > performance regressions, so while I agree with your general statement > about flakyness in general, I’m not convinced it applies here. Is it worth

Bug#811142: hy3 no longer works, since Debian sid now defaults to python3.5

On 15 January 2016 at 17:39, Siat N wrote: > Since python3.5 recently became the default python3 in Debian sid, hy3 > no longer works. Running most hy3 commands, whether in the REPL or > calling a script, now leads to compiler errors. For example: Oh neat, this should be

Bug#810595: [pkg-golang-devel] Bug#810595: golang-go: missing Breaks on all the packages it Replaces

Control: tags -1 + pending On 10 January 2016 at 02:03, Andreas Beckmann wrote: > during a test with piuparts and DOSE tools I noticed your package causes > removal of files that also belong to another package. > This is caused by using Replaces without corresponding Breaks.

Bug#807113: [pkg-go] Bug#807113: golang-golang-x-net-dev and golang-golang-x-crypto-dev: error when trying to install together

On 5 December 2015 at 05:45, Ralf Treinen wrote: > 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: This whole mess was my fault. :( (See #807002 for

Bug#805725: docker.io is not installable. The post-installation-script does not work.

On 21 November 2015 at 06:11, Peter Schütt wrote: > time="2015-11-21T11:39:38.430675900+01:00" level=error msg="[graphdriver] > prior storage driver \"aufs\" failed: driver not supported" > Nov 21 11:39:38 peter64 docker[9379]: > time="2015-11-21T11:39:38.430781428+01:00"

Bug#804354: [pkg-go] Bug#804354: golang-testify: FTBFS: dh_auto_test: go test -v github.com/stretchr/ [..] returned exit code 1

On 7 November 2015 at 09:14, Chris Lamb wrote: > The full build log is attached or can be viewed here: > > > https://reproducible.debian.net/logs/unstable/amd64/golang-testify_1.0-1.build1.log.gz I can't seem to reproduce this exact failure locally, but I did notice that

Bug#803321: [pkg-go] Bug#803321: [Reproducible-builds] Bug#803321: rawdns: FTBFS: cp: cannot stat 'debian/tmp/debian/tmp/dh-exec.ShSIquIE/etc/rawdns.json': No such file or

On 28 October 2015 at 12:55, Niko Tyni wrote: > Looks like #802034, fixed today in dh-exec_0.22. Indeed! https://reproducible.debian.net/rb-pkg/unstable/amd64/rawdns.html appears happy now, so I'm going to close this. Thanks Chris for the heads up and thanks Niko for the

Bug#803136: docker.io: FTBFS

On 29 October 2015 at 06:27, Edmund Grimley Evans wrote: > docker.io build-depends on: > - arm64:golang-github-hashicorp-go-msgpack-dev (>= 0.0~git20140221~) > arm64:golang-github-hashicorp-go-msgpack-dev depends on: > - arm64:golang-gopkg-mgo.v2-dev >

Bug#803321: [pkg-go] Bug#803321: rawdns: FTBFS: cp: cannot stat 'debian/tmp/debian/tmp/dh-exec.ShSIquIE/etc/rawdns.json': No such file or

On 28 October 2015 at 12:08, Chris Lamb wrote: > rawdns fails to build from source in unstable/amd64: I just tested this in a fresh sbuild schroot and I can't seem to reproduce the failure (the package builds just fine here). Any ideas for how I could more easily reproduce the

Bug#803136: docker.io: FTBFS

On 27 October 2015 at 02:33, Edmund Grimley Evans wrote: > There is a different error in each case, unfortunately, and on an > up-to-date amd64 system there is a yet another, different error. Yeah, this is most definitely due to the Go 1.5.1 upload. Thanks for

Bug#803130: [pkg-go] Bug#803130: libdevel-cover-perl and golang-golang-x-tools: error when trying to install together

On 27 October 2015 at 01:28, Ralf Treinen wrote: > 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/bin/cover Doh -- I'll update golang-golang-x-tools to not

Bug#802945: golang-golang-x-tools conflict with golang-go

block 802945 802988 thanks Thanks for the reports and patches, Hilko and Russ! I've got the go-ahead from sECuRE to upload a fixed golang-golang-x-tools, so I'm going to take care of this conflict shortly. :) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4

Bug#801559: golang-github-sirupsen-logrus-dev: fails to upgrade from 'testing' - trying to overwrite /usr/share/gocode/src/github.com/Sirupsen/logrus/formatters/logstash/logstash_test.go

On Mon, 12 Oct 2015 07:00:24 +0200 Andreas Beckmann wrote: > It installed fine in 'testing', then the upgrade to 'sid' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. Doh, pretty sure I messed up the version number

Bug#802073: golang-logrus: FTBFS: TestUserSuppliedLevelFieldHasPrefix fails 1 != 1

fixed 802073 golang-logrus/0.8.7-1 thanks This was fixed in the latest upload! :D ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4

Bug#801558: [pkg-go] Bug#801558: Bug#801558: golang-codegangsta-cli-dev: fails to upgrade from 'testing' - trying to overwrite /usr/share/gocode/src/github.com/codegangsta/cli/command.go

On 12 October 2015 at 10:20, Tianon Gravi <admwig...@gmail.com> wrote: > | Replaces: golang-codegangsta-cli-dev (<< 0.0~git20150117-1~) > | Breaks: golang-codegangsta-cli-dev (<< 0.0~git20150117-1~) > | Provides: golang-codegangsta-cli-dev > > Are the version num

Bug#801558: [pkg-go] Bug#801558: golang-codegangsta-cli-dev: fails to upgrade from 'testing' - trying to overwrite /usr/share/gocode/src/github.com/codegangsta/cli/command.go

On 11 October 2015 at 21:56, Andreas Beckmann wrote: > It installed fine in 'testing', then the upgrade to 'sid' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. Hmm, this seems strange, because

  1   2   >